DOP-C02 Monitoring and Logging Practice Question

A company runs a web application on EC2 instances behind an Application Load Balancer. They use Amazon CloudFront for content delivery. The DevOps team notices that some requests are returning HTTP 503 errors intermittently. After checking the CloudFront and ALB logs, they find that the errors originate from the ALB. What is the most likely cause?

⚠ Common exam trap

Test-takers frequently confuse 503 errors with SSL certificate issues or security group misconfigurations, but the intermittent nature of the errors and the fact that they originate from the ALB (not CloudFront) points directly to capacity scaling limitations rather than configuration errors.

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 is experiencing a surge in traffic and is scaling up, but during the scaling activity, some requests are rejected.

When an Application Load Balancer (ALB) experiences a sudden surge in traffic that exceeds its current capacity, it may temporarily reject requests with HTTP 503 errors while it scales up. During the scaling activity, the ALB's target group might not have enough healthy registered targets to handle the load, causing the ALB to return 503 responses until new instances are provisioned and pass health checks. This matches the intermittent nature of the errors described in the scenario.

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 SSL certificate on the ALB is expired.
Why it's wrong here
An expired SSL certificate on the ALB would cause TLS handshake failures when clients (or CloudFront) attempt HTTPS connections; the certificate validation error occurs before any HTTP request reaches the ALB, so the ALB cannot return a 503. Instead, CloudFront would typically surface a 502 Bad Gateway or an SSL negotiation error, not a 503 Service Unavailable. A 503 requires the ALB to be actively receiving requests but unable to fulfill them, which is not the case here.
✗
The security group for the ALB is blocking traffic from CloudFront.
Why it's wrong here
If the ALB's security group blocks traffic from CloudFront, the TCP connections from CloudFront are silently dropped, so no HTTP request reaches the ALB. This results in connection timeouts or failures, which CloudFront reports as 504 Gateway Timeout (or 502, depending on the specific failure), not 503. A security-group filter operates at the network layer and prevents the ALB from ever generating an HTTP response, so the 503 status cannot originate from this condition.
✗
CloudFront is configured to forward an HTTP method that the ALB does not support.
Why it's wrong here
CloudFront forwarding an HTTP method that the ALB does not support would cause the ALB (or the origin application) to respond with a 405 Method Not Allowed, because method unsupported is an application-level rejection. ALBs route all standard HTTP methods to targets without method-based filtering, so they do not return 503 for unsupported methods. A 503 is reserved for service unavailability or capacity issues, not for invalid request semantics.
✓
The ALB is experiencing a surge in traffic and is scaling up, but during the scaling activity, some requests are rejected.
Why this is correct
An ALB returns 503 Service Unavailable when it cannot handle incoming requests due to scaling activity or when all targets are unhealthy. During a traffic surge, the ALB nodes scale up by provisioning additional capacity, and during this scaling activity the ALB may temporarily reject or fail to accept new requests, causing clients to receive 503 responses. This matches the scenario described, making it the correct explanation for the issue.

Go deeper

DOP-C02 Monitoring and Logging Practice Question

Why each option matters

Option-by-option breakdown

Related to this question