§ how it works · terraform
Each card below is a step-by-step SVG visualization of one Terraform concept. What happens to your HCL, your state file, and the real cloud at each step of plan, apply, and destroy. Good for the "it works but I don't get why" moments.
These are drawn diagrams, not a sandbox. To get hands-on, go to the lessons on LocalStack.
workflow · 6 steps
What Terraform does on each command. The three sources of truth (HCL, state, the cloud), how they line up and drift apart, and why apply without plan is a bad habit.
workflow · 6 steps
How Terraform learns the order to create resources in. The graph built from implicit refs, parallel "layers", and why destroy runs in exactly the reverse direction.
state · 6 steps
What lives inside the state file, why serial and lineage are there, and why a password from HCL ends up as plain text in it. The full JSON, layer by layer.
state · 6 steps
Someone changed a tag in the AWS Console, and Terraform suddenly shows changes. What drift is, why it happens, and three ways to live with it.
state · 5 steps
S3 stores the state, DynamoDB holds the lock. What happens when two people run apply at the same time, and why a "team of one" is the only case where you can live without this.
state · 6 steps
What terraform plan actually compares. Why it refreshes, how three sources become one plan, and what -refresh=false hides.
state · 5 steps
Three commands that edit the state file directly: rename an entry, forget a resource, pull an existing one in from the cloud. What they change, what they leave alone, and where they bite.
state · 5 steps
Declarative blocks for renaming, dropping, and pulling in resources. What they give you beyond the CLI, which Terraform versions added them, and why they live in git.
resources · 5 steps
Two ways to create N identical resources. One indexes by number, the other by key. Deleting the middle of the array produces completely different plans.
resources · 6 steps
create_before_destroy for zero-downtime, prevent_destroy for the critical stuff, ignore_changes for drift, replace_triggered_by for cascading rebuilds. What each one does in practice.
variables · 6 steps
Six value sources for one variable, lined up in a queue. Which one overrides which, and why your .tfvars sometimes "doesn't apply."
modules · 6 steps
What happens at the root → child module boundary: input through variable, output through output, and why a module stays reusable only if it does not reach for global providers.
cicd · 6 steps
Save tfplan to a file, show it to a human, apply exactly that file, and stop a different diff from sneaking through by accident. The canonical CI pattern for Terraform.
cicd · 6 steps
The workflow gets a short JWT from GitHub, exchanges it for temporary STS creds, runs Terraform, and an hour later all of it just disappears. No access-key secrets.
cicd · 6 steps
An engine sits between the plan and apply steps: Checkov, OPA, or Sentinel. It reads plan.json and decides whether the change can be applied. A bucket with no encryption simply will not pass.