10 Scenario-Based Terraform Interview Questions and Answers

Candidate Reply: Losing the state file is bad because Terraform won’t know what resources it’s managing. First, I’d check if we have a backup, like in an S3 bucket if we’re using a remote backend. If there’s no backup, I’d use `terraform import` to rebuild the state file by manually importing existing resources, like an EC2 instance. For example, I’d write a resource block and run terraform import aws_instance.web i-1234567890abcdef0. To prevent this in the future, I’d set up a remote backend with versioning enabled.

resource "aws_instance" "web" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}
# Run: terraform import aws_instance.web i-1234567890abcdef0

Candidate Reply: If `terraform apply` fails, I first read the error message to understand what went wrong, like a missing permission or invalid config. I check the state file with `terraform state list` to see which resources were created. If something’s broken, I might remove it from the state using `terraform state rm`. Then, I fix the code, run `terraform plan` to confirm the changes, and re-run `terraform apply`. I always back up the state file before making changes.

Candidate Reply: I’d organize the Terraform code to handle multiple environments without duplicating code. I’d create a folder structure like `environments/dev`, `environments/staging`, and `environments/prod`, each with its own `terraform.tfvars` file for settings like instance sizes. I’d use modules for shared resources, like a VPC, and call them from each environment. This keeps the code DRY and easy to manage.

# environments/dev/terraform.tfvars
instance_type = "t2.micro"
environment   = "dev"

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

Candidate Reply: This is called drift. I’d run `terraform plan` to see the differences between the code and the actual resource. If the manual change is okay, I’d update the Terraform code to match it. If it’s wrong, I’d run `terraform apply` to bring the resource back to the coded state. To prevent this, I’d use IAM policies to limit manual changes and set up drift detection in Terraform Cloud.

Candidate Reply: Refactoring needs to be careful to avoid breaking things. I’d identify logical pieces, like networking or compute, and create a module for each. I’d move one resource group at a time to a module, update the state with `terraform state mv`, and test with `terraform plan` to ensure no changes happen. For example, I’d move a VPC to a module and update the main config to call it.

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block = var.cidr
}

# Run: terraform state mv aws_vpc.main module.vpc.aws_vpc.main

Candidate Reply: A state lock means someone else is running Terraform, or a previous run crashed. I’d first check the lock info with `terraform state lock-info` to see who’s holding it. If it’s a teammate, I’d coordinate with them. If it’s stuck, I’d use `terraform force-unlock` with the lock ID, but only after confirming no one’s actively applying changes. To avoid this, I ensure CI/CD pipelines queue Terraform runs.

# Check lock
terraform state lock-info

# Force unlock if needed
terraform force-unlock LOCK_ID

Candidate Reply: I’d use a blue-green deployment. In Terraform, I’d create a new auto-scaling group with the updated app version and update the load balancer to route traffic to it. Once it’s stable, I’d destroy the old group. I’d use `create_before_destroy` to ensure the new resources are ready first.

resource "aws_autoscaling_group" "app" {
  # Config for new version
  lifecycle {
    create_before_destroy = true
  }
}

Candidate Reply: If a provider update breaks things, I’d check the provider’s changelog for breaking changes. I’d pin the provider to the last working version in the code to avoid issues. Then, I’d test the new version in a dev environment, update the config to match any new requirements, and run `terraform init -upgrade` to apply it safely.

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

Candidate Reply: I’d use a remote state data source to share the VPC ID. In the project that creates the VPC, I’d define an output for the VPC ID. In other projects, I’d use the `terraform_remote_state` data source to fetch it. This keeps projects independent but connected.

# VPC project
output "vpc_id" {
  value = aws_vpc.main.id
}

# Other project
data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "vpc/terraform.tfstate"
    region = "us-east-1"
  }
}
resource "aws_subnet" "subnet" {
  vpc_id = data.terraform_remote_state.vpc.outputs.vpc_id
}

Candidate Reply: I’d use `terraform import` to bring the resource into Terraform’s state. First, I’d write a resource block in the code matching the existing resource, like an S3 bucket. Then, I’d run `terraform import` with the resource’s ID. After importing, I’d run `terraform plan` to check for differences and update the code if needed.

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-existing-bucket"
}

# Run: terraform import aws_s3_bucket.my_bucket my-existing-bucket