Exercise 3: What prevent_destroy Protects Against, With a Real Scenario — Possible Solution
====================================================================

`prevent_destroy = true` makes Terraform refuse to proceed with any
plan or apply that would destroy the resource it's set on -- the
command fails outright with an error, rather than silently destroying
something genuinely critical. It protects specifically against
ACCIDENTAL destruction: a teammate renaming a resource block (which
Terraform, without an explicit `moved` block, treats as destroying the
old name and creating a new one), a mistaken `count`/`for_each` edit
like the one in Exercise 2 that unintentionally targets the wrong
resource, or someone running `terraform destroy` against the wrong
workspace/directory entirely.

A concrete real-world scenario where it's genuinely worth setting: a
production database instance holding real customer data. A single
mistaken configuration change, or a `destroy` run against the wrong
target, would otherwise permanently delete the database and everything
in it (state alone doesn't back up actual data) with no additional
confirmation beyond Terraform's normal apply prompt. Setting
`prevent_destroy = true` on that resource means even a genuine mistake
in the configuration or a misdirected command produces a hard failure
instead of an executed deletion -- the team is forced to deliberately
remove the `lifecycle` block itself (a second, explicit, reviewable
step) before the database could ever actually be destroyed through
Terraform.

WHY THIS WORKS AS AN ANSWER
------------------------------
This names the specific FAILURE MODES prevent_destroy guards against
(rename-as-destroy, count/for_each mistakes, wrong-target destroy runs)
rather than a vague "protects important things," and gives a
scenario (a production database) where the consequence of an accidental
destroy is severe and hard to reverse, which is exactly the condition
that makes the safeguard worth the extra friction.