Terraform · Infrastructure as code

What are the most common Terraform mistakes in production?

MediummistakesreviewoperationsUpdated Oct 2026
Quiz this track

Short answer

Common failures include local or committed state, missing locking, unpinned providers, hand edits, oversized root modules and applying plans nobody reviewed. Most are process problems as much as syntax problems.

Terraform failures usually come from operational shortcuts rather than HCL syntax. The same handful of patterns appear in incidents: state is not shared, versions float, changes bypass review, or one configuration owns too much.

  • Committing terraform.tfstate or keeping it only on a laptop
  • Running CI without a remote backend or locking
  • Using latest provider versions and skipping the lock file
  • Editing cloud resources by hand and never reconciling drift
  • Using count for named collections and causing index churn
  • Putting every environment and service in one root module
  • Applying an unreviewed plan with -auto-approve
  • Storing secrets in variables that end up in state
hcl
terraform {
  backend "s3" {
    bucket       = "acme-tfstate"
    key          = "prod/app/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true
  }
}
A remote, encrypted backend with locking removes several of the most common failure modes at once.

Prevention is mostly process: a pull request template that asks for the plan, CI that runs fmt, validate, policy and plan, protected environments for production, and a clear state ownership model. Reviewers should look for replacements, IAM changes and resource deletions, not just whether the pipeline is green.

A green apply is not proof of a safe change. It only means Terraform completed the actions in the plan; the plan itself may have been wrong.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Which mistake causes the most damaging incidents?
  2. 2How do you catch a dangerous plan in review?
  3. 3Why is count a common source of churn?
  4. 4How do you stop hand edits from accumulating?

Say it in the interview

The recurring mistakes are operational: local or committed state, no locking, floating versions, hand edits, oversized root modules and unreviewed applies. I fix those with a remote encrypted backend, pinned versions, small state boundaries and a pipeline where the plan is the review artifact. A green apply only means Terraform did what the plan said, so reviewers still have to check replacements, IAM and deletions.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Terraform mock interview and get scored feedback on depth, clarity and confidence.