CloudFormation

## What CloudFormation means by "expected" Every CloudFormation stack has a stored template — the exact one that was last successfully applied — plus the parameter values it was applied with. Resolve the parameters, conditions and intrinsic functions in that template and you get a concrete statement of what every resource in the stack is supposed to look like: this bucket has versioning enabled, this security group has exactly these two ingress rules, this table has this billing mode. That resolved picture is the **expected configuration**. Drift is what happens when the real world stops matching it. Somebody opens the console at 3am to unblock an incident and adds an ingress rule. A support engineer flips a setting through a service API. An automated tool with write access to the account edits a tag. None of that goes through CloudFormation, so the stored template still describes the old shape while the live resource has moved on. ## What a detection run actually does Drift detection is a read operation. When you start it, CloudFormation walks the stack's resources, calls the owning service's read APIs to fetch each resource's current configuration, and compares that against the expected values. Each resource lands in one of four states: - `IN_SYNC` — the properties CloudFormation compared all match. - `MODIFIED` — at least one compared property differs; the report carries the expected value, the actual value and the path of each differing property. - `DELETED` — the resource no longer exists; something removed it outside the stack. - `NOT_CHECKED` — CloudFormation made no comparison, usually because drift detection is not supported for that resource type. Those per-resource results roll up to a stack-level status. If anything is `MODIFIED` or `DELETED`, the stack is `DRIFTED`. ## It reports; it does not repair This is the point candidates most often get wrong. A drift report changes nothing. The drifted resource keeps its hand-edited configuration, the stack keeps its stored template, and the next deployment proceeds as if nothing happened. There is no auto-revert switch and no "enforce" mode. So what do you do with a `MODIFIED` result? You make a decision, and there are only two honest options. **Make reality match the code.** Somebody made a change that should not stand, so you put the resource back. Beware of the obvious-looking move here: re-applying the same template does not do it. A stack update diffs the *new* template against the *stored* one, not against live resources — if the template has not changed, CloudFormation answers `No updates are to be performed` and the drift survives. You need an update that genuinely touches the drifted property, or you fix the resource directly. **Make the code match reality.** The change was legitimate and should have gone through the pipeline. Edit the template to describe the new value and update the stack, so the recorded expectation and the live resource agree again. What you must not do is leave it. A drifted resource means the template no longer describes production, which quietly breaks the promise the whole tool rests on: that you can redeploy this stack somewhere else and get the same thing. ## On demand, not continuous CloudFormation does not sit and watch. Drift is evaluated only when a detection run is started — from the console, from the API, or from something you schedule yourself. A stack that says `IN_SYNC` is telling you about the moment detection ran, not about now. Somebody can drift a resource thirty seconds after a clean report and nothing will notice until the next run. That is why teams that care about drift schedule detection rather than clicking it: a periodic job that starts detection across the estate and alerts on the drifted count. ## What it does not look at Drift detection is scoped to the resources the stack manages. It says nothing about resources someone created *next to* the stack — a hand-made security group in the same VPC is invisible to it, because the stack never claimed to own it. It also only looks at configuration, never at data: bucket contents, table rows and log entries are not properties, so they are not drift. And its coverage inside the stack is partial — drift support exists per resource type and per property, which is why `NOT_CHECKED` shows up constantly and why a clean report is weaker evidence than it looks.