An events service publishes critical notifications using Amazon SNS. Three independent downstream systems (A, B, and C) subscribe to the topic. Downstream system B sometimes fails to process certain messages (for example, it times out or returns an error while handling the message), and you want: 1) failures in B to be isolated so A and C keep processing unaffected, and 2) messages that B cannot successfully process after retries to be sent to a DLQ for B. Which design best meets these requirements?

Subscribe each downstream directly with HTTPS endpoints and configure a single SNS dead-letter queue (DLQ) for the topic.

SNS topic-level DLQs are primarily for failed message delivery to the subscription endpoint (for example, publish/HTTP delivery failures). If the downstream receives the message successfully but later fails application processing, SNS may not detect it, so you cannot reliably isolate per-consumer processing failures and route them to a per-consumer DLQ.

Use one shared SQS queue for all three downstream systems and configure a single DLQ only when all three downstream systems fail.

A shared queue couples the workloads: if B cannot process messages, the queue backlog and retry behavior can affect how messages are consumed by A and C. Also, SQS DLQ redrive is based on per-message retry attempts, not on whether “all three downstream systems” succeeded or failed for that message.

Use EventBridge rules to invoke A, B, and C synchronously with retries enabled, and send failures to a common DLQ.

Synchronous invocation increases coupling and does not provide the same per-subscriber processing isolation pattern as SNS-to-per-subscriber SQS queues with SQS redrive policies. EventBridge retries and DLQs are not a direct substitute for per-consumer SQS DLQs driven by consumer processing failures.

What does this SAA-C03 question test?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: For each downstream system, create its own SQS queue, subscribe each SQS queue to the SNS topic, and configure a redrive policy with a DLQ for each SQS queue. — The best pattern is SNS fan-out to separate SQS queues per downstream consumer. Create one SQS queue per downstream (A, B, and C) and subscribe each queue to the SNS topic. Then configure DLQs and redrive policies on each SQS queue. When B fails to process a message, it can leave the message unacknowledged in B’s queue; SQS will retry and eventually move the message to B’s DLQ. Because A and C have their own queues, B’s failures remain isolated and do not stop A and C from processing their messages. A is incorrect because SNS DLQs do not reliably capture application-level processing failures after successful delivery to an HTTPS endpoint, and it does not provide clean per-subscriber failure isolation. C is incorrect due to coupling created by a shared queue and because SQS DLQ behavior is based on message retry attempts, not coordinated failure across multiple consumers. D is incorrect because synchronous EventBridge invocation and a shared DLQ do not replicate the per-subscriber isolation and SQS redrive-driven DLQ behavior required.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.