Read, generate and modify configuration →hardMultiple ChoiceObjective-mapped

TF-004 Read, generate and modify configuration Practice Question

A Terraform configuration includes a resource block with a 'lifecycle' block that has 'create_before_destroy = true'. During an apply, the create step succeeds but the destroy step fails. What is the resulting state?

⚠ Common exam trap

HashiCorp often tests the misconception that a failed destroy step automatically removes the old resource from state or that Terraform rolls back the entire operation, but in reality, Terraform only removes a resource from state after a successful destroy.

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

✓

Both the old and new resources are in state.

When `create_before_destroy = true` is set, Terraform creates the new resource first, then destroys the old one. If the destroy step fails after the new resource is created, both resources exist in the state file because Terraform does not remove the old resource from state until the destroy operation completes successfully. The state retains both resource instances at the same address, which is why option D is correct.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Only the new resource remains in state, old resource is destroyed.
Why it's wrong here
This option is incorrect because the scenario implies the old resource was not successfully destroyed. If a destroy operation fails, or if Terraform's plan did not include destroying the old resource (e.g., due to a change in configuration that created a new resource without explicitly removing the old one, or a `prevent_destroy` lifecycle rule), then the old resource would persist in the cloud provider and remain tracked in the state file. Therefore, the state would reflect both resources.
✗
The state is empty for that resource address.
Why it's wrong here
This option is incorrect because Terraform maintains a comprehensive record of all managed infrastructure in its state file. When a new resource is created, it is immediately added to the state. If an old resource was not destroyed, it also remains in the state. An empty state for a resource address would only occur if the resource was successfully destroyed and removed from the state, or if it was never created or imported.
✗
Only the old resource remains in state.
Why it's wrong here
This option is incorrect because the problem statement implies a new resource was created. When Terraform successfully provisions a new resource, it updates the state file to include the details of this newly created infrastructure. Therefore, if a new resource was indeed created, it would certainly be present in the state alongside any existing, un-destroyed resources.
✓
Both the old and new resources are in state.
Why this is correct
This option is correct. When a Terraform configuration is modified in a way that causes Terraform to perceive a new resource (e.g., changing a resource's logical name, or modifying `count`/`for_each` indices) while the original resource is not explicitly destroyed or its destruction fails, both resources will be tracked in the state file. The state reflects the current reality of the managed infrastructure, including any resources that were created but not yet removed.

Go deeper

TF-004 Read, generate and modify configuration Practice Question

Why each option matters

Option-by-option breakdown

Related to this question