Terraform¶

Prerequisites: Infrastructure as Code — the concepts (declarative vs. imperative, idempotency, drift) this page assumes.

← Infrastructure as Code | Next: CI/CD →

Why This Exists¶

Infrastructure used to mean clicking buttons in a cloud console. The problem with that model isn't that it's slow — it's that the console has no diff. Nobody can tell you what changed, who changed it, or how to reproduce it in a second region. Terraform's entire value is turning infrastructure into a text file: reviewable in a pull request, diffable, and re-appliable.

The interview-relevant skill isn't HCL syntax. It's understanding state — the thing that makes Terraform dangerous when mishandled and powerful when respected.

The Core Workflow¶

flowchart LR
    W["Write HCL config"] --> I["terraform init<br/>(download providers, configure backend)"]
    I --> P["terraform plan<br/>(diff config vs state)"]
    P --> A["terraform apply<br/>(execute the diff)"]
    A --> S[("State file<br/>updated")]
    S -.feeds next diff.-> P

• init — downloads provider plugins, sets up the backend (where state lives). Run once per config change, safe to re-run.
• plan — a dry run. Read it like a code review: + create, ~ update in place, -/+ destroy-and-recreate. -/+ is the line that causes outages — it means the resource can't be updated, only replaced, which for a database means data loss unless you've planned for it.
• apply — executes the plan. Never apply without having read the plan output first; -auto-approve in a human's terminal is how "add a tag" becomes "recreate the load balancer."
• destroy — tears down everything Terraform manages in that state. One command, entire environment — treat it with the same caution as DROP DATABASE.

State: The Part That Actually Matters¶

The state file is Terraform's memory — a JSON record mapping your config's resource names to real-world resource IDs, plus every attribute Terraform knows about them. Lose it, and Terraform has no idea what it created; it will try to create everything again, colliding with resources that already exist.

Why this becomes a production incident: state files by default live on local disk. Two engineers running terraform apply from their own laptops each have their own local state file — the files themselves never touch or overwrite each other, since they're just separate files on separate machines. The actual damage happens against the real infrastructure, independently of the state files ever colliding: Engineer A applies, creates resource X, and their local state now reflects that. Engineer B's local state has no idea X exists — B's plan sees a gap between their (stale) state and their config, and apply can create a second copy of X, or, if B's config happened to reference the same resource name/identity, attempt to modify or destroy what A just created. Either way you end up with duplicated resources nobody has a single source of truth for, or one engineer's work getting silently clobbered by the other's apply — not because the state files overwrote each other, but because two independent, out-of-sync beliefs about reality both got to act on that same reality.

flowchart TB
    subgraph Wrong["Local state — the trap"]
        E1[Engineer A laptop] -->|apply| S1[(local state A)]
        E2[Engineer B laptop] -->|apply| S2[(local state B)]
        S1 -.conflicts with.-> S2
    end
    subgraph Right["Remote state — the fix"]
        E3[Engineer A] --> RS[(Remote backend: S3 with native locking,<br/>or legacy S3 + DynamoDB lock table)]
        E4[Engineer B] --> RS
        RS -->|lock held, B waits| E4
    end

The fix: a remote backend (S3, Terraform Cloud, GCS) that both centralizes the state file and provides locking — a second apply blocks while one is in flight, instead of racing it. Historically, S3-backed locking required a separate DynamoDB table (dynamodb_table in the backend config) to hold the lock, since S3 itself had no native compare-and-swap primitive. Terraform 1.10+ added native S3 locking using S3's own conditional-write support, so a DynamoDB table is no longer required for new S3 backends — treat the S3+DynamoDB pairing as the legacy pattern you'll still encounter in existing infrastructure, not the current recommended default for a fresh setup.

Variables, Outputs, and Modules¶

Variables parameterize a config so the same code runs against dev/staging/prod without copy-paste:

variable "instance_count" {
  type    = number
  default = 2
}

resource "aws_instance" "web" {
  count = var.instance_count
  # ...
}

Modules are reusable, versioned bundles of resources — think of them as functions for infrastructure. A vpc module that takes a CIDR block and returns subnet IDs means five teams stop hand-rolling five slightly-different, unaudited VPC configs:

module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

resource "aws_instance" "web" {
  subnet_id = module.vpc.public_subnet_ids[0]
}

Terraform builds a dependency graph from these references automatically — it knows aws_instance.web needs module.vpc to exist first, without you writing an explicit ordering.

Blast Radius and Workspaces¶

The single biggest design mistake in Terraform usage isn't syntax — it's one giant state file for the entire org. A typo in the networking module's plan now threatens to touch the database, the cache cluster, and the load balancer in the same apply, because they all live in one state.

Workspaces let one config target multiple environments with separate state, but they're not a substitute for splitting state by blast radius — a workspace-per-environment setup with one giant shared config still means every service in that environment shares a lock and a failure domain.

Drift¶

Drift is reality diverging from state — someone (or some other automation) changed a resource outside Terraform. terraform plan surfaces it as an unexpected diff on the next run; terraform apply will then either revert the manual change or, worse, attempt to reconcile in a way nobody predicted.

Trade-offs¶

Interview Questions¶

Key Takeaways¶

Previous: Infrastructure as Code | Next: CI/CD