TF-Associate-004 - Terraform state management (11% of the exam) - Section 6d
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
lock_openFree 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.check_circle 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.
Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.
It reconciles the state file to match reality and leaves nothing for a later apply to change.
errorWhy it is wrong: Plan never persists a reconciliation of its own; it may refresh an in-memory view, but it does not write the corrected values back to the state file.
terraform refresh, because it is the actively recommended command for updating state without side effects.
errorWhy it is wrong: The standalone terraform refresh command still exists but is deprecated; HashiCorp now steers practitioners to the refresh-only plan and apply modes instead.
A divergence between the configuration files and the state file that arises whenever a resource block is edited but not yet applied.
errorWhy it is wrong: Editing configuration ahead of an apply produces a planned change, not drift; drift concerns the mismatch between state and the real infrastructure, not between config and state.