Shipping Terraform IaC without fear

Infrastructure as code stops being scary the day the plan becomes boring. Most teams never get there, not because the tooling is hard, but because they treat "the plan looks fine" as a review instead of treating it as the artifact.

Start with state discipline

If you cannot explain where your state file lives, who can write to it, and what happens when two people run apply at the same time, nothing else matters. Locking is not a nice-to-have; it is the difference between a config change and a configuration incident. State should be remote, versioned, and locked, and the plan should say so.

Review the plan, not the diff

A Terraform diff shows you what changed in the code. The plan shows you what changes in the world. Review the plan. A one-line code change that destroys a database is invisible in the diff and loud in the plan. Make the plan the review artifact, and make -detailed-exitcode part of CI so a no-op change cannot slip through as a success.

Make destruction deliberate

Every destructive operation should feel like it needs a second signature. prevent_destroy on data, explicit lifecycle rules where it is honest, and a lint rule that greps for force destroy in the review checklist. Boring infrastructure is infrastructure that has to work to break itself.

The habit that compounds

Keep a short "what did I break this week" note. Not a post-mortem — a one-paragraph log. After a few weeks you will notice the same class of mistake showing up, and that is the exact moment your infrastructure becomes boring: when the failure modes are known, named, and reviewed for.