A team decommissions a staging environment, but terraform destroy fails with an error that a database instance cannot be destroyed because lifecycle.prevent_destroy is set. The team lead confirms the database must really be deleted. What is the correct way to proceed?
Select an answer to reveal the explanation.
Short Explanation
prevent_destroy is a safety catch you put on deliberately, so you take it off deliberately too, in code, with review. Pulling the database out of state isn't deleting it; it's abandoning a running, billing database that Terraform no longer knows about.
Full Explanation
The prevent_destroy lifecycle argument makes Terraform return an error for any plan that would destroy that resource instance, which is why the destroy fails. Because the guard lives in configuration, the intended way to remove it is a configuration change: set it to false or remove the argument in a reviewed commit, so the decision to delete the protected object is recorded and approved, then rerun the destroy. The -auto-approve flag only skips the interactive confirmation prompt; it does not bypass lifecycle guards. Removing the database from state with terraform state rm makes Terraform forget the object while the real database keeps running and incurring cost, so the environment is not actually decommissioned. The ignore_changes argument affects how updates to attributes are planned and has no effect on whether a resource can be destroyed. Exam caveat: prevent_destroy protects only while the resource block remains in configuration; deleting the whole block also deletes the guard, which is why removals of protected resources deserve review just as much as flag changes. Operational check: after the reviewed commit, run a destroy plan, confirm the database appears with a delete action and the expected count, and only then approve the destroy.