A compliance team suspects that someone changed production resources through the console outside of the "AWS CloudFormation" pipeline, leaving the deployed configuration out of step with the templates. They need a repeatable way to identify exactly which stack resources and properties no longer match what CloudFormation provisioned, so the differences can be reconciled. Which approach MOST directly surfaces these unmanaged out-of-band changes?
- ACreate a change set against the current template and inspect the listed resource modifications to find the out-of-band changes.
- BEnable a stack policy that denies modifications so future console changes are blocked and the existing differences become visible.
- CRun drift detection on the stack and review the drift results to see which resources and properties differ from their expected template configuration. Correct
- DRe-run the original template as a fresh stack update so any console changes are overwritten and revealed by the resources that get modified.
Why A is wrong: A change set compares the deployed stack to a proposed template, not to its actual live configuration, so manual console edits that match the template logically will not appear as differences.
Why B is wrong: A stack policy only governs updates made through CloudFormation, not direct console edits, and it neither detects nor reports configuration that has already drifted.
Why C is correct: Drift detection compares each stack resource against its expected template configuration and reports the specific resources and properties that differ, which is exactly how out-of-band changes are surfaced for reconciliation.
Why D is wrong: Re-applying the template would silently overwrite the manual changes rather than first reporting them, which loses the audit detail the compliance team needs to reconcile the differences.