Terraform Interview Questions and Answers (2026 Guide)

Terraform interviews rarely test whether you can recite HCL syntax. They test whether you understand *why* infrastructure as code behaves the way it does — how state drift happens, what terraform plan actually computes, and what you do when two engineers run apply at the same time. This guide groups the most common Terraform interview questions into basic, intermediate, and advanced tiers, with sample answers and the scenario-based problems that separate someone who has read the docs from someone who has run Terraform in production.

What you'll get here:

• 15 questions across three difficulty levels, with concrete answers
• The exact distinction interviewers listen for on state, modules, and workspaces
• Three scenario-based questions that mirror real on-call situations
• An FAQ on how to prep and what level of question to expect for your seniority

Quick reference: question topics by level

Basic Terraform interview questions

These confirm you understand the model. Don't skip them even for senior roles — a shaky answer here undermines everything after.

1. What is Terraform and how does it differ from configuration management tools?

Terraform is an infrastructure-as-code tool that provisions and manages infrastructure through declarative configuration files. You describe the desired end state, and Terraform figures out the API calls to reach it.

The distinction interviewers want: Terraform provisions infrastructure; tools like Ansible, Chef, and Puppet configure it. Terraform creates the VM, network, and load balancer. A configuration management tool then installs packages and edits files *on* that VM. Terraform is also declarative and provider-agnostic — the same workflow targets AWS, Google Cloud, Azure, Kubernetes, and hundreds of other providers through the same plan/apply cycle.

2. What is the Terraform state file and why does it matter?

State is a JSON file that maps the resources in your configuration to the real objects Terraform created. Without it, Terraform has no memory of what it built.

A strong answer names the three jobs state does:

• Mapping — it keeps a one-to-one binding between each configured resource and its real-world counterpart
• Metadata and dependencies — it tracks resource dependencies so Terraform destroys and creates things in the right order
• Performance — it caches attribute values so Terraform doesn't have to query every resource on every run

The follow-up almost always comes: *never edit the state file by hand.* Use terraform state subcommands instead.

3. Explain the core Terraform workflow.

The standard loop is init → plan → apply.

The detail that signals depth: `terraform plan` first refreshes state against the real world, then compares your config to that refreshed state, and only then proposes changes. apply runs the same plan logic before prompting for approval.

4. What is the difference between input variables, outputs, and local values?

• Input variables (variable blocks) parameterize a configuration — they're the arguments you pass in.
• Outputs (output blocks) expose values *from* a module so a parent module or the CLI can read them.
• Locals (locals blocks) are named expressions reused within a single module — like a local variable in code, not exposed outside.

A clean way to say it: variables are inputs, outputs are returns, locals are private helpers.

5. What happens when you run terraform apply on a configuration that's already deployed and unchanged?

Terraform refreshes state, compares it to the configuration, finds no differences, and reports "No changes." This question checks whether you understand that Terraform is convergent — it only acts on the delta between desired and actual state, not on the whole config every time.

Intermediate Terraform interview questions

This tier separates people who have used Terraform on a team from those who have only run it solo.

6. What is remote state and why use it instead of local state?

By default Terraform writes terraform.tfstate to your local disk. That breaks the moment a second person joins. Remote state stores the file in a shared backend — an S3 bucket, Google Cloud Storage, Azure Blob, or HCP Terraform.

The reasons matter as much as the mechanism:

• Shared access — the whole team reads and writes the same source of truth
• State locking — prevents two people from running apply simultaneously and corrupting state
• Security — backends support encryption and access control, so secrets in state aren't sitting on someone's laptop

7. What are Terraform modules and when should you write one?

A module is a container for resources used together. Every configuration has at least one — the root module, the files in your working directory. Modules you call from the root with a module block are child modules.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "prod-vpc"
  cidr = "10.0.0.0/16"
}

Write a module when a set of resources is reused across environments or projects — a standard VPC, a tagged S3 bucket pattern, an EKS cluster. The honest senior answer also includes restraint: don't wrap a single resource in a module just to feel organized. Modules earn their keep through reuse, not nesting.

8. What's the difference between count and for_each?

Both create multiple instances of a resource, but they index differently.

The classic gotcha interviewers wait for: with count, deleting the second of three subnets forces Terraform to destroy and recreate the third because indices shift. for_each avoids that because each instance is keyed by a stable string.

9. What are Terraform workspaces and what are their limits?

Workspaces let you keep multiple state files from a single configuration directory. There's always a default workspace; you add more with terraform workspace new dev and switch with terraform workspace select prod. You can reference the active one in config via terraform.workspace.

Where candidates lose points is the *limits*. Workspaces are fine when environments are nearly identical and differ only in scale or naming. They're a poor fit when:

• Environments need genuinely different configurations
• You want strict, separate access control per environment
• You need to guarantee that applying to dev can never touch prod

For those cases, separate directories or separate root modules beat workspaces.

10. What is a data source and how does it differ from a resource?

A resource block tells Terraform to *create and manage* an object. A data block tells Terraform to *read* something that already exists — an existing AMI, a VPC managed elsewhere, the current AWS account ID. Data sources are read-only; Terraform never modifies them. They're how one configuration consumes facts about infrastructure it doesn't own.

Advanced Terraform interview questions

These probe failure modes and large-team patterns. Vague answers here cap your level.

11. How does state locking work and what happens without it?

When Terraform runs an operation that writes state, it acquires a lock so no one else can write at the same time. With the S3 backend this is now handled natively via conditional writes; older setups used a DynamoDB table for the lock. Without locking, two concurrent apply runs can interleave writes and leave state corrupted — pointing at resources that no longer exist or missing ones that do. If a process dies mid-run and leaves a stale lock, terraform force-unlock <LOCK_ID> clears it, used carefully.

12. What is configuration drift and how do you detect it?

Drift is when real infrastructure diverges from what state records — usually because someone made a change in the cloud console by hand. You detect it by running terraform plan, which refreshes state and surfaces any differences as proposed changes. To inspect drift without proposing config changes, use terraform plan -refresh-only. The fix is either to bring the change back into code or to let Terraform revert it on the next apply. The cultural answer worth adding: drift is a symptom of out-of-band changes, so the real fix is process — lock down console write access.

13. How do you bring existing infrastructure under Terraform management?

You use terraform import (or an import block in modern Terraform) to associate an existing real-world object with a resource address in your configuration. Import writes the object into state — it does not generate the configuration. You still have to write the matching resource block by hand (or generate it), then run plan until it shows no changes, confirming your code matches reality.

14. How do you share outputs between separate Terraform configurations?

Use the terraform_remote_state data source. One configuration (say, networking) publishes outputs; another (say, an app stack) reads them from the remote backend.

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "company-tfstate"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_instance" "app" {
  subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id
}

The senior nuance: this couples two states together, so changes to the producer's outputs ripple into consumers. Many teams prefer publishing values to a parameter store or using explicit data sources to keep the boundary looser.

15. When would you use a dynamic block, and why is overuse discouraged?

A dynamic block generates repeatable nested blocks programmatically, iterating over a collection with for_each. It's useful inside reusable modules where the number of nested blocks (security group rules, for example) varies by input.

HashiCorp's own guidance is the answer interviewers want to hear: use them only to hide complexity behind a clean module interface, because overuse makes configuration hard to read. Write nested blocks literally whenever you can.

Scenario-based Terraform interview questions

Scenario questions are where senior interviews live. There's rarely one right answer — they're checking how you reason under pressure.

Two engineers run terraform apply at the same time. What happens?

The right answer starts with prevention: with a remote backend that supports state locking, the second run can't acquire the lock and waits or fails fast — no corruption. Without locking, both runs read the same state, make independent changes, and the last write wins, corrupting state and orphaning resources. The follow-up: how do you prevent this organizationally? Run apply only from CI/CD, never from laptops, so there's a single serialized path to production.

Someone deleted a production resource in the cloud console. Walk me through recovery.

State now references an object that doesn't exist. Running terraform plan will show Terraform wants to recreate it. If recreation is safe, apply rebuilds it. If the resource holds data you can't lose (a database), you don't blindly apply — you restore from backup or snapshot first, then terraform import the restored resource so state matches reality again. The point being tested: you distinguish stateless resources you can recreate from stateful ones you must restore.

You need to refactor a large main.tf into modules without destroying live infrastructure. How?

The naive approach — moving resources into a module — changes their resource addresses, so Terraform plans to destroy and recreate them. To avoid that, you use `moved` blocks (or historically terraform state mv) to tell Terraform the resource's address changed but the underlying object did not. Then plan should show no destroy/create actions. Always confirm with a plan before applying, and do it in small, reviewable batches rather than one giant refactor.

How to prepare for a Terraform interview

• Run it for real. Spin up a free-tier AWS account and provision a VPC, an EC2 instance, and an S3 backend from scratch. The bugs you hit are exactly what gets asked.
• Read the official docs, not just question dumps. The HashiCorp Terraform documentation is the primary source, and interviewers can tell when you've internalized the model versus memorized answers.
• Know your war stories. For any senior role, prepare one real example each of drift you fixed, a state issue you recovered from, and a module you designed.
• Pair Terraform with adjacent topics. Terraform questions rarely come alone — expect them mixed with cloud and CI/CD topics covered in our DevOps interview questions and AWS interview questions guides.

The fastest path past the resume screen

Strong Terraform answers get you through the interview. Getting *to* the interview is a different problem — most infrastructure and DevOps applications disappear into an applicant tracking system before a human reads them.

The higher-conversion move is to reach the hiring manager or a senior engineer on the team directly. Articuler uses semantic search across 980M+ professional profiles to find the actual person hiring for a role, drafts a personalized outreach note that gets far higher reply rates than a generic LinkedIn message, and builds a Playbook on what that specific interviewer cares about — so you walk in prepared for *their* questions, not a generic list. If you'd rather warm up the conversation before applying, our cold email templates are a good place to start, and our technical interview questions guide covers the broader engineering loop.

FAQ

What level of Terraform questions should I expect for my seniority?

Junior and mid-level roles focus on the basic and intermediate tiers — workflow, state basics, variables, modules, and count vs for_each. Senior and staff roles lean heavily on the advanced and scenario sections: state locking, drift, refactoring live infrastructure, and multi-team state sharing. If you're targeting a platform or SRE role, expect every scenario question above.

Is Terraform still worth learning in 2026?

Yes. Terraform remains one of the most widely adopted infrastructure-as-code tools across AWS, Google Cloud, and Azure, and infrastructure-as-code skills are a baseline expectation for most DevOps, platform, and cloud engineering roles. The concepts — declarative provisioning, state, modules — also transfer to alternatives like OpenTofu and Pulumi.

What's the most common Terraform interview mistake?

Memorizing command syntax while missing the model. Candidates who can recite flags but can't explain what terraform plan computes, or why state matters, get filtered out fast. Interviewers care about reasoning — especially on state and drift — far more than perfect recall of HCL.

Should I expect live coding in a Terraform interview?

Sometimes. Hands-on rounds may ask you to write a small module, debug a broken configuration, or explain a plan output. Practicing by building real infrastructure prepares you better than reading question lists, because debugging your own broken config is the closest analog to a live round.

How is Terraform different from AWS CloudFormation?

CloudFormation is AWS-only and managed by AWS; Terraform is cloud-agnostic and works across hundreds of providers with a single workflow. Terraform also keeps an explicit state file you manage, while CloudFormation manages stack state internally. For multi-cloud or provider-portable infrastructure, interviewers expect you to reach for Terraform.