DOP-C02 Monitoring and Logging Practice Question

A company runs a critical application on Amazon ECS with Fargate. The DevOps engineer wants to receive alerts when the application's error rate exceeds 5% over a 5-minute period. Which combination of services should be used?

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

✓

Amazon CloudWatch Logs metric filter to count errors, then a CloudWatch alarm.

The correct solution is to use Amazon CloudWatch Logs metric filter to count errors from application logs, which creates a custom metric representing the error count or rate. Then, a CloudWatch alarm can be configured on that metric to trigger when the error rate exceeds 5% over a 5-minute period. Option C is correct. Option A is incorrect because CloudWatch Synthetics is for synthetic monitoring (endpoint health checks), not for analyzing logs for error rates. Option B is incorrect because CloudWatch Logs Insights is an interactive query tool for ad-hoc analysis, not designed for real-time alarming. Option D is incorrect because CloudWatch Contributor Insights analyzes top contributors (e.g., error sources), but does not directly count error rates for alarms.

Answer analysis

Option-by-option breakdown

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

✗
Amazon CloudWatch Synthetics to monitor the application endpoint and create an alarm.
Why it's wrong here
CloudWatch Synthetics uses scripted canaries (Node.js/Python) to continuously generate traffic and validate endpoint availability, latency, and UI behavior. It cannot parse or count errors from existing application logs, so it cannot produce an error-rate metric from your ECS Fargate container's log streams. Even if you alarm on canary failures, that reflects synthetic user experience, not the real aggregate error rate in your application's logs.
✗
Amazon CloudWatch Logs Insights to query logs every 5 minutes and trigger a Lambda function.
Why it's wrong here
CloudWatch Logs Insights is an interactive query engine for analyzing log data on-demand; it is not designed for real-time or scheduled alerting. While you could run a Lambda function every 5 minutes to execute a query via the AWS SDK, that reintroduces compute, latency, and cost, and lacks the native, low-latency threshold evaluation that CloudWatch Alarms provide. A metric filter continuously processes log events as they arrive, making it the correct service for this use case.
✓
Amazon CloudWatch Logs metric filter to count errors, then a CloudWatch alarm.
Why this is correct
A CloudWatch Logs metric filter parses each incoming log event in real time, incrementing a custom (or extracted) metric whenever a log line matches a pattern (e.g., contains "ERROR" or a JSON field). You can then create a CloudWatch Alarm on that metric with an appropriate threshold, period, and statistic (e.g., Sum of errors over 5 minutes). This approach provides native, serverless, low-latency alerting without additional compute, and it is exactly the intended use case for detecting error rates from logs.
✗
Amazon CloudWatch Contributor Insights to detect error patterns, then an alarm.
Why it's wrong here
CloudWatch Contributor Insights is designed to identify top contributors—such as the highest-traffic IP addresses, users, or URLs—by analyzing log fields and generating contributor metrics. It does not provide a straightforward way to define an error-rate metric (e.g., errors per minute) or raise an alarm directly on the aggregate rate. While you could create an alarm on a contributor metric, that would be an unusual and roundabout implementation, and Contributor Insights itself does not perform threshold-based error-rate detection the way a metric filter does.

Go deeper

DOP-C02 Monitoring and Logging Practice Question

Why each option matters

Option-by-option breakdown

Related to this question