Macie, Config, and automated assessment
Lesson 4 of 4 in Monitoring and Alerting.
Amazon Macie answers a question nothing else in the detection stack can: where is the sensitive data? It inventories your S3 buckets continuously — public access, encryption, sharing, versioning — and runs sensitive-data discovery over object content.
Two gears. Automated sensitive data discovery samples across your buckets continuously and builds a map of where sensitive data probably lives, which is the right default when you do not yet know what you have. Discovery jobs are the targeted scan: you choose buckets, a one-off run or a schedule, and the data identifiers to apply — AWS-built managed identifiers for credentials, financial, personal and health data, plus custom data identifiers that pair your own regular expression with optional keywords, a maximum match distance and an ignore list, for formats only your business uses.
Then the limit that the exam turns into a distractor every time: Macie reports, it does not remediate. A finding names the bucket, the object and the identifier matched. It does not redact the object, does not move it, does not change the bucket policy. The remediation is yours — a finding to EventBridge, a Lambda or SSM runbook that quarantines the object, tightens the policy, or files the case. Any answer option in which Macie “masks” or “removes” sensitive data is wrong.
| Service | Verb | Cadence | What arrives | Does NOT |
|---|---|---|---|---|
Amazon Macie | discovers | continuous sampling, or scheduled discovery jobs | findings naming bucket, object and identifier | redact, move or encrypt the data it finds |
AWS Config | records and evaluates | on every configuration change, plus periodic rules | a configuration item timeline and COMPLIANT / NON_COMPLIANT verdicts | prevent the change — and record nothing while the recorder is off |
SSM State Manager | enforces | on the association’s schedule, change or no change | nothing to read — the desired state is simply re-applied | tell you why it drifted; that is Config’s timeline |
AWS Config is the historian. The configuration recorder — one per account per Region — writes a configuration item every time a resource changes: its attributes, its relationships to other resources, and the CloudTrail event id that caused the change. That last field is what turns “the security group is open” into “it was opened at 02:14 by this role via this API call”, which is why Config and CloudTrail are investigated together rather than in sequence.
On top of the record sit four constructs, and the exam expects you to pick the right one for the scale described:
- Config rules are individual checks. Managed rules cover the common ground (
s3-bucket-server-side-encryption-enabled,restricted-ssh,cloudtrail-enabled) with parameters you set; custom rules run your own Lambda function or a CloudFormation Guard policy. Change-triggered rules fire on a matching configuration item; periodic rules run on an interval, which is how you cover resource types that do not emit useful change events. - Conformance packs bundle rules, their parameters and their remediation into one deployable template with its own compliance score. AWS publishes packs mapped to CIS, PCI DSS, NIST and per-service best practice. Deployed from the Config delegated administrator as an organization conformance pack, one action covers every account including future ones — this is exactly what the exam guide means by deploying conformance packs for regular assessment.
- Aggregators pull configuration and compliance data from many accounts and Regions into one account, where advanced queries let you ask SQL questions of the whole inventory (“every unencrypted EBS volume, by account”). Aggregation is read-only: it reports faithfully on accounts whose recorders are off, which is to say it reports nothing.
- Remediation actions attach an SSM Automation runbook to a rule, run automatically or after approval, with a retry count. This is where detection becomes correction.
One construct sits outside that loop because it does not wait for a verdict. A State Manager association binds an SSM document to a target set — instance ids, a tag query, a resource group — and a schedule, and re-applies it on that cadence whether or not anything drifted. Install the CloudWatch agent. Apply this agent configuration from Parameter Store. Keep the SSM Agent current. Run the hardening baseline.
The difference from Config remediation is worth stating plainly, because exam wording distinguishes them. Config remediation is reactive: something changed, a rule noticed, a runbook corrected it. State Manager is convergent: the desired state is re-asserted on a timer, so drift has a bounded lifetime even when nothing generated an event — which covers the cases Config cannot see, like a configuration file edited inside an instance. When a question says “ensure the CloudWatch agent stays installed and correctly configured across a fleet”, that is a State Manager association, not a Config rule.
Put the three layers in order and you have the automated-assessment pattern the exam is testing: assess continuously (conformance packs, Security Hub standards, Macie discovery, Inspector scans), correct reactively (Config remediation, EventBridge to a runbook), enforce convergently (State Manager associations) — and above all of it, prevent where you can, which is Domain 6’s job.
Key terms: Managed and custom data identifiers, AWS Config, Configuration item (CI), AWS Config rule, Conformance pack, Config aggregator, Systems Manager State Manager, Systems Manager Automation document (runbook)
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.