Destructive Changes: What a Rename Really Does

1--- a/database.tf
2+++ b/database.tf
3-resource "aws_db_instance" "db" {
4+resource "aws_db_instance" "primary" {
5 
6     identifier = "prod-orders"
7 
8-- plan --------------------------------------------------------------
9 
10  # aws_db_instance.db will be destroyed
11  # (because aws_db_instance.db is not in configuration)
12  - resource "aws_db_instance" "db" {
13      - identifier = "prod-orders"
14    }
15 
16  # aws_db_instance.primary will be created
17  + resource "aws_db_instance" "primary" {
18      + identifier = "prod-orders"
19    }
20 
21Plan: 1 to add, 0 to change, 1 to destroy.

Nothing in the source diff hints at this. The reviewer approving a one-word rename and the operator approving "1 to destroy" have to be the same person looking at the same artifact, which is the argument for putting the plan in the pull request.

1# 1. Tell the tool the address moved. Reviewed like any change.
2moved {
3  from = aws_db_instance.db
4  to   = aws_db_instance.primary
5}
6 
7resource "aws_db_instance" "primary" {
8  identifier              = "prod-orders"
9  engine                  = "postgres"
10  instance_class          = "db.m6g.large"
11  allocated_storage       = 200
12 
13  # 2. Provider-side protection: survives the IaC tool being wrong.
14  deletion_protection     = true
15 
16  # 3. If it is ever deleted, take a snapshot on the way out.
17  skip_final_snapshot     = false
18  final_snapshot_identifier = "prod-orders-final"
19  backup_retention_period = 14
20 
21  lifecycle {
22    # 4. The tool refuses to plan a destroy at all.
23    prevent_destroy = true
24  }
25}

Layer 4 fails loudly and is the one someone deletes to make an apply pass. Layers 2 and 3 are the ones that hold when that happens, because removing them is a separate, visible change to the resource itself.

1. 16:52changePull request opened: rename db to primary for clarity, plus three unrelated tag changes
2. 16:55signalCI posts the plan as a comment. It is 340 lines; the summary line is at the bottom
3. 16:58actionReviewer reads the source diff, sees a rename and some tags, approves
4. 17:01changeMerged. Pipeline applies automatically — no destroy gate configured on this state
5. 17:02changeApply begins with the destroy, because destroy-then-create is the default order
6. 17:03signalConnection errors across every service that talks to the database
7. 17:04changeApply continues and creates an empty instance with the same identifier and a new endpoint
8. 17:06actionPaged. First hypothesis is a network problem, because the deploy that ran was "a tag change"
9. 17:14actionSomeone reads the apply log rather than the pull request and finds the destroy
10. 17:18actionRestore started from the most recent automated backup
11. 18:41recoveryRestore complete. Writes between the last backup and 17:02 are gone; reconciliation begins

Three cheap controls would each have stopped this independently: a destroy gate on the pipeline, prevent_destroy on the resource, and provider-side deletion protection. The expensive control — a careful reviewer — was present and did not help, because the information was not where they were looking.