An event-driven order processing service consumes messages from an Amazon SQS Standard queue. After a deployment, about 1% of messages start failing validation because a required field is missing. The consumer catches the exception and returns control, so the messages are retried. However, those poison messages keep reappearing and repeatedly consuming processing time for hours, delaying handling of valid messages. What is the most resilient way to handle the poison messages while keeping the system available?

Set the consumer visibility timeout to a very large value so failing messages are hidden for hours.

A long visibility timeout only postpones retries. Poison messages will still reappear once the timeout expires and can still consume receive/processing capacity, potentially continuing to impact throughput.

Switch the SQS queue from Standard to FIFO so poison messages do not retry.

FIFO queues preserve ordering (and provide deduplication), but they do not eliminate retry behavior. Without a DLQ/redrive policy, poison messages can still be received and retried until the retry limit is reached by application logic or retention/processing patterns.

Increase the consumer concurrency indefinitely so the system processes all messages even if some fail validation.

Higher concurrency may improve throughput for a time, but it does not remove poison messages from the system. The poison messages can still consume CPU/network resources repeatedly and can increase contention, costs, and instability rather than isolating the 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: Configure an SQS redrive policy to send messages to a dead-letter queue (DLQ) after a limited number of receives (maxReceiveCount). — Use an SQS redrive policy with a DLQ and a maxReceiveCount limit. For poison-message scenarios, this provides a predictable termination path: after the configured number of failed receives, the message is moved to the DLQ for investigation or replay later. This prevents the same invalid payloads from repeatedly cycling in the main queue and consuming receive capacity that would otherwise be used for valid messages. Adjusting visibility timeout or scaling concurrency changes behavior but does not isolate or stop poison-message retries in a controlled way; switching to FIFO also does not remove the need for a DLQ to stop repeated failures. Option A only delays failure retries. Option C changes ordering guarantees but still allows failed messages to be retried without DLQ isolation. Option D can temporarily mitigate impact but does not prevent poison-message cycling, which can still reduce effective processing capacity and system stability.

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.