Route ticket buyers at the CloudFront edge with a CloudFront function and a separate waiting room service

SAP-C02 By islever Editorial Last updated

Design a solution to meet performance objectives. Design a strategy to meet reliability requirements. Design reliable and resilient architectures.

Short answer

C Separate the waiting room as its own ECS service with its own scaling and use a CloudFront function to route based on the JWT.

Question

A company needs to improve the reliability of its ticketing application. The application runs on an Amazon Elastic Container Service (Amazon ECS) cluster. The company uses Amazon CloudFront to serve the application. A single ECS service of the ECS cluster is the CloudFront distribution’s origin. The application allows only a specific number of active users to enter a ticket purchasing flow. These users are identified by an encrypted attribute in their JSON Web Token (JWT). All other users are redirected to a waiting room module until there is available capacity for purchasing. The application is experiencing high loads. The waiting room module is working as designed, but load on the waiting room is disrupting the applications availability. This disruption is negatively affecting the application's ticket sale transactions. Which solution will provide the MOST reliability for ticket sale transactions during periods of high load?
  1. Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Ensure that the ticketing service uses the JWT information and appropriately forwards requests to the waiting room service.
  2. Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Make the ticketing pod part of a StatefulSet. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.
  3. Create a separate service in the ECS cluster for the waiting room. Use a separate scaling configuration. Create a CloudFront function that inspects the JWT information and appropriately forwards requests to the ticketing service or the waiting room service. Correct Answer
  4. Move the application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. Split the waiting room module into a pod that is separate from the ticketing pod. Use AWS App Mesh by provisioning the App Mesh controller for Kubernetes. Enable mTLS authentication and service-to-service authentication for communication between the ticketing pod and the waiting room pod. Ensure that the ticketing pod uses the JWT information and appropriately forwards requests to the waiting room pod.

Key Takeaways

Routing the decision at the CloudFront edge means the overloaded waiting room service never receives the requests that should be admitted to purchasing, so protecting the sales path does not depend on the ticketing service staying healthy while it makes the admission decision.

An ECS-hosted ticketing application is served through CloudFront and limits how many users may enter the purchasing flow, identified by an encrypted attribute in their JWT, with everyone else redirected to a waiting room module. The waiting room works correctly but its load is now disrupting the availability of ticket sale transactions during high load.

Common mistake: Letting the ticketing service forward requests to the waiting room. The ticketing service then has to parse the JWT, make the admission decision, and proxy the request, so when the waiting room is saturated the ticketing service's own thread or connection pool is consumed by the redirection work, which is exactly the coupling that is causing the disruption.

Expert Analysis

Why the Answer Is Correct

The problem is that the overloaded waiting room is consuming the capacity of the ticketing path that must stay available for sales. Creating a separate service in the ECS cluster for the waiting room with its own scaling configuration isolates its resource consumption, so it can be scaled for its own traffic pattern without touching the ticketing service's capacity. The routing decision is then moved to the edge: a CloudFront function runs on the viewer request, inspects the JWT information carried in the request, and forwards the request directly to either the ticketing service or the waiting room service origin. Because CloudFront functions execute at the edge before traffic reaches the origin, the waiting room load never touches the ticketing service, which is what provides the most reliability for sale transactions under high load. This also requires no migration to Kubernetes.

Why the Other Options Are Wrong

A: The architecture is correct in separating the services, but the ticketing service still has to inspect the JWT and proxy every waiting-room request, so under saturation the ticketing service's resources are consumed by redirection work, which is the coupling the requirement is trying to remove. B: Migrating to EKS and using a StatefulSet for the ticketing pod does not address the routing bottleneck, because the ticketing pod still forwards requests to the waiting room pod and remains coupled to its load, and it also adds a Kubernetes control plane to operate. D: Moving to EKS with App Mesh and mTLS adds inter-service authentication and a mesh controller without changing who makes the routing decision, so the ticketing pod still carries the redirection load, and mTLS authenticates service identity rather than authorizing an individual ticket buyer.

Community Comment Notes

The community voted 100 to 0 for C, and the top-voted comment linked the CloudFront Functions documentation, which states that CloudFront functions can validate hashed authorization tokens such as JSON Web Tokens by inspecting authorization headers or other request metadata. Several other commenters independently explained why A is weaker, because it has no finer control at the CloudFront level and keeps the routing decision inside the overloaded path.

Official Reference

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html

This link opens the official vendor documentation in a new tab.

Community Votes

C
100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 5 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 5

  1. Zas1 👍 11 Answered C
    CFFunctions:You can validate hashed authorization tokens, such as JSON web tokens (JWT), by inspecting authorization headers or other request metadata. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html
  2. trungtd 👍 2 Answered C
    Option A involves creating a separate service in the ECS cluster for the waiting room but relies on the ticketing service to forward requests to the waiting room service based on JWT information. This approach still puts some load and decision-making logic on the ticketing service, which can affect its performance during high load periods.
  3. 0b43291 👍 1 Answered C
    By separating the waiting room service, using separate scaling configurations, and leveraging CloudFront functions for efficient routing, Option C provides a reliable and scalable solution while minimizing architectural changes and operational overhead. The other options have the following drawbacks: Option A: While it separates the waiting room service, it still relies on the ticketing service to handle the routing logic based on JWT information, which could become a bottleneck during high loads. Option B: Migrating to Amazon EKS and using StatefulSets may not be necessary for this use case and could introduce additional complexity and operational overhead. Option D: While using Amazon EKS and App Mesh provides advanced traffic management and security features, it may be an overkill for this specific requirement and could add unnecessary complexity to the architecture.
  4. liuliangzhou 👍 1 Answered C
    A. No mention of finer control at the CloudFront level B. When it comes to migrating to EKS, it may bring additional complexity and cost. C. It combines the flexibility of ECS and the edge computing capability of CloudFront. D. It involves complex migration, configuration, and authentication mechanisms.
  5. Win007 👍 1
    A is correct

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Modernize centralized firewall appliances with a Gateway Load Balancer and Auto Scaling

S-grade

Use Lambda over a CloudWatch Logs stream to count unique users per client

S-grade

Serve global game assets with Route 53 latency records and health checks

S-grade

Reach a cross-account S3 data lake through a gateway endpoint and an access point bucket policy

S-grade

Practice All SAP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full SAP-C02 Practice Test →

← Back to SAP-C02 Study Guide