🧱 Terraform — 20 Scenario-Based Real-World Interview Questions (Part 2)

✅ Q1 — Terraform apply failed midway. Some resources created, some not. What do you do?

First run terraform plan again — Terraform reads state and detects drift. It will propose creating only missing resources. Never manually recreate unless state is broken. If needed, use terraform import to sync manually created resources.

✅ Q2 — Someone manually changed an AWS resource created by Terraform. How do you detect it?

Run terraform plan — it will show drift between state and real infra. Terraform compares provider API data with state file. Plan output will show changes to revert or update. Drift detection is automatic via refresh.

✅ Q3 — State file got corrupted locally. Recovery options?

If using remote backend with versioning (S3), restore previous version. That’s why versioning must be enabled. Without backup — you may need to import resources again. Local-only state is a production mistake.

✅ Q4 — Two engineers ran apply at same time — infra broke. How prevent this?

Use remote backend with state locking (S3 + DynamoDB lock table). Lock prevents concurrent writes. Terraform will block second apply. Never allow shared local state in teams.

✅ Q5 — You renamed a resource block — Terraform wants to recreate it. How avoid that?

Use terraform state mv to move state mapping to new resource name. This preserves real infra and avoids destroy/create. Renaming in code alone causes recreation.

✅ Q6 — You want to reuse VPC module across dev/stage/prod with different sizes. How?

Parameterize using variables. Pass different tfvars per environment. Keep module generic, env config specific. Never hardcode values inside module.

✅ Q7 — Terraform shows resource will be destroyed but you know it shouldn’t. What first?

Stop. Don’t apply. Check variable values, count/for_each keys, and conditional logic. Most accidental destroys come from changed keys or indexes. Review plan diff carefully.

✅ Q8 — Need to create 50 similar resources dynamically. Best approach?

Use for_each or count. Prefer for_each when resources have unique keys. It avoids index-shift destroy problems. Use maps for stable identity.

✅ Q9 — count vs for_each — when does count become dangerous?

When list order changes. Terraform reindexes and destroys/recreates resources. This causes unexpected churn. for_each with map keys is safer for production.

✅ Q10 — You must use an existing manually created resource in Terraform. How?

Use terraform import. It maps existing resource ID to Terraform state. After import, adjust config to match actual settings. Then run plan to verify no drift.

✅ Q11 — Terraform apply is very slow — what can you tune?

Increase parallelism with -parallelism flag. Reduce unnecessary dependencies. Split large configs into modules/stacks. Avoid huge single-state monolith.

✅ Q12 — Need output from one Terraform stack in another. How?

Use remote state data source. Example: data terraform_remote_state. Pull outputs from shared backend. Avoid copy-paste values.

✅ Q13 — Sensitive values like DB password — how manage?

Use sensitive variables + secret manager integration. Don’t hardcode in tf files. Use CI secret injection or Vault/SSM. Mark outputs as sensitive.

✅ Q14 — Terraform plan shows change every run for same resource. Why?

Usually unordered fields or timestamps in config. Or provider bug. Use lifecycle ignore_changes for non-critical drift fields. Fix root cause if possible.

✅ Q15 — Need zero-downtime replacement of resource. What Terraform feature helps?

Use lifecycle { create_before_destroy = true }. It creates new resource first, then deletes old. Works for supported resources only.

✅ Q16 — How do you prevent accidental resource deletion?

Use lifecycle prevent_destroy = true. Terraform will error instead of destroying. Common for DB and production buckets.

✅ Q17 — Module depends on resource outside module — how enforce order?

Pass resource output as module input — creates implicit dependency. Or use depends_on at module level. Avoid hidden ordering assumptions.

✅ Q18 — Terraform needs different configs per region. How design?

Use provider aliases per region. Or separate stacks per region. Avoid multi-region in single state unless necessary.

✅ Q19 — CI/CD pipeline running Terraform — what extra safety step?

Always run terraform plan and require approval before apply. Store plan file artifact. Never auto-apply to prod blindly.

✅ Q20 — Large team Terraform best practice?

Small states, reusable modules, remote backend, locking, versioned modules, PR-based plan review. Monolithic state is a scaling killer.