A retailer's CloudFormation stack includes the production order database. A small template edit is ready, and the team needs to know whether the update will replace that database before anything changes. What should they do first?
Select an answer to reveal the explanation.
Short Explanation
A change set is the rehearsal, not the show. You get to read who gets replaced before CloudFormation touches the order database. Rollback is a safety net after damage starts, and it is a rough way to discover that the database was in the blast radius.
Full Explanation
A CloudFormation change set computes the update and reports each resource as modify or replace without performing it. Replacement of a stateful database is visible there, which is the fact this team still needs. Executing the update and trusting rollback discovers the replacement by doing it; rollback of a replaced database is not a clean undo of data movement. Deleting the stack is the opposite of a cautious update and, without a retain policy, risks the data. CloudTrail data events record API calls after they happen, so they cannot preview a stack change, and object-level logging is unrelated to whether CloudFormation will replace RDS. Caveat: a change set goes stale if the stack or template changes before you execute it, so review and execute as one sitting. Operational check: open the change set, filter for Replacement true, and do not execute while the database is on that list unless replacement was intended.