In AWS Config, how does a rule actually detect that a resource has drifted from your baseline, and how would you make that drift correct itself?

## The recorder is the foundation Nothing in AWS Config works until the **configuration recorder** is on. The recorder watches supported resource types and, on each change, writes a **configuration item (CI)**: the resource's full configuration, its relationships to other resources (this ENI belongs to that instance), and metadata about the change. CIs are delivered to an S3 bucket through the delivery channel and kept as a timeline, which is what lets Config answer historical questions that a live `Describe*` call cannot — "what did this security group look like on the 3rd, and what changed?" This is also the main cost lever: Config bills per configuration item recorded and per rule evaluation. Recording *all* resource types in a busy account, especially noisy ones like Auto Scaling groups or ENIs in a rapidly-scaling fleet, generates a large CI volume. You can scope the recorder to specific resource types, exclude types, and choose a recording frequency of continuous or daily for eligible types. ## Rules and how they trigger A **Config rule** is an evaluation over recorded state. There are two trigger types: - **Configuration change** — the rule runs when a CI is recorded for a resource in its scope. This gives near-real-time drift detection: a bucket is opened to the world, a CI lands, the rule fires, the resource flips to NON_COMPLIANT. - **Periodic** — the rule runs on a schedule (for example every hour, or every 24 hours) regardless of change. This is required for rules whose subject has no per-change signal, such as "do any IAM users lack MFA?" Rules come in three flavours: **AWS managed rules**, identified by a source identifier such as `S3_BUCKET_PUBLIC_READ_PROHIBITED`, `REQUIRED_TAGS` or `RDS_STORAGE_ENCRYPTED`; **custom Lambda rules**, where Config invokes your function with the CI and your code returns a compliance verdict; and **custom policy rules** written in the Guard policy language, which avoids running a Lambda at all. A subtle but important point: a rule evaluates *recorded configuration*, not live reality and not API calls. If the recorder is not capturing a resource type, rules over it never evaluate, and the resource shows as having no results rather than as non-compliant — an absence that is easy to mistake for compliance. ## Making drift fix itself Compliance status alone changes nothing. **Remediation** attaches an SSM Automation runbook to a rule. AWS publishes a large family of `AWSConfigRemediation-*` runbooks for exactly this purpose, and you can write your own. Remediation can be: - **Manual** — an operator selects non-compliant resources and triggers the runbook. - **Automatic** — Config executes the runbook as soon as a resource is found non-compliant, with a configurable retry count and rate limit. The runbook needs an IAM role Config can pass to SSM Automation with permission to make the fix. Automatic remediation deserves real thought: it is excellent for reverting a public S3 bucket or removing an over-broad default security group rule, and dangerous where the "fix" can break a legitimate workload — auto-terminating an untagged instance is the classic self-inflicted incident. A common middle path is auto-remediating only the small set of rules that are unambiguously safe and routing everything else to a ticket. ## Scale: conformance packs and aggregators A **conformance pack** bundles rules and their remediations as one deployable unit, and can be deployed across an Organization so every account gets the same baseline. A **Config aggregator** collects compliance data from multiple accounts and Regions into one view, and supports advanced queries with a SQL-like syntax over recorded configuration — useful for inventory questions such as "every unencrypted EBS volume across the estate". ## How it relates to the neighbours Config is also the evaluation engine underneath most AWS Security Hub controls, which is why Security Hub scores look empty when Config recording is off in a Region. And Config answers *what the resource looked like*, complementing rather than replacing the API-call audit trail. ## Interview framing Strong answers move in one line from "recorder captures CIs" to "rules evaluate them on change or on a schedule" to "remediation runs an SSM Automation runbook", and then volunteer the two real-world caveats: the cost of recording everything, and the risk of automatic remediation on rules that are not unambiguous.