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.

This one is easy haven't people heard about SQS dead-letter queues (DLQs).

B is correct: Scalability: The EC2 Auto Scaling group can automatically scale in and out based on the SQS metric (ApproximateAgeOfOldestMessage), which reflects how long messages have been waiting to be processed. Error handling: SQS supports dead-letter queues (DLQs) to isolate and handle failed messages for later analysis or reprocessing. Decoupled architecture: SQS enables a loosely coupled and fault-tolerant system design.

also think B will be good there

I would go B for the DLQ

By utilizing the ApproximateAgeOfOldestMessage metric, you can scale out and scale in based on the workload, ensuring that your application can handle increases in traffic.

100 % its B, My reasons are: 1. SNS is for pub/sub, not event processing. SNS sends events to multiple subscribers but does not provide queue-based scaling. 2. Lambda also has concurrency limits, which might cause failures at high event rates.

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