Terraform interview questions

State

• What is state for, and why can Terraform not simply read the live infrastructure? Mapping, metadata and performance.
• Where should it live? Remote backend with locking - never in git, because it contains secrets in plain text.
• What does state locking prevent? Two applies corrupting each other. Be ready for "what if the lock is stuck?"
• What is drift, and what does `terraform plan` do about it? It refreshes and shows the difference.
• Someone changed a resource in the console. What happens on the next apply?
• `terraform import` - bringing an existing resource under management.
• What does `terraform state rm` do, and when is it the right tool? It stops managing without destroying.

Language and structure

• `count` versus `for_each`, and why `for_each` is safer - removing an element from a list reindexes everything after it.
• Modules - what belongs in one, and versioning them.
• Workspaces, and the common opinion that separate state files per environment beat workspaces for anything serious.
• `depends_on` and when the implicit graph is not enough.
• Data sources against resources.
• Why is `terraform destroy` dangerous, and how do you protect production?

Secrets and CI

• How do you handle secrets when state stores them in plain text? Encrypt the backend, restrict access, and prefer references to a secret manager over values in variables.
• What does a Terraform pipeline look like? Plan on pull request, apply on merge, with the plan reviewed by a human.
• How do you stop two pipelines applying at once?
• How do you test infrastructure code before it reaches production?

The judgement questions

How you structure repositories across many environments and teams, when a module is over-abstracted, and what you deliberately leave outside Terraform. The surrounding operational ground is in DevOps interview questions, and the cloud specifics in AWS interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus a module you have written and a migration you have run. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: multi-account structure, state migrations, and what you chose not to manage in Terraform. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a Terraform interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Terraform interview questions?

What state is for and where it should live, state locking, drift and what plan does about it, `count` versus `for_each`, importing existing resources, and the scenario where a plan wants to destroy and recreate a resource.

Why should Terraform state not be stored in git?

It contains resource attributes including secrets in plain text, it has no locking so concurrent applies corrupt it, and it changes on every apply which makes it a poor fit for version control. A remote backend with locking and encryption is the standard answer.

What is the difference between count and for_each?

`count` indexes by position, so removing an item shifts every later resource and causes unintended destroys and recreations. `for_each` keys by a stable identifier, so removing one entry affects only that resource - which is why it is preferred for anything that changes.

What do you do if Terraform wants to destroy a production database?

Understand why first - usually a change to an attribute that forces replacement. Then choose between `prevent_destroy` as a guard, `create_before_destroy` where it applies, restructuring the change to avoid the forced replacement, or importing and reconciling state.