Why can approving an old deployment delete infrastructure?
After this you can answer: Why can approving an old deployment delete infrastructure?
Say it in 30 seconds
Section titled “Say it in 30 seconds”The deeper answer
Section titled “The deeper answer”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.
Counter-questions
Section titled “Counter-questions”Why fetch full Git history?
Should the record update only after a healthy release?
Does the override make an old app rollback possible?
Where in MiniTickets
Section titled “Where in MiniTickets”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/