The correct answer is Route incoming requests to Amazon Simple Queue Service (Amazon SQS). Configure an EC2 Auto Scaling group based on queue size. Update the software to read from the queue.

This architecture decouples job submission from processing. By placing job requests into an SQS queue, you ensure that none are lost during peak load. Auto Scaling can then launch additional EC2 instances based on the number of pending jobs in the queue. This setup allows the system to dynamically adapt to changes in workload while reducing CPU bottlenecks and improving reliability and performance.

Create a copy of the instance. Place all instances behind an Application Load Balancer might help distribute incoming requests, but it doesn't automatically scale based on demand or address the CPU saturation issue without Auto Scaling. Additionally, ALBs are better suited for stateless HTTP traffic, not job queuing or processing scenarios.

Create an S3 VPC endpoint for Amazon S3. Update the software to reference the endpoint improves security and performance of S3 access inside a VPC, but it doesnt solve the root problemCPU overload and lack of workload scaling.

Stop the EC2 instances. Modify the instance type to one with a more powerful CPU and more memory. Restart the instances may temporarily improve performance, but it doesnt provide elasticity. Without Auto Scaling, the system wont adjust to future traffic spikes and remains vulnerable to overload.

Why this question matters: It tests your understanding of how to build scalable and fault-tolerant processing architectures using Amazon SQS and EC2 Auto Scaling. This design pattern is commonly used to decouple workloads and ensure no job is lost under load.

Tip: When you see 100% CPU utilization and dropped or missed jobs, look for decoupling patterns using SQS, Lambda, or Auto Scaling. These allow the system to scale based on real-time demand and improve overall resilience.

Full AWS Practitioner Certification Question