Terraform Engineer Interview Questions & Answers

A Terraform Engineer owns the Infrastructure as Code (IaC) platform and standards. Unlike Cloud Engineers who use Terraform as one tool, Terraform Engineers specialise in HCL, modules, state management, policy as code, and CI/CD pipelines for infrastructure. This role differentiates from DevOps Engineers (who focus on broader deployment and CI/CD) and Platform Engineers (who build self-service platforms using IaC foundations). These 40+ questions test whether candidates can architect, maintain, and secure Terraform at scale.

This guide covers behavioural questions (team collaboration, incident management), core technical areas (HCL and modules, multi-environment deployment, policy and testing), and real-world scenarios. Use these to assess candidates' understanding of state locking, remote backends, workspaces, providers, Terragrunt, Sentinel policy as code, and infrastructure testing.

Terraform Engineer Interview Process Overview

HCL, Modules & State Management

• What's the difference between 'terraform plan', 'terraform apply', and 'terraform refresh'? Why would you run refresh before plan in a team environment?

  Sample Answer Guidance: Plan shows intended changes without modifying anything. Apply executes changes. Refresh updates local state to match real infrastructure without changing it. In teams, refresh syncs state before plan to avoid deploying stale changes and risking conflicts.
• Explain Terraform state. Why is it critical, what problems arise from local state, and how does remote state solve those problems?

  Sample Answer Guidance: State is the record of real infrastructure Terraform has created. Local state is unsafe for teams (no locking, version control risks). Remote state (S3, Terraform Cloud, Consul) enables locking, audit trails, and concurrency control. Backends like S3 with DynamoDB locking prevent concurrent applies that corrupt state.
• How would you structure a reusable module in Terraform? What goes in variables.tf, main.tf, outputs.tf, and why?

  Sample Answer Guidance: variables.tf declares module inputs with descriptions and defaults. main.tf contains resource definitions. outputs.tf exposes values for downstream modules. This separation makes modules composable and testable. Each file has a clear responsibility, aiding readability and maintenance.
• What is state locking, and why is it essential? How do you implement it with S3 and DynamoDB?

  Sample Answer Guidance: State locking prevents concurrent applies that corrupt state. With S3, DynamoDB stores lock metadata. When apply runs, Terraform acquires a lock via DynamoDB; if another apply starts, it waits or fails. This ensures only one engineer modifies infrastructure at a time.
• Describe the terraform import command. When would you use it, and what are its limitations?

  Sample Answer Guidance: terraform import brings existing infrastructure under Terraform management without recreating it. Use it when resources exist but aren't in code yet. Limitations: it only updates state, not the Terraform configuration—you still write the resource block manually. It can't import complex relationships like security group rules easily.
• How do you handle sensitive data (API keys, passwords, database credentials) in Terraform? What's the best practice?

  Sample Answer Guidance: Use 'sensitive' flag on variables and outputs to prevent values from appearing in logs or terminal output. Store secrets in HashiCorp Vault, AWS Secrets Manager, or Terraform Cloud's variable store. Never commit secrets to version control; use .gitignore and encrypted backend state.
• What's the difference between a 'count' and 'for_each' in Terraform? When would you choose one over the other?

  Sample Answer Guidance: count uses numeric indices; for_each uses map keys (more stable). Use for_each when order doesn't matter and you want stable resource addressing—if you remove an element mid-list, only that element is destroyed. count is simpler for fixed repetition. for_each is safer for dynamic lists.

CI/CD for Infrastructure, Testing & Policy as Code

• Design a CI/CD pipeline for Terraform. What steps would you include between pushing code and apply?

  Sample Answer Guidance: Pipeline: terraform init → fmt/lint (tflint) → validate → plan (saved to artifact) → human approval → apply. Earlier steps catch syntax errors and policy violations before plan. Plan review ensures safety. Never auto-apply to prod. Use branch protection (require PR reviews) before merge to main.
• What is Terratest? How would you write a test for a Terraform module that provisions an RDS database?

  Sample Answer Guidance: Terratest is a Go testing framework for infrastructure. Test an RDS module by: deploying it via terraform.InitAndApply(), querying AWS to verify DB exists with correct settings (encrypted, multi-AZ), then terraform.Destroy() to clean up. This verifies the module produces expected infrastructure without manual testing.
• Explain policy as code in Terraform. Compare Sentinel and OPA. When would you enforce that all resources must have cost tags?

  Sample Answer Guidance: Policy as code (Sentinel, OPA) blocks non-compliant Terraform plans. Sentinel is Terraform Cloud native; OPA is open-source and agnostic. Enforce cost tags via policy rule: every resource must have 'cost_centre' tag. This prevents untagged resources in prod, ensuring cost allocation and governance.
• How would you implement cost estimation in a Terraform CI/CD pipeline? Why is it important?

  Sample Answer Guidance: Terraform Cloud includes cost estimation: it shows monthly cost delta for each plan. Alternatively, use Infracost (open-source) in CI to comment cost changes on PRs. This prevents surprise expenses—engineers see 'RDS instance added: +$300/month' before approving, reducing billing incidents.
• Describe your approach to Terraform linting and formatting. What tools would you use and why?

  Sample Answer Guidance: Use terraform fmt to standardise code format (automatic in CI). Use tflint for linting (detect unused variables, deep checks). Use checkov for security scans (detect overly permissive security groups, unencrypted resources). Run all three in CI before plan to catch issues early and enforce consistency.
• How would you safely enable destroy operations in CI/CD without risking accidental resource deletion?

  Sample Answer Guidance: Never auto-approve destroy. Require manual step: terraform destroy only after explicit approval from senior engineer or team lead. Log all destroy operations. Use -target to destroy specific resources if needed, not blanket destroy. Protect critical resources via lifecycle { prevent_destroy = true } to block accidental deletion.

Evaluation Criteria