Terraform interview questions and answers

What is Terraform, and how is it different from Ansible?

Terraform is an infrastructure as code (IaC) tool. You describe the infrastructure you want in HashiCorp Configuration Language (HCL), and Terraform works out which API calls create, change or delete things to match. It is declarative: you write the end state, not the steps.

Ansible, Chef and Puppet are mainly configuration management tools. They install and configure software on servers that already exist. Terraform provisions the resources themselves, such as networks, databases, IAM roles and DNS records, across many providers, and it keeps a state file of what it created. Many teams use both: Terraform builds the servers, and an image or a configuration tool sets them up.

A strong answer also names the cost: Terraform depends on state, and state needs care. That sets up most of the follow-up questions.

Walk me through terraform init, plan and apply.

These commands are the core workflow:

• terraform init prepares the working folder. It downloads providers and modules, connects to the backend where state lives, and writes the dependency lock file .terraform.lock.hcl. Run it again after you add a provider, a module or a backend change.
• terraform plan reads state, refreshes it against the real infrastructure, compares that with your configuration and prints the difference. + means create, ~ update in place, - destroy, and -/+ destroy and then create a replacement (+/- when create_before_destroy flips the order).
• terraform apply makes the changes and updates state. Given a saved plan file, it applies exactly that plan, which is how pipelines make sure what was reviewed is what runs.
• terraform destroy removes everything the configuration manages. It is the same as terraform apply -destroy.

terraform init                # download providers and modules, set up the backend
terraform fmt -check          # fail if any file is not formatted
terraform validate            # check syntax and internal consistency
terraform plan -out=tfplan    # preview the changes and save the plan
terraform apply tfplan        # apply exactly the plan you reviewed

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

A resource block is something Terraform owns: it creates it, tracks it in state, updates it and destroys it. A data block only reads something that already exists, such as the newest AMI, an existing VPC or the current AWS account ID, and makes its attributes available to the rest of the configuration. Destroying the configuration never deletes what a data source read.

# A data source reads something Terraform does not manage.
data "aws_ami" "al2023" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-2023.*-x86_64"]
  }
}

# A resource is something Terraform creates, updates and destroys.
resource "aws_instance" "web" {
  ami           = data.aws_ami.al2023.id
  instance_type = "t3.micro"
}

How does Terraform decide the order to create resources?

Terraform builds a dependency graph from references. When one block refers to another, such as bucket = aws_s3_bucket.logs.id, that is an implicit dependency, so the bucket is created first and destroyed last. Resources with no path between them are created in parallel, up to 10 at a time by default (-parallelism=n changes that).

Use depends_on only for dependencies Terraform cannot see from references. The meta-arguments section below covers when.

resource "aws_s3_bucket" "logs" {
  bucket = "acme-logs-dev"
}

# This reference is an implicit dependency, so the bucket is created first.
resource "aws_s3_bucket_versioning" "logs" {
  bucket = aws_s3_bucket.logs.id

  versioning_configuration {
    status = "Enabled"
  }
}

What is a module, and when should you write one?

Every folder of .tf files is a module. The folder where you run Terraform is the root module, and it can call child modules with a module block from a local path, a Git repository or a registry. A module has inputs (variables), outputs and resources, so it works like a function for infrastructure.

Write one when the same group of resources repeats, such as a service with a load balancer, a container service and alarms, and you want one tested interface for it. Avoid thin wrappers around a single resource: they add a layer without hiding any decisions.

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name            = "app"
  cidr            = "10.0.0.0/16"
  azs             = ["us-east-1a", "us-east-1b"]
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24"]
  private_subnets = ["10.0.11.0/24", "10.0.12.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

# Read the module's outputs like any other attribute.
resource "aws_security_group" "app" {
  name   = "app"
  vpc_id = module.vpc.vpc_id
}

How do you pass values between modules, and between stacks?

Inside one configuration, the parent passes values in as module arguments and reads values out as module.<name>.<output>. A module only sees what you pass it.

Between separate stacks with their own state, the terraform_remote_state data source reads another state's outputs. It is simple, but it couples the stacks tightly and the reader needs access to the whole state snapshot. Many teams publish shared values to SSM Parameter Store instead, or look them up with data sources, such as finding a VPC by its tags.

data "terraform_remote_state" "network" {
  backend = "s3"

  config = {
    bucket = "acme-tf-state"
    key    = "network/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_security_group" "app" {
  name   = "app"
  vpc_id = data.terraform_remote_state.network.outputs.vpc_id
}

How do you version and pin modules?

Registry modules take a version argument. ~> 5.1 allows any 5.x release from 5.1 up but never 6.0, and ~> 5.1.0 allows only 5.1.x patches. Git modules pin with ?ref= and a tag. Upgrade on purpose with terraform init -upgrade, then read the plan.

For your own modules, tag releases with semantic versions and keep a changelog. A breaking change to inputs is a new major version, and moved blocks inside the module help callers upgrade without replacing resources.

# Registry module: pin it with version.
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.1" # any 5.x from 5.1 up, never 6.0
}

# Git module: pin it to a tag with ref.
module "service" {
  source = "git::https://github.com/acme/terraform-modules.git//service?ref=v1.4.0"
}

What is a provider, and how do you pin its version?

A provider is a plugin that talks to one API, such as AWS, Kubernetes, GitHub or Datadog. Declare it in required_providers with a source and a version constraint, then configure it with a provider block. required_version pins the Terraform CLI version itself.

~> 5.0 means any 5.x and never 6.0, the usual way to take fixes without surprise major upgrades. In the AWS provider, default_tags adds tags to every resource that supports them.

terraform {
  required_version = ">= 1.5"

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

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      ManagedBy = "terraform"
    }
  }
}

What is .terraform.lock.hcl, and should you commit it?

Yes, commit it. terraform init writes the exact provider versions it chose, and their checksums, to this dependency lock file. With it in Git, every teammate and every CI run uses the same provider builds, and a tampered download fails the checksum.

The lock file tracks providers only, not modules. To move to newer provider versions, run terraform init -upgrade and commit the new file. If your team uses different operating systems, record hashes for each platform with terraform providers lock.

terraform init -upgrade        # move to the newest versions your constraints allow
terraform providers lock \
  -platform=linux_amd64 \
  -platform=darwin_arm64       # record hashes for Linux CI runners and Apple silicon Macs

How do you deploy to two AWS regions or accounts from one configuration?

Declare extra provider configurations with alias, then pick one per resource with provider = aws.west, or pass one into a module with providers = { aws = aws.prod }. For another account, use assume_role in the provider block so Terraform runs as a role in that account.

AWS provider 6.0, released in June 2025, adds a region argument to most resources, so one provider block can manage several regions. In 5.x, aliases are the way to do it.

provider "aws" {
  region = "us-east-1"
}

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

provider "aws" {
  alias  = "prod"
  region = "us-east-1"

  assume_role {
    role_arn = "arn:aws:iam::111122223333:role/terraform-deploy"
  }
}

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

module "prod_network" {
  source    = "./modules/network"
  providers = { aws = aws.prod }
}

How do you bring existing infrastructure under Terraform?

Since Terraform 1.5, write an import block with the resource address (to) and the cloud ID (id), plus a matching resource block, then plan. The plan shows the import and any difference between the real object and your code, and apply records it in state. Because it is code, the import goes through review like any other change.

To skip writing the resource block by hand, run terraform plan -generate-config-out=generated.tf and Terraform drafts it from the real object. Tidy what it writes. The older terraform import command still works, but it changes state right away and writes no configuration.

Terraform 1.7 added for_each to import blocks, so you can import many objects with one block.

import {
  to = aws_s3_bucket.legacy
  id = "acme-legacy-reports"
}

resource "aws_s3_bucket" "legacy" {
  bucket = "acme-legacy-reports"
}

# Write only the import block, then:
terraform plan -generate-config-out=generated.tf
# Review and tidy generated.tf, then plan again until it shows no changes.

# Terraform 1.7+: import many objects with one block.
import {
  for_each = toset(["acme-raw", "acme-clean"])
  to       = aws_s3_bucket.data[each.key]
  id       = each.key
}

resource "aws_s3_bucket" "data" {
  for_each = toset(["acme-raw", "acme-clean"])
  bucket   = each.key
}

How do you rename a resource, or move it into a module, without destroying it?

Add a moved block (Terraform 1.1+) with the old address in from and the new one in to. The next plan shows the resource as moved instead of destroyed and created. It also handles switching from count to for_each and moving resources into or out of modules.

Keep moved blocks in shared modules for a while after a release, so everyone who calls the module gets the move on their next plan.

# Renamed a resource
moved {
  from = aws_s3_bucket.logs
  to   = aws_s3_bucket.app_logs
}

# Switched from count to for_each
moved {
  from = aws_s3_bucket.data[0]
  to   = aws_s3_bucket.data["raw"]
}

# Moved a resource into a module
moved {
  from = aws_s3_bucket.assets
  to   = module.storage.aws_s3_bucket.assets
}

How do you stop managing a resource without deleting it?

In Terraform 1.7 and later, delete the resource block and add a removed block with lifecycle { destroy = false }. Terraform drops the resource from state and leaves the real object alone. On older versions, terraform state rm does the same from the command line, without the review step.

This is also how you hand a resource to another team or another stack: remove it here, then import it there.

# Terraform 1.7+: stop managing the bucket without deleting it.
removed {
  from = aws_s3_bucket.legacy

  lifecycle {
    destroy = false
  }
}

What is the difference between terraform fmt, validate and plan?

terraform fmt rewrites files into the standard style, and -check makes it fail instead, which is what CI runs. terraform validate checks syntax, types and references inside the configuration without calling any cloud API. It needs an initialized folder, so CI runs terraform init -backend=false first. terraform plan is the first step that talks to the provider APIs and reads state.

Add a linter such as TFLint for provider-specific mistakes, like an instance type that does not exist, and a security scanner such as Checkov or Trivy (which took over the checks from tfsec) for things like public buckets.

terraform fmt -check -recursive
terraform init -backend=false -input=false
terraform validate
tflint
trivy config .

How does terraform test work?

Terraform 1.6 added a built-in test framework. Test files end in .tftest.hcl and hold run blocks. Each run does a plan or an apply and then checks its assert blocks, each with a condition and an error_message. Runs that apply create real infrastructure, and Terraform destroys it at the end of the test file.

Use command = plan for quick checks of names, tags and counts. Since Terraform 1.7, mock providers let you test module logic without cloud credentials. Keep a few apply tests for what only real infrastructure can prove.

# Terraform 1.6+. Run with: terraform test
variables {
  environment = "dev"
}

run "bucket_name_includes_environment" {
  command = plan

  assert {
    condition     = aws_s3_bucket.logs.bucket == "acme-logs-dev"
    error_message = "The bucket name must include the environment."
  }
}

run "versioning_is_on" {
  command = plan

  assert {
    condition     = aws_s3_bucket_versioning.logs.versioning_configuration[0].status == "Enabled"
    error_message = "Versioning must be enabled."
  }
}

What are preconditions, postconditions and check blocks?

Preconditions and postconditions (Terraform 1.2+) live in the lifecycle block of a resource or data source, and outputs can have preconditions too. A precondition checks an assumption before Terraform acts, such as the AMI being x86_64. A postcondition checks the result, using self. If either fails, the run stops with your error message.

A check block (Terraform 1.5+) is a softer, ongoing assertion. It runs on every plan and apply and reports a warning when it fails, without blocking anything. It can hold its own data source, so it suits checks such as "does the health endpoint return 200?" after a change.

resource "aws_instance" "web" {
  ami           = data.aws_ami.al2023.id
  instance_type = var.instance_type

  lifecycle {
    precondition {
      condition     = data.aws_ami.al2023.architecture == "x86_64"
      error_message = "The AMI must be x86_64."
    }

    postcondition {
      condition     = self.public_dns != ""
      error_message = "The instance must get a public DNS name."
    }
  }
}

# Uses the hashicorp/http provider. A failed check is a warning, not an error.
check "health" {
  data "http" "app" {
    url = "https://${aws_lb.web.dns_name}/health"
  }

  assert {
    condition     = data.http.app.status_code == 200
    error_message = "The health check did not return 200."
  }
}

How do you keep secrets out of Terraform code and state?

Never put secrets in .tf files or committed .tfvars files. Pass them at run time, for example from your CI secret store as TF_VAR_ environment variables, or better, let the cloud service own them. With manage_master_user_password = true, RDS creates the database password in Secrets Manager itself, so Terraform never sees it.

Know what sensitive = true does and does not do: it hides a value in plan and apply output, but the value is still saved in state. Terraform 1.10 added ephemeral values, such as ephemeral variables and ephemeral resources, that are never saved in state or plan files, and 1.11 added write-only arguments, so a provider can receive a secret without storing it. Check that your provider version supports the argument you need.

variable "api_token" {
  type      = string
  sensitive = true # hidden in plan and apply output, but still saved in state
}

# Let RDS create and keep the password in Secrets Manager,
# so it never appears in your code, your state or your outputs.
resource "aws_db_instance" "orders" {
  identifier                  = "orders"
  engine                      = "postgres"
  instance_class              = "db.t3.micro"
  allocated_storage           = 20
  username                    = "app"
  manage_master_user_password = true
}

output "db_secret_arn" {
  description = "Where applications read the database credentials"
  value       = aws_db_instance.orders.master_user_secret[0].secret_arn
}

How do you secure state, and enforce rules across teams?

Keep state in a private, versioned, encrypted bucket with public access blocked, and let only the CI roles and a few admins read it. Use one state per environment so a mistake cannot reach prod, and log access to the bucket with CloudTrail.

For rules such as "no public buckets" or "every resource has a cost tag", add policy as code: Sentinel or OPA policies in HCP Terraform, OPA with Conftest on the plan JSON, or Checkov and Trivy in CI. Back them up with guardrails in AWS itself, such as account-level S3 Block Public Access and service control policies.

resource "aws_s3_bucket" "state" {
  bucket = "acme-tf-state"
}

resource "aws_s3_bucket_versioning" "state" {
  bucket = aws_s3_bucket.state.id

  versioning_configuration {
    status = "Enabled" # lets you roll back a bad state write
  }
}

resource "aws_s3_bucket_server_side_encryption_configuration" "state" {
  bucket = aws_s3_bucket.state.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

resource "aws_s3_bucket_public_access_block" "state" {
  bucket                  = aws_s3_bucket.state.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

The state file is corrupted, or someone deleted it. What do you do?

What a strong answer covers, in order:

1. Stop all applies first, so nothing else writes to the broken state. Pause the pipeline.
2. If the bucket has versioning, find the last good version, download it, read it and restore it. Terraform needs -force to push a state with an older serial.
3. Run terraform plan. It should show no changes, or only changes made after that version, which you then review one by one.
4. If no good copy exists, rebuild state with import blocks, starting with resources that would be dangerous to recreate, such as databases. Plan until it shows no changes.
5. Afterward, make sure the bucket has versioning, locking, tight write access and an alert on deletes.

# Bucket versioning must already be on.
aws s3api list-object-versions --bucket acme-tf-state --prefix app/terraform.tfstate

aws s3api get-object --bucket acme-tf-state --key app/terraform.tfstate \
  --version-id <version-id> restored.tfstate

# Read restored.tfstate first. -force is needed because it has an older serial.
terraform state push -force restored.tfstate
terraform plan    # expect no changes, or only changes you can explain

Someone changed a security group by hand in the console. How do you handle it?

What a strong answer covers, in order:

1. Run terraform plan -refresh-only to see exactly what changed, then find out who changed it and why. A manual fix during an incident may have been the right call.
2. If the change was wrong, run a normal apply and Terraform puts the rules back the way the code says.
3. If the change was right, update the code to match and apply, so the plan is clean again. Do not leave it as drift.
4. Prevent the next one: remove console write access for those resources, alert on changes with CloudTrail or AWS Config, and run a scheduled drift plan.
5. Use ignore_changes only for attributes another system is meant to own, never to hide drift.

The plan wants to destroy and recreate the production database. What now?

What a strong answer covers, in order:

1. Do not apply. Find the attribute marked # forces replacement in the plan, such as the identifier, the engine or the encryption setting.
2. If a rename caused it, the address changed, not the database. Add a moved block and plan again.
3. If an attribute really changed, revert it, or find a way to make the change in place. Some changes, such as encrypting an unencrypted database, need a planned migration from a snapshot.
4. Take a fresh snapshot before any change you are unsure about.
5. Protect it for next time: prevent_destroy in lifecycle, deletion_protection = true on the database, and a CI rule that blocks any plan that destroys a database.

A CI job was cancelled, and now every run fails on the state lock.

What a strong answer covers, in order:

1. Read the lock error. It shows the lock ID, who holds it and when it was taken.
2. Make sure that run is really gone: check the CI system and ask the team. Unlocking while a run is still applying can corrupt state.
3. Then run terraform force-unlock with the lock ID. With S3 lock files the lock is a .tflock object, and with DynamoDB it is an item in the table. Use the command rather than deleting either by hand.
4. Run a plan to see whether the cancelled run left half-made changes.

# Only after you are sure no other run is still going:
terraform force-unlock <LOCK_ID>    # the ID is printed in the lock error

One huge state takes 15 minutes to plan. How do you split it?

What a strong answer covers, in order:

1. Pick the seams. The network, shared data stores and each service usually become separate stacks with their own state, linked by outputs or data source lookups.
2. Within one state, use moved blocks for renames and moves into modules.
3. Across states, use a removed block with destroy = false in the old stack and an import block in the new one, for the same real objects. In one change window, apply the import in the new stack, then the removal in the old one.
4. Both plans should show no creates or destroys for the moved resources. Move one group at a time, and keep a state backup.

# Old stack: delete the resource block and stop managing the bucket, but keep it.
removed {
  from = aws_s3_bucket.reports

  lifecycle {
    destroy = false
  }
}

# New stack: adopt the same bucket.
import {
  to = aws_s3_bucket.reports
  id = "acme-reports"
}

resource "aws_s3_bucket" "reports" {
  bucket = "acme-reports"
}

An apply failed halfway through. What state are you in?

What a strong answer covers, in order:

1. Terraform saves state for everything it finished, so the resources it created are tracked. Nothing is rolled back for you.
2. Read the error, fix the cause, such as a missing permission, a quota or a bad value, and plan again. Terraform carries on from where it stopped.
3. If a resource was created but a provisioner failed, Terraform marks it tainted, and the next apply replaces it.
4. If an API call timed out, the object may exist in AWS but not in state, and the next apply fails because it already exists. Import it instead of deleting it.

You need to move from AWS provider 5.x to 6.x. How do you plan it?

What a strong answer covers, in order:

1. First move to the latest 5.x and fix every deprecation warning there, since most removals in a major version were deprecated in the one before.
2. Read the version 6 upgrade guide and search your code for the resources it lists.
3. Change the constraint to ~> 6.0 on a branch, run terraform init -upgrade and plan every environment.
4. Aim for a plan with no changes. Read any change line by line before you apply, starting in dev.
5. Commit the updated .terraform.lock.hcl and move one stack at a time. Shared modules may need a new major version too.

A stack still keeps its state on one engineer's laptop. How do you move it to S3?

What a strong answer covers, in order:

1. Create the state bucket first, with versioning, encryption and public access blocked, ideally from a small separate stack.
2. Add a backend "s3" block to the terraform block, with literal values.
3. Run terraform init -migrate-state and confirm. Terraform copies the local state into the bucket.
4. Plan from a clean checkout on another machine to prove the remote state works. Then delete the local state files and make sure *.tfstate is in .gitignore.

# 1. Add the backend "s3" block to the terraform block.
# 2. Move the existing state into it:
terraform init -migrate-state
# 3. Confirm, then check that nothing changed:
terraform plan