All interview questions

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%

0/7

Mastered

Questions and answers

0/7 mastered

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.

Shaky on any of these?

The Terraform & IaC track on the roadmap teaches every concept behind them, from the ground up.