Examkin

Question

Difficulty: Very hardEdge Caching and Content Delivery for Resilient Architectures

A financial services company hosts a global web application across multiple AWS Regions. The primary infrastructure is in the us-east-1 Region, containing an Application Load Balancer (ALB) and an Auto Scaling group of EC2 instances. To meet strict recovery time objective (RTO) requirements, the company deploys a replica of the environment in the eu-central-1 Region as a standby. The application serves a mix of cacheable static assets and highly dynamic, non-cacheable transactional API endpoints under /api/*. The architecture must ensure minimal latency, immediate failover to the standby region during an outage without relying on client-side DNS caching, and full support for all HTTP write methods (POST, PUT, DELETE) on the transactional endpoints. Which solution should a solutions architect recommend to meet these requirements with the least operational complexity?

  1. Create an Amazon CloudFront distribution and define an Origin Group with the us-east-1 ALB as the primary origin and the eu-central-1 ALB as the secondary origin. Configure origin failover with 500, 502, 503, and 504 status codes. Create two cache behaviors: a default behavior for static assets with caching enabled, and a behavior for the /api/* path with caching disabled by setting the Minimum, Maximum, and Default TTLs to 0, forwarding all headers, cookies, and query strings, and allowing all HTTP methods.Answer
  2. B
    Configure Amazon Route 53 with latency-based routing policies pointing to both the us-east-1 and eu-central-1 ALBs. Enable Route 53 health checks on both endpoints to automatically failover traffic to the healthy region during a regional failure, and use AWS WAF at the ALBs to inspect and distribute incoming transactional write requests.
  3. C
    Create an Amazon CloudFront distribution with the us-east-1 ALB as the sole origin, and deploy an AWS WAF Web ACL associated with the distribution. Configure a custom AWS WAF rule that detects HTTP 5xx errors from the us-east-1 ALB and dynamically rewrites the host header to point to the standby ALB in the eu-central-1 Region.
  4. D
    Create an Amazon CloudFront distribution and define an Origin Group with the us-east-1 ALB as the primary origin and the eu-central-1 ALB as the secondary origin. To ensure that the dynamic transactional endpoints under /api/* are always up to date and failover works correctly, configure the default cache behavior with a TTL of 0 for all assets, and use AWS WAF to inspect and forward POST/PUT requests directly to the secondary region.

Answer

Create an Amazon CloudFront distribution and define an Origin Group with the us-east-1 ALB as the primary origin and the eu-central-1 ALB as the secondary origin. Configure origin failover with 500, 502, 503, and 504 status codes. Create two cache behaviors: a default behavior for static assets with caching enabled, and a behavior for the /api/* path with caching disabled by setting the Minimum, Maximum, and Default TTLs to 0, forwarding all headers, cookies, and query strings, and allowing all HTTP methods.
The correct solution utilizes Amazon CloudFront Origin Groups, which natively handle regional failover at the edge. When the primary origin returns any of the configured 5xx errors, CloudFront transparently retries the request against the secondary origin without involving client-side DNS updates. By defining two cache behaviors, the static assets remain cached for performance, while the dynamic path (/api/*) is configured with TTLs of 0 and forwards all headers, cookies, and query strings, ensuring that transactional requests are dynamically routed to the active origin and support all HTTP write operations.

Step-by-Step Solution

1
Configure the CloudFront Origin Group.
An Origin Group is defined with the primary load balancer in us-east-1 and the secondary standby load balancer in eu-central-1, specifying failover HTTP status codes (500, 502, 503, 504).
This establishes a resilient, edge-based failover mechanism that bypasses DNS cache propagation delays, meeting the low RTO requirement.
2
Configure the cache behavior for static content.
The default cache behavior (*) is configured with standard caching enabled (positive TTLs) to serve static assets from edge locations.
This offloads traffic from the backend origins, reducing latency and compute overhead.
3
Configure the cache behavior for the dynamic REST API.
A specific cache behavior for the path /api/* is created with caching disabled (TTLs set to 0), allowed HTTP methods configured to include POST, PUT, DELETE, and cache key settings configured to forward all headers, cookies, and query strings.
This ensures that transactional API calls bypass cache storage, preserve user session state, and execute successfully against the healthy backend.

Key Concept

CloudFront Origin Groups and Origin Failover combined with path-based cache behaviors for hybrid static/dynamic architectures.
Rate this question

Topics

Edge Caching and Content Delivery for Resilient Architectures

More questions from this topic