DOP-C02 Monitoring and Logging Practice Question

A company is using Amazon CloudWatch Logs to collect logs from multiple applications. The DevOps team wants to create a metric filter to count the number of ERROR log entries and trigger an alarm when the count exceeds 10 in 5 minutes. Which TWO steps must the team take? (Choose TWO.)

⚠ Common exam trap

DOP-C02 often tests whether candidates confuse the roles of metric filters, subscription filters, and dashboards — the trap is selecting subscription filters (for streaming) or dashboards (for visualization) when the requirement is specifically to count and alarm on log events.

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

✓

Create a metric filter on the log group that extracts ERROR count.

Option B is correct because a CloudWatch Logs metric filter must be defined on the log group to parse log events and publish a custom metric that counts occurrences of the ERROR pattern; this is the mechanism that turns raw log data into a numeric CloudWatch metric. Option C is correct because once the metric exists, a CloudWatch alarm is created against that metric with a threshold of 10 and an evaluation period of 5 minutes so it can trigger when the count exceeds the limit. Option A is not needed because subscription filters stream logs to destinations like Kinesis Data Firehose for processing, not for creating metrics or alarms. Option D is irrelevant because retention policy only controls how long log events are stored and does not affect metric filtering or alarming. Option E is unnecessary because a dashboard only visualizes metrics and does not create the metric or trigger the alarm.

Answer analysis

Option-by-option breakdown

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

✗
Create a subscription filter to stream logs to Amazon Kinesis Data Firehose.
Why it's wrong here
Creating a subscription filter to stream logs to Kinesis Data Firehose is incorrect for this alerting scenario. A subscription filter routes matching log events in real time to destinations such as Amazon Kinesis Data Streams, Lambda, or Firehose, but it does not generate a CloudWatch metric or invoke an alarm directly. While the Firehose stream could later be processed with custom code to count errors, that requires additional services and does not natively expose an ERROR count metric for CloudWatch alarms. Therefore it does not satisfy the requirement to trigger an alert when the count exceeds 10.
✓
Create a metric filter on the log group that extracts ERROR count.
Why this is correct
Creating a metric filter on the log group that extracts ERROR count is the first required action. A metric filter defines a pattern, such as the literal string 'ERROR', and evaluates each incoming log event against that pattern; every match increments a specified CloudWatch metric value. The filter can also output a custom value and unit, producing a metric that can be used for alarms and dashboards. This is the native CloudWatch Logs mechanism to translate unstructured log text into a numerical time-series metric.
✓
Create a CloudWatch alarm on the metric with the threshold of 10.
Why this is correct
Creating a CloudWatch alarm on the metric with the threshold of 10 is the second required action because a metric filter only records the metric—it does not proactively notify anyone. The alarm continuously compares the extracted ERROR count metric against the threshold of 10 over a specified period, and when the threshold is breached for the configured consecutive evaluation periods, it changes state and triggers actions such as an Amazon SNS notification or EC2 Auto Scaling policy. Without this alarm, the metric filter alone cannot alert the operations team when error volume exceeds the threshold.
✗
Set a log group retention policy to retain logs indefinitely.
Why it's wrong here
Setting a log group retention policy to retain logs indefinitely is ineffective for detecting a spike in ERROR count because retention only controls how long CloudWatch Logs stores the raw log events. It does not scan, filter, or aggregate ERROR occurrences, nor does it feed any metric or alarm state. Additionally, indefinite retention increases storage costs and does not improve either the extraction of metrics or the alerting capability. Thus, it is irrelevant to the monitoring requirement described in the question.
✗
Create a CloudWatch dashboard to visualize the ERROR count.
Why it's wrong here
Creating a CloudWatch dashboard to visualize the ERROR count is not a valid alerting mechanism because dashboards provide a passive, human-readable view of metric trends; they do not evaluate thresholds or initiate actions when conditions change. Even if the dashboard shows the ERROR count, no one would be notified automatically if the count exceeds 10 unless an alarm is also configured to send notifications. Dashboards are useful for post-incident analysis and operational visibility, but they cannot satisfy a requirement to trigger an alert or notification.

Go deeper

DOP-C02 Monitoring and Logging Practice Question

Why each option matters

Option-by-option breakdown

Related to this question