Terraform Interview Questions and Answers

Almost every DevOps, platform, and cloud-infrastructure interview has a Terraform component, because IaC is how modern teams provision and version their cloud. At the junior level you will be asked to explain the language and the basic workflow: what a resource is, the difference between terraform plan and apply, and why you commit configuration to git. At mid-to-senior level the questions shift to judgment — how you structure state for ten teams, how you keep environments from clobbering each other, how you recover from a corrupted state file, and how you wire terraform into CI without letting two pipelines apply at once.

Interviewers use Terraform as a proxy for whether you understand declarative, idempotent systems. A strong candidate talks about the desired-state model: Terraform compares your configuration to recorded state to the real provider API, then computes the minimal set of create/update/delete actions. That mental model — config, state, real world, and the diff between them — is the through-line behind state management, drift, and import questions, so anchor your answers to it.

HCL (HashiCorp Configuration Language) is declarative — you describe the end state, not the steps. The core building block is the resource block, which maps to a single object the provider manages (an EC2 instance, an S3 bucket, a Kubernetes namespace). Each resource has a type and a local name, and you reference its attributes elsewhere with aws_instance.web.id; those references are what build Terraform's dependency graph. You rarely need explicit ordering, but depends_on exists for the cases where a dependency is not expressed through an attribute reference.

Variables parameterize a configuration (input), outputs expose computed values (output, often consumed by other modules or printed after apply), and locals name intermediate expressions to avoid repetition. Data sources are read-only lookups — they fetch information about existing infrastructure you did not create, such as the latest AMI or an existing VPC, without managing it. A frequent point of confusion interviewers test: a resource creates and owns an object; a data source only reads one. Knowing count and for_each (and why for_each with a map or set is usually preferable, because each instance is keyed by a stable identifier instead of a numeric position, so removing a middle element does not shift indices and force re-creation) signals real fluency.

State is the most important — and most failure-prone — concept in Terraform. The state file (terraform.tfstate) is Terraform's record of which real-world objects map to which resource blocks, including their last-known attributes. Without it Terraform could not tell the difference between create, update, and delete; it would not know the ID of the EC2 instance it already made. This is why losing or corrupting state is so painful: Terraform forgets it owns infrastructure and may try to recreate it.

In any team setting state must be remote, not on a laptop. A remote backend (S3, Terraform Cloud/HCP, GCS, azurerm) stores state centrally so everyone plans against the same truth, and provides state locking so two engineers — or two CI runs — cannot apply concurrently and race each other into corruption. On the S3 backend, native lockfile locking (use_lockfile = true, GA since Terraform 1.10/1.11) is now the default approach; the older pattern paired S3 with a DynamoDB table, but the dynamodb_table argument is deprecated. Mentioning the native lockfile is a quick way to show your knowledge is current rather than several versions old.

State can contain secrets in plaintext (a database password attribute, a generated key), so remote backends should be encrypted at rest and access-controlled, and tfstate should never be committed to git. Know the recovery tools cold: terraform state list and state show to inspect, state mv to refactor without destroying, state rm to drop a resource from state without touching the real object, and how to surgically fix state rather than blow it away.

A module is just a directory of .tf files you can call from elsewhere with the module block, passing inputs and reading outputs. The root module is your entry point; child modules are reusable components (a 'vpc' module, an 'eks-cluster' module). Good module design is a senior signal: keep them small and composable, expose a tight set of variables, version them (a git ref or a registry version), and avoid baking environment-specific values inside. DRY matters, but over-abstraction — a single module with thirty toggle flags — is a real anti-pattern interviewers like to surface.

For multiple environments there are two common approaches, and you should be able to argue between them. Terraform workspaces give you multiple named state files from one configuration (terraform workspace new staging), which is lightweight but risky: a single misstep can apply prod changes from the wrong workspace, and configuration cannot truly diverge per environment. The more common production pattern is directory-per-environment — separate root modules (envs/prod, envs/staging) each with their own backend/state and tfvars, calling shared child modules. This gives stronger isolation and blast-radius control at the cost of some duplication. Workspaces shine for ephemeral, identical copies (per-developer or per-PR stacks), not for prod-vs-staging divergence. Note that CLI workspaces are distinct from HCP Terraform / Terraform Cloud workspaces, which are a heavier, separately-configured unit — interviewers occasionally probe that distinction.

Drift is when the real infrastructure no longer matches state — someone clicked in the console, an autoscaler changed a value, or another tool edited the resource. terraform plan detects drift by refreshing state against the provider and showing the difference; the fix is either to update your config to match reality or re-apply to push the resource back to your declared state. To inspect drift without proposing config changes, run terraform plan -refresh-only (and apply -refresh-only to reconcile state) — the standalone terraform refresh command is deprecated because it rewrote state silently with no review step.

terraform import brings an existing, unmanaged object under Terraform control. The modern, reviewable form is the import block (Terraform 1.5+): you declare the resource address and real ID in config, and terraform plan -generate-config-out=generated.tf can even scaffold a starter resource block for you to clean up. The classic gotcha applies mainly to the older CLI command (terraform import ADDRESS ID), which only writes the object into state and generates no configuration — so if you forget to author a matching resource block, the next plan proposes to destroy what you just imported.

Providers are the plugins that translate HCL into API calls (aws, google, kubernetes, helm). Pin provider and Terraform versions with required_providers and a committed .terraform.lock.hcl so every machine and CI runner resolves identical versions — version drift between a laptop and the pipeline causes maddening, non-reproducible plans. In CI the safe pattern is: terraform fmt -check and validate on every PR, terraform plan -out=tfplan as a reviewable artifact on the PR, and terraform apply tfplan only after merge/approval, applying that exact saved plan so what was reviewed is what runs. Remote state locking is what keeps two pipeline runs from applying simultaneously; -auto-approve belongs only behind a gated, single-writer job.