USA
Canada
UK
Europe
Australia
Singapore
Japan
IndiaQ1. What is Terraform state and why does it matter?
Short answer: State maps config to real resources; it must be shared and locked in a team.
Strong answer: Terraform records the mapping between your configuration and real infrastructure in a state file. It’s how Terraform knows what exists and computes changes. In a team, store it remotely (S3/Azure Storage/Terraform Cloud) with locking to prevent concurrent corruption, and never edit it by hand. Losing or corrupting state is a serious problem.
Likely follow-up: Why is remote state with locking essential for teams?
What the interviewer is checking: Core Terraform operations.
Common mistake: Keeping state locally and committing it to git.
Q2. Explain the plan/apply workflow.
Short answer: plan shows the diff; apply executes it; the workflow is reviewable and idempotent.
Strong answer: terraform plan computes the difference between desired config and current state, showing what will be created/changed/destroyed. apply executes that plan. This makes changes previewable and reviewable (like a PR), and idempotent — re-applying unchanged config is a no-op. Always review plans before applying, especially destroys.
Likely follow-up: Why review a plan before apply in production?
What the interviewer is checking: Safe IaC workflow.
Common mistake: Running apply without reviewing the plan.
Q3. How do you structure reusable Terraform with modules?
Short answer: Encapsulate resources into modules with inputs/outputs, reused across environments.
Strong answer: Modules package a set of resources with variables (inputs) and outputs, so you reuse patterns (a VPC, a service) across environments and teams with different parameters. Keep modules focused and versioned, and compose them in root configs per environment. This avoids copy-paste and drift.
Likely follow-up: How do you promote the same module across dev/stage/prod?
What the interviewer is checking: IaC maintainability.
Common mistake: Copy-pasting resource blocks instead of modularizing.
Q4. What is drift and how do you detect/handle it?
Short answer: Drift is when real infra diverges from state; detect with plan, then reconcile.
Strong answer: Drift happens when infrastructure is changed outside Terraform (manual console edits). terraform plan surfaces the difference. You reconcile by either updating config to match reality or re-applying to restore desired state (or importing unmanaged resources). Preventing manual changes is the real fix.
Likely follow-up: How do you bring a manually-created resource under Terraform?
What the interviewer is checking: Operational IaC.
Common mistake: Making console changes that silently drift from code.
Q5. How do you manage multiple environments (dev/stage/prod)?
Short answer: Separate state per environment via workspaces or, better, separate config/state directories.
Strong answer: Isolate each environment’s state so a change in dev can’t affect prod — using separate backends/directories (preferred for clarity) or workspaces, parameterized via variables. Keep prod changes gated and reviewed. Shared state across environments is dangerous.
Likely follow-up: What’s the risk of one shared state for all environments?
What the interviewer is checking: Environment-isolation practice.
Common mistake: One state file spanning all environments.
Q6. How do you handle secrets in Terraform?
Short answer: Keep secrets out of code/state where possible; source from a secrets manager and mark sensitive.
Strong answer: Avoid hardcoding secrets; source them from a secrets manager (Vault, cloud secret stores) or environment, mark variables/outputs as sensitive, and secure the state backend (encrypted, access-controlled) because secrets can land in state. Never commit secrets or plaintext state to source control.
Likely follow-up: Why is the state file a secrets-exposure risk?
What the interviewer is checking: Security awareness.
Common mistake: Putting plaintext secrets in .tf files or unencrypted state.
Q7. What is the difference between count and for_each?
Short answer: count creates N by index; for_each creates instances keyed by a map/set.
Strong answer: count creates resources by numeric index, but removing a middle item re-indexes and can recreate resources. for_each creates instances keyed by map/set keys, so add/remove affects only that key — safer for dynamic collections. Prefer for_each for keyed, stable resource sets.
Likely follow-up: Why can removing an item from a count list recreate other resources?
What the interviewer is checking: Practical Terraform nuance.
Common mistake: Using count for keyed collections and causing churn.