Skip to content

Why can approving an old deployment delete infrastructure?

1 min read · main part only; folded sections are optional

After this you can answer: Why can approving an old deployment delete infrastructure?

The recorded incident involved a workflow that waited for approval and then applied its old infrastructure definition. The historical result was deletion of ten newer resources; the case records the evidence and recovery context.

The guard executes the current main version of the guard script, so a stale checkout cannot bypass a fix merely by carrying an older script. CI-triggered runs must match the fetched main tip. All runs compare the checked-out commit with the SSM deployed-commit marker; missing or divergent history is treated conservatively.

This is a guard against known stale versions, not an atomic transaction spanning GitHub and AWS. Main can advance after a check. Deployment serialization and recording attempted infrastructure changes limit related risks, but they do not make every possible concurrent modification safe. The intentional older-infrastructure override is a separate, destructive operation; ordinary app rollback does not need it.

Why fetch full Git history?
The guard compares ancestry. A shallow checkout can lack the recorded commit and cannot reliably establish which infrastructure version is older.
Should the record update only after a healthy release?
No. A failed apply can still create resources. The workflow records once an infrastructure apply began, including failure, to protect those partial changes.
Does the override make an old app rollback possible?
App rollback already uses image_tag with current infrastructure. The override is reserved for a deliberate infrastructure rollback.

Read the path chapter, select the relevant map piece →, then inspect scripts/deploy-guard.sh → older_than_recorded. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/