Terraform State Drift — Causes and Resolution
Exhibit
Refer to the exhibit.
```
$ terraform show
# data.aws_ami.ubuntu
id = "ami-0c55b159cbfafe1f0"
# aws_instance.web
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "WebServer"
}
}
```Refer to the exhibit. A Terraform configuration includes an `aws_instance.web` resource. The state shows the instance with a specific AMI and instance type. After running `terraform plan`, Terraform reports no changes. However, an engineer observes that the actual instance in AWS has a different AMI ID but the same instance type. What is the most likely cause?
Quick Answer
The answer is that the state file has not been refreshed since the manual AMI change, so it still reflects the old AMI. This is the most likely cause of terraform state drift because Terraform compares its local state file against the configuration, not against the live infrastructure, during a standard plan. When the state is stale, it reports no changes even though the actual AWS instance has been modified externally. On the HashiCorp Terraform Associate TF-003 exam, this scenario tests your understanding of state drift causes and the refresh lifecycle—a common trap is assuming `terraform plan` always checks the real world, when in fact it only reads the cached state. Remember that drift is invisible until you explicitly run `terraform refresh` or `terraform apply`, which triggers a state sync. A useful memory tip: “Plan reads state, not reality; refresh bridges the gap.”
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The state file has not been refreshed since the manual AMI change; it still reflects the old AMI
The state file is stale because it has not been refreshed since the AMI was manually changed outside of Terraform. When `terraform plan` runs, by default it first refreshes the state, but if the manual change occurred before the last refresh, the plan would have detected drift. However, if no refresh has occurred after the manual change, the plan compares the configuration with the old state, showing no changes. The issue is that the state file still reflects the old AMI. Option B correctly identifies that the state has not been refreshed since the manual change.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The instance type was modified after the last apply, but AMI was not
Why it's wrong here
The question says AMI changed and instance type same.
- ✓
The state file has not been refreshed since the manual AMI change; it still reflects the old AMI
Why this is correct
Terraform compares state to config, not state to real world, unless refresh happens.
- ✗
The `terraform plan` command ignores drift by default
Why it's wrong here
Plan always reads state; drift is only shown if refresh is enabled.
- ✗
The AMI data source is returning a different value each time
Why it's wrong here
Data sources update during refresh, but the resource AMI is a fixed attribute.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A user runs `terraform plan` and notices that the plan includes 'Outgoing changes' for a number of resources that were not modified in the configuration. What is the most likely cause?
hard- A.The provider version has changed.
- ✓ B.The resources were manually changed in the cloud provider.
- C.The backend configuration changed.
- D.The state file is outdated and needs to be refreshed.
Why B: When `terraform plan` shows 'Outgoing changes' for resources that were not modified in the configuration, it indicates that the actual state of the resources in the cloud provider has diverged from the desired state defined in the Terraform configuration. This phenomenon is known as 'drift'. The most common and direct cause of drift, especially when the configuration itself hasn't changed, is that the resources were manually modified outside of Terraform's management (Option B). While an 'outdated state file' (Option D) is a symptom of this drift, and `terraform plan` implicitly refreshes the state to detect these changes, the *root cause* of the state file being outdated and the drift occurring is the manual modification of resources in the cloud. Option D describes a symptom and a necessary action (refreshing the state to reflect reality), not the underlying cause of the drift itself. Option A (provider version change) can cause plan changes but is less directly related to 'drift' from manual changes. Option C (backend configuration change) is unrelated to resource drift.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.