I've reviewed Terraform codebases across 4 organisations now. The pattern is always the same: it starts clean, then someone adds "just one more resource," and 6 months later you have a 2,000-line main.tf that nobody wants to touch.
Here's why it happens and how to fix it.
Microsoft's Cloud Adoption Framework gives you a beautiful diagram of Azure Landing Zones. Neat boxes, clean lines, management groups in perfect hierarchy. What it doesn't tell you is how much pain lies between that diagram and reality.
Here's what I learned implementing landing zones for enterprise workloads.
"We apply the same engineering practices to our Terraform as we do to our application code."
This sounds responsible. It's also why your infrastructure deployments take 3 weeks to get through code review.
Infrastructure as Code is code, yes. But it's a fundamentally different KIND of code. Treating it identically to application code creates more problems than it solves.
Terraform state is both the most important and most dangerous file in your infrastructure. It's the source of truth for what Terraform manages. Lose it, corrupt it, or let two people modify it simultaneously, and you're in for a very bad day.
Here are the lessons I learned — some of them the hard way.
We test application code religiously. Unit tests, integration tests, E2E tests. CI won't pass without 80% coverage.
Infrastructure code? "Just run terraform plan and eyeball it."
That inconsistency is where production incidents are born.
Your infrastructure was deployed with Terraform. It's version-controlled. It's reviewed. It's compliant.
Then someone SSH'd into a server and changed a config file. Someone used the Azure portal to add a firewall rule. Someone ran kubectl edit to patch a deployment in production.
Now your Terraform state says one thing. Reality says another. That gap is configuration drift — and it's the silent killer of reliable infrastructure.