DOP-C02 Incident and Event Response Practice Question

A company uses AWS Organizations with multiple accounts. The security team needs to receive real-time notifications when any IAM user in any account creates an access key. Which solution is the most operationally efficient?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Use AWS Config rules with a CloudWatch Events rule to detect CreateAccessKey and publish to an SNS topic.

The most operationally efficient because AWS Config rules can evaluate resource configurations and, when paired with a CloudWatch Events rule, can detect the CreateAccessKey API call in real-time and publish a notification to an SNS topic. Option A is incorrect because while CloudTrail logs are useful for auditing, using Athena to query logs is not real-time and adds operational overhead. Option B is incorrect because SCPs can deny actions but do not provide notifications. Option C is incorrect because Trusted Advisor checks for exposed keys after creation, not in real-time.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Enable CloudTrail in all accounts and send logs to a central S3 bucket, then use Amazon Athena to query.
Why it's wrong here
Centralizing CloudTrail logs into an S3 bucket and querying them with Athena enables deep forensic analysis but is fundamentally a batch, on-demand process. CloudTrail log delivery is batched (often every 5–15 minutes), and Athena only returns results when someone runs a query, so there is no proactive, real-time alert when a CreateAccessKey event occurs. This posture is useful for post-incident investigation, but it cannot notify administrators in time to prevent or quickly respond to malicious activity.
✗
Create an SCP that denies access key creation and monitor with CloudWatch.
Why it's wrong here
An SCP that denies iam:CreateAccessKey is a preventive guardrail: it stops the action from succeeding at the AWS Organizations level, but it generates no SNS notification and does not emit a CloudWatch event when the action is attempted. Because the request is denied, no access key is created, and the SCP itself has no built-in alerting mechanism; alerting would require separately processing CloudTrail logs for Denied events. Additionally, SCPs are not an accurate detection mechanism and cannot affect the management account, making this a poor match for a detection-notification requirement.
✗
Use AWS Trusted Advisor to check for exposed access keys.
Why it's wrong here
AWS Trusted Advisor's exposed-access-key check periodically scans for keys that have been publicly disclosed (for example, in public code repositories), not for new CreateAccessKey API calls. The check runs on a scheduled basis rather than in real time, and it doesn't examine CloudTrail's event stream, so it cannot detect the moment an access key is created. Even if it eventually flags a compromised key, it does not satisfy the requirement to alert instantly upon key creation.
✓
Use AWS Config rules with a CloudWatch Events rule to detect CreateAccessKey and publish to an SNS topic.
Why this is correct
The CloudWatch Events (EventBridge) rule consumes the CloudTrail API event stream, matches the CreateAccessKey event pattern, and triggers an SNS topic in near real-time, giving immediate notification the moment the key is created. AWS Config rules complement this by continuously evaluating the resulting IAM configuration for compliance, but the decisive low-latency detection comes from the event rule matching the API call rather than relying on manual log analysis or periodic scans.

Go deeper

DOP-C02 Incident and Event Response Practice Question

Why each option matters

Option-by-option breakdown

Related to this question