infrastructure-as-code

Infrastructure as Code

The value of IaC isn't that it's faster than clicking through a console — it's that the configuration file is the single source of truth, and anyone can read it to know what the system actually is without logging into anything. The moment someone makes a change out of band, that promise breaks, and every plan after it lies a little.

Terraform is the default lens here because it's the common ground across clouds, but the discipline applies equally to CloudFormation, Pulumi, or Bicep.

If the state of the system can't be reconstructed by reading the repo, it isn't infrastructure as code — it's infrastructure with extra steps.

For Terraform specifics — plan symbols, state operations, backends, forced replacement, and drift detection — read references/terraform.md.

1. Read every plan before you apply it

terraform plan exists so nobody has to trust their own diff — read the actual output, every time, even for changes that feel trivial. The plan is the one place a typo becomes visible before it becomes an incident: a renamed resource that Terraform reads as destroy-then-create, a provider default that shifted, a variable that resolved to something unexpected.

• Look for destroy and replace, not just create — those are the operations with a blast radius, and they hide easily in a long plan.
• Treat "no changes" as a result to verify, not skip — if you expected a change and got none, something upstream is wrong.
• Never apply a plan you didn't personally read, even in CI — a human or a policy gate (see policy-as-code) should see the diff before it lands.

Done when: the plan output for every production apply is attached to its approval record, so what was approved can be compared against what was applied.

2. Protect state like it's a production database, because it is

Terraform state is the map between your configuration and real-world resource IDs. Lose it, and you haven't lost a file — you've lost the ability to manage anything without manual reconciliation. Corrupt it with a concurrent write, and two applies can fight over the same resource.