To meet a business rule that the production database must never be deleted by accident, an engineer adds lifecycle { prevent_destroy = true } to it. Months later a refactoring pull request deletes the database's entire resource block from the configuration. What does terraform plan do?
Select an answer to reveal the explanation.
Short Explanation
prevent_destroy is a sticky note on the resource block, not a lock on the database. Tear out the block and the note goes in the bin with it. That's the trap: you think you've got a permanent guard, but it only protects you while the block is still there.
Full Explanation
prevent_destroy is a lifecycle meta-argument evaluated from configuration. While the block exists, any plan that would destroy the object, including a replacement, fails with an error. The protection lives only in the configuration, however. When the whole resource block is deleted, the lifecycle setting is deleted with it, and Terraform sees an object in state with no matching configuration, which it plans to destroy. The HashiCorp documentation states this limitation directly. The setting is not persisted in state as a standing guard, so the idea that state keeps protecting the object misreads where the rule lives. Forgetting a resource without destroying it is what a removed block with lifecycle destroy = false, or terraform state rm, is for; simply deleting the block never implies that behaviour. Terraform does not ignore orphaned state entries either; an object in state without configuration is exactly what produces a destroy action. Exam caveat: for genuine deletion protection, pair prevent_destroy with provider-side protection such as a deletion protection setting and with policy checks that reject destroy actions. Operational check: review every plan for destroy actions on stateful resources, and require explicit approval when a pull request removes a resource block.