Top 10 Terraform Associate (003) interview questions and how to answer them in 2026

The 10 questions

1. What’s the difference between count and for_each?

count creates an indexed list accessed as resource[0], resource[1]. Adding or removing an item in the middle of the list re-creates everything downstream because indexes shift. for_each iterates over a map or set of strings and uses the key as a stable identifier — adding or removing items only touches the specific entry. Use for_each for any list of named resources (subnets, IAM users, S3 buckets); reserve count for boolean toggles like count = var.enabled ? 1 : 0. Picking count for a real list is the most common production mistake.

2. How does Terraform handle remote state and why use it?

Remote state stores the .tfstate file in a backend (S3 with DynamoDB lock, HCP Terraform, Azure Storage, GCS) instead of locally. Team workflows require it for three reasons: state locking prevents concurrent apply from corrupting the file, secrets in state are kept off developer laptops, and CI/CD pipelines need a shared source of truth. Local state is acceptable only for single-developer prototypes. Candidates who say “we just commit it to git” lose the offer.

3. What’s the difference between terraform plan, apply, and refresh?

plan compares the desired configuration to the recorded state and shows a dry run. apply executes the plan against real infrastructure and updates state. refresh (now -refresh-only mode in modern versions) re-reads the actual resource attributes from providers and updates state without changing infrastructure — useful when something was changed out-of-band. terraform plan implicitly refreshes by default unless you pass -refresh=false.

4. How do you handle secrets in Terraform state?

Three practices stack. First, encrypt the state backend at rest (S3 SSE-KMS, HCP Terraform default). Second, restrict bucket read access via IAM — only the CI role and a small ops group should read it. Third, never put plaintext secrets in tfvars committed to git. Use sensitive = true on outputs to suppress CLI display, pull secrets from Vault or AWS Secrets Manager via data sources, and never run terraform show on a shared screen. Saying “the state file is just JSON” in front of a security-aware hiring manager is a tell.

5. Walk me through create_before_destroy and prevent_destroy.

Both live inside a lifecycle {} block. create_before_destroy = true tells Terraform to provision the new resource before tearing down the old one — essential for stateful resources behind a load balancer where the default destroy-then-create causes downtime. prevent_destroy = true makes terraform destroy error out for that resource — a guardrail on production databases and DNS zones, but it doesn’t prevent plan-time changes that effectively replace the resource (those still fail loudly). Use both together for production-critical stateful resources.

6. What are modules and how do you version them?

A module is a reusable directory of .tf files with declared inputs (variables) and outputs. The root module calls child modules via module "name" { source = "..." }. Sources can be local paths, git refs (git::https://...?ref=v1.2.0), HCP Terraform Private Registry, or the public Terraform Registry. Pin every module to an immutable version — either a semver tag or a git SHA — never main. Treat modules like libraries: semver them, publish a changelog, and test before bumping consumers.

7. local-exec vs remote-exec provisioners — when do you actually use them?

Honest answer: rarely. HashiCorp’s own guidance is to treat provisioners as a last resort. local-exec runs a command on the Terraform host (CI runner); remote-exec SSHs into the created resource and runs commands there. Prefer cloud-init / user_data / image baking with Packer / configuration management with Ansible. Saying “we provision the VM with remote-exec” in 2026 reveals an older codebase — modern stacks use immutable images and let Terraform stop at “resource exists.”

8. How do you manage multiple environments — workspaces vs directories vs separate state?

Three patterns. Workspaces (terraform workspace new staging) keep one codebase and one backend, switching the state key per workspace — cheapest but riskiest because a typo can apply to the wrong environment. Separate directories (environments/staging/main.tf, environments/prod/main.tf) with shared modules give clear isolation and per-env backends — the most common production pattern. HCP Terraform organizations and projects do the same with UI guardrails. The right answer for an interview is “separate directories with shared modules, per-env backend, per-env IAM role.”

9. What’s the difference between a data source and a resource?

A resource block declares something Terraform manages — it’ll create, update, and destroy it. A data block declares something Terraform reads but doesn’t manage — an existing VPC, the latest Amazon Linux AMI, a Vault secret, the current AWS account ID. Data sources resolve at plan time and feed dynamic inputs into resources. Confusing them in an interview is the fastest way to fail the Terraform technical screen.

10. How much do Terraform-anchored DevOps and platform roles pay in 2026?

$115,000–$145,000 mid-level in the US for DevOps and platform engineer roles with Terraform on the daily stack. Senior platform engineers at FAANG and well-funded startups reach $170,000–$210,000 base. The official HashiCorp Terraform Associate page covers current exam objectives. BLS reports a 2024 median of $104,420 for all computer occupations; IaC-heavy DevOps roles consistently exceed that by 30–50%.

What these questions test

Every question has a “docs answer” and an “operational answer.” Interviewers want the operational one — the version that includes the gotcha (index shifting under count, state locking under remote backends, prevent_destroy not catching plan-time replacements, provisioners being a last resort). Passing the 003 exam proves you can recognize the right Terraform syntax. Answering these correctly proves you’ve actually run terraform apply against production.

Frequently asked questions