TF-004 Use the core Terraform workflow Practice Question
A developer is reviewing a terraform plan output and sees that a resource of type "aws_instance" with name "web" will be updated. The developer expected no changes because the configuration hasn't been modified. The instance was manually resized in the AWS console by another team. The developer wants to reconcile the state without destroying the instance. What should they do?
⚠ Common exam trap
HashiCorp often tests the distinction between `terraform apply -refresh-only` and `terraform apply` with `-target`, where candidates mistakenly think targeting a resource will only refresh it, but in reality `-target` still applies configuration changes and can cause updates or destruction.
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
✓
Run terraform apply -refresh-only to update the state to match reality.
`terraform apply -refresh-only` updates the Terraform state to match the actual infrastructure without making any configuration changes. This command reads the current state of the `aws_instance.web` resource from AWS and writes it to the state file, reconciling the drift caused by the manual resize. It does not destroy or recreate the instance, preserving the existing resource.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run terraform apply -refresh-only to update the state to match reality.
Why this is correct
When infrastructure resources have been modified outside of Terraform (a condition known as drift), `terraform apply -refresh-only` is the precise command to update Terraform's state file to reflect these real-world changes. This operation queries the cloud provider for the current attributes of all managed resources and updates the state file accordingly, without making any alterations to the actual infrastructure. It effectively synchronizes Terraform's understanding with reality, acknowledging external modifications and preventing Terraform from attempting to revert them in subsequent `apply` operations.
- ✗
Run terraform state rm aws_instance.web and then terraform import.
Why it's wrong here
Running `terraform state rm` removes the resource from Terraform's state file. If the configuration for `aws_instance.web` remains, a subsequent `terraform plan` would propose to create a *new* instance, as it no longer tracks the existing one. This directly contradicts the requirement to reconcile without destroying the instance. This command sequence is typically used to remove a resource from state before re-importing it, perhaps when moving it between modules or fixing a corrupted state entry, but not for simply updating drift on an actively managed resource.
- ✗
Manually edit the state file to match the instance attributes.
Why it's wrong here
Manually editing the Terraform state file is highly discouraged and unsupported by HashiCorp due to significant risks and potential for data corruption. State files contain sensitive data, resource IDs, and internal consistency checks; direct manipulation can easily corrupt the file's integrity, leading to inconsistencies, data loss, or rendering Terraform unable to manage the infrastructure. Such actions can break the crucial link between Terraform's configuration and the actual cloud resources, making future operations unpredictable and dangerous.
- ✗
Run terraform apply with -target=aws_instance.web to update only that resource.
Why it's wrong here
`terraform apply` (even when using the `-target` flag) instructs Terraform to make the real infrastructure conform to the specified configuration in the `.tf` files. If the Terraform configuration still defines the original, smaller instance size, running `apply` would detect the drift and propose to revert the instance back to that size. This action would undo the desired external change, rather than accepting it and updating Terraform's state to match the current reality.
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 →
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.