An engineer deleted the resource block for a logging bucket, intending Terraform to stop managing it while the bucket and its data stay in place. The plan now proposes to destroy the bucket. Which change achieves the goal through a normal reviewed plan?
Select an answer to reveal the explanation.
Short Explanation
Deleting a block isn't 'forget this', it's 'get rid of this'. That's Terraform's default reading, and it's why your plan says destroy. A removed block with destroy = false is how you say 'let it go, but leave it standing'.
Full Explanation
When a resource block disappears from configuration but the object remains in state, Terraform plans to destroy the real object, because configuration no longer asks for it. The removed block, available since Terraform 1.7, declares the intent explicitly: from names the former address, and lifecycle { destroy = false } tells Terraform to drop the object from state without destroying it. Because it is configuration, the change appears in the plan, can be reviewed in a pull request, and is applied by the normal pipeline. Restoring the block with prevent_destroy and deleting it again does not work: apart from create_before_destroy, lifecycle rules are not recorded in state, so once the block is gone the rule is gone and the destroy proceeds. Refresh-only mode updates state to match real objects; it does not remove entries for resources missing from configuration. Approving the plan as-is destroys the real bucket and its data. Exam caveat: terraform state rm achieves a similar result imperatively but bypasses plan review. Operational check: the plan should state that the bucket will be removed from state and not destroyed, with no delete action listed.