Terraform consultant — infrastructure as code you can actually review.

Teams usually call me at one of two points: they have clicked their way to a working AWS account and now need it reproducible, or they have Terraform already and it has become something nobody wants to run on a Friday. The work differs, but both start with reading what exists rather than proposing a rewrite.

Almost every serious Terraform incident I have been called into traces back to state rather than to the resource code. It is worth being blunt about the failure modes.

Local state means one laptop is the source of truth for production. When that laptop is unavailable - or its owner has left - you are reconstructing reality by hand. Remote state in S3 with versioning is the fix, and versioning matters as much as remoteness because it is what lets you recover from a bad write.

No locking means two applies can run at once and interleave their writes. The result is state that describes an infrastructure that never existed. Locking is a small amount of configuration that removes an entire category of very bad day.

One giant state file is the most common structural mistake. Every plan touches everything, applies get slow, and the blast radius of a mistake is the whole estate. Splitting state along boundaries that already exist - per environment, per account, per bounded service - makes plans fast and failures local. The cost is wiring outputs between stacks, which is a fair trade.

Hand-edited state is where confidence gets lost. It is occasionally necessary, but it should be rare, deliberate, backed up first, and followed by a plan that proves the result is consistent.

Module design is where Terraform codebases either stay maintainable or quietly become worse than the console. A few principles I hold to.

Write modules for the pattern you have used at least twice. A module abstracted from a single use case encodes one team's assumptions as if they were universal, and the second consumer immediately needs an escape hatch. The result is a module with thirty variables that is harder to read than the resources it wraps.

Pin versions - provider versions, module versions, and the Terraform version itself. Unpinned dependencies mean your infrastructure changes when someone else publishes, which is the opposite of infrastructure as code. Pinning is what makes a plan from three months ago still mean something.

Keep the interface small and the defaults sensible. A module that requires twelve inputs to do the common thing will be copy-pasted instead of reused, and copies do not receive fixes.

Prefer boring composition over clever abstraction. Nested modules four layers deep are impressive until someone has to trace why a security group rule exists at three in the morning. Debuggability is a design requirement.

Terraform describes intent. Reality diverges from intent constantly - someone fixes something urgently in the console, a service updates a default, an autoscaling process changes a value. The question is not whether drift happens but whether you find out on your terms.

Scheduled drift detection - a plan run on a cadence that reports differences without applying them - turns drift from a surprise into a list. Most detected drift is benign, and the value is that the small proportion that is not gets seen while it is still small.

Policy as code is the other half. Checks that run in the pipeline - no unencrypted storage, no public access on data buckets, no security group open to the world on admin ports, mandatory tagging for cost allocation - catch the mistake at review time rather than at audit time. This matters more as AI-assisted code generation raises the volume of infrastructure changes: the review bottleneck moves, so the guardrails have to be automated rather than human.

Where this connects to compliance work: the same policy checks that stop a misconfiguration are also the evidence an auditor wants that misconfigurations are systematically prevented. Built once, they serve both. See DevOps and compliance and secure cloud landing zone for how that fits together, and Terraform vs CloudFormation if you are still choosing.