DOP-C02 Monitoring and Logging Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Deliver CloudTrail logs to an S3 bucket, enable S3 Event Notifications to trigger a Lambda function that filters and publishes to SNS.

  Why this is correct

  CloudTrail writes log files to S3 as compressed JSON objects, and S3 Event Notifications fire as soon as each object is created, triggering a Lambda function in near-real-time. The Lambda can decompress the log file, parse individual events, and apply precise filters—such as specific event names, source IPs, or IAM principals—before publishing only the high-risk actions to SNS. This serverless, event-driven pattern scales automatically with account activity and avoids the cost and noise of notifying on every raw CloudTrail event, making it both efficient and cost-effective for high-volume accounts.

• ✗

  Create a CloudWatch Events rule that matches the specific API calls and publishes to an SNS topic.

  Why it's wrong here

  CloudWatch Events (now Amazon EventBridge) can match CloudTrail events using event patterns and publish each matching event to SNS, but this triggers one SNS message per API call, which can overwhelm subscribers and incur high SNS/Lambda costs in busy accounts. It also does not support sophisticated filtering across fields within a batch of logged events; you must define a rigid pattern for exact matches, and you cannot aggregate or summarize data before alerting. Because CloudTrail already delivers batch JSON files to S3, this approach duplicates event processing and is less scalable than triggering a Lambda on the S3 object to parse and filter at scale.

• ✗

  Use CloudWatch Logs Insights to query CloudTrail logs and set up a metric filter with an alarm.

  Why it's wrong here

  CloudWatch Logs Insights is an interactive query engine, not a real-time event processor; you must manually or periodically run queries, and metric filters only evaluate log events as they stream into CloudWatch Logs, not on the results of Insights queries. To use this approach you must configure CloudTrail to deliver logs to CloudWatch Logs, which incurs additional ingestion costs and latency, and metric filters report only a count of matching events over a time interval—they cannot inspect nested fields like userIdentity or eventSource without complex syntax. The resulting CloudWatch Alarm is threshold-based (e.g., errors in 5 minutes), so it does not provide immediate, per-call SNS notifications and misses isolated high-risk actions that occur below the threshold.

• ✗

  Enable AWS Config rules to detect changes and trigger an SNS notification.

  Why it's wrong here

  AWS Config rules are designed to evaluate resource configuration changes—such as an S3 bucket becoming public or a security group opening a port—against compliance policies, not to inspect the CloudTrail API event stream. A high-risk action like an IAM console login, a GetSecretValue call, or an unsuccessful unauthorized API attempt does not necessarily change a resource configuration, so Config rules will not capture it. Even for configuration changes, Config evaluations are triggered on a change lifecycle or by a periodic schedule, which introduces delay and does not give you the fine-grained event details (who, what, when) that CloudTrail contains. Relying on Config for API-level alerting is therefore both incomplete and not near-real-time.

Go deeper

Related to this question