Exam AWS Certified Solutions Architect - Associate SAA-C02 topic 1 question 350 discussion

B https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html When you attach DL-queue you can specify the retry.

Answer is A What are the benefits of dead-letter queues? The main task of a dead-letter queue is handling message failure. A dead-letter queue lets you set aside and isolate messages that can’t be processed correctly to determine why their processing didn’t succeed. Setting up a dead-letter queue allows you to do the following: Configure an alarm for any messages delivered to a dead-letter queue. Examine logs for exceptions that might have caused messages to be delivered to a dead-letter queue. Analyze the contents of messages delivered to a dead-letter queue to diagnose software or the producer’s or consumer’s hardware issues. Determine whether you have given your consumer sufficient time to process messages. thus the main issue of this technology is to put the failed message on the dead letter queue Answer B cant be an option because the main SQS never send deliver a message to the dead letter if the message has been recived.

B is the answer

I would go for B (No mention of Lambda in this case so SQS service will send msg to DLQ) I think the confusion is around the use of microservices and the fact that Lambda can send unprocessed messages to a DLQ using Lambda retries

This is tough, but if you study - https://aws.amazon.com/blogs/compute/using-amazon-sqs-dead-letter-queues-to-replay-messages/ You will see that the process flow is discussed. The flow of the message sent by the producer to SQS is as follows: The producer application sends a message to an SQS queue The consumer application fails to process the message in the same SQS queue The message is moved from the main SQS queue to the default dead-letter queue as per the component settings. A Lambda function is configured with the SQS main dead-letter queue as an event source. It receives and sends back the message to the original queue adding a message timer. The message timer is defined by the exponential backoff and jitter algorithm. You can limit the number of retries. If the message exceeds this limit, the message is moved to a second DLQ where an operator processes it manually. So the answer is B

Ans-B https://aws.amazon.com/blogs/compute/using-amazon-sqs-dead-letter-queues-to-replay-messages/

sqs cannot delivery messages to multiple locations. answer is A

BBBBBBBBBB

Answer is B The redrive policy specifies the source queue, the dead-letter queue, and the conditions under which Amazon SQS moves messages from the former to the latter if the consumer of the source queue fails to process a message a specified number of times. When the ReceiveCount for a message exceeds the maxReceiveCount for a queue, Amazon SQS moves the message to a dead-letter queue (with its original message ID). For example, if the source queue has a redrive policy with maxReceiveCount set to 5, and the consumer of the source queue receives a message 6 times without ever deleting it, Amazon SQS moves the message to the dead-letter queue. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

Ans A Failed to process 4 times The redrive policy specifies the source queue, the dead-letter queue, and the conditions under which Amazon SQS moves messages from the former to the latter if the consumer of the source queue fails to process a message a specified number of times. When the ReceiveCount for a message exceeds the maxReceiveCount for a queue, Amazon SQS moves the message to a dead-letter queue (with its original message ID). For example, if the source queue has a redrive policy with maxReceiveCount set to 5, and the consumer of the source queue receives a message 6 times without ever deleting it, Amazon SQS moves the message to the dead-letter queue. Not B because it says message moves to DLQ if it receives 4 times, but the max count in question is 4 times not 3 times

came up in my exam yesterday picked B

B --> https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-dead-letter-queue.html

B is correct. Both A & B aren't conceptually wrong but B is the way SQS handles failed queues. See an excerpt from Amazon's documentation: "...ReceiveCount for a message exceeds the maxReceiveCount for a queue, Amazon SQS moves the message to a dead-letter queue (with its original message ID). For example, if the source queue has a redrive policy with maxReceiveCount set to 5, and the consumer of the source queue receives a message 6 times without ever deleting it, Amazon SQS moves the message to the dead-letter queue..."

Answer is A. I have been supporting MQ series for 10 over years. Usually when a queue failed to be processed, it will be dumped to the dead letter queue. B is not possible because there are no failed messages. C and D are not possible because there is no dead letter queue for failed messages.

I will go with B.

Microservices can try to process the events internally for four times then send it to DLQ. For B we need atleast 2 DLQ if we want to reprocess the event using the main SQS. answer would be A

"The redrive policy specifies the source queue, the dead-letter queue, and the conditions under which Amazon SQS moves messages from the former to the latter if the consumer of the source queue fails to process a message a specified number of times." the q who make the transfer not the microservice .BB