DOP-C02 Incident and Event Response 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.

• ✓

  CloudWatch Logs metric filters and alarms

  Why this is correct

  CloudWatch Logs metric filters are the correct mechanism for real-time alerting on CloudTrail API activity. A metric filter defines a pattern that matches specific CloudTrail log events, such as `errorCode = "UnauthorizedOperation"`, and continuously increments a custom CloudWatch metric. A CloudWatch alarm can then evaluate that metric over a fixed period (e.g., 5 minutes) and trigger an SNS notification when the threshold is breached, enabling fast, automated responses to suspicious API calls.

• ✓

  CloudTrail with CloudWatch Logs integration

  Why this is correct

  CloudTrail's integration with CloudWatch Logs is the enabling pipeline: it streams audit events from all tracked accounts or regions into a centralized CloudWatch Logs log group in near real time. Without this integration, events remain only in S3 files, which are delivered on a 5–15 minute delay and cannot directly drive CloudWatch alarms. While essential, this integration alone does not alert on API calls — it is the prerequisite that makes metric filters and alarms possible.

• ✗

  CloudTrail with Amazon S3 event notifications

  Why it's wrong here

  Amazon S3 event notifications are triggered when a new object is written to a bucket, but CloudTrail delivers its log files to S3 on a rolling schedule (typically every 5–15 minutes), making notifications asynchronous and far from real time. Even if you trigger a Lambda function on ``s3:ObjectCreated:*``, you would only know that a log file arrived, not which API call was made, without parsing the entire file. You also cannot configure S3 notifications to filter based on the content of CloudTrail events, so this approach is unsuitable for immediate security alerting.

• ✗

  Amazon Athena and CloudWatch dashboards

  Why it's wrong here

  Amazon Athena can run SQL queries against CloudTrail logs stored in S3, and CloudWatch dashboards can visualize the query results, but this combination is reactive and human-driven. Dashboards only display current data when manually refreshed or on a schedule; they do not push notifications or trigger automated actions when unusual API calls occur. Athena queries also incur per-execution costs and have no built-in threshold evaluation, so this setup is for post-incident analysis, not alerting.

• ✗

  AWS Config and AWS Lambda

  Why it's wrong here

  AWS Config evaluates resource configurations against managed or custom rules and records configuration changes, not API calls made via CloudTrail. Although Config can invoke Lambda functions for remediation when a configuration becomes noncompliant, it has no visibility into who performed an action or which API was called. CloudTrail is the service dedicated to recording API activity; conflating Config with CloudTrail misunderstands the distinct data sources each service captures.

Go deeper

Related to this question