Manage resource drift and Terraform state - TF-Associate-004 Terraform state management

Manage resource drift and Terraform state.

Drift is real-world change that diverges from state; refresh reconciles state with reality, and plan surfaces drift as proposed changes. Candidates should reason about terraform state mv, rm and the -replace option, and why hand-editing state is dangerous.

configuration driftstate refreshterraform state mv and rm-replace instead of taint

Practice question for this objective

Free sampleTerraform state managementhard

A colleague changed the instance type of an EC2 instance directly in the AWS console. Your Terraform configuration still specifies the original type. You run terraform plan without any extra flags. What does Terraform report and change?

resource "aws_instance" "api" {
  ami           = "ami-0abcd1234"
  instance_type = "t3.small"
}
$ terraform plan

AIt refreshes the state in memory, detects the drift, and shows a planned change to return the instance to t3.small, but applies nothing. Correct
BIt immediately writes the drifted instance type back into state and silently reconciles the configuration to match reality.
CIt reports no changes because the state file, not the live resource, is Terraform's source of truth for planning.
DIt errors out and demands you run terraform apply -refresh-only before any plan can be produced.

Understand that terraform plan refreshes state in memory to surface drift but never changes infrastructure or the state file. terraform plan reads the current real-world attributes, compares them to the configuration, and shows the actions needed to converge; it is a read-only dry run that persists nothing, so detected drift appears as a proposed change only.

Why A is correct: By default plan performs an in-memory refresh, compares real infrastructure with the configuration, and proposes reverting the console change; plan itself never modifies infrastructure or the state file.

Why B is wrong: This is tempting because plan does read live values, but plan never persists anything to the state file and never rewrites your configuration; only apply updates state.

Why C is wrong: This misunderstands refresh: plan compares configuration against refreshed real-world values, so out-of-band changes surface as drift rather than being ignored.

Why D is wrong: Refresh-only is a real mode but is optional, not a prerequisite; plan runs a refresh on its own and produces output without any such error.

See more TF-Associate-004 practice questions, answers explained.

Examworthy is not affiliated with or endorsed by HashiCorp. Original, blueprint-aligned practice material only.

Manage resource drift and Terraform state.

Practice question for this objective

More in this domain