AWS Certified Solutions Architect – Associate (SAA-C03) — Question 936

A solutions architect is designing the cloud architecture for a new stateless application that will be deployed on AWS. The solutions architect created an Amazon Machine Image (AMI) and launch template for the application.

Based on the number of jobs that need to be processed, the processing must run in parallel while adding and removing application Amazon EC2 instances as needed. The application must be loosely coupled. The job items must be durably stored.

Which solution will meet these requirements?

Answer options

• A. Create an Amazon Simple Notification Service (Amazon SNS) topic to send the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on CPU usage.
• B. Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on network usage.
• C. Create an Amazon Simple Queue Service (Amazon SQS) queue to hold the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on the number of items in the SQS queue.
• D. Create an Amazon Simple Notification Service (Amazon SNS) topic to send the jobs that need to be processed. Create an Auto Scaling group by using the launch template with the scaling policy set to add and remove EC2 instances based on the number of messages published to the SNS topic.

Correct answer: C

Explanation

Amazon SQS provides durable storage for messages and enables loose coupling by allowing EC2 worker instances to poll the queue at their own pace. To scale the Auto Scaling group efficiently in response to the actual workload, the scaling policy should be based on the number of messages in the SQS queue (backlog per instance). Amazon SNS is a pub/sub service and does not durably store messages for worker pulling, making options A and D incorrect, while scaling based on network usage (option B) does not directly reflect the volume of pending jobs.