DOP-C02 Resilient Cloud Solutions Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use an Application Load Balancer in front of both S3 buckets and point CloudFront to the ALB.

  Why it's wrong here

  An Application Load Balancer cannot use S3 buckets as targets; ALB target groups support only EC2 instances, IP addresses, or Lambda functions, so this architecture would require an additional proxy or custom origin service to bridge to S3. Even if you placed a reverse proxy behind the ALB, the design adds a stateful compute layer, extra network hop, and ongoing operational overhead, which contradicts the requirement for minimal management of a static-site failover. CloudFront already provides native S3 integration and origin failover, making the ALB both technically invalid and unnecessarily complex.

• ✗

  Create a second CloudFront distribution pointing to the secondary bucket and use Route 53 failover routing between the two distributions.

  Why it's wrong here

  Deploying a second CloudFront distribution and using Route 53 failover routing introduces a DNS-level decision point that can take several minutes to propagate due to TTL settings, causing a visible outage during failover. Each distribution is a separate cache tier, so you would need to manage two origins, two cache policies, and two certificates, increasing cost and operational burden. CloudFront origin failover, by contrast, happens at the edge node instantaneously based on HTTP response codes, with no dependency on DNS caches or additional distribution configuration. Route 53 health checks also cannot directly health-check a CloudFront distribution's origin; they would require an external endpoint, adding yet more moving parts.

• ✗

  Modify the application to switch the CloudFront origin URL using Lambda@Edge when health checks fail.

  Why it's wrong here

  Modifying the application to switch the CloudFront origin URL via Lambda@Edge on health-check failure introduces custom code that must be maintained, tested, and deployed, contradicting the requirement for minimal operational overhead. This approach is tempting because Lambda@Edge can indeed inspect responses and redirect requests at the edge, making it a valid solution for custom origin failover logic when CloudFront’s native origin group feature—which automatically handles failover between primary and secondary S3 origins without any application code—is not used.

• ✓

  Configure CloudFront Origin Failover by adding both buckets as origins, with the primary in us-east-1 and secondary in us-west-2.

  Why this is correct

  CloudFront Origin Failover is the native, minimal-configuration solution: you create an origin group containing two S3 buckets as the primary and secondary origins, and attach that group to your cache behavior. When the primary origin returns a configurable HTTP error code (commonly 5xx) or a connection timeout, CloudFront automatically retries the request against the secondary bucket in us-west-2, all within the same edge location and without involving DNS or custom code. This requires no additional compute, no Route 53 policies, and no application modifications—only enabling Cross-Region Replication between the two buckets so content stays consistent. It is the only option that leverages a built-in CloudFront feature designed specifically for this use case, meeting both the fault-tolerance and low-operational-overhead requirements.

Go deeper

Related to this question