Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 179 discussion

I would go with B just because of the wording. I believe A should work just fine, but the question asks for "scale in and out based on the number of events." In my opinion, that is what SNS->Lambda->SQS(DLQ) would do, too; I think the SNS->Lambda scale in/out behavior is more implicit. So I will go with B here because it is more explicit.

Configuring scaling based on the age of the oldest message is nowhere near as good as scaling based on size of the Queue for this use case. age of the oldest message will grow linearly based on time. If there is a dramatic spike in the Queue size due to increased traffic, like 100X increase in size. Then the queue will have grown a lot but the oldest message will only increase in age linearly, so the scaling will not be able to realize how much the workload has increased.

The correct answer is B. Reasons: 1. SQS + Auto Scaling provides event-based scalability 2. ApproximateAgeOfOldestMessage metric enables workload-based scaling 3. SQS native dead-letter queue handles error messages 4. Most resilient and cost-effective solution for event processing at scale Issues with other options: A: SNS doesn't store messages for reprocessing C: DynamoDB Streams has scalability and retention limitations D: ALB + EC2 is more complex and expensive than serverless processing

While A would probably work fine most of the time, B is more resilient. Once a message is in the Q, it will either be marked as complete or go to DLQ. In A, in edge cases like lambda exceeding concurrency limit, the message would be throttled after the SNS returns success to the sender.... Without SNS DLQ, the message would be lost.

scale in scale out => ALB a separate queue => DLQ

• By sending event details to an Amazon SNS topic and configuring an AWS Lambda function as a subscriber, the solution automatically scales with the number of incoming events. • Lambda functions scale in and out based on the event load without manual intervention. • Adding an on-failure destination to the Lambda function that targets an Amazon SQS queue ensures that any processing errors move the event into a separate queue for review. • This setup meets both the scalability and error-handling requirements efficiently.

Option A uses Lambda to process the solution. However, we don't know if the processing finishes within 15 mins or not. Also, SNS isn’t as well-suited for handling large event queues as SQS, and scaling based on message queue metrics is not supported in this configuration. So, the correct option is definitely B.

Only B and D mention about reviewing error in a separate queue by dead letter Q, with D never use SQS where this is supported.

People who are choosing A. Have you done associate level certs as this does not make any sense. You shouldnt be attempting this exam if that's how lost you are.

The Auto Scaling group of EC2 instances can automatically adjust the number of instances based on the ApproximateAgeOfOldestMessage metric. This ensures that the solution scales dynamically with the volume of events, maintaining efficient processing. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html

B for sure

I do think the B is correct way with ApproximateNumberOfMessages instead of ApproximateAgeOfOldestMessage. there is no such metric ...AgeOfOldestMessage

publishing events to an SQS queue, creating an EC2 Auto Scaling group that scales based on the queue's ApproximateAgeOfOldestMessage metric, and configuring the application to write failed messages to a dead-letter queue provides a scalable, fault-tolerant, and cost-effective solution for event processing with the ability to handle processing errors separately.

Vote for A

A seems better. Dont really know.

Option B. Question states, " must move to into a separate queue for review" Dead-Letter queues give you this capability for debugging or troubleshooting the issue. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

A fulfils all objectives. In B, ApproximateAgeOfOldestMessage doesn't translate to a reliable scaling pattern, and EC2s are implied. C does not implement a dead-letter queue D is overengineered.