Terraform Interview Questions and Answers

What interviewers are testing: Whether you distinguish declarative infrastructure lifecycle management from procedural configuration or language-specific IaC—not tool logos.

A strong answer is:

"I use Terraform to create and wire cloud resources with a plan-first workflow. Ansible configures what already exists. Picking between them is about lifecycle management versus task orchestration—not which logo is on the slide."

What interviewers are testing: Whether you describe the declarative plan/apply loop and how configuration, state, and provider refresh interact—not just "Terraform is IaC."

Terraform is an infrastructure as code tool that reads HCL configuration, builds a dependency graph, and drives provider APIs to reach the declared desired state. The core workflow is init → plan → apply with a persisted state file tracking real-world IDs.

See what is Terraform and how Terraform works for the full execution model.

A strong answer is:

"Terraform reads configuration, refreshes managed objects through providers, uses state to map resource addresses to real objects, then builds an execution plan to converge infrastructure toward the configuration."

What interviewers are testing: Whether you narrate fmt → validate → saved plan → review → apply and treat plan files as sensitive artifacts.

Safe workflow:

1. terraform fmt — format consistency (terraform fmt)
2. terraform validate — static check (terraform validate)
3. terraform plan -out=plan.tfplan — preview changes
4. Human or CI review — read add/change/destroy counts
5. terraform apply plan.tfplan — apply exact planned graph

Saved plan files can contain sensitive values and backend information, so keep them out of Git and protect them like Terraform state.

A strong answer is:

"I never apply blind. Plan to a file, review in CI or with a teammate, then apply that saved plan so what runs matches what we approved."

What interviewers are testing: Whether you name the core configuration blocks—terraform, provider, resource, data, variable, output, locals—and what each contributes to a module.

Example resource:

resource "local_file" "demo" {
  filename = "${path.module}/hello.txt"
  content  = "interview prep"
}

A strong answer is:

"Providers talk to APIs; resources are the objects I manage. Variables feed inputs, outputs expose results, and locals keep expressions readable without extra input prompts."

What interviewers are testing: Whether you understand providers as separately versioned plugins, know where version constraints belong, and understand the role of .terraform.lock.hcl.

A provider is a plugin that implements resource types for one platform—AWS, Azure, Kubernetes, or hashicorp/local for files on disk.

terraform init downloads provider binaries listed in required_providers and records versions in the dependency lock file (provider version lock).

A strong answer is:

"I declare provider version constraints in required_providers and commit .terraform.lock.hcl, which records the selected provider versions and checksums. Normal init reuses those selections; init -upgrade deliberately reevaluates them."

What interviewers are testing: Whether you distinguish lifecycle management through a resource block from read-only lookup through a data block—the underlying object may still be managed elsewhere.

Example: data.aws_ami looks up an AMI ID; resource.aws_instance creates the EC2 instance. See Terraform data sources.

A strong answer is:

"A resource block manages lifecycle; a data source only reads information. The underlying object may be managed elsewhere by Terraform, another system, or manually."

What interviewers are testing: Whether you know CLI variable precedence and keep secrets out of committed tfvars while considering state/plan persistence.

For Terraform CLI, variable sources apply in this order from lowest to highest precedence:

1. Default in the variable block
2. TF_VAR_* environment variables
3. terraform.tfvars and terraform.tfvars.json
4. *.auto.tfvars and *.auto.tfvars.json (lexical order)
5. -var and -var-file options (processed in command-line order)

CLI -var and -var-file are the highest of these local sources. Full patterns: terraform variables.

variable "environment" {
  type        = string
  description = "Deployment environment name"
  default     = "dev"
}

A strong answer is:

"I keep secret values out of committed .tfvars files and supply them through the CI/HCP secret mechanism or another approved secret-injection path. For sensitive inputs I also check whether the value will persist in state or plans."

What interviewers are testing: Whether you treat outputs as a module's public interface and know some values are plan-known while computed attributes may stay unknown until apply.

Outputs expose selected values from a module or root configuration. Some are known during planning; provider-computed values may remain unknown until apply—for humans, scripts, or remote state consumers.

output "web_address" {
  value       = "http://${aws_instance.web.public_ip}"
  description = "Public URL of the web tier"
}

Mark sensitive outputs when they contain secrets (terraform sensitive data). terraform_remote_state exposes root outputs, not arbitrary internal resource attributes. Full patterns in terraform output.

A strong answer is:

"Outputs form the public interface of a module or root configuration. Child-module outputs feed parent modules, automation can consume root outputs, and separate configurations can consume published values through remote state or another explicit data-sharing mechanism."

What interviewers are testing: Whether you explain state as the binding between configuration addresses and remote objects—not merely a cache for the dependency graph.

State maps HCL addresses (aws_instance.web) to real IDs (i-0abc123). Providers need those IDs for updates and destroys. State stores the binding between resource instances and remote objects along with metadata and last-known attribute values Terraform needs during planning and refresh.

Without state, Terraform would not know which remote object matches each resource block. Deep dive: Terraform state.

A strong answer is:

"State is Terraform's mapping between resource addresses in configuration and the real objects Terraform manages, including resources it created or imported. Plan compares config plus state to the provider's live view—missing state means Terraform may try to recreate or lose track of orphans."

What interviewers are testing: Whether you treat remote state as confidential—credentials, private keys, and resource metadata require encryption and RBAC.

State can contain secrets even when variables or outputs are marked sensitive—sensitive = true primarily redacts display in normal CLI output; Terraform can still store the value in state and saved plans. Newer mechanisms such as ephemeral values and provider write-only arguments reduce what persists, but provider support and restrictions apply.

For S3 specifically, HashiCorp recommends enabling bucket versioning for state recovery. State commands: terraform state command. Sensitive handling: terraform sensitive data.

A strong answer is:

"I store shared state remotely with appropriate encryption and access controls, enable backend-supported locking where available, and never commit state to Git because it can contain full resource attributes and secrets."

What interviewers are testing: Whether you know locking is backend-specific, can configure S3 native locking, and treat bucket versioning as a recovery layer.

A backend block configures where state lives—S3, GCS, Azure Blob, HCP Terraform, etc. For backends that support locking, Terraform automatically acquires a lock for operations that can write state; backend configuration determines how that lock is implemented.

Current S3 backend example with native state locking:

terraform {
  backend "s3" {
    bucket       = "team-terraform-state"
    key          = "prod/network/terraform.tfstate"
    region       = "us-east-1"
    use_lockfile = true
    encrypt      = true
  }
}

Older S3 backend configurations may use DynamoDB locking, but that mechanism is deprecated in current Terraform and will be removed in a future minor release.

Enable S3 bucket versioning as a recovery layer for accidental state deletion or overwrite.

Lesson: Terraform backend remote state and state locking.

A strong answer is:

"Remote state centralizes state, and I explicitly enable a backend-supported locking mechanism—for S3 today, use_lockfile = true—so concurrent applies cannot both modify state."

What interviewers are testing: Whether you justify modules for reuse, stable interfaces, and version pinning—not copy-paste HCL reduction alone.

Modules bundle reusable configuration trees—network, EKS cluster, database—with defined inputs and outputs. Root modules call child modules; child modules hide complexity.

module "vpc" {
  source = "./modules/vpc"
  cidr   = var.vpc_cidr
}

Pin registry modules with version constraints and pin VCS modules with an immutable tag or commit ref (terraform registry modules). Structure guide: terraform modules.

A strong answer is:

"Modules are reusable packages. I expose a small variable surface and outputs so every environment calls the same VPC module instead of forking copy-paste HCL."

What interviewers are testing: Whether you pin registry modules with version and Git modules with ref, and know .terraform.lock.hcl locks providers—not remote module selections.

Registry call:

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

Git call pins a ref:

module "app" {
  source = "git::https://example.com/infra.git//modules/app?ref=v2.1.0"
}

The dependency lock file locks providers, not remote module versions—Terraform reselects modules from the source/version constraint on initialization, so module pinning matters independently.

See module source version for ref strategies.

A strong answer is:

"I pin registry modules with version = and Git modules with ref tags. Floating refs in production are how surprise schema changes land on Friday applies."

What interviewers are testing: Whether you pick for_each with stable string keys over count when resource identity must survive list reordering.

for_each keys must be stable—changing a key destroys and recreates. With count, instances are identified by numeric index. If those indices correspond to elements in an ordered list, inserting or removing an element can shift identities and cause unexpected replacements.

Full lesson: terraform count for_each.

A strong answer is:

"for_each when each instance has a meaningful name or key—subnets by region, users by email. count for homogeneous replicas or boolean optional resources. I avoid count on ordered lists that reorder."

What interviewers are testing: Whether you understand for_each keys drive resource address identity and a rename triggers destroy/create.

for_each uses the key as the identity in state. Renaming "web" to "web-primary" makes Terraform plan destroy ["web"] and create ["web-primary"]—even if the cloud object could have been renamed in place.

Fix paths:

1. moved block — tell Terraform the new address (moved removed block)
2. terraform state mv — manual state address rename
3. Design keys on immutable IDs, not display names

A strong answer is:

"Keys are identities. I use stable IDs in for_each maps and moved blocks when I refactor addresses—otherwise Terraform rightly plans destroy/create."

What interviewers are testing: Whether you rely on expression references for normal dependency edges and reserve depends_on for dependencies Terraform cannot infer.

Default order follows the dependency graph—if resource A references B's attributes, A depends on B. Explicit depends_on breaks rare ordering gaps when references are invisible.

Implicit reference:

resource "local_file" "child" {
  content  = local_file.parent.content
  filename = "child.txt"
}

Resource dependencies lesson: terraform resource dependencies.

A strong answer is:

"References build the graph automatically. I use depends_on only for a real dependency Terraform cannot infer from expression references—for example when one resource's behavior depends on another even though no attribute reference connects them. I do not use depends_on as a generic delay or eventual-consistency workaround."

What interviewers are testing: Whether you know when create_before_destroy, prevent_destroy, and ignore_changes apply—and that ignore_changes is not a drift-hiding crutch.

Details: terraform lifecycle.

A strong answer is:

"create_before_destroy can reduce downtime when the platform permits old and new instances to coexist. prevent_destroy is a guardrail for critical resources, and ignore_changes is for attributes intentionally managed outside Terraform—not for hiding unexplained drift."

What interviewers are testing: Whether you distinguish CLI workspaces from HCP Terraform workspaces and know CLI workspaces are weak environment isolation.

Terraform CLI workspaces are multiple state instances inside one backend configuration—default, staging, prod—not separate cloud accounts by magic.

terraform workspace list
terraform workspace select staging

CLI workspaces are not HCP Terraform workspaces. HashiCorp distinguishes them: CLI workspaces are multiple state files attached to the same working directory and backend; HCP Terraform workspaces are broader execution boundaries with their own state, variables, and run settings.

Use CLI workspaces for ephemeral environments or small teams. CLI workspaces are not recommended as the isolation mechanism when environments require separate credentials or access controls—separate configurations or backends are usually clearer for that case. Lesson: terraform workspaces.

A strong answer is:

"Workspaces split state under the same backend config. I use them for quick sandboxes; for prod I often prefer separate state buckets or keys so blast radius and IAM differ per environment."

What interviewers are testing: Whether you know import binds addresses to existing objects, generated config is a starting point, and -generate-config-out remains experimental.

Two common paths:

Configuration-driven import:

import {
  to = aws_instance.web
  id = "i-0abc123"
}

Then plan with optional config generation:

terraform plan -generate-config-out=generated.tf

Import associates an existing remote object with a Terraform resource address. With configuration-driven import, Terraform can also generate starter resource configuration using -generate-config-out, but you should review and simplify that generated HCL rather than treating it as production-ready configuration.

As of current Terraform documentation, configuration generation with -generate-config-out remains experimental—review generated HCL especially carefully and prune attributes rather than accepting every provider default.

Then terraform plan should show no changes once config matches reality. Guide: terraform import.

A strong answer is:

"Import attaches an address to an existing ID. I write or generate matching HCL, import, then plan until clean—generated config is a starting point, not something I apply blindly."

What interviewers are testing: Whether you use moved blocks to preserve remote objects during address refactors when the move is valid.

moved blocks declare resource/module address changes so Terraform can update state bindings without destroying the underlying object where the move is valid.

Common cases:

• resource rename within a module
• move into or out of a module
• count/for_each address migrations
• compatible type changes where Terraform and the provider support them

moved {
  from = aws_instance.web
  to   = module.web.aws_instance.this
}

Paired with terraform moved removed block lesson content.

A strong answer is:

"moved blocks are my refactor tool—rename modules or split resources while telling state the new address. I still verify with plan before apply."

What interviewers are testing: Whether you can distinguish configuration, state, and live infrastructure and decide whether to revert drift or adopt it intentionally.

Drift means live infrastructure differs from state—someone edited the console, autoscaling changed capacity, or a failed apply left partial changes.

Responses:

If the out-of-band change is intentional, update configuration to represent the new desired state and use refresh-only only when you deliberately need to synchronize state/output values. Do not treat refresh-only as a substitute for fixing HCL—refresh-only updates state but not configuration.

A strong answer is:

"Drift shows up in plan. I either apply Terraform's desired state back, or update HCL when the change is intentional—refresh-only syncs state to reality but does not make drift the new desired configuration."

What interviewers are testing: Whether you configure multiple provider instances with aliases and pass them into child modules via the providers map.

Aliases configure multiple instances of the same provider—multi-region AWS, separate AWS accounts, or prod versus DR Kubernetes clusters.

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

resource "aws_s3_bucket" "backup" {
  provider = aws.west
  bucket   = "logs-west"
}

For child modules, pass required provider configurations through the module's providers map; the child declares expected aliases with configuration_aliases. Lesson: terraform provider alias module.

A strong answer is:

"Provider aliases let me configure the same provider for multiple regions or accounts. For child modules, I pass the required provider configurations through the module's providers map, and the child declares any expected aliases with configuration_aliases."

What interviewers are testing: Whether you separate fmt/validate/plan gates from policy-as-code and static IaC security tools.

Typical pipeline:

1. terraform fmt -check — formatting
2. terraform init -backend=false then terraform validate — configuration and provider schema validation without remote backend
3. terraform plan on PR — post diff to review
4. Policy-as-code — Sentinel, OPA, or your organization's policy system
5. Static IaC security/lint tools — Checkov, tfsec, TFLint as applicable
6. Apply only from protected branch with OIDC credentials—not long-lived keys

terraform validate checks configuration syntax and schema; it is not policy-as-code. For module tests, see terraform test in Q31. Full patterns: terraform CI/CD and terraform test.

A strong answer is:

"CI runs fmt, validate, and plan on every PR. Apply uses short-lived cloud credentials and only after human or policy approval—never auto-apply from laptop state."

What interviewers are testing: Whether you verify no active apply holds the lock before force-unlock and re-plan immediately after clearing a stale lock.

Ordered response:

1. Confirm another pipeline or engineer is not legitimately applying
2. Read lock info — lock ID, who, timestamp in error message
3. Wait if active apply is running
4. terraform force-unlock LOCK_ID only when lock is stale after crashed process
5. Re-plan immediately — the failed apply may have partially changed infrastructure; reconcile before retrying

Never force-unlock while someone else applies.

Locking reference: terraform state locking.

A strong answer is:

"I verify the lock is stale—a crashed CI job—not an in-flight apply. force-unlock is last resort with the lock ID, then I re-plan immediately to reconcile any partially completed changes."

What interviewers are testing: Whether you fix constraints or network/mirror issues and use init -upgrade intentionally—not hand-edit .terraform.lock.hcl.

Checklist:

1. Network — can CI reach registry.terraform.io?
2. Version constraint — typo in required_providers
3. Lock file drift — inconsistent lock file after manual edits (inconsistent dependency lock file)
4. Platform — wrong OS/arch binary in air-gapped env—use provider mirror
5. Clear working cache — remove .terraform and re-init; do not delete .terraform.lock.hcl as routine troubleshooting

rm -rf .terraform && terraform init

For an intentional provider upgrade, use terraform init -upgrade within constraints and review the resulting lock-file diff. Init lesson: terraform init.

A strong answer is:

"I fix the provider source/version constraints or network/mirror issue, then rerun terraform init; for an intentional provider upgrade I use terraform init -upgrade and review the resulting lock-file diff."

What interviewers are testing: Whether you know computed attributes resolve during apply and downstream references still wire correctly.

Some attributes are unknown until the provider creates the resource—generated IDs, computed IPs. Plan shows (known after apply) for those values.

Downstream resources that reference them still work—Terraform wires dependencies and resolves values during apply. Lesson: terraform known after apply.

A strong answer is:

"(known after apply) means the provider computes that attribute during creation or update. Terraform can still pass the unknown value through dependency expressions and resolve it during apply."

What interviewers are testing: Whether you verify workspace, backend, and variables before debugging HCL—and never use -target to hide an unexpected destroy.

Stop—do not apply.

1. Verify workspace / backend / state key — planning against the wrong environment is a common catastrophic mistake
2. Verify variable files and credentials/account
3. Read plan line — which address and why (attribute change, removed block, key change)
4. Compare to last good plan in CI
5. Check recent HCL edits—count index shift, for_each key rename, removed lifecycle
6. Refresh-only plan if suspect stale state
7. Revert commit or fix HCL; re-plan until destroy disappears
8. prevent_destroy on critical resources as guardrail

Do not use -target merely to hide an unexpected destroy from the plan; fix the root cause. HashiCorp treats targeting as an exceptional recovery/troubleshooting mechanism, not normal deployment workflow.

Troubleshooting library: terraform troubleshooting and terraform debug logging.

A strong answer is:

"Unexpected destroys are a full stop. I verify workspace and backend first, diff the plan against the last green build, find the HCL or state address change that triggered it, and re-plan until the destroy count is zero before anyone applies."

What interviewers are testing: Whether you distinguish normal plan refresh, refresh-only state sync, and deprecated terraform refresh.

Accepting drift into state does not automatically update HCL. If someone manually changes a resource and you accept that into state with refresh-only, but configuration still requests the old value, a subsequent normal plan may attempt to restore the configured value.

Lesson: terraform drift refresh only.

A strong answer is:

"Normal plan refreshes then diffs config against state. Refresh-only updates state to match reality without applying changes—but my HCL still defines what Terraform will try to converge to on the next normal plan."

What interviewers are testing: Whether you prefer -replace over deprecated taint so replacement intent appears in the plan.

Modern approach—replacement intent is visible in the plan:

terraform plan -replace='aws_instance.web'
terraform apply -replace='aws_instance.web'

terraform taint still exists but is deprecated; -replace is preferred because the replacement shows in the plan instead of first mutating state.

A strong answer is:

"I use -replace so the destroy/create shows explicitly in plan review. taint is legacy—I avoid it in new workflows."

What interviewers are testing: Whether you know sensitive controls display redaction while ephemeral controls persistence—and the concepts are orthogonal.

sensitive and ephemeral are orthogonal: sensitive controls display redaction; ephemeral controls persistence. A value can require both depending on context.

Terraform 1.10+ introduced ephemeral variables and child outputs; Terraform 1.11+ supports provider-defined write-only resource arguments.

Lesson: terraform sensitive data.

A strong answer is:

"sensitive hides secrets from routine output but not from state. ephemeral is for values that should not persist in artifacts at all—when the provider and Terraform version support it."

What interviewers are testing: Whether you know Terraform tests can execute plans or applies and when mock providers avoid creating real infrastructure.

terraform test executes test run blocks that can perform plans or applies. Tests using real providers can create real infrastructure that costs money—run them in isolated test accounts/projects and ensure cleanup; use mock providers when real infrastructure is unnecessary. It complements, not replaces, CI plan gates and policy engines.

Lesson: terraform test.

A strong answer is:

"terraform validate catches configuration/schema problems; terraform test verifies behavior with assertions. I use mock providers when provider calls are unnecessary and isolated real accounts when I need integration-level confidence."

What interviewers are testing: Whether you keep variables as the module input surface and locals for internal derived expressions.

variable "environment" {
  type = string
}

variable "application" {
  type = string
}

locals {
  name_prefix = "${var.environment}-${var.application}"
}

Use variables at module boundaries; use locals to avoid repeating expressions or building derived names inside a module. Lesson: terraform locals.

A strong answer is:

"Variables are the public input surface. Locals are private computed values inside the module—I do not expect callers to set them."