🧱 Terraform — 20 Advanced Interview Questions (Detailed Answers)
✅ Q1 — How does Terraform build and use the dependency graph?
Terraform builds a dependency graph from resource references and implicit links between attributes. If resource A references B’s attribute, B is created first automatically. The graph is used to parallelize safe operations. You can override with depends_on when dependency is logical but not referenced in code.
✅ Q2 — What really happens during terraform plan internally?
Terraform refreshes state by querying provider APIs, compares config vs state vs real infra, and computes an execution plan. It does not change anything — only simulates actions. It also evaluates variables, locals, and expressions. Plan output is based on current state snapshot.
✅ Q3 — Explain Terraform refresh and when it runs.
Refresh updates state with real provider data. It runs automatically during plan/apply unless disabled. It detects drift and external changes. Skipping refresh can speed up runs but risks incorrect plans.
✅ Q4 — What is lifecycle block and when do you use it?
Lifecycle block changes resource behavior — like prevent_destroy, ignore_changes, create_before_destroy. It’s used when provider defaults are unsafe for production. Example: ignore auto-added tags or prevent DB deletion. It should be used carefully — not as a band-aid.
✅ Q5 — When is ignore_changes dangerous?
It can hide real drift and config mistakes. Terraform will stop managing that attribute. Overuse leads to config/state mismatch. Use only for externally managed fields like timestamps or autoscaling values.
✅ Q6 — How does Terraform handle partial failures?
Terraform stops and records completed resources in state. Next apply resumes from that state. It does not roll back automatically. That’s why idempotent config and safe lifecycle settings matter.
✅ Q7 — What is provider alias and real use case?
Provider alias allows multiple configurations of same provider. Example: manage resources in two AWS regions or accounts. Each resource explicitly chooses provider alias. Useful in multi-region or cross-account setups.
✅ Q8 — Difference between data source and resource?
Resource creates or manages infrastructure. Data source only reads existing infrastructure data. Data sources are read-only. Example: lookup existing VPC ID.
✅ Q9 — Terraform module versioning best practice?
Always pin module versions using git tags or registry versions. Never use “latest” in production. Version pinning ensures reproducibility. Breaking module changes won’t silently affect infra.
✅ Q10 — What causes “resource replaced instead of updated”?
Some attributes are immutable at provider level. Changing them forces recreation. Terraform marks them as ForceNew fields. Example: subnet CIDR, RDS storage type sometimes.
✅ Q11 — How does Terraform handle secrets in state?
Secrets stored in resource attributes are stored in state file. Even if marked sensitive, they exist in state. That’s why backend encryption and restricted access are critical. Never expose state publicly.
✅ Q12 — State file security best practices?
Use remote backend with encryption enabled. Restrict IAM access. Enable versioning. Use locking. Never commit state to Git.
✅ Q13 — What is taint and when used?
terraform taint marks a resource for forced recreation on next apply. Used when resource is broken but not detected as drift. It’s manual override for replacement.
✅ Q14 — Difference between taint and replace flag?
Taint updates state marking. -replace is apply-time override. Replace is safer and more explicit now. Taint is older approach.
✅ Q15 — How do you split Terraform for very large infrastructure?
Use multiple state stacks by domain — network, compute, data, platform. Connect using remote state outputs. Avoid mega-state with thousands of resources. Smaller states reduce blast radius.
✅ Q16 — Terraform workspaces — when good vs bad?
Workspaces allow multiple state instances for same config. Good for simple env separation. Bad for complex environments — can become confusing. Many teams prefer folder-per-env instead.
✅ Q17 — What is for_each key stability rule?
Keys must be stable identifiers. If keys change, Terraform destroys and recreates resources. Never use computed or random keys for for_each. Use names or IDs.
✅ Q18 — Why does Terraform sometimes show “known after apply”?
Because value depends on resource created during apply — like generated IDs or ARNs. Terraform cannot know before creation. This affects dependent expressions.
✅ Q19 — How do you safely refactor Terraform modules?
Move resources using state mv. Introduce module gradually. Run plan frequently. Never refactor and apply blindly. Refactor is state operation, not just code move.
✅ Q20 — Biggest real-world Terraform mistake teams make?
Single giant state + no locking + no module versioning. This leads to race conditions, unsafe applies, and refactor nightmares. Terraform scales only when state architecture is designed properly.