cloud1-11 gave Infrastructure as Code a first look — declarative vs. imperative, Terraform named as the cross-provider option, plan/apply and configuration drift introduced at a conceptual level. This course goes deep specifically on Terraform itself: not IaC in general, but this one tool, in real depth.

The Configuration Drift Problem

A server gets provisioned by hand through a cloud console. Six months later, nobody fully remembers which settings were changed, when, or why — a firewall rule added during an incident, a instance size bumped up "temporarily" during a traffic spike and never reverted. Staging quietly stops matching production. This is configuration drift, and it's the exact problem cloud1-11 named but didn't solve: infrastructure that exists only in a console, with no record of its own history, and no reliable way to reproduce it.

Declarative vs. Imperative Infrastructure

An imperative script says exactly what steps to run, in order: "create a VM, then attach a disk, then open port 443." Run it twice and it may fail the second time (the VM already exists) or duplicate resources. A declarative tool like Terraform instead says what the end state should look like — "there should be one VM, with this disk, with this port open" — and lets Terraform figure out what actions are needed to get there, including doing nothing if reality already matches.

That block doesn't say "run these commands" — it says "this instance should exist, with these properties." Terraform compares that declared intent against what's actually running and works out the difference itself.

Terraform vs. the Cloud-Native Alternatives

Each cloud-native tool is genuinely well-integrated with its own provider — but locked to it. Terraform's core value, especially relevant given cloud1-2's own cross-provider terminology map, is expressing infrastructure across providers (or a multi-cloud environment) using one consistent language and workflow.

Terraform vs. Ansible — Two Different Jobs

Terraform provisions infrastructure — it creates the VM, the network, the database instance. It has no concept of "log in and install a package." Ansible configures infrastructure that already exists — installing software, editing config files, restarting services, on machines Terraform (or something else) has already brought into being. They're complementary, not competing: a real pipeline commonly runs Terraform first to create the servers, then Ansible to configure them.

The Terraform Workflow: Write → Plan → Apply → Destroy

• Write — describe desired infrastructure in .tf configuration files
• Plan — Terraform compares desired state against actual state and shows exactly what it intends to change, before touching anything
• Apply — Terraform executes that plan, creating/updating/deleting only what's needed
• Destroy — Terraform tears down everything it manages, cleanly, in dependency order

The plan step is the single biggest practical difference from clicking through a console: you see the change before it happens, every time.

When Terraform Fits — and When It Doesn't

A one-off resource for quick local testing, or a genuinely single, tiny, rarely-touched environment, often isn't worth the ceremony. Terraform earns its keep once infrastructure needs to be reproducible, reviewed by a team, or exist in more than one environment (dev/staging/prod) — exactly the scenarios where console-driven drift becomes a real, recurring problem.

Hands-On Exercises

Chapter 1's resource block was a preview. This chapter installs the real CLI and runs an actual configuration end to end — deliberately using a provider that needs no cloud account or credentials, so the workflow itself is the entire focus.

Installing Terraform

Terraform ships as a single binary — download it from HashiCorp's releases, or install via a package manager (brew install terraform on macOS, choco install terraform on Windows, or an apt/dnf repository on Linux). Verify the install:

The terraform and provider Blocks

Every configuration starts with a terraform block declaring which providers it needs, and a provider block configuring one of them. A provider is a plugin that knows how to talk to a specific system — AWS, Azure, a local filesystem, even things like GitHub or Cloudflare all have providers.

terraform init

init reads the required_providers block, downloads the matching provider plugin(s) into a local .terraform/ directory, and initializes the backend (by default, a plain local state file — remote backends are Chapter 6's own topic).

The Dependency Lock File

init also writes .terraform.lock.hcl, recording the exact provider version and checksum actually installed. This is the same idea as node1-2's package-lock.json or ruby2-7's Gemfile.lock: it guarantees everyone running init against this configuration gets the identical provider build, not just "something matching the version constraint."

• Commit .terraform.lock.hcl to git — it's what makes provider versions reproducible across machines and teammates
• Never commit .terraform/ — it's a local download cache, regenerated by init on any machine, exactly like node_modules/ or a Rust target/ directory

Provider Version Pinning

The version = "~> 2.5" constraint means "any 2.5.x release, but not 2.6.0 or higher." Pinning matters for the same reason the lock file does — an un-pinned provider could silently pick up a newer version with different behavior, producing configuration drift of its own, this time in the tool itself rather than the infrastructure it manages.

The resource Block In Depth

A resource has the shape resource "<type>" "<local name>" { ... }. The type (local_file) is defined by the provider; the local name (hello) is how this configuration refers to it. Together they form a unique resource address, local_file.hello, used throughout the rest of the configuration and in CLI commands.

terraform plan

Run plan before ever applying — it shows exactly what will change, using + for create, - for destroy, and ~ for update-in-place.

terraform apply

apply re-runs the same plan and, after an interactive confirmation, executes it.

hello.txt now exists on disk. Run terraform plan again with nothing changed, and it reports "No changes" — the same idempotency property from Chapter 1's Exercise 1, now demonstrated for real.

terraform destroy

Tears down everything this configuration manages, in dependency order, after its own interactive confirmation.

Hands-On Exercises

Chapter 2 wrote one resource in isolation. Real infrastructure is many resources referencing each other — this chapter covers how HCL expresses those relationships, and the meta-arguments that control how resources are created.

HCL Syntax Building Blocks

A block has a type, zero or more labels, and a body of arguments: resource "type" "name" { key = value }. Values can be strings, numbers, booleans, lists (["a", "b"]), or maps ({ key = "value" }). String interpolation embeds an expression inside a string with ${...}, and comments use # or /* */.

Data Sources

A resource block creates and manages something. A data block only reads something that already exists — infrastructure this configuration doesn't own, like a shared VPC created elsewhere, or the latest AMI ID published by a cloud provider.

The Implicit Dependency Graph

data.aws_ami.ubuntu.id above is a reference — and referencing one resource's attribute from inside another is exactly what tells Terraform "create/read this one first." Terraform builds this into a full dependency graph (a DAG) automatically, from every reference in the configuration, and applies resources in the correct order — running independent resources in parallel where nothing connects them. File order never matters — only the actual references do.

count

Creates multiple copies of a resource from a single block, indexed numerically via count.index.

Resource addresses become local_file.server_config[0], [1], [2].

for_each

Creates multiple copies keyed by a map or set of strings, via each.key/each.value — the modern default for anything beyond a fixed, never-changing count.

Resource addresses become local_file.server_config["web"], ["api"], ["worker"] — keyed by a stable name, not a position.

depends_on

For the rare case where one resource genuinely depends on another but no attribute reference exists to express it (e.g. IAM permission propagation delays), depends_on states the dependency explicitly. Used sparingly — an implicit reference is almost always preferable when one is available, since it stays correct even if the configuration is later refactored.

The lifecycle Block

A meta-argument block controlling special-case behavior for how a resource is created, updated, or destroyed:

• create_before_destroy — builds the replacement before tearing down the original, avoiding downtime on a forced replacement
• prevent_destroy — makes terraform destroy (or a plan that would destroy this resource) fail outright, a safety rail for genuinely critical resources
• ignore_changes — tells Terraform to stop reporting drift on specific attributes, e.g. tags a separate system updates automatically

Hands-On Exercises

Every value so far has been hardcoded directly into a resource block. Real configurations need to be parameterized — the same configuration deployed to dev, staging, and prod, with only a handful of values actually differing between them.

Input Variables

A variable block declares a named input, with an optional type, default, and description. Reference it anywhere in the configuration with var.<name>.

Omitting default makes the variable required — Terraform refuses to plan until a value is supplied, useful for forcing an explicit choice (like an environment name) rather than silently falling back to a guess.

Variable Validation

A validation block rejects bad input at plan time, before anything is ever created — cheaper than discovering the mistake mid-apply.

Sensitive Variables

Marking a variable sensitive = true redacts its value from CLI plan/apply output — Terraform prints (sensitive value) instead of the real string.

Locals

A locals block defines internal computed values — not inputs, just names for expressions used more than once. Unlike variables, locals aren't set from outside the configuration; they exist purely to avoid repeating the same expression.

.tfvars Files

Instead of typing -var flags on every run, values can live in a .tfvars file. terraform.tfvars and any *.auto.tfvars file load automatically; anything else needs an explicit -var-file flag — the pattern Chapter 8's workspaces build on for genuinely separate dev.tfvars/prod.tfvars files per environment.

Variable Precedence Order

Lowest to highest priority — later sources override earlier ones:

1. Environment variables (TF_VAR_name)
2. terraform.tfvars, if present
3. terraform.tfvars.json, if present
4. Any *.auto.tfvars/*.auto.tfvars.json files, in alphabetical order
5. -var and -var-file command-line flags, in the order given — always win

Hands-On Exercises

Chapter 4's warn-box left a thread open: state stores real secret values in plaintext. This chapter explains what state actually is, why Terraform can't function without it, and what that means for how it must be handled.

What State Is & Why Terraform Needs It

Every apply writes terraform.tfstate — a JSON file mapping every resource address (local_file.hello) to the real-world object it created and every attribute that object actually has. Without it, Terraform would have no way to distinguish "a resource this configuration already created" from "a resource with the same name that happens to exist for some other reason" — every plan would risk creating duplicates rather than recognizing something as already satisfied. State is the literal record that makes the desired-vs-actual comparison from Chapter 1 possible at all.

Local State

By default, state lives as a plain file on local disk — fine for solo experimentation, but it means only one machine has any record of what Terraform manages. Anyone else running apply against the same configuration, from a different machine, has no shared state to compare against.

Remote State — A Preview

Local state has two problems at once: secrets sitting in a file that's tempting to accidentally commit, and no shared record for a team. Chapter 6 covers remote backends in full — storing state in a shared, access-controlled location instead of on one person's disk, solving both problems together.

terraform state Commands

Inspecting and safely modifying state without hand-editing the file:

state mv renames a resource in state without destroying and recreating the real object — Terraform otherwise treats a renamed block exactly like Chapter 3's addressing rules imply: a different address means a different resource, and a different resource means destroy-then-create.

Drift Detection, In Full

cloud1-11 introduced drift conceptually. Here's the actual mechanism: terraform plan performs a three-way comparison — the desired configuration (the .tf files), the last-known state (what Terraform believes exists), and a fresh refresh against the real infrastructure itself. If a manual console change altered something Terraform manages, the refresh step detects that the real world no longer matches state, and plan reports it — exactly the "manual fix gets silently reverted by the next automated apply" scenario cloud1-11 warned about.

Automatic Backups

Every state-modifying command writes terraform.tfstate.backup before making its change — a single-generation safety net if a state operation goes wrong.

Hands-On Exercises

Chapter 5 flagged two problems with local state: secrets sitting in a file tempting to accidentally commit, and no shared record for a team. Remote backends solve both.

Why Local State Breaks With a Team

A second teammate cloning the repository has zero record of what the first person's apply already created — their local terraform.tfstate simply doesn't exist yet. Worse, if two people do somehow share a state file and both run apply at nearly the same time, each reads the same starting state, computes a plan against it, and both try to write an updated state back afterward — whichever write happens last silently overwrites the other, potentially losing track of resources the first apply just created.

Remote Backends

A backend block inside terraform {} moves state storage off local disk entirely, into a shared, access-controlled location every team member and CI runner reads from and writes to.

The S3 + DynamoDB Backend

The classic AWS pattern: an S3 bucket holds the state file itself (with encrypt = true for encryption at rest — the same principle dbsec1-5/crypto1-5/6 already covered), and a DynamoDB table provides locking. Every teammate and CI job reads/writes the exact same object in S3, so there's genuinely one shared source of truth instead of N different local copies.

State Locking

Before writing to state, Terraform first acquires a lock — a conditional write to the DynamoDB table that only succeeds if no lock currently exists. If someone else's apply already holds the lock, Terraform blocks with a clear error rather than racing to write state at the same time:

This is exactly what prevents the concurrent-write corruption described above — only one apply can ever be mid-flight against a given piece of state at a time.

Terraform Cloud / HCP Terraform

A managed alternative to hand-rolling S3+DynamoDB — built-in state storage, locking, a web UI, and run history, with no separate bucket or lock table to provision yourself. Genuinely the "batteries included" option, at the cost of depending on a hosted service rather than infrastructure the team fully owns.

Backend Migration

Switching from local state to a remote backend (or between two remote backends) isn't automatic — it requires an explicit migration:

After migrating, every teammate needs to re-run terraform init themselves — their local Terraform still points at the old backend configuration until they do.

Hands-On Exercises

Everything so far has lived in a single, flat set of files. Real infrastructure repeats the same shapes — a web server, a VPC, a database tier — over and over, across environments and projects. Modules package a shape once and reuse it.

What a Module Is

Any directory of .tf files is a module. Whichever one terraform commands are run from is the root module — every configuration in this course so far has technically already been one, just never explicitly calling any others.

Child Modules

A module block calls another module from the root (or from another module), passing inputs as arguments matching that module's own declared variables, and reading its declared outputs back.

Module Structure & Composition

A module's own directory follows the same variables.tf/main.tf/outputs.tf convention as any configuration — inputs come in through its variable blocks, results go out through its output blocks. Everything else inside stays private to the module; the caller never sees its internal resource names.

The Public Terraform Registry

registry.terraform.io hosts community and vendor-maintained modules — a well-tested VPC module, for instance, covers subnet layout, route tables, NAT gateways, and dozens of edge cases a first attempt at writing one from scratch would likely miss.

Module Versioning

Registry modules use the same ~> version-constraint syntax as providers (Chapter 2) — pinning a module version protects against an upstream update introducing a breaking change without warning, exactly the same reproducibility guarantee the provider lock file already provides.

DRY Infrastructure

Module blocks accept for_each and count too — calling the same module multiple times with different inputs, rather than copy-pasting a resource shape once per environment.

Hands-On Exercises

Chapter 4's .tfvars files and Chapter 7's for_each-over-a-module both hinted at multiple environments. This chapter names the real options directly, and the tradeoffs between them.

The Multi-Environment Problem

Dev, staging, and prod are almost always the same infrastructure shape with different values — smaller instance sizes in dev, different domain names, different scaling targets. The question is how to run one configuration against three genuinely separate sets of real infrastructure without copy-pasting the whole thing three times.

Terraform Workspaces

A workspace gives each named environment its own state file, within the same backend and configuration. terraform.workspace is available inside the configuration itself to vary behavior by environment.

Workspaces vs. Separate State Keys

An alternative to workspace commands entirely: give each environment its own backend key (Chapter 6's S3 key argument) via -backend-config, with no terraform workspace involved. Functionally similar — separate state per environment — but explicit at the backend-configuration level rather than an in-CLI selection that's easy to forget you've made.

Workspaces vs. Separate Directories

The strongest-isolation option: a genuinely separate directory (and root module) per environment — environments/dev/, environments/prod/ — each with its own main.tf calling the same shared modules from Chapter 7's registry pattern, but with entirely separate state, separate backend configuration, and often separate provider credentials.

The Workspace-Isn't-a-Full-Isolation-Boundary Gotcha

Workspaces separate state — nothing else. The configuration, the backend, and the provider credentials are all shared across every workspace. Selecting the wrong workspace by mistake — intending dev but currently sitting in prod — still runs apply against real production infrastructure, using real production credentials, because nothing in the setup itself enforces which workspace "should" be safe to touch right now.

Hands-On Exercises

Every prior chapter assumed clean, fully-managed resources. Real infrastructure has messier edges — a one-time bootstrap step with no native equivalent, or a resource that already existed before Terraform ever touched it. This chapter covers the deliberate escape hatches for exactly those cases.

Provisioners — local-exec and remote-exec

A provisioner block runs a command as a side effect of a resource's creation — local-exec on the machine running Terraform itself, remote-exec on the resource that was just created, via SSH or WinRM.

Why Provisioners Are Discouraged

A provisioner's command is imperative code embedded inside a declarative resource — the exact split Chapter 1 opened with. Terraform has no visibility into what that script actually did, can't record its effect in state, and can't detect or reconcile drift on it the way it can for a real resource attribute. HashiCorp's own guidance is to treat provisioners as a last resort — and per Chapter 1's Terraform-vs-Ansible distinction, using remote-exec to configure a server is arguably doing Ansible's job from inside Terraform, the exact mixing of responsibilities Chapter 1's warn-box already cautioned against.

When Provisioners Are Still Justified

A genuinely one-time bootstrap action with no native resource or provider API equivalent, or triggering an external signal/webhook right after creation. Not a substitute for real configuration management — if the goal is installing and maintaining software on a server, that's still Ansible's job.

Importing Existing Infrastructure

terraform import brings a resource created outside Terraform — by hand in a console, or by another tool — under Terraform's management, without destroying and recreating it.

The Import Workflow in Practice

1. Write a resource block matching the real object as closely as possible
2. Run terraform import <address> <real-world-id>
3. Run terraform plan — any remaining mismatch shows up as a planned change
4. Adjust the resource block, repeat step 3, until plan reports no changes

Newer Terraform versions (1.5+) support a declarative import block plus config generation, letting Terraform draft the resource block for you — a materially easier modern alternative to hand-writing it from scratch, though the underlying iterate-until-plan-shows-nothing workflow is unchanged.

Resolving cloud1-11's Own Gotcha

cloud1-11 warned that a manual console fix gets silently reverted by the next automated apply. Now the real fix: if a manual change genuinely needs to persist, either (a) update the .tf configuration itself to match the new reality, so the next plan shows no diff, or (b) if the resource was created entirely outside Terraform, bring it under management with import first. Re-running apply repeatedly and hoping the drift stops happening is never a real fix — Terraform will keep reverting toward whatever the configuration says, every single time, until the configuration itself changes.

Hands-On Exercises

Every command so far has been run by hand. A real team runs Terraform through CI — this chapter ties the whole workflow together using pipelines1's own material, applied specifically to infrastructure changes.

terraform fmt & validate

fmt rewrites files into Terraform's canonical style; fmt -check exits non-zero without changing anything, suitable for a CI gate. validate catches syntax and type errors — without touching real infrastructure or needing full provider credentials, just an initialized backend.

The Plan-as-PR-Comment Pattern

A CI job runs terraform plan on every pull request and posts the output as a comment directly on that PR — reviewers see exactly what would change in real infrastructure before ever approving the merge, not just the raw .tf diff. A one-line variable change can produce a plan that recreates a dozen resources; the diff alone would never show that.

A Real GitHub Actions Workflow

Following pipelines1-3's workflow-YAML pattern and pipelines1-6's job-dependency gating:

Policy as Code

Automated rules that block a plan from ever being applied if it violates a defined policy — "no public S3 buckets," "no unencrypted volumes," enforced mechanically rather than relying on a reviewer noticing. Sentinel is HashiCorp's own policy engine (Terraform Cloud/Enterprise); OPA (via conftest) is the open-source alternative usable in any CI pipeline. Both directly enforce the security practices dbsec1/crypto1/owasp1 already covered — the difference is these rules run automatically on every plan, not just when a reviewer happens to remember to check.

terraform test & Terratest

Terraform's native testing framework (1.6+) uses .tftest.hcl files with run blocks and assert conditions, and can execute against mocked providers — fast, free tests with no real infrastructure spun up. Terratest (a third-party, Go-based library, older and still widely used) takes the opposite approach: it actually provisions real infrastructure to test against, then tears it down — slower and billable, but validates genuinely real provider behavior rather than a mock's approximation of it.

Bringing It Together — the Full CI/CD Gate

fmt/validate → test → plan + policy check → human review of the posted plan comment → merge → apply. The same test → build → staging → production chain pipelines1-9's own capstone assembled for application code, applied here to infrastructure changes instead.

Hands-On Exercises

Ten chapters, one piece at a time. This closing chapter combines every one of them into a single, realistic three-tier environment — a VPC, a compute tier, and a database — built and deployed the way a real team actually would.

The Target Environment

A VPC with public and private subnets, a web tier running in the public subnets, and a database in the private subnets — a genuinely common shape, deliberately chosen so every chapter's own technique has a real place to be applied.

Step 1 — Remote Backend & Locking

Configured first, before anything else exists: Chapter 6's S3+DynamoDB backend, so state is safely shared and locked from the very first apply onward — never starting on local state and migrating later.

Step 2 — The VPC via a Registry Module

Chapter 7: the VPC itself is a vetted community module, not hand-written — its subnet layout, route tables, and NAT gateways already cover edge cases a first attempt wouldn't.

Step 3 — Variables & Environment-Specific Values

Chapter 4: instance_count, an environment variable with validation, and a sensitive db_password — with Chapter 5's own honest caveat still true: sensitive hides CLI output, the encrypted backend from Step 1 is what actually protects the value at rest.

Step 4 — The Compute Tier With for_each

Chapter 3: web servers created with for_each over a stable set of names, referencing the VPC module's own subnet-ID outputs — the dependency graph resolving automatically, exactly as Chapter 3 first demonstrated with a data source.

Step 5 — The Database Tier With lifecycle Protection

Chapter 3's own Exercise 3 scenario, applied for real: the database gets prevent_destroy = true — a deliberate safeguard against exactly the accidental-destroy risk that exercise walked through.

Step 6 — Environments: Separate Directories, Not Workspaces

Chapter 8 concluded that workspaces alone aren't a strong enough boundary for a genuinely high-stakes production environment — this capstone deliberately follows that conclusion, using separate environments/dev/ and environments/prod/ directories, each with its own backend key and credentials, rather than terraform workspace select.

Step 7 — Handling a Pre-Existing Resource

The DNS record for this environment was created by hand, before this project existed. Chapter 9's two-step import workflow brings it under management: write the matching resource block, run terraform import, then iterate against plan until it reports no changes.

Step 8 — The CI/CD Gate

Chapter 10's full pipeline wraps the whole thing: fmt/validate → terraform test → plan posted as a PR comment, gated by a policy-as-code check → human review → merge → apply, running only from the reviewed main branch.

The Full Picture

What's Still Out of Scope, Honestly

This capstone provisions infrastructure — it deliberately does not configure servers or install software, exactly the Terraform-vs-Ansible boundary Chapter 1 drew from the very first page; that's still a genuinely separate, still-outstanding piece of this site's own bucket list. Multi-region disaster recovery, cost optimization at real scale (cloud1-9/cloud2-7), and a dedicated secrets manager beyond an encrypted backend are all real next steps a production system would eventually need, named honestly rather than treated as solved here.

Closing the Course

From Chapter 1's configuration-drift problem to a real, CI-gated, multi-resource environment — every chapter in between solved one specific, genuine piece of that original problem. State, locking, modules, environments, import, and automated review together are what actually make infrastructure reproducible, reviewable, and safe to change — not any single command on its own.

Hands-On Exercises