Terraform interview questions
7 questions interviewers actually ask, each with a model answer you can study and an AI drill that grades how you would say it out loud.
0/7
Mastered
Questions and answers
Model answer
State is the file that maps your configuration to real-world resources and stores metadata Terraform needs to plan changes. It is the source of truth, so it must be stored remotely with locking, for example S3 with a DynamoDB lock, to prevent corruption when teams run apply concurrently. Losing or corrupting state is one of the worst things that can happen.
Model answer
Plan computes the difference between desired configuration and current state and shows exactly what will be created, changed, or destroyed without making any changes. Apply executes that plan against the real infrastructure. You should always read the plan, ideally a saved plan file, before applying in production.
Model answer
Keep each environment state isolated. Options are separate directories per environment, separate backends, or workspaces. Many teams prefer separate directories or backends because it makes the separation explicit and reduces the risk of applying a change to the wrong environment. Share logic through versioned modules.
Model answer
A module is a reusable, encapsulated set of resources defined behind input variables and output values. It lets you package a pattern, like a VPC or an app stack, once and reuse it across teams and environments, pinned to a version. Modules are how you keep infrastructure code DRY and consistent.
Model answer
Drift is when the real infrastructure differs from what state and config describe, usually because someone changed it manually. Run terraform plan to detect it, since the plan will show changes needed to reconcile reality with config. Prevent drift by restricting manual changes and routing all changes through code.
Model answer
Use a lifecycle block with prevent_destroy on the resource, always review the plan before apply, restrict who can run apply in production, and use policy as code to block dangerous changes. For shared state, locking prevents concurrent applies that could cause surprises.
Model answer
Static keys are long-lived and leak easily, and rotating them is painful. Assuming a role or using OIDC federation in CI gives short-lived, automatically-rotated credentials scoped to exactly what the run needs. This shrinks the blast radius if anything is exposed and is the modern best practice.