DOP-C02 Monitoring and Logging Practice Question
A company uses AWS CloudFormation to deploy a three-tier web application. The stack includes an Application Load Balancer (ALB), an Auto Scaling group of EC2 instances, and an Amazon RDS Multi-AZ database. The DevOps team has configured the EC2 instances to send application logs to CloudWatch Logs using the CloudWatch agent. They also set up a CloudWatch alarm on the ALB's 5xx error count. During a recent deployment, the team noticed that the alarm did not trigger even though the application was returning 5xx errors. The team verified that the CloudWatch agent is running on the instances and logs are appearing in CloudWatch Logs. What should the team do to ensure the alarm triggers correctly?
⚠ Common exam trap
Recognize the difference between ALB-generated 5xx errors (HTTPCode_ELB_5XX_Count) and target-generated 5xx errors (HTTPCode_Target_5XX_Count).
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
✓
Verify that the CloudWatch alarm is using the correct metric 'HTTPCode_Target_5XX_Count' and that the threshold is appropriate.
The ALB publishes two separate 5xx metrics: HTTPCode_ELB_5XX_Count (errors generated by the load balancer itself, e.g., 503 due to no healthy targets) and HTTPCode_Target_5XX_Count (errors returned by the backend targets). Since the application is returning 5xx errors from the EC2 instances, the alarm should use HTTPCode_Target_5XX_Count. The team likely set the alarm on HTTPCode_ELB_5XX_Count, which would not trigger for backend errors. Option A is not the best because creating a log-based metric filter would create a separate alarm and does not fix the existing ALB alarm. Option B is wrong because switching to HTTPCode_ELB_5XX_Count still tracks the wrong metric. Option C is unrelated because the agent is already working and logs are flowing.
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 metric filter on the EC2 instance's log group to count 5xx errors and create an alarm on that.
Why it's wrong here
A metric filter on the EC2 instance log group only captures application log lines that you explicitly parse; it cannot see ALB target responses because those are measured by the load balancer itself via CloudWatch metrics. Even if ALB access logs are enabled, they are delivered to S3 or CloudWatch Logs separately, and a custom log filter would not reliably represent the target error count. The operational signal you need is the predefined ALB metric, not a log-based approximation that misses failed requests never reaching the application.
- ✗
Change the CloudWatch alarm to use the 'HTTPCode_ELB_5XX_Count' metric instead.
Why it's wrong here
The HTTPCode_ELB_5XX_Count metric measures only 5xx responses generated by the load balancer itself, such as 503 when no healthy targets are available, 502 for invalid responses, or 504 from gateway timeouts. In contrast, HTTPCode_Target_5XX_Count tracks the actual 5xx status codes returned by your backend EC2 instances, which is the precise signal for application-level failures behind the ALB. Substituting the ELB metric would mask any target errors that do not also cause a load balancer error, leaving backend issues undetected.
- ✗
Restart the CloudWatch agent on the EC2 instances.
Why it's wrong here
Restarting the CloudWatch agent on the EC2 instances is irrelevant because ALB metrics are published directly by the load balancer to CloudWatch without any agent involvement. The CloudWatch agent only collects operating system and application metrics from the instances and does not forward ALB telemetry. Since the agent is already sending logs as noted, restarting it will not affect the alarm's metric data or change how the ALB publishes 5xx target error counts.
- ✓
Verify that the CloudWatch alarm is using the correct metric 'HTTPCode_Target_5XX_Count' and that the threshold is appropriate.
Why this is correct
For a three-tier web application behind an ALB, the correct metric to alarm on for backend errors is HTTPCode_Target_5XX_Count, which counts the number of HTTP 5xx responses sent by registered targets. You must verify that the alarm uses this metric and that the threshold is aligned with your accepted error budget—for example, alarm after 10 errors in 5 minutes—to avoid noisy alerts from transient issues. This metric directly reflects the health of your EC2 instances as the target group, making it the appropriate signal for detecting application failures.
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.