Terraform Interview Questions: State, Plans and Resource Renames

Start with a small, inspectable configuration

The exercise was run with Terraform 1.13.3 on macOS arm64. Put the following main.tf in a new empty practice directory and use that version for the reproduced results. There are no providers to download, provisioners or remote backend settings. Keep the practice directory separate from other Terraform configurations.

The resource stores the fictional revision string. Its generated identity is useful for comparing before and after states, but its particular value is not important. This exercise demonstrates Terraform lifecycle behavior; it does not demonstrate AWS operations or external infrastructure drift.

terraform {
  required_version = "= 1.13.3"
}
variable "revision" {
  type    = string
  default = "draft-a"
}
resource "terraform_data" "note" {
  input = var.revision
}
output "revision" {
  value = terraform_data.note.output
}

1. What does state contribute when the configuration already describes the resource?

For this example, state records the managed instance associated with terraform_data.note and its attributes. After the first apply, Terraform can compare later configuration with that existing instance. The resource address is part of that association. A new name in the configuration is not automatically understood as the same existing instance.

Follow-up practice: If you change only the resource’s local name, what evidence would let you distinguish an intended move from a new resource plus removal? Explain before running the rename steps.

Run the initial apply and unchanged plan

Run these commands from the new practice directory. The apply creates the synthetic local resource state. The following saved plan should show no changes. Inspect the resource identity with terraform state show terraform_data.note and keep it for the later comparison.

terraform init -backend=false
terraform apply -auto-approve
terraform plan -out=unchanged.tfplan
terraform show unchanged.tfplan
terraform state show terraform_data.note

2. Does changing an input necessarily replace a resource?

No. In this tested terraform_data example, changing input from draft-a to draft-b produces an in-place update. The generated resource ID remains the same after applying that plan. That observation does not establish the behavior of every argument on every resource; read the specific plan and resource contract.

Follow-up practice: What would the plan need to show for you to call it a replacement? Describe the difference between an update action and delete/create actions.

Change the input and verify the identity

This saves and applies the input-change plan. The observed plan updates the resource; the state then contains draft-b while retaining the original ID. Keep supplying draft-b in subsequent plans so a default-value change does not distract from the rename experiment.

terraform plan -var=revision=draft-b -out=input-change.tfplan
terraform show input-change.tfplan
terraform apply -auto-approve input-change.tfplan
terraform state show terraform_data.note

3. Why can a simple rename propose deletion and creation?

Rename the resource label note to memo and update the output reference to terraform_data.memo.output, leaving the rest of main.tf unchanged. Without a move declaration, the tested plan sees an old address no longer declared and a new address not associated with the previous instance. It proposes deletion at terraform_data.note and creation at terraform_data.memo. We inspected this plan but did not apply it.

Follow-up practice: Is this evidence that the input value changed? No: identify which configuration change produced the address mismatch.

Inspect the naive rename without applying it

After editing the two references described above, run this plan and read its actions. Do not apply this plan if your goal is to preserve the existing instance. The next step supplies the missing address relationship.

terraform plan -var=revision=draft-b -out=naive-rename.tfplan
terraform show naive-rename.tfplan

4. What does a moved block communicate?

It declares that the instance formerly identified by one address should now be associated with another. In this exercise, the moved-block plan reports the change from terraform_data.note to terraform_data.memo without a resource create, update or destroy action. Applying that plan updates the address recorded in local state and preserves the ID.

Follow-up practice: Would a moved block justify ignoring other changes in a plan? Explain why an address move and a simultaneous argument change need separate review.

Add the move and compare the result

Keep the renamed main.tf and add this moved.tf. Create a fresh plan after adding the block; the earlier naive plan does not acquire the new information retroactively.

moved {
  from = terraform_data.note
  to   = terraform_data.memo
}

Apply the move-aware plan

The tested plan contained a no-op resource action with previous_address identifying terraform_data.note. After apply, state show at the new address returned the original ID. These commands change only this practice directory’s synthetic state.

terraform plan -var=revision=draft-b -out=moved-rename.tfplan
terraform show moved-rename.tfplan
terraform apply -auto-approve moved-rename.tfplan
terraform state show terraform_data.memo

5. Is terraform_data a way to prove that an external system has not drifted?

Not in this configuration. There is no external service to inspect. The no-change plan proves that this local example has no planned change under the supplied configuration and input. It does not demonstrate cloud refresh behavior, permissions, remote locking or recovery from a concurrent change.

Follow-up practice: Rewrite “this test proves our AWS environment is correct” into a statement limited to the local behavior actually observed.

6. How would you explain the experiment in an interview?

I created a local terraform_data instance, confirmed an unchanged plan, updated its input without changing its ID, and then compared two renames. The unannotated rename proposed delete/create; the moved block preserved the instance while changing its state address. I reviewed the naive plan without applying it. This is lab evidence, not a production migration story.

Follow-up practice: If the interviewer asks for a production example, explain the limits of this exercise rather than inventing a deployment or a prevented outage.

Rehearsal: predict the plan before reading it

For each step, write the resource address, input, expected action and whether you expect the ID to change. Then compare those predictions with the actual plan and state output.