Ultimate access to all questions.
Answer-first summary for fast verification
Answer: Integrate the sender and processor applications with an Amazon Simple Queue Service (Amazon SQS) queue. Configure a dead-letter queue to collect the messages that failed to process.
## Explanation **Correct Answer: C** - Integrate the sender and processor applications with an Amazon Simple Queue Service (Amazon SQS) queue. Configure a dead-letter queue to collect the messages that failed to process. **Why this is the correct answer:** 1. **Message Retention**: SQS supports message retention for up to 14 days (default is 4 days), which meets the requirement that messages may take up to 2 days to be processed. 2. **Dead-Letter Queue (DLQ)**: SQS provides built-in support for dead-letter queues, which perfectly addresses the requirement that "If the messages fail to process, they must be retained so that they do not impact the processing of any remaining messages." Failed messages can be moved to a DLQ after a configurable number of receive attempts. 3. **Operational Efficiency**: SQS is a fully managed service that requires no infrastructure management, making it operationally efficient compared to managing EC2 instances. 4. **Throughput**: 1,000 messages per hour is well within SQS's capabilities. 5. **Decoupling**: SQS provides reliable message queuing that decouples the sender and processor applications. **Why other options are incorrect:** **A. Amazon EC2 with Redis**: - Requires manual infrastructure management (not operationally efficient) - No built-in dead-letter queue functionality - Requires scaling and maintenance - Not a fully managed AWS service **B. Amazon Kinesis Data Stream**: - Designed for real-time streaming analytics, not for simple message queuing - More complex to implement and maintain - Not optimized for this use case of simple message passing between two applications - Higher cost for this relatively low-volume scenario **D. Amazon SNS**: - SNS is a pub/sub service, not a queueing service - Messages are not retained if no subscriber is available - No built-in message retention for up to 2 days - No dead-letter queue functionality for failed processing - Messages would be lost if the processing application is unavailable **Key AWS Services Comparison:** - **SQS**: Message queuing with retention and DLQ support - **SNS**: Pub/sub messaging with fan-out capabilities - **Kinesis**: Real-time streaming data processing - **Managed Services vs Self-Managed**: SQS is fully managed, while EC2+Redis requires manual management This solution provides the required message retention, dead-letter queue functionality, and operational efficiency through AWS's fully managed SQS service.
Author: LeetQuiz Editorial Team
No comments yet.
A company has two applications: a sender application that sends messages with payloads to be processed and a processing application intended to receive the messages with payloads. The company wants to implement an AWS service to handle messages between the two applications. The sender application can send about 1,000 messages each hour. The messages may take up to 2 days to be processed: If the messages fail to process, they must be retained so that they do not impact the processing of any remaining messages.
Which solution meets these requirements and is the MOST operationally efficient?
A
Set up an Amazon EC2 instance running a Redis database. Configure both applications to use the instance. Store, process, and delete the messages, respectively.
B
Use an Amazon Kinesis data stream to receive the messages from the sender application. Integrate the processing application with the Kinesis Client Library (KCL).
C
Integrate the sender and processor applications with an Amazon Simple Queue Service (Amazon SQS) queue. Configure a dead-letter queue to collect the messages that failed to process.
D
Subscribe the processing application to an Amazon Simple Notification Service (Amazon SNS) topic to receive notifications to process. Integrate the sender application to write to the SNS topic.