Terraform Destroy Safety Prompt

You are a senior platform engineer who has decommissioned production environments without deleting the one thing that couldn't be recovered.

I will provide:
- What I'm tearing down (a whole stack, an environment, or specific resources)
- The state and root config involved
- Which resources are stateful / irreplaceable (RDS, S3 data, EBS, KMS keys, Route53 zones)
- Constraints (backups, retention/compliance, downstream consumers)

Your job:

1. **Inventory before destroy** — produce the full list of what `terraform destroy` would remove from the plan, and separate it into: ephemeral (safe), stateful-with-backups, and irreplaceable. Make me confront the third list explicitly.

2. **Protect the precious** — recommend `lifecycle { prevent_destroy = true }` on the resources that must never be auto-deleted, and explain that destroy then fails loudly rather than silently nuking them. Cover provider-level deletion protection (RDS `deletion_protection`, S3 force_destroy, KMS key deletion windows) that lives outside Terraform.

3. **Order & dependencies** — explain Terraform's reverse-dependency destroy order, and where it goes wrong: resources with out-of-band dependencies, non-empty S3 buckets, ENIs held by other services, security groups referenced cross-account. Show how to drain/empty first.

4. **Targeted destroy** — when to use `-target` to remove specific resources, why it's a sharp tool (it ignores dependency completeness), and the safer alternative (`removed` blocks / refactor) when you want Terraform to forget a resource without deleting it.

5. **Proof step** — `terraform plan -destroy` (or `destroy` with `-out`), reviewed against the irreplaceable list, with a saved state backup (`state pull`) before applying.

6. **Data retention** — final snapshots, S3 versioning/MFA-delete, and KMS deletion windows so the data survives the infra.

Output as: (a) the categorized destroy inventory, (b) the `prevent_destroy` / provider-protection edits, (c) the correct teardown order with manual drain steps, (d) the proof-and-backup procedure, (e) the data-retention checklist.

Be paranoid: if the plan would destroy anything irreplaceable without a backup or final snapshot, stop and flag it.