SAP-C02 · Question #191
An ecommerce company runs its infrastructure on AWS. The company exposes its APIs to its web and mobile clients through an Application Load Balancer (ALB) in front of an Amazon Elastic Kubernetes…
The correct answer is A. AWS WAF is blocking suspicious requests. E. Some pods are taking more than 30 seconds to answer API calls. After adding CloudFront and AWS WAF in front of an ALB and EKS cluster, there is an increase in 504 Gateway Timeout and 502 Bad Gateway errors for a specific domain.
Question
An ecommerce company runs its infrastructure on AWS. The company exposes its APIs to its web and mobile clients through an Application Load Balancer (ALB) in front of an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The EKS cluster runs thousands of pods that provide the APIs. After extending delivery to a new continent, the company adds an Amazon CloudFront distribution and sets the ALB as the origin. The company also adds AWS WAF to its architecture. After implementation of the new architecture, API calls are significantly. However, there is a sudden increase in http status code 504 (Gateway Timeout) errors and http status code 502 (Bad Gateway) errors. This increase in errors seems to be for a specific domain. Which factors could be a cause of these errors? (Choose two.)
Options
- AAWS WAF is blocking suspicious requests.
- BThe origin is not properly configured in CloudFront.
- CThere is an SSL/TLS handshake issue between CloudFront and the origin.
- DEKS Kubernetes pods are being cycled.
- ESome pods are taking more than 30 seconds to answer API calls.
How the community answered
(46 responses)- A43% (20)
- B17% (8)
- C33% (15)
- D7% (3)
Why each option
After adding CloudFront and AWS WAF in front of an ALB and EKS cluster, there is an increase in 504 Gateway Timeout and 502 Bad Gateway errors for a specific domain.
AWS WAF blocking suspicious requests can prevent them from reaching the origin, or if WAF itself is misconfigured or under stress, it could cause upstream connection issues or delays that manifest as 5xx errors from CloudFront or the ALB.
If the origin were improperly configured in CloudFront, clients would likely experience more consistent errors like 503 Service Unavailable or DNS resolution failures, rather than an increase in 504/502 errors specific to a domain after initial setup.
An SSL/TLS handshake issue between CloudFront and the origin would typically result in specific 502 Bad Gateway errors with a handshake failure message, but it is less likely to be the sole cause of both 504 timeouts and 502 errors simultaneously for a specific domain.
While EKS Kubernetes pods being cycled can cause transient disruptions, a sudden *increase* in 504/502 errors specific to a domain suggests a more persistent issue rather than temporary, healthy pod lifecycle events.
A 504 Gateway Timeout error typically indicates that an upstream server (EKS pods via ALB) did not respond within the specified time limit. CloudFront has a default origin request timeout of 30 seconds; if EKS pods take longer to process requests, CloudFront will return a 504.
Concept tested: Troubleshooting HTTP 5xx errors in CloudFront, WAF, ALB, EKS architectures
Source: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html
Community Discussion
No community discussion yet for this question.