10 Real Terraform Interview Questions (and Expert Answers!) — 2025 DevOps Guide

Question 1: What is Terraform and why does it matter?#

Terraform is how you talk to your infrastructure with code instead of clicks.

You’re not poking around the AWS console at 3 a.m. like it’s 2009.

You write code. Something like: “I need a VPC, three subnets, and a database.”

And Terraform answers: “Got it. I’ll build it. I’ll check it. And I’ll keep it that way.”

Convenience is the small part. The real win is control, and repeatability. That’s the whole point of infrastructure as code.

As of 2025, Terraform sits at version 1.11. Actively developed, widely deployed, and still the default tool for defining infrastructure.

Question 2: How does Terraform talk to the cloud?#

Through providers.

Think of a provider as an adapter. It knows how to speak to a given API:

• AWS,
• Azure,
• Kubernetes,
• GitHub,
• and tons more.

You declare required_providers in your code. Run terraform init, and it pulls the right versions, then verifies their SHA-256 hashes.

1
terraform {
2
  required_providers {
3
    aws = {
4
      source  = "hashicorp/aws"
5
      version = "~> 5.97.0"
6
    }
7
  }
8
}
9

10
provider "aws" {
11
  region = "us-west-2"
12
}

The .terraform.lock.hcl file pins those versions in place.

1
provider "registry.terraform.io/hashicorp/aws" {
2
  version     = "5.97.0"
3
  constraints = "~> 5.97.0"
4
  hashes = [
5
    "h1:aaa111...",
6
    "h1:bbb222...",
7
    "h1:ccc333..."
8
  ]
9
}

Same idea as package dependencies. Don’t pin them, and you’ll get surprises. Surprises in production?

Yeah. Not fun.

Question 3: What is terraform.tfstate and why is it critical?#

It’s Terraform’s memory.

The state file tracks:

• What resources exist
• Their IDs
• Their attributes
• And how they’re all wired together

Lose it, and Terraform forgets everything you’ve built. So it might decide to recreate your entire production stack from scratch.

Where do you keep state safely? Two solid options:

• S3 bucket with native locking (available since Terraform 1.11)
• HCP Terraform (formerly Terraform Cloud)

TIP

Never, ever commit your state file to git. Not even to a private repo. Not even “just this once.” Just… don’t.

Question 4: What is the actual function of plan, apply, destroy, and refresh?#

Read them as: preview, execute, delete, sync.

• terraform plan — shows what will change
• terraform apply — actually makes the changes
• terraform destroy — deletes everything in your config
• terraform refresh — syncs the state with reality

In the upcoming Terraform 1.12, plan runs refresh for you. No separate command.

🎯 Advice: Always run terraform plan before terraform apply.

Especially on a Friday. Especially late at night.

Especially in prod.

Question 5: What is drift, and how do you detect it?#

Drift is when your real infrastructure stops matching your code.

Say your config declares t3.micro. Then someone goes into the AWS console and bumps it to t3.large by hand.

Terraform has no idea. It only notices the gap when you run terraform plan.

So how do you catch it?

• On HCP Terraform, you get a built-in drift detector. It can fire alerts to Slack or Teams through notifications.
• Not on HCP Terraform or Terraform Enterprise? Then run terraform plan in CI at least once a day.

Drift isn’t a bug. It’s a warning. Someone changed something outside of Terraform.

And remember: Infrastructure as Code does not like human hands.

Question 6: What are modules and how do you use them without creating a mess?#

A module is basically a function for your infrastructure. Write it once, reuse it everywhere.

Picture a small VPC module. You run it in dev, staging, and prod. Only the IP ranges and names change. The logic underneath stays identical.

⚠️ Keep it simple: one module — one purpose. Don’t build a single module that spins up a VPC, provisions a database, and pings Slack on the side.

Once your module is solid, you’ve got options:

• Publish it to the Terraform Registry
• Or even store it as an OCI artifact (this feature is experimental in Terraform 1.12)

Question 7: Variables vs Secrets — where’s the line?#

Simple distinction. Variables and secrets are not the same thing.

Use variables for anything that changes between environments.

Secrets are another matter. Never hardcode them. Ever.

I’ve watched this happen on real projects. Don’t be the person who writes:

1
password = "supersecret123"

So where do secrets belong?

• AWS Secrets Manager
• HashiCorp Vault
• Or just mark variables as sensitive in HCP Terraform

If you do pass a secret as a variable, set sensitive = true.

That keeps it out of the terraform plan output.

1
variable "db_password" {
2
  description = "Database password"
3
  type        = string
4
  sensitive   = true
5
}

And since Terraform 1.10, you can use short-lived values to keep secrets out of your state files entirely.

Question 8: What if terraform apply fails halfway through?#

It happens. To junior devs, to senior engineers, to me.

Here’s the recovery, step by step:

1. Run terraform state list to see what was created.
2. If the resource exists in the cloud but not in the state — use terraform import.
3. If it shouldn’t exist — remove it from state with terraform state rm.
4. Then re-run terraform plan and check that everything looks clean.

Terraform now supports moved and removed blocks. So you can refactor without hand-editing the state file. Less risk, no manual hacking, clean refactors. Nice.

Question 9: How do you separate dev, stage, and prod?#

Three approaches that hold up in practice:

1. Workspaces — simple, but hard to scale
2. Folder structure like environments/dev, stage, prod — the golden standard
3. Terragrunt — great for multi-account or multi-team setups

🧠 Whatever you pick, one rule is non-negotiable:

🎯 One backend → one state → one environment.

Never mix dev and prod in the same state file. That’s storing fire and gasoline in the same drawer.

Question 10: How do you shift security left?#

Security isn’t a step you bolt on later. It starts at terraform plan.

That’s where Policy as Code earns its keep. Tools like:

• OPA (Open Policy Agent)
• Sentinel (by HashiCorp)
• Checkov (by Bridgecrew)
• Snyk IaC

…catch problems before they ship.

🔒 For example:

You write a rule: “All S3 buckets must use KMS.” Wired up correctly, Terraform checks that during the plan. Rule fails, run blocked.

Some of these tools live in your CI pipeline. Others plug straight into HCP Terraform.

Want to push further? terraform test lets you write unit tests for your modules, and it drops right into CI.

Security belongs in how you build, not in a cleanup you do afterward.

Final Thoughts#

That’s the set. 10 questions, 10 real answers. Not to help you scrape through an interview, but to walk in confident, prepared, and dangerously well-informed.

Thank you for reading! Don’t forget to check out the video version for additional insights and visuals.