Q: "terraform plan" suddenly shows 6 production resources will be destroyed, although no Terraform code was changed. What would you check first?
Triage runbook when terraform plan unexpectedly proposes destroying production resources (subnets, databases, VMs) without code changes, handling provider upgrades, remote changes, and lockfile validation.
🛠️ Production Runbook & Step-by-Step Resolution
Examine the Exact Forces Replacement Trigger
Inspect the plan output line by line looking for `# forces replacement`. Terraform explicitly denotes which attribute change forces resource recreation (~ versus -/+).
terraform plan -out=tfplan
terraform show -no-color tfplan | grep -B 2 -A 5 "forces replacement"Check .terraform.lock.hcl & Provider Version Drift
Verify if the azurerm provider version upgraded unexpectedly. Often a new provider version introduces default attribute values or renames fields that cause existing resources to be recreated.
Audit Azure Activity Logs for Manual Portal Modifications
Check Azure Activity Log on the 6 target resources. If an engineer manually modified a subnet CIDR, SKU, or tag via Azure Portal, Terraform detects drift and attempts to restore the declared state by recreating the resource.
- Check the plan output for # forces replacement to identify the exact attribute causing destruction.
- Verify provider version pinning in .terraform.lock.hcl against unexpected azurerm provider upgrades.
- Inspect Azure Activity Log to see if someone made manual changes in the Azure Portal that caused drift.
- Protect production resources using lifecycle { prevent_destroy = true } blocks.