Terraform
Terraform best practices I keep coming back to
Terraform is powerful because it makes infrastructure reviewable. The same power can become risky when state, modules, and ownership are unclear. These are the practices I keep returning to because they make infrastructure easier to reason about.
Keep state boring
Remote state, locking, clear workspace boundaries, and predictable naming are basic, but they matter. Most painful Terraform problems begin when state ownership is unclear or when too many unrelated resources live in one state file.
Build modules around real reuse
A module should hide meaningful complexity, not every line of configuration. I prefer small modules with explicit inputs, sensible defaults, and outputs that support the next layer. When a module becomes a second programming language, it is probably doing too much.
Review plans like production changes
A Terraform plan is not a formality. It is the change record. Plans should be readable in CI, reviewed before apply, and checked for destructive actions, IAM drift, unexpected recreation, and cost impact.
Separate environments carefully
Development, staging, and production should be similar enough to catch issues but separate enough to reduce blast radius. Environment differences should be intentional and visible.
Document the contract
Good Terraform repositories explain ownership, prerequisites, how to plan, how to apply, where state lives, and how rollbacks or emergency changes work. Documentation is part of the infrastructure.