Examkin

Question

Difficulty: Very hardPerformance and Scalability Optimization

A professional certification organization is launching a high-stakes synchronous online exam. The platform must support 850,000850,000 candidates logging in and downloading their customized exam profiles within a 55-minute window starting at exactly 14:00 UTC. The current architecture consists of an Application Load Balancer (ALB) routing to an Auto Scaling group (ASG) of Amazon EC2 instances, with an Amazon Aurora PostgreSQL database cluster containing one writer and two reader instances. During a load simulation, the reactive scaling policies failed to provision EC2 instances in time, the ALB dropped connection requests, and the database reader instances experienced CPU exhaustion and query timeouts. Which strategy should a solutions architect recommend to ensure the platform scales and maintains performance during the exam launch?

  1. A
    Rely on the ALB's default automatic scaling to handle the traffic. Configure the ASG with a target tracking policy based on average CPU utilization, setting the scaling cooldown period to 6060 seconds. Enable Aurora Auto Scaling based on average CPU utilization, and configure the application to direct read queries to the RDS Multi-AZ standby instance of the database writer to handle the initial surge.
  2. B
    Request ALB pre-warming from AWS Support. Set up a scheduled scaling policy on the ASG to scale out to the maximum capacity 3030 minutes prior to the exam. Deploy Amazon ElastiCache for Memcached to cache the customized exam profiles, enabling multi-AZ replication to ensure cache availability, and configure the application to query the cache before the Aurora reader instances.
  3. Request ALB pre-warming from AWS Support for the expected traffic profile. Set up a scheduled scaling policy on the ASG to launch the required number of EC2 instances 3030 minutes before the exam starts. Pre-provision additional Aurora Replicas in the cluster before the exam begins, and configure an Aurora Auto Scaling policy to handle any additional read queries during the test.Answer
  4. D
    Request ALB pre-warming from AWS Support. Configure a target tracking scaling policy on the ASG using a CPU utilization target of 40%40\%, setting the cooldown period to 300300 seconds. Configure Aurora Auto Scaling to scale reader instances dynamically based on average CPU utilization, relying on the cluster reader endpoint to distribute query loads during the initial burst.

Answer

Request ALB pre-warming from AWS Support, set up a scheduled scaling policy on the ASG to launch the required number of EC2 instances in advance, pre-provision additional Aurora Replicas before the exam starts, and use Aurora Auto Scaling to handle extra queries during the test.
The correct option addresses all scaling bottlenecks in advance. Because the traffic surge occurs instantly within a 55-minute window, reactive scaling is ineffective. Pre-warming the ALB prevents initial connection drops. Scheduled scaling ensures the EC2 instances are fully booted and ready. Pre-provisioning Aurora Replicas ensures the database read layer can handle the immediate load spike, as database instance creation takes too long for reactive scaling policies to respond.

Step-by-Step Solution

1
Address the entry point scaling bottleneck by contacting AWS Support to pre-warm the Application Load Balancer.
The ALB is configured with sufficient capacity in advance to prevent dropped connection requests during the initial 55-minute surge.
Standard ALB scaling algorithms adjust capacity based on traffic growth over time; immediate surges of 850,000850,000 concurrent connections will exceed standard thresholds and result in HTTP 503 or connection drop errors before the ALB can scale out.
2
Implement a scheduled scaling policy for the EC2 Auto Scaling group to launch instances 3030 minutes prior to the exam start.
The compute layer is fully scaled and warmed up before the spike occurs.
Reactive scaling policies (such as target tracking or step scaling) require metrics to violate thresholds for a sustained period, after which the EC2 instances must boot, configure, and register. This process takes several minutes, making reactive scaling ineffective for instantaneous flash events.
3
Pre-provision additional Aurora Replicas in the database cluster and configure an Aurora Auto Scaling policy for dynamic load adjustments.
The database read capacity is scaled beforehand to handle the massive peak query rate.
Creating new database replicas takes several minutes to provision. Pre-provisioning ensures capacity is immediately available at 14:00 UTC, while the auto-scaling policy helps accommodate subsequent fluctuations during the exam.

Key Concept

Handling massive flash traffic workloads requires scaling all architectural layers in advance using pre-warming, scheduled scaling, and resource pre-provisioning rather than relying on reactive scaling mechanisms.
Estimated Time:3m 0s
Rate this question

Topics

Performance and Scalability Optimization

More questions from this topic