SOA-C02 Monitoring, Logging, and Remediation Practice Question
A company runs a critical web application on a fleet of EC2 instances behind an Application Load Balancer (ALB). The instances are in an Auto Scaling group. The operations team uses CloudWatch alarms to monitor the application's health. Recently, they noticed that the application's error rate has increased sporadically, but the CPU utilization and memory usage remain normal. The team suspects that the issue is related to a specific HTTP endpoint returning 5xx errors. They want to set up monitoring that will alert them when the error rate exceeds 5% of total requests over a 5-minute period. The application logs are already sent to CloudWatch Logs. Which combination of steps should the SysOps administrator take to meet this requirement?
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 in CloudWatch Logs to extract error codes and total requests from the application logs. Create two custom metrics: one for error count and one for total requests. Then create a CloudWatch alarm using a math expression that calculates error rate (error count / total requests) and triggers when >0.05 for 5 minutes.
It creates a metric filter on the log group to count errors and total requests, then an alarm on the error rate. Option B is wrong because AWS X-Ray is for tracing, not for error rate monitoring from logs. Option C is wrong because it relies on the CloudWatch agent to generate metrics, which is not already set up. Option D is wrong because it uses the ALB's HTTPCode_ELB_5XX metric, but the issue is application-specific, not ALB-level.
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 in CloudWatch Logs to extract error codes and total requests from the application logs. Create two custom metrics: one for error count and one for total requests. Then create a CloudWatch alarm using a math expression that calculates error rate (error count / total requests) and triggers when >0.05 for 5 minutes.
Why this is correct
This is the correct approach because the application logs are already flowing into CloudWatch Logs, and a metric filter can parse them in real time to extract both the number of error codes (e.g., status codes or application-specific errors) and the total request count. By creating two custom metrics—ErrorCount and TotalRequests—you can then define a CloudWatch alarm using a metrics math expression such as e1/e2, with the alarm triggering when the ratio exceeds 0.05 for a 5-minute period. This leverages the existing log data without requiring additional instrumentation or external services, and it accurately reflects application-level error rates as observed in the logs.
- ✗
Enable AWS X-Ray on the application to trace requests and identify error patterns. Create a CloudWatch alarm on the X-Ray error rate metric.
Why it's wrong here
This option uses AWS X-Ray, which is a tracing service and does not directly provide error rate metrics from logs as needed. X-Ray can help identify specific issues, but it's not the appropriate method for creating a CloudWatch alarm on error rate from application logs.
- ✗
Install the CloudWatch agent on the EC2 instances to collect application-level metrics. Configure the agent to emit a custom metric for error rate. Then create an alarm on that metric.
Why it's wrong here
Installing the CloudWatch agent to emit a custom error-rate metric is redundant and not the most direct solution because the agent primarily collects OS-level metrics (CPU, memory, disk) and can forward logs, but it does not inherently parse log content to compute an error rate. To emit a custom error-rate metric via the agent, you would need to add custom code or scripts inside the application or use a log processor to calculate the rate, which adds complexity and duplicates functionality that a metric filter already provides. Since the application logs are already being sent to CloudWatch Logs, using metric filters is simpler, cost-effective, and requires no changes to the EC2 instances or the application code.
- ✗
Enable detailed monitoring on the ALB and create a CloudWatch alarm on the HTTPCode_ELB_5XX metric with a threshold of 5% of the request count. Use the ALB's RequestCount metric to compute the percentage.
Why it's wrong here
Detailed monitoring on the ALB only provides HTTPCode_ELB_5XX, which counts 5XX responses generated by the load balancer itself (e.g., 503 due to no healthy targets), not 5XX responses originating from the application instances. For application-specific errors, you would need HTTPCode_Target_5XX, and even then, ALB metrics only reflect HTTP status codes, not application-level error codes logged in the application (e.g., business logic errors). Moreover, calculating a percentage using ALB RequestCount may be misleading because the ALB RequestCount includes all requests, but the error rate you care about is based on application logs that can capture errors not visible at the load balancer layer. Thus this approach misidentifies the metric source and can report an inaccurate error rate.
Go deeper
Related to this question
About these practice questions
This SOA-C02 question is part of Courseiva's 247-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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 SOA-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 SOA-C02 exam.