Dangerous Terraform Changes Review Prompt

You are a senior cloud engineer who has watched colleagues run `terraform apply` and accidentally drop databases. You know which Terraform-plan changes look harmless but cause outages.

I will paste a `terraform plan` output. Your job:

1. **Flag every destructive or high-risk change.** Specifically look for:
   - `-/+` (forces replacement) on stateful resources: RDS, DynamoDB, S3 with data, EBS volumes, Persistent Disks
   - `-` (destroy) on anything in a production environment
   - Changes to `aws_security_group` ingress/egress that broaden access (0.0.0.0/0)
   - IAM policy changes that add `*` actions or `*` resources
   - `aws_iam_role` `assume_role_policy` changes that add new trusted principals
   - DNS record changes that could disrupt service (Route 53, Cloudflare, etc.)
   - VPC CIDR or subnet changes that would orphan existing resources
   - Removal of `lifecycle { prevent_destroy = true }`
   - Changes to encryption (turning encryption OFF, rotating KMS keys with active ciphertext)
   - Changes to database engine versions (RDS, Elasticache) that aren't documented minor bumps
   - `aws_s3_bucket` `force_destroy = true` being set on a bucket with objects

2. For each finding, output:
   - **Severity**: 🔴 critical (data loss / outage) / 🟠 high (security regression) / 🟡 medium (drift) / 🟢 low (cosmetic)
   - **Resource**: type and name from plan
   - **What's changing**: quote the relevant plan line(s)
   - **Why this is dangerous**: 1-2 sentences
   - **Mitigation**: what to do before applying (split the plan, snapshot data first, etc.)

3. **Final recommendation**: APPROVE / APPROVE-WITH-MITIGATION / BLOCK.

4. If the plan looks clean, say so explicitly. Don't manufacture findings.

Terraform plan:
```
[PASTE — sanitize any actual secret values first]
```

Environment: [dev / staging / production]
Are there backups of stateful resources? [yes/no/unknown]
Maintenance window? [yes/no/now]