SOA-C02 Monitoring, Logging, and Remediation Practice Question

A company runs a web application on EC2 instances behind an Application Load Balancer. The SysOps administrator creates a CloudWatch alarm on the ALB's HTTPCode_ELB_5XX_Count metric to trigger an SNS notification when there are many 5xx errors. However, the alarm remains in INSUFFICIENT_DATA state. What is a likely cause?

⚠ Common exam trap

The trap here is that candidates often overlook the regional scope of CloudWatch metrics and alarms, assuming that metrics are globally accessible, when in fact they are strictly regional.

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

✓

The ALB and the CloudWatch alarm are in different AWS Regions.

CloudWatch alarms can only evaluate metrics from the same AWS Region in which the alarm is created. If the ALB and the CloudWatch alarm are in different Regions, the alarm will never receive metric data points, causing it to remain in INSUFFICIENT_DATA state. This is a common cross-Region limitation for CloudWatch metrics.

Answer analysis

Option-by-option breakdown

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

✗
The HTTPCode_ELB_5XX_Count metric is not available for ALBs.
Why it's wrong here
The HTTPCode_ELB_5XX_Count metric is a standard Application Load Balancer metric published by the AWS/ApplicationELB namespace. It counts the number of HTTP response codes in the 5xx class returned by the load balancer itself, such as 503 or 502 errors from the ALB, not from the target instances. This metric is fully available with 1-minute granularity, so the premise that it is unavailable is incorrect.
✓
The ALB and the CloudWatch alarm are in different AWS Regions.
Why this is correct
CloudWatch alarms can only evaluate metrics that exist in the exact same AWS Region as the alarm. Standard ALB metrics are published into the Region where the Application Load Balancer is deployed; an alarm created in a different Region cannot see or reference those metric data points. Cross-region metric aggregation is not a native feature for ALB CloudWatch metrics, so placing the alarm in a different Region from the ALB would indeed prevent the alarm from ever receiving data and leave it in INSUFFICIENT_DATA.
✗
The IAM role for CloudWatch does not have permission to read the ALB metrics.
Why it's wrong here
CloudWatch alarms do not assume or rely on IAM roles to read ALB metric data. ALB metrics are automatically ingested into the account's CloudWatch service in the same Region, and the alarm evaluation engine accesses that stored metric data without needing any IAM permissions. IAM roles are relevant only for API calls made by users, applications, or services that need access to CloudWatch data through an SDK or CLI, not for a CloudWatch alarm's internal evaluation of already-published metrics.
✗
The alarm's period is set to 1 minute, but the metric is published every 5 minutes.
Why it's wrong here
ALB metrics, including HTTPCode_ELB_5XX_Count, are published every 1 minute, so setting the alarm's period to 1 minute is perfectly valid and aligns with the metric's availability. There is no gap between the metric publication frequency and the alarm period that would cause missing data. If this were a custom or third-party metric with a 5-minute publishing interval, a 1-minute period would indeed cause data gaps, but that is not the case for ALB metrics.

Go deeper

SOA-C02 Monitoring, Logging, and Remediation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question