Sending and receiving messages in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does AWS SQS handle message visibility after receiving a message?

When a message is received from an AWS SQS queue, what happens to that message's visibility to other consumers?

A The message remains visible and can be received by multiple consumers simultaneously.

B The message is immediately deleted from the queue and cannot be received again.

C The message becomes invisible for a set visibility timeout period, preventing other consumers from receiving it during that time.

D The message is moved to a dead-letter queue automatically after being received.

💡 Hint

Think about how SQS prevents multiple consumers from processing the same message at the same time.

When a message is received, SQS hides it from other consumers for the visibility timeout period. This ensures only one consumer processes it at a time. If the message is not deleted before the timeout expires, it becomes visible again.

❓ Architecture

intermediate

Choosing the right AWS messaging service for decoupling microservices

You want to decouple two microservices where one sends events and the other processes them asynchronously. Which AWS service is best suited for this?

A Amazon EC2, because it can run the microservices on virtual servers.

B Amazon SQS, because it provides a reliable queue to store and deliver messages asynchronously.

C Amazon RDS, because it stores messages in a relational database.

D Amazon CloudFront, because it caches messages globally.

💡 Hint

Think about a service designed specifically for message queuing and asynchronous communication.

Amazon SQS is designed to decouple components by providing a reliable message queue. EC2 runs servers, RDS is a database, and CloudFront is a content delivery network, none of which are ideal for asynchronous messaging.

❓ security

advanced

Securing messages in AWS SNS topics

Which method ensures that only authorized AWS accounts can publish messages to your SNS topic?

A Attach a resource-based policy to the SNS topic that allows only specific AWS account IDs to publish.

B Enable server-side encryption on the SNS topic to restrict publishers.

C Use IAM roles on the subscriber side to control publishing permissions.

D Configure the SNS topic to use VPC endpoints to restrict publishing.

💡 Hint

Consider how SNS controls who can send messages to a topic.

Resource-based policies on SNS topics specify which AWS accounts or principals can publish messages. Encryption protects message content but does not restrict who can publish. IAM roles control permissions for users or services, but publishing control is best done via topic policies. VPC endpoints restrict network access but not publishing permissions.

❓ Configuration

advanced

Configuring AWS SQS dead-letter queue (DLQ) behavior

You want messages that fail processing multiple times to be moved automatically to a dead-letter queue. Which configuration setting controls this behavior?

A Set the <code>Maximum Receives</code> threshold on the source queue's redrive policy to the desired retry count.

B Enable server-side encryption on the dead-letter queue.

C Configure the visibility timeout on the dead-letter queue to zero seconds.

D Attach an IAM policy to the dead-letter queue allowing message deletion.

💡 Hint

Think about how SQS knows when to move a message to the DLQ after retries.

The redrive policy on the source queue includes a Maximum Receives setting. When a message is received more times than this threshold without deletion, it is moved to the dead-letter queue automatically. Encryption and IAM policies are important but do not control this behavior. Visibility timeout affects message visibility, not DLQ redrive.

✅ Best Practice

expert

Optimizing AWS SNS and SQS integration for high throughput and reliability

You have an architecture where an SNS topic publishes messages to multiple SQS queues subscribed to it. To optimize for high throughput and ensure no message loss, which combination of settings is best?

A Enable SNS message filtering policies and disable SQS queue encryption for faster processing.

B Use standard SNS topics and standard SQS queues without any deduplication or ordering settings.

C Configure SNS to send messages via HTTP endpoints instead of SQS for better throughput.

D Enable SNS FIFO topics with content-based deduplication and configure SQS FIFO queues subscribed to it.

💡 Hint

Consider how FIFO topics and queues help with ordering and exactly-once delivery.

Using FIFO SNS topics with content-based deduplication and subscribing FIFO SQS queues ensures messages are delivered exactly once and in order, which is critical for high reliability and throughput. Standard topics and queues provide at-least-once delivery but no ordering guarantees. Disabling encryption reduces security and may not improve throughput significantly. HTTP endpoints are less reliable than SQS for message durability.

Practice

1. What is the main purpose of sending messages in a cloud message queue service like AWS SQS?

easy

A. To put data into a queue so other parts can use it later

B. To delete data permanently from the system

C. To directly update a database record

D. To create a new virtual machine

Solution

1. Step 1: Understand message sending in queues

   Sending messages means placing data into a queue for later use by other parts of the system.

2. Step 2: Identify the purpose of sending messages

   The purpose is to store data temporarily so it can be processed asynchronously, not to delete or update directly.

3. Final Answer:

   To put data into a queue so other parts can use it later -> Option A

4. Quick Check:

   Sending messages = storing data in queue [OK]

Hint: Sending messages means putting data in a queue for later use [OK]

Common Mistakes:

• Confusing sending with deleting data
• Thinking sending updates databases directly
• Assuming sending creates compute resources

2. Which AWS service is primarily used for sending and receiving messages in a queue?

easy

A. Amazon EC2

B. Amazon SQS

C. Amazon RDS

D. Amazon S3

Solution

1. Step 1: Identify AWS services for messaging

   Amazon SQS (Simple Queue Service) is designed for sending and receiving messages in queues.

2. Step 2: Differentiate from other services

   EC2 is for servers, RDS for databases, and S3 for storage, not messaging queues.

3. Final Answer:

   Amazon SQS -> Option B

4. Quick Check:

   Message queue service = Amazon SQS [OK]

Hint: SQS is AWS's queue service for messages [OK]

Common Mistakes:

• Choosing EC2 which is for servers
• Confusing S3 storage with messaging
• Selecting RDS which is a database

3. Consider this AWS CLI command to receive a message from an SQS queue:
aws sqs receive-message --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue --max-number-of-messages 1
What will this command do?

medium

A. Create a new queue named MyQueue

B. Send one message to the queue

C. Delete one message from the queue

D. Receive up to one message from the queue

Solution

1. Step 1: Analyze the AWS CLI command

   The command uses receive-message with --max-number-of-messages 1, which means it tries to get up to one message from the queue.

2. Step 2: Understand the effect of the command

   It does not send, delete, or create queues. It only retrieves messages for processing.

3. Final Answer:

   Receive up to one message from the queue -> Option D

4. Quick Check:

   receive-message = get messages [OK]

Hint: receive-message gets messages, send-message puts them [OK]

Common Mistakes:

• Thinking receive-message sends messages
• Confusing receive with delete
• Assuming it creates queues

4. You wrote this code snippet to receive messages from an AWS SQS queue but it returns no messages:

response = sqs.receive_message(QueueUrl=queue_url, MaxNumberOfMessages=5)
messages = response['Messages']
for msg in messages:
    print(msg['Body'])

What is the likely cause of the error?

medium

A. The response has no 'Messages' key if the queue is empty

B. MaxNumberOfMessages must be 1, not 5

C. The queue URL is incorrect or empty

D. You must delete messages before receiving

Solution

1. Step 1: Understand SQS receive_message response

   If the queue is empty, the response does not include the 'Messages' key, causing a KeyError when accessing it.

2. Step 2: Identify the error cause

   Not checking if 'Messages' exists before looping causes failure when no messages are returned.

3. Final Answer:

   The response has no 'Messages' key if the queue is empty -> Option A

4. Quick Check:

   Empty queue means no 'Messages' key [OK]

Hint: Check if 'Messages' key exists before using it [OK]

Common Mistakes:

• Assuming 'Messages' always exists
• Setting MaxNumberOfMessages incorrectly
• Thinking messages must be deleted before receiving

5. You want to build a system that sends messages to an AWS SQS queue and ensures each message is processed exactly once by a receiver. Which combination of features should you use?

hard

A. Standard queue with short polling and no message deletion

B. Standard queue with long polling and message deletion after processing

C. FIFO queue with deduplication and message deletion after processing

D. FIFO queue without deduplication and no message deletion

Solution

1. Step 1: Understand message processing guarantees

   Standard queues can deliver messages more than once; FIFO queues preserve order and support exactly-once processing with deduplication.

2. Step 2: Ensure messages are deleted after processing

   Deleting messages after processing prevents reprocessing the same message.

3. Step 3: Combine features for exactly-once processing

   Use FIFO queue with deduplication and delete messages after processing to guarantee exactly-once delivery.

4. Final Answer:

   FIFO queue with deduplication and message deletion after processing -> Option C

5. Quick Check:

   Exactly-once = FIFO + deduplication + delete [OK]

Hint: Use FIFO queue with deduplication and delete messages after processing [OK]

Common Mistakes:

• Using standard queue for exactly-once needs
• Not deleting messages after processing
• Ignoring deduplication feature