You start drift detection on an AWS CloudFormation stack and the call returns immediately with only an ID. Which calls do you make to get the per-resource result, and what do the resource statuses IN_SYNC, MODIFIED, DELETED and NOT_CHECKED tell you?

## Why the first call gives you nothing useful Checking a stack for drift means calling the read API of every service that owns a resource in it. For a large stack that is slow and rate-limited, so CloudFormation models it as a job rather than a request. `DetectStackDrift` starts the job and immediately returns a `StackDriftDetectionId`. Nothing about the result is in that response. ```bash ID=$(aws cloudformation detect-stack-drift \ --stack-name payments-prod \ --query StackDriftDetectionId --output text) ``` One detection run per stack at a time — starting a second while one is in flight is rejected. ## Polling the job `DescribeStackDriftDetectionStatus` takes that id and reports on the job itself: - `DetectionStatus` — `DETECTION_IN_PROGRESS`, `DETECTION_COMPLETE`, or `DETECTION_FAILED`. Failure is usually a permissions problem: the caller could not read one of the resources. - `StackDriftStatus` — the roll-up: `DRIFTED`, `IN_SYNC`, `NOT_CHECKED`, or `UNKNOWN`. - `DriftedStackResourceCount` — how many resources came back drifted, which is the number worth turning into an alarm. A scripted run is a poll loop on `DetectionStatus`, not a single call. ## Reading the per-resource detail The roll-up tells you *whether*, never *what*. For that, `DescribeStackResourceDrifts --stack-name` returns one entry per resource, each carrying a `StackResourceDriftStatus`: **`IN_SYNC`** — every property CloudFormation compared matched the expected value. Note the qualifier: properties it does not support are simply not part of the verdict. **`MODIFIED`** — at least one compared property differs. This entry is the useful one. It carries `ExpectedProperties` and `ActualProperties` as resolved JSON, plus `PropertyDifferences`: a list where each element has a `PropertyPath` (a JSON pointer into the resource's properties), the `ExpectedValue`, the `ActualValue`, and a `DifferenceType`: - `NOT_EQUAL` — the property exists on both sides with different values. The everyday case. - `ADD` — a value is present in the live configuration that the expected configuration does not have, typically an extra entry in a list-shaped property such as a rule or a tag. - `REMOVE` — the property is gone from the live configuration. So an ingress rule added by hand at 3am shows up as an `ADD` under the security group's ingress property path, with the rule itself as the actual value. That is exactly the forensic detail a reviewer wants. **`DELETED`** — the resource is gone. Something deleted it outside the stack, and CloudFormation now holds a logical id pointing at nothing. A subsequent stack update will typically try to act on a resource that no longer exists. **`NOT_CHECKED`** — no comparison happened, almost always because drift detection is not supported for that resource type. It is not a clean bill of health, and in most real stacks there are several of these. You can narrow the listing with `--stack-resource-drift-status-filters` — filtering to `MODIFIED DELETED` is the usual way to get an actionable list, and filtering to `NOT_CHECKED` is how you find out how much of the stack the report never looked at. ## One resource at a time If you already know which resource you care about — say you are verifying a fix — `DetectStackResourceDrift --stack-name X --logical-resource-id Y` checks a single resource and answers **synchronously**, returning that one `StackResourceDrift` structure directly. No job id, no polling. It is also the cheap way to re-check after correcting something, instead of re-scanning a hundred-resource stack. ## Practical shape of an automation Because detection is on demand, teams wrap the whole sequence in a scheduled job: start detection on each stack, poll to completion, list the `MODIFIED` and `DELETED` entries, and publish `DriftedStackResourceCount` as a metric with an alarm on it. Two details bite people writing this the first time: the poll loop is mandatory because the start call is asynchronous, and the roll-up alone is not enough to page a human — the property differences are what make the alert actionable rather than merely alarming. A last subtlety worth carrying into the interview: the results are a snapshot taken while the job ran. If a deployment is in flight during detection you can get differences that are simply mid-update states, which is why scheduled detection is usually pointed at quiet windows.