"Configuring an Amazon SNS dead-letter queue for a subscription ... A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully", this is exactly what C says. https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html B, an SQS queue "between the application and Amazon SNS" would change the application logic. SQS cannot push messages to the "on-premises https endpoint", rather the destination would have to retrieve messages from the queue. Besides, option B would eventually deliver the messages that failed on the first attempt, which is NOT what is asked for. The goal is to retain undeliverable messages for analysis (NOT to deliver them), and this is typically achieved with a dead letter queue.

A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully.https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html

LEAST development effort! A: Custom dead letter queue using Kinesis Data Stream (laughable solution!) so lots of coding B: Change app logic to put SQS between SNS and the app. Also too much coding D: Same as A, too much code change C: SNS dead letter queue is by default a SQS que so no coding required

Problem here SNS dead letter queue is a SQS queue, so technically speaking both B and C are right. But I suppose that they want us to speak about SNS dead letter queue, that nobody do... meh, frustrating.

https://docs.aws.amazon.com/sns/latest/dg/sns-configure-dead-letter-queue.html

GPT4 to the rescue: The most appropriate solution would be to configure an Amazon SNS dead letter queue with an Amazon Simple Queue Service (Amazon SQS) target with a retention period of 14 days (Option C). This setup would ensure that any undelivered messages are retained in the SQS queue for up to 14 days for analysis, with minimal development effort required.

I like (B) since it is put SQS before SNS so we could prepare for retention. (C) dead letter Queue is kind of "rescue" effort. Also (C) should mention reprocessing dead letter.

C is correct. It used a combination of SNS and SQS so it better than B.

C is the answer

B is correct Answer. SQS Retain messages in queues for up to 14 days C is incorrect because there is nothing called Amazon SNS dead letter queue

https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html

C. Configure an Amazon SNS dead letter queue that has an Amazon Simple Queue Service (Amazon SQS) target with a retention period of 14 days. By using an Amazon SQS queue as the target for the dead letter queue, you ensure that the undelivered messages are reliably stored in a queue for up to 14 days. Amazon SQS allows you to specify a retention period for messages, which meets the retention requirement without additional development effort.

Dead Letter is a SQS feature not SNS. A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing. For more information, see Configuring an Amazon SNS dead-letter queue for a subscription and Amazon SNS message delivery retries. https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html

In SNS, DLQs store the messages that failed to be delivered to subscribed endpoints. For more information, see Amazon SNS Dead-Letter Queues. In SQS, DLQs store the messages that failed to be processed by your consumer application. This failure mode can happen when producers and consumers fail to interpret aspects of the protocol that they use to communicate. In that case, the consumer receives the message from the queue, but fails to process it, as the message doesn’t have the structure or content that the consumer expects. The consumer can’t delete the message from the queue either. After exhausting the receive count in the redrive policy, SQS can sideline the message to the DLQ. For more information, see Amazon SQS Dead-Letter Queues. https://aws.amazon.com/blogs/compute/designing-durable-serverless-apps-with-dlqs-for-amazon-sns-amazon-sqs-aws-lambda/

C is best to handle this requirement. Although good to note that dead-letter queue is an SQS queue. "A dead-letter queue is an Amazon SQS queue that an Amazon SNS subscription can target for messages that can't be delivered to subscribers successfully. Messages that can't be delivered due to client errors or server errors are held in the dead-letter queue for further analysis or reprocessing." https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html#:~:text=A%20dead%2Dletter%20queue%20is%20an%20Amazon%20SQS%20queue

C - Amazon SNS dead letter queues are used to handle messages that are not delivered to their intended recipients. When a message is sent to an Amazon SNS topic, it is first delivered to the topic's subscribers. If a message is not delivered to any of the subscribers, it is sent to the topic's dead letter queue. Amazon SQS is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. Amazon SQS queues can be configured to have a retention period, which is the amount of time that messages will be kept in the queue before they are deleted. To meet the requirements of the company, you can configure an Amazon SNS dead letter queue that has an Amazon SQS target with a retention period of 14 days. This will ensure that any messages that are not delivered to the on-premises warehouse application will be stored in the Amazon SQS queue for up to 14 days. The company can then analyze the messages in the Amazon SQS queue to determine why they were not delivered.

https://docs.aws.amazon.com/sns/latest/dg/sns-dead-letter-queues.html