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.

• ✗

  Enable CloudWatch Logs for the ALB and use CloudWatch Logs Insights to query 5xx logs, then create a metric filter and alarm.

  Why it's wrong here

  Enabling ALB access logs and using CloudWatch Logs Insights with a metric filter is unnecessarily complex and indirect: access logs must first be enabled and delivered to S3, then ingested into CloudWatch Logs, which adds latency. The ALB already publishes the HTTPCode_ELB_5XX_Count metric natively, so parsing logs to create a separate metric filter duplicates existing data and incurs additional cost and operational overhead. Furthermore, CloudWatch Logs Insights is designed for ad-hoc querying, not as a real-time alarm source.

• ✗

  Configure AWS Config rules to check ALB 5xx error counts and trigger alarms.

  Why it's wrong here

  AWS Config rules are designed to evaluate resource configuration compliance against desired policies, such as ensuring an ALB has a certain security policy or is associated with a WAF, not to monitor transient operational metrics like HTTP 5xx counts. Config does not ingest CloudWatch metrics, and it cannot evaluate time-series data or trigger alarms based on error thresholds. While a custom AWS Config rule could invoke a Lambda function, that function would still need to call CloudWatch GetMetricData, making this a roundabout and unsupported method for real-time monitoring.

• ✓

  Use CloudWatch ALB metrics (HTTPCode_ELB_5XX_Count) and create a CloudWatch Alarm on the Sum statistic with a threshold based on total request count.

  Why this is correct

  Correct: The Application Load Balancer natively emits the HTTPCode_ELB_5XX_Count metric to CloudWatch, representing the number of 5xx responses returned by the load balancer itself. Create a CloudWatch Alarm on this metric using the Sum statistic over a period (e.g., 5 minutes) and set a threshold, optionally using a math expression to divide by RequestCount to track the error ratio. This is the simplest and most direct method because it uses existing metrics with no additional setup, latency, or cost.

• ✗

  Use AWS X-Ray to trace requests and create a CloudWatch alarm based on X-Ray error rate.

  Why it's wrong here

  AWS X-Ray focuses on distributed tracing of individual requests, providing insights into latency, service dependencies, and errors at the trace level, but it does not aggregate ALB 5xx counts into a CloudWatch metric. To get error rate from X-Ray you would need to create a group and then publish a CloudWatch metric from that group through a custom solution, such as a Lambda function. X-Ray also requires your application to be instrumented with SDKs, making it an unnecessarily heavy and indirect approach for simple 5xx monitoring that native ALB metrics already provide.

Go deeper

Related to this question