DOP-C02 Origin Failover Practice Question
A company uses Amazon CloudFront to distribute content from an S3 bucket origin. Some users report intermittent access errors. The DevOps team suspects the origin is overwhelmed. What is the MOST effective way to improve resilience?
⚠ Common exam trap
Candidates may assume an ALB is necessary for origin failover, but CloudFront can directly failover between S3 buckets using origin groups without additional load balancers.
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
✓
Configure CloudFront to perform health checks on the origin.
Configuring CloudFront to perform health checks on the origin allows it to detect origin issues and trigger failover to a secondary origin, improving resilience. CloudFront origin groups support failover based on error rates, effectively acting as health checks. Option A is incorrect because an ALB is not required for origin failover; CloudFront can directly use multiple S3 buckets as origins. Option B (reducing TTL) increases requests to the origin, worsening the problem. Option C (increasing TTL) reduces load but does not address origin failures or provide failover.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Set up an origin failover with two S3 buckets behind an Application Load Balancer (ALB).
Why it's wrong here
An origin failover group is a valid resilience pattern, but using two S3 buckets behind an Application Load Balancer is technically invalid because ALB targets are EC2 instances, IP addresses, or Lambda functions—not S3 buckets. CloudFront already supports direct S3 bucket origins with failover configured in an origin group, making the ALB entirely unnecessary complexity. Even if it were possible, the ALB would become a single point of failure and add no health-check value beyond what CloudFront's native origin group provides.
- ✗
Reduce the CloudFront cache TTL to serve fresher content.
Why it's wrong here
Lowering the cache TTL forces CloudFront to consider cached objects stale sooner, which increases the number of origin fetches and amplifies load exactly when the origin is already overwhelmed. Fresher content does nothing to mitigate an origin failure or provide a failover path, so this change worsens availability. The correct resilience approach is to detect and route around the unhealthy origin, not to hammer it more frequently.
- ✗
Increase the CloudFront cache TTL to reduce requests to the origin.
Why it's wrong here
Raising the TTL reduces the request rate to the origin by serving more from the cache, which can temporarily lower load. However, it does not provide any mechanism to detect or recover from an origin outage; if the origin is down, users simply receive stale cached content until the cache expires. The option also offers no failover capability, so a complete origin failure still results in errors when the cache misses. In short, it only delays the problem and can degrade content freshness.
- ✓
Configure CloudFront to perform health checks on the origin.
Why this is correct
An origin group with health checks lets CloudFront monitor the primary origin using HTTP or HTTPS requests; when the origin returns errors or times out, CloudFront automatically fails over to a designated secondary origin. This gives near-instant recovery without manual intervention, directly addressing the overwhelmed origin scenario described in the question. Health checks are essential for the failover mechanism to know when to stop sending traffic to the failing origin.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every DOP-C02 question from scratch — 1,298 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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 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.