Terraform Interview Questions for Cloud and DevOps Roles

Terraform has become the default infrastructure-as-code tool across cloud engineering and DevOps hiring. Most job descriptions list it as required rather than preferred, and most technical screens now include at least a few Terraform questions regardless of whether “Terraform” appears in the job title.

The good news: Terraform interviews are very predictable. Interviewers probe a small set of concepts — state management, modules, workspaces, and the plan/apply workflow — and the same gaps trip up candidates repeatedly.

When Terraform Questions Appear#

If the role involves provisioning cloud infrastructure at all, expect Terraform questions. This includes:

• Cloud engineer roles where you manage VPCs, compute, databases, and IAM
• DevOps engineer roles where you own the infrastructure pipeline
• Platform engineer roles where you build shared infrastructure for other teams
• SRE roles where you manage environment configurations as code
• Even some backend engineer roles at companies with strong infrastructure culture

The depth of questioning scales with seniority. Junior roles: can you read a Terraform file and understand what it will create? Mid-level: can you write and structure Terraform for a real environment? Senior: how would you design a Terraform setup for a team of engineers across multiple accounts and environments?

Core Concepts Questions#

“What is Terraform state and why does it exist?” Testing: fundamental understanding of how Terraform works. State is how Terraform tracks what it has created in the real world. Without state, Terraform cannot know whether a resource exists, what its current configuration is, or whether it needs to be changed. State is stored in a terraform.tfstate file (locally by default) and is the source of truth Terraform compares against your configuration on every plan.

“What is remote state and why would you use it?” Testing: team operations knowledge. Local state breaks immediately when more than one person needs to run Terraform against the same infrastructure. Remote state backends (S3 with DynamoDB locking on AWS, GCS with Cloud Storage on GCP, Terraform Cloud) allow teams to share state safely. The interviewer wants to hear about state locking specifically — without locking, two engineers running terraform apply simultaneously can corrupt state.

“What is state locking and what happens if a lock gets stuck?” Testing: practical experience. When Terraform starts an operation that modifies state, it acquires a lock to prevent concurrent writes. If a process crashes mid-apply, the lock can be left in place. The fix is terraform force-unlock <lock-id> — but candidates should mention checking whether anything is actually still running before forcing a release, because unlocking during a live apply can cause state corruption.

“What is the difference between terraform plan and terraform apply?” Testing: workflow basics. Plan shows what changes would be made without making them — it diffs the desired configuration against the current state. Apply executes the changes. A strong candidate mentions that in CI/CD pipelines it is standard practice to run plan in pull requests for review, and apply only after merge and approval. Running apply without a plan review in production is a common mistake.

“What is a Terraform module and what problem does it solve?” Testing: code organisation knowledge. A module is a reusable, self-contained unit of Terraform configuration. Modules solve the duplication problem — instead of copying the same VPC configuration across five environment directories, you write it once as a module and call it with different variable values. Interviewers want to hear about input variables, output values, and the distinction between root modules and child modules.

“What are Terraform workspaces and when would you use them?” Testing: environment management understanding. Workspaces allow multiple instances of the same state file from the same configuration directory. The intended use case is lightweight environment separation. However — and this is what separates strong candidates — most experienced engineers prefer separate directories or separate state backends per environment over workspaces, because workspaces share the same code and backend configuration, which makes true isolation difficult.

“What is a data source in Terraform?” Testing: configuration reading ability. Data sources allow Terraform to query existing infrastructure that it did not create. For example, you might use data "aws_vpc" to look up an existing VPC by tag and reference its ID in a new subnet resource. This is important for working with infrastructure that was created before Terraform, or managed by a different team.

“How do Terraform providers work?” Testing: understanding of extensibility. Providers are plugins that Terraform uses to interact with APIs — AWS, GCP, Azure, GitHub, Datadog, and thousands more. Each provider is downloaded during terraform init. The interviewer may ask about provider versions and why pinning provider versions matters (breaking changes in new provider versions can break existing configurations).

“What is terraform import and when would you use it?” Testing: real-world migration experience. terraform import brings an existing resource that was created outside Terraform into state so Terraform can manage it going forward. Use case: a team hand-created an RDS instance six months ago and now wants it under Terraform management. The candidate should mention that import only updates state — the configuration still needs to be written manually.

“What are lifecycle rules in Terraform and when would you use create_before_destroy?” Testing: resource lifecycle understanding. Lifecycle rules control how Terraform handles resource replacement. create_before_destroy tells Terraform to create the replacement resource before destroying the old one — useful for resources like load balancer target groups where a brief outage during replacement is unacceptable. prevent_destroy adds a safeguard against accidentally destroying critical resources like databases.

Questions About Variables and Configuration#

“What is the difference between input variables, local values, and output values?” Testing: HCL structure knowledge. Input variables are parameters passed to a module or root configuration. Local values are computed values within a module, reducing repetition. Output values expose information from a module or root configuration for use elsewhere — essential for passing resource IDs between modules.

“How do you manage sensitive values in Terraform?” Testing: secrets hygiene. Sensitive variables can be marked with sensitive = true to prevent them appearing in plan output. But the deeper concern — which the interviewer is really asking about — is that sensitive values still end up in state files. State must be encrypted at rest (S3 with SSE, GCS with CMEK). For high-sensitivity secrets, managing them in a secrets manager and referencing them via data sources at runtime is safer than passing them as Terraform variables at all.

“What is terraform.tfvars and how does variable precedence work?” Testing: practical configuration knowledge. terraform.tfvars is the default file Terraform reads for variable values. Precedence (lower wins): defaults in variable blocks, then terraform.tfvars, then *.auto.tfvars, then -var-file flags, then individual -var flags on the command line. Environment variables prefixed with TF_VAR_ are also read.

Questions About Structure and Tooling#

“How would you structure Terraform for multiple environments?” Testing: team engineering thinking. Common patterns: separate directories per environment (environments/dev, environments/staging, environments/prod) each with their own backend configuration and state file; or a single root module with workspaces. Most experienced teams prefer directory separation for clearer isolation, simpler access control (different IAM for different state backends), and the ability to promote infrastructure changes from dev through to prod with explicit control.

“Have you used Terragrunt and why would you use it?” Testing: ecosystem awareness. Terragrunt is a thin wrapper around Terraform that adds DRY patterns for backend configuration, dependency management between modules, and environment promotion workflows. It is widely used in large Terraform codebases where the repetition in backend configuration becomes painful. Not required knowledge, but showing familiarity signals genuine Terraform experience.

“What is terraform validate and when does it help?” Testing: development workflow knowledge. terraform validate checks whether configuration is syntactically valid and internally consistent, without contacting any remote APIs. Useful in CI to catch obvious mistakes before plan runs. It does not check whether referenced resources exist or whether provider credentials are valid.

Scenario Question: Multi-Engineer State Management#

An interviewer might ask: “You need to manage Terraform state for a team of five engineers working across dev, staging, and prod environments. How would you structure this?”

A strong answer covers:

Remote state backend — Use S3 with DynamoDB for state locking (AWS), or GCS with a Cloud Storage backend (GCP). State files should never live on a laptop.

Environment separation — Separate state files per environment, stored in separate paths or buckets. Dev engineers should be able to run terraform apply in dev without touching prod state. Prod state should require elevated permissions.

Module structure — Shared infrastructure components (VPC, security groups, IAM roles) live in modules. Environment directories call those modules with environment-specific variable values. This avoids copying and diverging configuration.

CI/CD integration — Plan runs automatically on pull requests; engineers review the plan output before merging. Apply runs automatically after merge to the environment branch, using a service account with only the minimum permissions needed. No engineer runs terraform apply locally against staging or prod.

State access controls — The S3 bucket or GCS bucket holding state should have strict IAM controls, versioning enabled (so state can be recovered if corrupted), and server-side encryption.

Common Terraform Interview Mistakes#

Not understanding state. The single most common failure. Candidates describe Terraform as “it reads your config and creates the infrastructure” without understanding that state is the key mechanism. If you do not understand what state is and why it can go wrong, you will fail Terraform questions at mid-level and above.

Running apply without reviewing the plan. Some candidates describe their workflow as “I run apply and check if anything breaks.” This is not acceptable for production infrastructure. Interviewers will probe whether you review plan output before applying.

Hardcoded secrets in configuration. Describing secrets passed directly as variable values in code, or committed to a repository, is an immediate concern signal in a security-aware interview.

Using workspaces for everything. Workspaces are often described as the answer to environment management. They can work for simple cases but have real limitations that experienced interviewers know. Showing awareness of those limitations (shared backend, same code for all envs, harder access control) is a mark of experience.

Terraform vs Pulumi vs CloudFormation: What to Say in Interviews#

You may be asked how Terraform compares to alternatives. Here is what to know:

CloudFormation is AWS-native, no separate state backend needed (AWS manages state), tightly integrated with AWS services. Limitations: verbose, AWS-only, slower feedback loop during development.

Pulumi uses real programming languages (TypeScript, Python, Go) instead of HCL. This is appealing to software engineers. State management works similarly to Terraform. The trade-off: team members need programming language knowledge, and the learning curve is different.

Terraform/OpenTofu works across providers (AWS, GCP, Azure, Kubernetes, GitHub, PagerDuty, etc.) with a consistent workflow. HCL is approachable and purpose-built for configuration. The multi-provider support is the strongest reason to choose it over CloudFormation for multi-cloud or mixed environments.

The right interview answer: understand the trade-offs and describe when each makes sense, rather than advocating for one tool universally.