Infrastructure as code

Infrastructure as code only pays off if people trust it enough to use it. Plenty of teams have a Terraform repository and still make changes in the console, because the code is frightening to run.

Modules worth reusing

The common failure is copy-paste: a working configuration duplicated across environments, then edited in one place and not the others. Six months later staging and production differ in ways nobody can enumerate.

We build composable modules with sensible defaults, so a new environment is a small amount of configuration rather than a fork of an existing one. Modules are versioned and tested, so upgrading is deliberate rather than accidental.

State, handled properly

State is where Terraform hurts. Remote backends with locking, separated per environment so a staging mistake cannot damage production, and a clear convention for what belongs in which state file. We keep blast radius small - one state file for an entire estate means every change risks everything.

Reviews that mean something

Plan output runs automatically on pull requests and posts as a comment, so a reviewer sees exactly what will change before approval. Policy checks run alongside - encryption required, public access denied, approved regions, tagging enforced - as testable rules rather than documented conventions.

Drift is the quiet failure

Code only tells the truth if reality matches it. Someone makes an emergency console change at 2am, it works, it is never written back, and six months later a routine apply reverts it and takes production down.

We deploy continuous drift detection that compares declared state against live state and surfaces divergence as an alert. Where reconciliation is safe we automate it; where it is not, the alert routes to a human with the exact diff.

For configuration inside instances, Ansible roles bring hardening in line with benchmarks and keep it there, with the same review and versioning discipline as application code.