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

12 May 2025

I know the kind of phrase that makes engineers panic:

“You’ve got a Terraform interview tomorrow. You ready?”

Take a breath.

Today, I’m sharing 10 Terraform questions that actually come up in real interviews — and how to answer them like a pro.

But more importantly, I’ll explain them clearly, practically, and with real-life examples, so you don’t just memorize the answers — you understand them.

Alright, let’s dive in.

---

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

Terraform is how you talk to your infrastructure — with code, not clicks.

You’re not clicking around AWS at 3 a.m. like it’s 2009.

You’re writing code:

“I need a VPC, three subnets, and a database.”

Terraform says:

“Got it. I’ll build it. I’ll check it. And I’ll make sure it stays that way.”

It’s not just convenient — it’s control. It’s repeatability. It’s infrastructure as code.

As of 2025, Terraform is at version 1.11, actively developed and widely used. It remains the industry standard for defining infrastructure.

---

Question 2: How does Terraform talk to the cloud?

Terraform talks to the cloud through something called providers.

These providers are like adapters — they know how to talk to APIs like:

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

In your code, you define required_providers, and when you run terraform init, it pulls in the right versions and verifies their SHA-256 hashes.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.97.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

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

provider "registry.terraform.io/hashicorp/aws" {
  version     = "5.97.0"
  constraints = "~> 5.97.0"
  hashes = [
    "h1:aaa111...",
    "h1:bbb222...",
    "h1:ccc333..."
  ]
}

Think of it like package dependencies — if you don’t pin them, expect surprises. And 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 stores:

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

Lose it… and Terraform has no memory. It forgets everything you’ve built. Which means it might try to recreate your entire production stack — from scratch.

So where should you store your state safely?

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

🎯 Pro 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?

Think of them as: preview, execute, delete, and 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 upcoming Terraform 1.12, plan includes refresh automatically — no need to run it separately.

🎯 Advice: Always run terraform plan before terraform apply.

Especially if it’s Friday. Especially if it’s late.

Especially if it’s prod.

---

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

Drift happens when your real infrastructure no longer matches your code.

Let’s say your config says t3.micro, but someone in AWS changed it manually to t3.large.

Terraform won’t magically know. It only sees drift when you run terraform plan.

So, how do you detect drift?

• If you’re using HCP Terraform, good news — it has a built-in drift detector that can send alerts to Slack or Teams via notifications.
• If you’re not using HCP Terraform or Terraform Enterprise, make sure to run terraform plan in CI at least once a day.

Drift isn’t a bug — it’s a warning. It means someone made changes 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?

Think of a module like a function in code — write it once, reuse it everywhere.

For example, imagine you’ve got a simple VPC module. You use it in dev, staging, and prod — only the IP ranges and names change. The logic stays the same.

⚠️ Keep it simple: one module — one purpose. Don’t build a module that creates a VPC, sets up a database, and sends a Slack notification — all in one go.

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?

Let’s keep it simple — variables and *secrets are not the same.

Use variables for anything that changes between environments.

But secrets are a different story — never hardcode them. Ever.

I’ve seen this in real projects — don’t do this:

password = "supersecret123"

So, where should you put secrets?

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

If you do pass a secret as a variable — make sure it’s marked as sensitive = true.

That way, it won’t show up in the terraform plan output.

variable "db_password" {
  description = "Database password"
  type        = string
  sensitive   = true
}

And starting with Terraform 1.10, you can now 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, senior engineers… even to me.

So here’s how you handle it — 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 verify everything looks clean.

Terraform now supports moved and removed blocks, so you can refactor without manually editing the state file. That means less risk, no manual hacking — just clean refactoring. Beautiful.

---

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

There are three proven approaches:

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

🧠 But whichever method you choose, there’s one rule you should never break:

🎯 One backend → one state → one environment.

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

---

Question 10: How do you shift security left?

Security isn’t something you add later — it starts with your terraform plan.

That’s where Policy as Code comes in. Tools like:

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

…help you catch issues early.

🔒 For example:

You write a rule — “All S3 buckets must use KMS.” With the right setup, Terraform checks that during the plan. If it fails — the run is blocked.

Some of these tools run right in your CI pipeline, others plug into HCP Terraform directly.

Want to go deeper? terraform test lets you write unit tests for your modules — and it fits right into your CI pipeline.

Security should be part of how you build, not something you fix later.

---

Final Thoughts

And that’s it. 10 questions, 10 real answers — not just to help you survive an interview, but to help you 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.

---

Follow Me

🎬 YouTube
🐦 X / Twitter
🎨 Instagram
🐘 Mastodon
🧵 Threads
🎸 Facebook
🧊 Bluesky
🎥 TikTok
💻 LinkedIn
📣 daily.dev Squad
🧩 LeetCode
🐈 GitHub

---

Community of IT Experts

👾 Discord

---

Is this content AI-generated?

Nope! Each article is crafted by me, fueled by a deep passion for Docker and decades of IT expertise. While I employ AI to refine the grammar—ensuring the technical details are conveyed clearly—the insights, strategies, and guidance are purely my own. This approach may occasionally activate AI detectors, but you can be certain that the underlying knowledge and experiences are authentically mine.

Previous post

GitOps on AWS - Real-World DevOps Pipeline with Argo CD, Terraform & EKS

Next post

Docker MCP - Turn GPT into a Real DevOps Assistant (Slack, GitHub, Stripe)