A county remediates common CIS AWS Foundations failures with event-driven automation when Config detects drift. What improvement pattern is that?
Select an answer to reveal the explanation.
Short Explanation
When Config sees the same CIS Foundations miss again, you should remediate it with event-driven automation—you won't fix recurring drift by chasing isolated threat intel findings since they're one-off threats. You'll miss it if you're digging through historical API audit trails since that's past API history, not current config compliance. You'll still miss the recurring pattern with aggregated posture correlations since they summarize findings instead of triggering on Config's baseline rule, so stick with the Config event.
Full Explanation
Event-driven remediation of recurring AWS baseline failures detected by Config in municipal accounts closes common CIS AWS Foundations misses when drift occurs, instead of event-driven remediation of isolated AWS threat intel findings detected by Config in municipal accounts which addresses one-off threat intelligence rather than recurring classes of baseline noncompliance. Config detects noncompliance; automation applies the known fix for recurring classes of failure—public access blocks, required logging, encryption settings—and records the change for county accountability. That continuous-improvement pattern keeps baseline hygiene current across county AWS accounts that otherwise accumulate the same findings repeatedly.
Event-driven remediation of isolated AWS threat intel findings detected by Config in municipal accounts fails because the county pattern targets recurring CIS Foundations configuration failures, not isolated threat-intel detections of single malicious indicators. Event-driven remediation of historical AWS API audit trails detected by Config in municipal accounts fails because Config evaluates current resource configuration against CIS AWS Foundations rules rather than preserving historical API activity records, which is CloudTrail's audit role, and the pattern requires fixing recurring baseline drift not reviewing past API calls. Event-driven remediation of aggregated AWS posture correlations detected by Config in municipal accounts fails because Config detects specific recurring baseline noncompliance for direct remediation rather than producing aggregated cross-source posture correlations, which is Security Hub's aggregation role, so it does not describe the Config-detected recurring-failure pattern.
Exam caveat: Event-driven Config remediation of recurring CIS Foundations failures is the expected continuous-improvement pattern. Isolated threat intel, historical API audit trail, and aggregated posture correlation event-driven remediation variants are common distractors.
Operational check for county cloud security: identify a recurring CIS Foundations failure class, implement Config-triggered remediation in a staging account, inject drift, confirm auto-remediation and ticketing, then promote after burn-in while keeping Config enabled in production municipal accounts.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.