TF-004 Read, generate and modify configuration Practice Question
When running terraform plan, the output indicates that a resource will be replaced (destroy then create) due to a change in the 'name' attribute. However, the engineer only changed a tag. What is the most likely cause?
⚠ Common exam trap
A common misconception is that any attribute change causing replacement must be due to a ForceNew on that specific attribute, when in fact a computed attribute like 'name' can force replacement on any resource change because the provider recalculates it and sees a diff.
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 'name' attribute is computed and any change to the resource forces replacement.
When a resource attribute is marked as 'computed' and 'ForceNew' in the Terraform provider schema, any change to that attribute—or, in some provider implementations, any change to the resource at all—triggers a destroy-and-create cycle. In this scenario, the engineer changed only a tag, but the provider has been configured to treat the entire resource as requiring replacement if any attribute changes, often because the 'name' attribute is computed from other inputs or because the provider's internal logic forces replacement on any update. This is a known behavior in certain Terraform providers where the 'name' attribute is set to 'Computed' and 'ForceNew' in the schema, causing any modification to the resource to result in a plan that shows replacement.
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 tag change triggered a ForceNew attribute.
Why it's wrong here
While some resource attributes are marked `ForceNew`, meaning any change necessitates resource replacement, tags are typically designed for in-place updates. Most cloud providers allow tags to be modified on existing resources without requiring their destruction and recreation. Therefore, a simple tag modification alone is highly unlikely to trigger a `ForceNew` behavior for the entire resource, which would cause replacement.
- ✗
The resource has create_before_destroy enabled.
Why it's wrong here
The `create_before_destroy` lifecycle setting dictates the *order* in which a replacement operation occurs, ensuring the new resource is provisioned successfully before the old one is terminated. It does not, however, *cause* a resource replacement. Replacement is triggered when a `ForceNew` attribute is modified, and `create_before_destroy` merely optimizes the transition for high availability, rather than initiating the replacement itself.
- ✓
The 'name' attribute is computed and any change to the resource forces replacement.
Why this is correct
Many resource types have core identifying attributes, such as 'name', that are immutable after initial creation. If the provider marks the 'name' attribute as `ForceNew`, any attempt to modify its value in the configuration will necessitate the destruction of the existing resource and the creation of a new one. Even if 'name' is `computed`, meaning its value is determined by the provider, if the provider's internal logic dictates that the resource's identity (often tied to its name) cannot be altered in-place, then any change impacting that identity will trigger replacement.
- ✗
The underlying API does not support in-place updates.
Why it's wrong here
While some cloud provider APIs indeed lack support for in-place updates for specific resource types or attributes, it is highly uncommon for an entire resource to be completely immutable for *all* its attributes. If the underlying API truly did not support *any* in-place updates, then *any* modification to *any* attribute, including simple tags, would invariably trigger a resource replacement. This scenario is generally rare, as most APIs allow at least some metadata or configuration changes without full resource recreation.
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.