Chapter 43: Terraform Interview Questions and Capstone Project

43.2 Interview round 2 — scenarios

By Ravindra Bagale · Last updated: 25 October 2026

Story. A Netflix-style platform interview moves quickly to real situations: something broke, what do you do first. The interviewer wants a calm order of steps, not a single command. Use the drill below: read the plan, protect state, find the cause, fix it in code, and apply through the pipeline.

terraform plan -no-color | tail -1
terraform state pull > before-fix.tfstate
terraform plan -refresh-only
git checkout -b fix/sg-drift
terraform plan -out=tfplan

What each line does

• terraform plan -no-color | tail -1 — Reads the summary line first.
• terraform state pull > before-fix.tfstate — Keeps a private backup before any change.
• terraform plan -refresh-only — Shows what changed outside Terraform.
• git checkout -b fix/sg-drift — Puts the fix on a branch for review.
• terraform plan -out=tfplan — Saves the reviewed fix plan for the pipeline.

Scenario questions and model answers

1. Plan shows 1 to destroy you did not expect after a refactor. — Stop; add a moved block, plan again.
2. Two engineers applied at once and state broke. — Restore the previous version from S3 versioning, enable use_lockfile, move applies into Jenkins.
3. Someone changed a security group in the console. — That is drift; detect with plan -detailed-exitcode, then codify or revert.
4. An access key is in a .tf file in Git. — Revoke and rotate it now, clean history, switch to roles.
5. How do you promote a change dev to prod? — Same module version, separate state per environment, saved plan, approval, apply the saved plan.
6. A provisioner failed and the instance is tainted. — Move the script to user_data or Ansible and remove the provisioner.
7. How do you stop a public S3 bucket reaching prod? — Checkov and tfsec in the pipeline before approval, plus a public access block in the module.

When it is green.

Plan: 0 to add, 1 to change, 0 to destroy.
Note: Objects have changed outside of Terraform

When it is red.

Candidate answer: "I would run terraform apply -auto-approve to fix it."
(no plan reading, no backup, no review)

Fix. Always describe reading the plan and backing up state before any fix.

What: every term in plain English

• incident order — Stop, protect state, find the cause, fix in code, apply through the pipeline.
• state pull — Downloads the current remote state to your screen or a file.
• refresh-only plan — Shows only changes made outside Terraform.
• saved plan — A plan written with -out. Apply runs exactly that plan.
• S3 versioning — Keeps old copies of the state file so you can roll back.
• blast radius — How much breaks if one change goes wrong.
• break-glass — An emergency login used only when the pipeline cannot help.

Example 1: Scenario: an unexpected destroy after a refactor

A Flipkart-style team moved a bucket into a module. Plan wanted to destroy prod data. The right answer is a moved block, shown live.

1. Apply a bucket at the root.
2. Move the code into a module.
3. Read the scary plan.
4. Add a moved block.
5. Plan again.

# before: resource "random_pet" "data" {}
module "store" {
  source = "./modules/store"
}

moved {
  from = random_pet.data
  to   = module.store.random_pet.data
}

terraform plan | tail -3

Output

  # random_pet.data has moved to module.store.random_pet.data
    resource "random_pet" "data" {
        id = "fond-eagle"
    }

Plan: 0 to add, 0 to change, 0 to destroy.

What it shows: Without the moved block the summary was Plan: 1 to add, 0 to change, 1 to destroy.

Example 2: Scenario: two people applied and state broke

At an HDFC-style bank team two engineers ran apply together before locking was on. Show how you restore the last good state from S3 versions.

1. List old versions of the state object.
2. Download the last good one.
3. Push it back carefully.
4. Turn on use_lockfile.

aws s3api list-object-versions --bucket corp-tfstate \
  --prefix web/prod.tfstate --query 'Versions[0:3].[VersionId,LastModified]' --output text
aws s3api get-object --bucket corp-tfstate --key web/prod.tfstate \
  --version-id 3HL4kqtJlcpXroDTDmJ.rmSpXd3dIbrHY good.tfstate
terraform state push good.tfstate
terraform plan

Output

3HL4kqtJlcpXroDTDmJ.rmSpXd3dIbrHY   2026-10-24T09:12:00Z
Uo9Kq1n2B3c4D5e6F7g8H9i0J1k2L3m4    2026-10-24T09:11:58Z
...
Plan: 0 to add, 0 to change, 0 to destroy.

What it shows: state push refuses an older serial unless you add -force. Use -force only after a teammate checks the file with you.

Example 3: Scenario: someone opened a port in the console

A Zomato-style on-call engineer opened port 22 to the world to debug. Detect it, then revert through review.

terraform plan -refresh-only -no-color | sed -n '1,20p'
terraform plan -detailed-exitcode -out=tfplan; echo "exit=$?"
terraform apply tfplan

Output

Note: Objects have changed outside of Terraform
  # aws_security_group.web has changed
      + ingress {
          + cidr_blocks = ["0.0.0.0/0"]
          + from_port   = 22
        }
exit=2
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

What it shows: In a real team the apply runs from Jenkins after approval, not from your laptop.

Example 4: Scenario: an access key was committed

The worst one. A Paytm-style repo had a key in provider.tf. The first step is to revoke the key, not to clean Git.

1. Deactivate the key in IAM now.
2. Check CloudTrail for use.
3. Remove it from code and history.
4. Switch the provider to a role.

aws iam update-access-key --user-name ci-user --access-key-id AKIAEXAMPLEKEY --status Inactive
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLEKEY \
  --max-results 5 --query 'Events[].[EventTime,EventName]' --output text

provider "aws" {
  region = "ap-south-1"
  assume_role {
    role_arn = "arn:aws:iam::111122223333:role/terraform-ci"
  }
}

Output

2026-10-24T08:01:12Z  GetCallerIdentity
2026-10-24T08:01:15Z  ListBuckets

What it shows: Only after the key is dead do you clean history and add a secret scanner to the pipeline.

Command cheat sheet

Verify: did it work?

1. Backup exists

   ls -l before-fix.tfstate
   

   Output

   -rw-r--r-- 1 ravi ravi 18233 Oct 25 09:10 before-fix.tfstate
   

2. Clean after fix

   terraform plan -detailed-exitcode; echo $?
   

   Output

   No changes. Your infrastructure matches the configuration.
   0
   

3. Lock is on

   grep use_lockfile backend.tf
   

   Output

   use_lockfile = true
   

When it is red 1

Error: Error acquiring the state lock
Lock Info:
  ID:        6f1c2d3e-aaaa-bbbb-cccc-1234567890ab
  Operation: OperationTypeApply
  Who:       jenkins@build-17

Cause. Another apply holds the lock, or a crashed job left it.

Fix, step by step

1. Check the Jenkins job is really dead.
2. Run terraform force-unlock with the ID.
3. Never force-unlock while a job is still running.

When it is red 2

Failed to write state: cannot overwrite existing state with serial 41 with a different state that has the same serial

Cause. You tried to push an older or copied state.

Fix, step by step

1. Compare both files with a teammate.
2. Use state push -force only after you agree.

When it is red 3

Error: Saved plan is stale
The given plan file can no longer be applied because the state was changed by another operation

Cause. Someone applied after your plan was saved.

Fix, step by step

1. Run plan -out again.
2. Get it reviewed again.
3. Apply the new file.

Cleanup

rm -f before-fix.tfstate good.tfstate tfplan

Practice tasks

Homework: try at home

Recap

• Stop and read the plan before any fix.
• Back up state with state pull.
• Fix in code on a branch.
• Apply a saved plan from the pipeline.
• Revoke leaked keys first, clean Git second.

FAQ

Is force-unlock safe?

Only when you are sure no apply is running.

Can I edit state by hand?

Avoid it. Use state mv, state rm, moved, import and removed blocks.

What if the pipeline is down during an outage?

Use a documented break-glass role, then codify the change after.

Should I mention tools like Atlantis?

Yes, if you used them. Say what problem they solved.

How do I show seniority?

Talk about blast radius, review and rollback, not only commands.

Interview questions

1. Plan shows a destroy you did not expect. What now?

   Stop. Find why, usually a rename or refactor. Add a moved block and plan again.

2. How do you recover a corrupted state?

   Restore the last good version from S3 versioning, then plan to confirm.

3. Someone changed prod by hand. What do you do?

   Detect with plan, find who with CloudTrail, then codify or revert through review.

4. A secret is in Git. First step?

   Revoke and rotate it. Then clean history and switch to roles.

5. How do you promote dev to prod?

   Same module version, separate state, saved plan, approval, apply that plan.

Samajla ka?

Ravi Sir's Cards for this lesson

Revision cardInterview card

मराठी cards