Courseiva
Incident and Event Response →mediumMultiple Choice

DOP-C02 Incident and Event Response Practice Question

A DevOps team observes that an Amazon CloudFront distribution is returning HTTP 504 errors for a small percentage of requests. The origin is an Application Load Balancer (ALB) that distributes traffic to EC2 instances. The team has already checked the ALB's access logs and found that the ALB returns 200 OK for all requests. What should the team investigate NEXT?

⚠ Common exam trap

Many candidates assume 504 errors always indicate an unhealthy origin, but the ALB logs show 200 OK, so they incorrectly focus on health checks or caching instead of the timeout mismatch between CloudFront and the ALB.

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

✓

Check the ALB's idle timeout settings and compare with CloudFront origin timeout.

The ALB returns 200 OK for all requests, so the origin itself is not failing. However, HTTP 504 errors from CloudFront typically indicate that the origin (ALB) is not responding within CloudFront's timeout window. The ALB's idle timeout (default 60 seconds) can cause the ALB to close idle connections, while CloudFront's origin timeout (default 30 seconds) is separate. If the ALB's idle timeout is shorter than the time CloudFront waits for a response, the ALB may close the connection before CloudFront receives the full response, leading to a 504. Option D directly addresses this mismatch.

Answer analysis

Option-by-option breakdown

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

  • ✗

    Check the ALB target group health check settings and ensure instances are healthy.

    Why it's wrong here

    Checking ALB target group health is a red herring here: if targets were unhealthy, the ALB would itself return 503 Service Unavailable or 502 Bad Gateway, and CloudFront would receive that error status, not time out. Since the ALB access logs show HTTP 200 responses, the registered instances are healthy and are successfully completing requests from CloudFront's perspective. Therefore, health check settings cannot be the cause of the 504, and the issue lies in timing between the two services.

  • ✗

    Examine the request headers in CloudFront logs to identify unusual patterns.

    Why it's wrong here

    Examining request headers for unusual patterns would only help identify application-level exceptions or WAF-related blocks, but a 504 from CloudFront is a gateway timeout meaning the origin never completed a response within CloudFront’s wait window. Headers themselves do not cause CloudFront to stop waiting; the response arrives too late (or not at all). While adversarial header patterns might induce slow backend processing, the actionable fix is still to compare timeout configurations, not to look for header anomalies.

  • ✗

    Review the CloudFront cache hit ratio and optimize caching strategies.

    Why it's wrong here

    Reviewing cache hit ratio and optimizing caching strategies will not resolve a 504 because the error occurs even on the first miss, when CloudFront must forward the request to the ALB and wait for the response. A high cache hit ratio would reduce the number of origin requests, but it cannot change the fact that the ALB is closing the connection or taking too long for the uncached requests. The 504 is a network/origin timeout issue, not a cache efficiency metric, so this action addresses a different performance problem.

  • ✓

    Check the ALB's idle timeout settings and compare with CloudFront origin timeout.

    Why this is correct

    The correct root cause is a timeout mismatch: CloudFront waits for an origin response within its configured origin timeout (default 30 seconds), while the ALB has an idle timeout (default 60 seconds) that can close the connection to the backend if no bytes flow. If the ALB idle timeout is shorter than CloudFront’s timeout, the ALB can terminate a long-running request before the backend finishes, causing CloudFront to receive no response and return 504. Since the ALB logs show 200 for completed requests, the occasional slow requests are being cut off by this idle setting; aligning the ALB idle timeout to be greater than CloudFront’s origin timeout (or tuning backend latency) is the fix.

About these practice questions

One of 1,298 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.