The correct answer is: Add an Auto Scaling group for the application that sends meeting invitations and configure it to scale based on the SQS queue depth.

Scaling the consumer application based on the SQS queue depth ensures that more EC2 instances are added when the backlog of appointment requests grows. This improves processing throughput and reduces delays in sending confirmations and invitations. SQS queue metrics, such as ApproximateNumberOfMessagesVisible, can be used as a scaling trigger.

Why the other options are incorrect:

Adding a DynamoDB Accelerator (DAX) improves read latency for DynamoDB but does not help with the current bottleneck, which is the time taken to process and send meeting invitationsnot database read performance.

Introducing Amazon API Gateway in front of the web application may help with scaling the request ingestion layer, but the reported issue is not with request handlingit's with downstream message processing speed.

Adding Amazon CloudFront improves the delivery of static content and cached responses but has no impact on backend processing of asynchronous appointment logic or SQS message handling.

Why this question matters: This question tests your understanding of decoupled architectures using SQS and how to scale consumer workloads based on queue depth, a common pattern for maintaining performance under load.

Tip: When faced with delays in asynchronous workflows that use SQS, always check if the consumer application can scale based on queue depth. Look at metrics like message age and backlog to identify performance bottlenecks.

Full AWS Practitioner Certification Question