DevOps Tutorials, Guides & Best Practices

Terraform interview questions can look easy until the interviewer turns them into production scenarios: state is locked, a plan wants to replace a database, a module hides provider configuration, or a developer imported a resource without reviewing the diff. This guide is for DevOps engineers, cloud engineers, platform engineers, and SRE-adjacent candidates who need practical Terraform answers, not memorized definitions.

Quick takeaway: Prepare around operational judgment: core workflow, providers, modules, state, backends, workspaces, imports, drift, sensitive data, and CI/CD controls. That matches the HashiCorp Terraform Associate objective map better than a random question dump.

The structure below is grounded in HashiCorp documentation and certification prep material. HashiCorp describes Terraform as an infrastructure as code tool for building, changing, and versioning infrastructure safely and efficiently in the Terraform overview. The Terraform Associate 004 learning path and exam content list are useful signals for what interviewers often test: IaC fundamentals, workflow, configuration language, modules, state, maintenance, and HCP Terraform. Supporting PDF training material was used only for curriculum framing, including the KodeKloud Terraform Associate PDF and a TrustRadius Terraform guide; random exam dumps were rejected.

What Terraform Interviews Usually Test

Good Terraform interviews test whether you can operate infrastructure safely. If you are also preparing for broader role interviews, pair this article with GCP interview questions for DevOps and cloud engineers and junior DevOps interview questions so you can separate tool knowledge from role-level judgment.

Area	What the interviewer wants	Strong answer signal
Workflow	Can you run Terraform safely?	You explain init, fmt, validate, plan, apply, review, and rollback thinking.
State	Do you understand Terraform ownership?	You mention state mapping, locking, remote backends, secrets, and drift.
Modules	Can you scale IaC across teams?	You discuss inputs, outputs, composition, versioning, and provider boundaries.
Production operations	Can you troubleshoot safely?	You cover import, moved blocks, targeted runs as exceptions, and CI/CD gates.

Terraform Fundamentals and IaC Questions

1. What is Terraform?

Terraform is an infrastructure as code tool. It lets teams describe infrastructure in configuration files, then use Terraform to create, update, and version that infrastructure through a consistent workflow. HashiCorp frames Terraform as a way to build, change, and version infrastructure safely and efficiently in its Terraform product documentation.

2. What problem does Infrastructure as Code solve?

IaC makes infrastructure reviewable, repeatable, and version-controlled. Instead of clicking through a console, teams can review a pull request, run a plan, see the expected change, and apply it through a controlled workflow.

3. What is the difference between declarative and imperative infrastructure automation?

Declarative tools describe the desired end state. Terraform then works out the changes needed to reach that state. Imperative automation describes steps. In interviews, the useful answer is that declarative IaC is easier to review, but you still need operational checks because the plan may include destructive changes.

4. What is HCL?

HCL is HashiCorp Configuration Language. Terraform configuration uses HCL syntax for resources, providers, variables, outputs, modules, expressions, and meta-arguments. A strong answer does not stop at syntax; it explains how HCL becomes a dependency graph and a plan.

Core Terraform Workflow Questions

The Terraform Associate learning path explicitly covers the core workflow: write configuration, initialize a working directory, create a plan, and apply changes. In an interview, show that you can use the commands and explain the safety gates around them.

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan

5. What does terraform init do?

`terraform init` prepares a working directory. It initializes backend settings, downloads provider plugins, and prepares modules. HashiCorp documents the command in the terraform init reference. If init fails in CI, check backend access, provider source/version constraints, network access to registries, and lock file changes.

6. What is terraform plan used for?

`terraform plan` shows what Terraform intends to create, update, replace, or destroy before applying. The plan command reference is a good source for the exact behavior. In production, a plan is a review artifact, not just a command you run before apply.

7. What does terraform apply do?

`terraform apply` executes the proposed changes and updates state. HashiCorp covers the command in the apply reference. A strong answer mentions using a saved plan file in controlled pipelines so the applied change matches what was reviewed.

8. Why run fmt and validate in CI?

Run `terraform fmt -check` to keep style consistent and `terraform validate` to catch configuration errors before planning. They do not prove the change is safe, but they are cheap gates before provider-backed planning.

Providers, Resources, and Data Sources

Terraform providers are plugins that let Terraform interact with target APIs. The providers documentation is the source for this part of the mental model. Most real interview questions ask whether you understand the separation between provider configuration, managed resources, and data sources that read existing objects.

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

provider "aws" {
  region = var.aws_region
}

resource "aws_s3_bucket" "logs" {
  bucket = var.log_bucket_name
}

data "aws_caller_identity" "current" {}Code language: JavaScript (javascript)

9. What is a provider?

A provider is the integration layer between Terraform and an API, such as AWS, Azure, Google Cloud, Kubernetes, GitHub, or another service. It defines available resources and data sources.

10. What is the difference between a resource and a data source?

A resource is managed by Terraform. A data source reads information from something that already exists. Interviewers often use this to test whether you will accidentally try to manage an object Terraform should only reference.

11. Why pin provider versions?

Provider behavior can change across versions. Version constraints and the dependency lock file make provider selection predictable across laptops and CI runners.

12. How do variables and outputs fit into Terraform?

Input variables parameterize configuration, while outputs expose values from a module or root configuration. HashiCorp documents input variables and output values separately because they solve different boundaries: inputs feed a module, outputs publish results.

State, Backends, and Locking Questions

Terraform state is one of the most important interview topics. HashiCorp says state maps resources in configuration to real-world infrastructure and stores metadata; see the purpose of Terraform state. A candidate who treats state as an implementation detail is not ready to operate Terraform in a team.

Question	Weak answer	Better answer
Where is state stored?	In a file.	Local or remote backend; teams should use remote state with locking and access control.
Is state sensitive?	Usually no.	Often yes, because outputs and provider data can expose secrets or infrastructure details.
What if state is wrong?	Run apply again.	Investigate drift, refresh, import, moved blocks, or state commands carefully.
Can two people apply at once?	They should not.	Use remote backend locking and CI workflow controls.

terraform {
  backend "s3" {
    bucket         = "example-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}Code language: JavaScript (javascript)

13. Why does Terraform need state?

Terraform needs state to know which real resources correspond to which configuration blocks. Without state, Terraform cannot reliably plan updates, replacements, or destroys for infrastructure it manages.

14. Why use a remote backend?

A remote backend centralizes state for a team, supports collaboration, and can provide locking depending on the backend. The backend block documentation is the starting point for backend behavior.

15. What is state locking?

State locking prevents concurrent operations from corrupting or racing the same state. In an interview, mention that lock failures usually mean another run is active or a previous run left a stale lock that must be investigated, not blindly removed.

16. What is drift?

Drift is a difference between real infrastructure and Terraform configuration or state, often caused by manual console changes, external automation, or provider-side defaults. A good answer starts with a plan and investigation, not an immediate apply.

Modules and Reuse Questions

Modules are how Terraform configuration becomes reusable. HashiCorp defines module usage in the modules documentation. For interviews, focus on boundaries: what a module owns, which inputs it accepts, what outputs it exposes, and how it handles providers.

module "network" {
  source = "git::https://example.com/platform/network.git?ref=v1.4.0"

  environment = var.environment
  cidr_block  = var.vpc_cidr
}

output "vpc_id" {
  value = module.network.vpc_id
}Code language: JavaScript (javascript)

17. What is a Terraform module?

A module is a container for Terraform configuration. Every Terraform configuration has a root module, and it can call child modules to package reusable infrastructure patterns.

18. What makes a good module interface?

A good module has clear inputs, useful outputs, sensible defaults, documentation, versioning, and a narrow responsibility. If a module tries to manage everything, it becomes hard to test and upgrade.

19. Should providers be configured inside modules?

Usually keep provider configuration at the root and pass provider aliases when needed. This makes modules easier to reuse across accounts, regions, and environments.

20. How do you version modules?

Use versioned registry modules or pinned Git refs. Avoid pointing production directly at a moving branch unless your release process intentionally supports that.

Workspaces and Environment Strategy

Terraform CLI workspaces often appear in interviews because they are easy to misuse. HashiCorp explains in the workspaces documentation that CLI workspaces are separate state instances in the same working directory. They are not a complete isolation model for complex environments that need separate credentials or access controls.

21. What are Terraform CLI workspaces?

CLI workspaces let one working directory use multiple state instances. Every initialized directory starts with a default workspace. Most commands operate against the currently selected workspace.

22. When should you avoid CLI workspaces?

Avoid using CLI workspaces as the main isolation mechanism for serious production, staging, and development boundaries that need different credentials, policies, or backends. Separate configurations and backends are usually clearer.

23. How would you structure dev, staging, and prod?

For small experiments, workspaces can be acceptable. For production systems, prefer separate root configurations or directories with distinct backends, credentials, variables, and access controls.

Import, Refactoring, and Lifecycle Questions

Experienced interviewers ask about resources that already exist, resources that need renaming, and changes that could force replacement. HashiCorp documents import and the lifecycle meta-argument because these are common maintenance tasks.

# Import an existing resource into state after writing matching configuration.
terraform import aws_s3_bucket.logs example-log-bucket

# Preserve state mapping during a refactor.
moved {
  from = aws_s3_bucket.logs
  to   = module.logging.aws_s3_bucket.logs
}Code language: PHP (php)

24. How do you import an existing resource?

Write configuration that matches the existing resource, run `terraform import` or use an import block depending on your Terraform version, then run a plan and reconcile differences before applying.

25. What is a moved block?

A moved block tells Terraform that a resource address changed because of refactoring. It avoids Terraform interpreting the change as destroy old resource and create new resource.

26. What does prevent_destroy do?

The `prevent_destroy` lifecycle setting blocks Terraform from destroying a resource. It can protect critical infrastructure, but it can also block legitimate replacements, so teams need a documented override process.

27. Is targeted apply safe?

A targeted plan or apply can be useful for recovery, but it should be treated as an exception. It can skip dependencies and leave the broader configuration in a less obvious state.

Sensitive Data and Security Questions

Terraform can touch credentials, secrets, network boundaries, and privileged cloud resources. HashiCorp has separate guidance for managing sensitive data. A strong interview answer treats state, variables, logs, and CI outputs as possible leakage paths.

28. How should Terraform handle secrets?

Do not commit secrets in `.tf` or `.tfvars` files. Use secret managers, CI/CD secret stores, dynamic provider credentials where possible, and restrict state access because state can contain sensitive values.

29. Does sensitive = true encrypt a value?

`sensitive = true` hides values in CLI output, but it does not automatically encrypt state or make the secret safe everywhere. Backend security and secret handling still matter.

30. What access should CI/CD have?

Use least privilege. CI should have enough access to plan and apply the intended infrastructure, but not broad human-admin access. Prefer short-lived credentials and separate plan/apply gates for production.

Terraform in CI/CD and Team Workflows

For DevOps and platform roles, interviewers care about how Terraform runs in a team. Connect your answer to CI/CD interview questions if the conversation moves from Terraform mechanics into release governance.

terraform fmt -check -recursive
terraform init -input=false
terraform validate
terraform plan -input=false -out=tfplan
# Production apply should require review, approval, and the same saved plan.
terraform apply -input=false tfplanCode language: PHP (php)

31. What should happen in a Terraform pull request?

Run formatting, validation, and plan generation. Review the plan for replacements, destroys, IAM changes, network exposure, and state impact. Apply should happen only through an approved workflow.

32. How do you handle production applies?

Use remote state, locking, approval gates, clear ownership, and a plan artifact. Avoid unreviewed local applies to production.

33. What would you check if a plan wants to replace a database?

Stop and inspect the cause. Check provider diff, immutable arguments, lifecycle settings, state drift, module changes, and whether a safer migration path exists. Never hand-wave a destructive replacement in an interview.

Common Terraform Interview Mistakes

• Calling Terraform “just a scripting tool” instead of explaining desired state and plans.
• Saying local state is fine for teams without mentioning remote backends and locking.
• Using workspaces as a blanket answer for environment isolation.
• Suggesting secrets can safely live in tfvars files or state because variables are marked sensitive.
• Ignoring destructive plan output, especially replacement of stateful resources.
• Not knowing how import, moved blocks, and module refactors affect state.
• Giving command definitions without explaining production review and approval controls.

How to Prepare for a Terraform Interview

Use the HashiCorp sample questions to understand the style of exam-like prompts, but prepare for real interviews by practicing scenarios. Build a small module, configure a backend, run a plan, import a resource in a sandbox, and explain the tradeoffs. For adjacent automation topics, review Ansible interview questions and Ansible roles so you can distinguish configuration management from infrastructure provisioning.

Practice task	Why it helps
Create a simple module	Tests variables, outputs, composition, and naming.
Configure a remote backend	Tests team workflow, locking, and state security.
Import an existing resource	Tests migration thinking and plan review.
Refactor with moved blocks	Tests safe changes without replacement.
Run Terraform in CI	Tests operational workflow, approvals, and least privilege.

FAQ

These short answers cover the questions that usually come up after the main interview scenarios.