Terraform and Infrastructure-as-Code Interviews: What Hiring Managers Actually Probe

Infrastructure-as-code interviews have changed. A few years ago, being able to recite what "terraform plan" does was enough to get through a screen. Today, platform and DevOps teams want to know whether you can run Terraform safely inside a team, across environments, without breaking production. Here is how to prepare for the questions that actually decide these interviews. 1. State is the whole conversation Almost every serious Terraform interview comes back to state. Expect questions like: Where do you store state and why? How do you lock it? What happens if two engineers apply at the same time? Be ready to explain a remote backend (for example S3 with DynamoDB locking, or Terraform Cloud), why local state is a liability on a team, and how you would recover from a corrupted or drifted state file. Mentioning "terraform state mv", "import" blocks, and when you would reach for "state rm" shows you have operated real systems. 2. Modules and structure Interviewers like to ask how you would lay out a repository for dev, staging, and production. There is no single right answer, but you should be able to compare workspaces versus separate directories per environment, and explain how you version modules. A strong answer talks about small, composable modules with clear inputs and outputs, pinned provider versions, and avoiding "god modules" that try to build an entire account. 3. Drift, plans, and safe change A common scenario question: "Someone changed a security group in the console. What happens on the next apply, and how would you prevent it?" Walk through detecting drift with a scheduled plan, deciding whether to codify or revert the change, and preventing it with IAM guardrails. Also talk about reviewing plans in pull requests, using policy-as-code (OPA, Sentinel, or Checkov), and why "-target" is an emergency tool, not a workflow. 4. Secrets and sensitive values Expect to be asked how you keep secrets out of state and code. Good answers mention a secrets manager, marking variables as sensitive, encrypting the backend, and remembering that sensitive values can still appear in state. 5. The live exercise Many teams now include a short live task: write a module for a VPC or a bucket with versioning and encryption, or fix a broken configuration. Talk while you type. Explain why you choose "for_each" over "count" for resources that may be reordered, and say out loud when you would add a lifecycle rule such as "prevent_destroy". How to practice Build a tiny project end to end: remote state, two environments, a reusable module, and a CI pipeline that runs fmt, validate, and plan on every pull request. Then rehearse explaining it in three minutes. If your nerves tend to erase details during live rounds, tools like Linkjob AI (https://linkjob.ai) can provide real-time help during job interviews and technical interviews, which some candidates use to keep their structure and key points straight while they talk. The candidates who stand out are not the ones who memorized every command. They are the ones who can explain trade-offs calmly and show they will not be the person who accidentally destroys production on a Friday afternoon.