TF-004 Use Terraform outside the core workflow Practice Question
Exhibit
Terraform will perform the following actions:
# aws_instance.web will be updated in-place
~ resource "aws_instance" "web" {
~ ami = "ami-abc123" -> "ami-def456"
id = "i-1234567890abcdef0"
~ instance_type = "t2.micro" -> "t2.small"
tags = {
"Name" = "web-server"
}
}
Plan: 0 to add, 1 to change, 0 to destroy.Refer to the exhibit. An operator runs terraform plan and gets the following output. They have not modified the Terraform configuration since the last successful apply. What is the most likely cause of the planned changes?
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 instance was modified manually via the AWS console.
The plan shows changes to attributes like AMI and instance type. Since the configuration hasn't changed, these differences indicate that the instance was modified manually, likely via the AWS console. This is a classic example of configuration drift, where the actual infrastructure state diverges from the desired state defined in Terraform configuration. Option D correctly identifies this cause.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Terraform provider was updated to a new version.
Why it's wrong here
A Terraform provider update typically introduces new features, deprecates old ones, or fixes bugs, but it does not unilaterally modify existing resource attributes in the cloud without a corresponding change in the Terraform configuration. If the configuration itself remains unchanged, a provider update alone would not cause Terraform to propose an in-place update to an attribute, as the desired state, as defined by the configuration, has not changed. Such an update would usually only occur if the configuration were modified to leverage new provider logic or if the provider itself had a bug causing an incorrect desired state interpretation.
- ✗
The instance was terminated and recreated.
Why it's wrong here
If the instance had been terminated and recreated, the `terraform plan` output would explicitly show a `(destroy)` action for the existing resource and a `(create)` action for a new one, often combined into a `(replace)` action. The scenario describes an in-place modification of an attribute, which is fundamentally different from a full resource replacement. Terraform's plan output clearly distinguishes between these actions, indicating a direct update rather than a complete lifecycle event.
- ✗
Terraform state was corrupted.
Why it's wrong here
Terraform state corruption would typically manifest as errors during `terraform plan` or `apply`, or lead to proposals to recreate resources that already exist, or destroy resources that are still desired, due to an inability to reconcile the configuration with the recorded state. It would not usually result in a precise, in-place update of a single attribute, as this implies the state file is largely intact and correctly identifies the resource, but its recorded attributes diverge from the actual infrastructure's current state.
- ✓
The instance was modified manually via the AWS console.
Why this is correct
When an infrastructure resource managed by Terraform is altered directly through the cloud provider's console or API, its actual state diverges from the desired state defined in the Terraform configuration and the last known state recorded in the Terraform state file. Running `terraform plan` detects this 'drift' by comparing the actual infrastructure's current attributes with the desired state, then proposing actions to reconcile them, such as updating the attribute back to its configured value.
Go deeper
Related to this question
About these practice questions
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.