Terraform practices for infrastructure teams

Treat infrastructure changes as production changes

Terraform makes infrastructure declarative, but a reviewed file can still delete a database or widen public access. Plans need the same attention as application deployments: clear ownership, automated checks, peer review and a tested recovery path.

Pin Terraform and provider versions, commit dependency locks and upgrade intentionally. Reproducibility is a safety property.

Design modules with a clear purpose

A module should express a stable organisational capability, not wrap every provider resource. Prefer a small interface with safe defaults and useful outputs. Avoid deeply nested modules whose effects are difficult to trace in a plan.

Version shared modules and publish migration notes. Product teams need time to adopt changes without every environment moving at once.

Separate state by ownership and blast radius

One global state file creates contention and gives every change an enormous failure radius. Split state along boundaries that can be deployed and recovered independently, such as an application environment or shared network layer. Do not split so finely that ordinary changes require a maze of remote-state dependencies.

Use encrypted remote state, locking and tightly scoped access. State can contain sensitive values even when configuration files do not.

Build a predictable workflow

Run formatting, validation, security checks and plans in CI. Apply an approved saved plan rather than generating a different plan later. Restrict direct local applies to documented emergencies and record what changed.

Detect drift, but investigate before automatically overwriting it. Drift may indicate an incident response, an unmanaged process or a mistaken ownership boundary.

Frequently asked questions