An AWS CloudFormation drift detection run reports a stack IN_SYNC, but you have good reason to believe someone changed one of its resources in the console. Give the reasons CloudFormation can miss a real change.

## What IN_SYNC actually asserts Read the claim narrowly. A stack-level `IN_SYNC` means: of the resources CloudFormation checked, and of the properties within those resources it supports, and at the instant the detection job read them, none differed from the expected values. Every clause in that sentence is a hole, and a senior answer names them. ## Coverage is per resource type Drift detection is not a generic mechanism CloudFormation applies to everything. Each resource type has to be supported explicitly, and the supported set — while large — is not everything. Any resource of an unsupported type comes back `NOT_CHECKED`, which is not a status people read carefully. Crucially, `NOT_CHECKED` resources do not push the stack roll-up to `DRIFTED`; a stack can be `IN_SYNC` overall while containing several resources nobody ever looked at. The practical move is to make that visible: ```bash aws cloudformation describe-stack-resource-drifts \ --stack-name payments-prod \ --stack-resource-drift-status-filters NOT_CHECKED ``` If that returns a long list, your clean report covers a fraction of the stack. Treat the count as a coverage metric, not as noise. ## Coverage is per property Even inside a supported type, drift comparison operates on properties, and not every property of a supported type is compared. A change to a field outside the compared set leaves the resource `IN_SYNC`. This is the sharpest edge of the whole feature, because the resource *was* checked — so nothing in the report hints that anything was skipped. ## Only what the template explicitly set CloudFormation compares against the *expected* configuration, which is built from what the template and its parameters actually declare. A property the template never mentioned, left at the service's default, is not part of the expectation — so a person setting it by hand is not obviously contradicting anything the stack said. The more sparse your template, the less surface drift detection has to compare, which is a real argument for declaring the properties you care about rather than relying on defaults. ## It is a snapshot, not a watch Detection runs when it is started and reports the state it read. Two consequences follow. First, a change made after the run is invisible until the next run, so the freshness of the answer is whatever your schedule is. Second, a change made *and reverted* between runs leaves no trace at all — the drift report is not an audit trail, and it never tells you who did anything. If the question is "who changed prod", the answer is an account-level audit log, not a drift report. ## Things it structurally never sees - **Resources next to the stack.** Detection walks the stack's own resources. A rule added to a security group the stack does not manage is out of scope entirely. - **Data, not configuration.** Bucket contents, table items, parameter values inside another service — none of those are resource properties. - **State that is not modelled.** Runtime conditions, in-place software on an instance, and anything a resource does after creation are outside the template's vocabulary. ## What to do instead of trusting the report A senior answer does not stop at the limitations; it says what changes. **Make detection routine and measured.** Because it is on demand, wire a scheduled job — an EventBridge scheduled rule invoking a small function that calls `DetectStackDrift` per stack, polls, and publishes `DriftedStackResourceCount` — and alarm on it. Publish the `NOT_CHECKED` count alongside so the coverage gap is visible rather than assumed. **Detect at the moment it matters.** Running detection immediately before a deployment is worth more than a nightly scan, because that is the moment an unnoticed hand edit is about to be silently overwritten or silently preserved. **Prefer prevention to detection.** The strongest control is that nobody can make the change by hand in the first place: production write access through the console is the thing that produced the drift, and permission design removes the whole class of problem that drift detection can only sample for afterwards. **Close the loop when drift is found.** Every `MODIFIED` result is a decision — revert the resource, or codify the change in the template and update. Leaving it means the template has stopped describing production, and the next person to redeploy the stack finds that out the hard way. ## The one-line version Silence is not proof. `IN_SYNC` means "nothing I looked at differed", and the interesting engineering question is always how much of the stack that sentence actually covers.