Concept and mechanism
Declared infrastructure supports repeatability but does not remove impact on persistent state. A CloudFormation change set shows predicted changes for review; creation does not execute the change. Even with available validation, the preview does not guarantee a successful update. Replacement can affect data, names, connections, and dependencies. Identify those effects before the window and connect them to protection, acceptance criteria, and recovery. Estimated duration needs to include validation and possible rollback, not merely the time when the API receives the request. Approval is a decision about known consequences and explicit limits.
Guided application
Drift detection compares only what it can evaluate within supported scope. NOT_CHECKED does not equal IN_SYNC, implicit properties may not be compared, and nested stacks need their own assessment. Maintain an inventory of manual changes and decide how to reconcile them with the template. In Patch Manager, distinguish Scan from Install and baseline compliance from absence of vulnerabilities. A narrow baseline can produce all-compliant nodes while leaving risks outside its scope. For APS, automation needs ownership, suitable permissions, concurrency limits, execution evidence, and criteria for stopping or recovering when results differ from expectations.
A few changed lines replace a database. The committee receives the change set, data-protection evidence, nested-stack drift, and rehearsed recovery before deciding.
Common pitfalls
Preview treated as guarantee; Scan treated as installation; a deviation-free report treated as complete coverage.
Related topics: Signals, alarms, and operational diagnosis · Continuity and usable recovery · Authorization, keys, and secret consumers
Automate actions with verifiable scope, consequences, and criteria.
Reference: CloudFormation change set review and execution · SOA-C02 archived guide v2.3; retired2025-09-29