Evaluating AWS Resource Compliance: Config, Security Hub, Audit Manager

AWS Config is the compliance engine, and everything downstream depends on two plumbing pieces you must know cold. The configuration recorder watches supported resource types (all types, or a selected list) in a Region and emits a configuration item — a point-in-time JSON snapshot of a resource's state — every time that state changes. The delivery channel ships configuration history files and periodic snapshots to an S3 bucket and can publish change notifications to an SNS topic. Both must exist for Config to function; you get exactly one recorder and one delivery channel per Region per account.

Know what breaks when the recorder is stopped: no new configuration items are produced, so change-triggered rules stop evaluating entirely and the resource timeline develops a gap you can never backfill — a real problem when an auditor asks what a resource looked like in March. Periodic rules continue to run on their schedule, which is why a half-broken Config setup can look deceptively alive.

Rules come in two flavors. Managed rules are AWS-authored checks such as restricted-ssh, required-tags, or rds-storage-encrypted — parameterizable, no code. Custom rules are either Lambda-backed (your function receives the configuration item and returns COMPLIANT, NON_COMPLIANT, or NOT_APPLICABLE — maximum flexibility, but you own the code and its permissions) or custom policy rules written in CloudFormation Guard syntax, a declarative policy-as-code DSL evaluated by Config itself with no Lambda to build or maintain.

Every rule has an evaluation trigger: configuration change (fires when a matching resource's configuration item changes), periodic (fires on a fixed schedule from 1 to 24 hours regardless of changes), or both. Encryption checks suit change triggers; checks with no underlying resource event — such as IAM credential age — must be periodic.

Detection without response is a dashboard, not a control. Config closes the loop through a remediation configuration: an association between a specific rule and a Systems Manager Automation runbook that fixes the noncompliant resource. AWS ships purpose-built runbooks — the AWSConfigRemediation-* family plus classics like AWS-DisablePublicAccessForSecurityGroup — and you can author your own for anything they don't cover.

The mechanics the exam probes: the runbook executes under an AutomationAssumeRole that you supply as a parameter. That IAM role must trust the Systems Manager service and hold the permissions the runbook's steps actually need — revoking security group rules, putting bucket policies, whatever the fix requires. Remediation can be automatic (fires as soon as the rule flags the resource, with configurable retry attempts and retry intervals) or manual (a human clicks Remediate in the console). For changes too risky to fully automate, an Automation runbook can include an approval step (aws:approve), pausing execution until a designated approver signs off — automation with change control, a pattern the exam rewards at concept level.

Notifications ride a separate rail: Config emits compliance-change events to EventBridge, and an EventBridge rule fans them out to SNS, a ticketing system, or an incident channel. That matters for the resources you cannot auto-fix — you can't encrypt an existing unencrypted RDS instance in place, so the right "remediation" for rds-storage-encrypted is a ticket to rebuild from an encrypted snapshot, not a runbook. Choosing between auto-fix and notify-and-track is exactly the judgment Task 6.3 tests.

One rule in one account proves nothing about an organization. Conformance packs package a set of Config rules — and optionally their remediation configurations — into a single YAML template deployed and tracked as one unit. AWS publishes prebuilt packs mapped to frameworks (Operational Best Practices for PCI DSS, HIPAA Security, CIS, and others), and you can author custom packs. From a delegated administrator account you can deploy a pack organization-wide, so every member account gets the same rule set and drift from the baseline is impossible to hide. Each pack reports a compliance score — the percentage of rule-resource combinations currently passing — which turns "are we compliant with our PCI controls?" into a single trending number per account.

The multi-account view is the job of the aggregator. An aggregator collects configuration and compliance data from multiple source accounts and Regions into one read-only pane. Two modes matter: an organization aggregator pulls from every account automatically once trusted access is enabled, while an individual-accounts aggregator requires each source account to explicitly authorize the aggregator account — an unauthorized source simply doesn't appear, which is the classic "aggregator is missing accounts" scenario. When a question says "a single view of compliance status across all accounts in the organization," the answer is an aggregator (often paired with org-deployed conformance packs).

Finally, keep the Config versus CloudTrail distinction sharp: Config records state — what a resource looks like now and at any recorded point in the past, and whether that state is compliant. CloudTrail records events — which principal made which API call, from where, and when. "Who opened this security group?" is CloudTrail; "was this security group compliant on the audit date?" is Config. The Config timeline even links each change to the CloudTrail events that caused it.

Where Config gives you rule-by-rule verdicts, Security Hub standards give you a graded scorecard against recognized baselines. Enabling a standard — AWS Foundational Security Best Practices (FSBP), CIS AWS Foundations Benchmark, PCI DSS, or NIST 800-53 — turns on its set of controls, each an automated check that reports a status of passed or failed (with states like suppressed or no-data on top). Security Hub rolls those statuses into a security score per standard: the percentage of enabled controls currently passing. That score is your continuous posture metric — the number a CISO watches between audits.

An exam-relevant dependency: most Security Hub controls are backed by AWS Config rules that Security Hub creates and manages on your behalf, so a stopped Config recorder silently degrades your Security Hub scores too. One broken recorder, two broken compliance surfaces.

Across an organization, a delegated administrator account with cross-Region and cross-account aggregation sees every member's control statuses and scores in one place. The detection-and-response architecture behind that — finding routing, EventBridge integration, response automation — belongs to Domain 1; here the point is narrower: Security Hub is the compliance reporting layer, the org-wide answer to "what fraction of the CIS benchmark do we pass, per account?"

Automation rules, at concept level, let the administrator automatically modify matching findings — suppress a control finding that's an accepted risk in a sandbox OU, or raise severity on production accounts — so the score reflects your actual risk posture instead of drowning in known exceptions. Suppression is deliberate and auditable; it is not deletion.

Config tells you a resource is compliant; an auditor wants evidence, organized against the framework they're auditing. That is AWS Audit Manager. You create an assessment from a prebuilt or custom framework — SOC 2, PCI DSS, HIPAA, and many others — and Audit Manager continuously and automatically collects evidence mapped to each control: Config rule compliance results, Security Hub control findings, CloudTrail user activity, and configuration snapshots from API calls. Evidence lands in daily evidence folders per control, which you review and roll into an assessment report for the auditor. The distinction to internalize: Config answers the technical question ("is this bucket encrypted?"); Audit Manager answers the audit question ("show me twelve months of proof, organized against SOC 2 control CC6.1").

AWS Artifact covers the other half of the shared responsibility model. It is a self-service portal for downloading AWS's own compliance documents — SOC 1/2/3 reports, PCI attestations, ISO 27001 certifications — proving the security of the cloud, which no amount of your own tooling can attest to. Artifact also manages agreements such as the Business Associate Addendum, at mention level. When a question says "the auditor needs AWS's SOC 2 report," the answer is Artifact — full stop, no Config involved.

Most frameworks demand recurring access reviews, and the exam expects you to know the native tooling. IAM Access Analyzer unused-access findings are the modern answer: an unused-access analyzer continuously flags IAM roles that haven't been used, unused access keys and console passwords, and granted-but-unused permissions across the organization — a standing feed of least-privilege violations rather than a quarterly spreadsheet exercise. The older primitives still appear as answers: the IAM credential report is a downloadable account-wide CSV of every user's credential age, key rotation, and MFA status — ideal for the periodic "prove all keys were rotated" check — and access advisor last-accessed data shows when a principal last used each service, the input for pruning stale permissions. Designing the least-privilege policies themselves is Domain 4 territory; Task 6.3 is the review loop that verifies them. Trusted Advisor deserves a mention: its security checks (root MFA, exposed access keys, open security groups) overlap this space, but it is advisory — it feeds findings, not an audit trail.

Tag compliance is its own recurring exam theme because tags drive cost allocation, access control, and audit scoping. The detective control is the managed Config rule required-tags: it flags any in-scope resource missing your mandated keys or values, and pairs naturally with an EventBridge notification or a remediation ticket. At the organization layer, tag policies (an AWS Organizations policy type) define the standard tag keys, casing, and permitted values, and report noncompliant tags across all accounts — standardization and reporting at the org level, with the Config rule doing per-resource detection. Preventing untagged resources from being created at all is a guardrail question, which belongs to Task 6.1.

Task 6.3 is ultimately about running this pipeline: framework requirement → detective control → remediation or ticket → evidence. Walk it end to end with a PCI-style requirement: "restrict inbound traffic to the cardholder data environment to only necessary ports."

Step 1 — detective control. Deploy the Operational Best Practices for PCI DSS conformance pack org-wide from the Config delegated administrator, or at minimum enable restricted-ssh and restricted-common-ports against the CDE accounts. The rules are change-triggered: the moment anyone opens a security group, evaluation fires.

Step 2 — response. Attach a remediation configuration binding the rule to AWS-DisablePublicAccessForSecurityGroup, running automatically under an AutomationAssumeRole scoped to revoke security group ingress. For findings that can't be auto-fixed safely, an EventBridge rule on the compliance-change event opens a ticket instead. Security Hub's PCI DSS standard scores the same posture continuously, so the compliance owner watches one number trend, not individual rules.

Step 3 — evidence. An Audit Manager assessment on the PCI framework automatically files the Config compliance results and CloudTrail activity into daily evidence folders under the matching control. When the assessor asks "prove ingress was restricted throughout the period," you export the assessment report; the Config timeline shows each security group's state on any date, with the CloudTrail events that changed it. For the provider side, you hand over AWS's PCI attestation from Artifact.

That is the difference between a point-in-time audit (scramble, screenshot, hope) and a continuous compliance program: the evidence exists before anyone asks. The Well-Architected Tool complements this at the architecture level — a structured review of your workload against the Security Pillar's best practices, per exam guide skill 6.3.3.

The exam loves broken-pipeline scenarios, and each failure has a short diagnostic list.

Rules aren't evaluating. First suspect the recorder: stopped, or not recording the resource type in question (a selective recorder that omits AWS::EC2::SecurityGroup means no configuration items, so change-triggered rules never fire). Second, check the rule's scope — a rule filtered to a tag or resource ID silently ignores everything else. For Lambda-backed custom rules, verify Config is allowed to invoke the function (the function's resource policy must permit the Config service) and check the function's own logs for errors: a crashing evaluator looks identical to a rule that never ran.

Auto-remediation isn't firing. Three culprits cover nearly every case: the remediation is configured as manual rather than automatic; the AutomationAssumeRole is missing permissions for the runbook's steps or doesn't trust Systems Manager; or the rule-to-remediation association was never created — the rule flags noncompliance forever while the runbook sits unused. Exhausted retry attempts on a persistently failing runbook also stop further attempts.

The aggregator is missing accounts. In individual-accounts mode, the source account never authorized the aggregator — authorization is per source account and pending until accepted. In organization mode, trusted access or the required service-linked role isn't in place, or the account has left the organization.

Conformance packs fail to deploy in member accounts. Check the prerequisites: the member's Config recorder must be enabled and started, the Config service-linked roles must exist, and any custom Lambda-backed rules in the pack must reference functions that actually exist in that account. A pack that deploys cleanly in the management account and fails in members is almost always a missing prerequisite, not a bad template.