Concept and mechanism
Infrastructure as Code makes configuration intent versioned and reviewable. It does not eliminate differences between plan and execution. A CloudFormation change set helps inspect changes, replacements, and deletions before execution. Current documentation includes predeployment checks such as property syntax, naming conflicts, and quotas, but the result still does not guarantee success of custom logic or every execution condition. Replacing a resource containing data deserves preservation, downtime, and recovery analysis. The reviewer should understand service effects instead of approving merely because the change set was created.
Guided application
Drift detection also has scope. Not all resources and properties are supported; undeclared defaults may fall outside comparison. NOT_CHECKED does not mean compliance. An IN_SYNC stack does not prove every actual setting was examined, and examining the parent stack does not automatically traverse nested stacks. After an authorized hotfix, compare intent with the correction that resolved the incident. Update the template or deliberately revert while preserving evidence. In automation receiving a timeout after creation, check whether the resource already exists with the expected identity before retrying. This reconciliation reduces duplication when the previous outcome is uncertain.
A manual correction keeps production available, but the next release would restore the old value. Reconciliation is part of closure.
Common pitfalls
Preview as guarantee; IN_SYNC as universal coverage; blind retry after timeout; rollback reintroducing the incident.
Related topics: Fleet automation and governance · Capacity, resilience, and recovery
Explain checked scope and reconcile state with authorized intent.
Reference: CloudFormation drift detection · DOP-C02