Use the core Terraform workflow →easyMultiple ChoiceObjective-mapped

TF-004 Use the core Terraform workflow Practice Question

A user runs 'terraform plan' and the output includes a change that adds a new resource. However, the user expected the change to modify an existing resource. What is the most likely cause?

⚠ Common exam trap

HashiCorp often tests the misconception that Terraform identifies resources by their configuration block content (e.g., tags or names) rather than by the resource type and name in the block header, leading candidates to incorrectly attribute the behavior to provider updates or attribute 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 resource name or type was changed in the configuration.

When a resource's name or type is changed in the configuration, Terraform interprets it as a request to destroy the old resource and create a new one, because Terraform maps each resource block to a state entry using its resource type and name (e.g., `aws_instance.web`). The plan output will show a `+` (create) for the new resource and a `-` (destroy) for the old one, rather than a `~` (update in-place). This matches the user's observation of a new resource being added instead of the expected modification.

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 provider version was updated.
Why it's wrong here
A provider version update primarily affects how Terraform interacts with the API, potentially introducing new features, deprecating old ones, or fixing bugs. While it *could* lead to a resource being replaced if a breaking change in the provider forces a new resource type or attribute behavior, a simple version update itself doesn't inherently cause a *new* resource to be planned. More commonly, it would result in in-place modifications or errors if attributes are no longer supported, rather than a full recreation.
✗
A required attribute was added to the resource block.
Why it's wrong here
Adding a new attribute to an *existing* resource block in the configuration typically results in an in-place update to the corresponding remote object, assuming the attribute is modifiable and doesn't trigger a replacement. Terraform would identify the change and plan to update the existing resource, not destroy and recreate it as a new resource. Only if the specific attribute is marked as `ForceNew` by the provider would it necessitate recreation.
✗
The state file was manually deleted.
Why it's wrong here
If the Terraform state file (`terraform.tfstate`) is manually deleted, Terraform loses its record of all previously deployed infrastructure. Consequently, when `terraform plan` is executed, Terraform would perceive *all* resources defined in the configuration as entirely new and propose to create every single one, not just a single resource. This scenario would result in a plan showing many `(+ create)` actions across the entire configuration.
✓
The resource name or type was changed in the configuration.
Why this is correct
Terraform identifies resources by their unique address, which is composed of their type and local name (e.g., `aws_instance.web`). If either the resource type (e.g., changing `aws_instance` to `aws_ami`) or the local name (e.g., changing `web` to `app`) is altered in the configuration, Terraform considers this a completely different resource from what is recorded in the state file. It will then plan to destroy the old resource (if it exists in state) and create a brand new one with the updated address, resulting in a `(- destroy, + create)` action for that specific resource.

Go deeper

TF-004 Use the core Terraform workflow Practice Question

Why each option matters

Option-by-option breakdown

Related to this question