SQS queue concept in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding SQS Message Visibility Timeout

What happens to a message in an AWS SQS queue when a consumer receives it but does not delete it before the visibility timeout expires?

A The message becomes visible again in the queue and can be received by other consumers.

B The message is permanently deleted from the queue automatically.

C The message is moved to a dead-letter queue immediately.

D The message is duplicated and sent to all consumers.

💡 Hint

Think about what visibility timeout means for message processing.

When a message is received, it becomes invisible for a set time (visibility timeout). If the consumer does not delete it in that time, the message becomes visible again for other consumers to process.

❓ service_behavior

intermediate

SQS Message Retention Period Behavior

If an SQS message is not deleted, how long will it remain in the queue before it is automatically removed?

A Messages are retained for a default of 4 days, configurable up to 14 days.

B Messages remain indefinitely until deleted manually.

C Messages are deleted after 1 hour automatically.

D Messages are deleted immediately after being received.

💡 Hint

Check the default and maximum retention period for SQS messages.

SQS messages have a retention period that defaults to 4 days but can be configured up to 14 days. After this period, messages are deleted automatically.

❓ Architecture

advanced

Designing for High Throughput with SQS

You need to design an architecture using SQS to handle a very high volume of messages with minimal delay. Which approach best supports this requirement?

A Use a single standard queue with a single consumer to avoid message duplication.

B Use a single standard SQS queue with multiple consumers processing messages in parallel.

C Use multiple FIFO queues with one consumer each to distribute load.

D Use a single FIFO SQS queue with one consumer to maintain order.

💡 Hint

Consider the difference between standard and FIFO queues and how parallelism affects throughput.

Standard queues support nearly unlimited throughput and allow multiple consumers to process messages in parallel, which reduces delay. FIFO queues guarantee order but have lower throughput limits.

❓ security

advanced

Securing Access to an SQS Queue

Which method is the most secure way to restrict access to an SQS queue so that only a specific AWS Lambda function can send and receive messages?

A Use a queue policy that allows access from any AWS service.

B Make the queue public and rely on Lambda's internal security.

C Attach an IAM policy to the Lambda function role allowing only that function to access the queue.

D Use a security group to restrict network access to the queue.

💡 Hint

Think about how AWS controls permissions for services and resources.

IAM policies attached to the Lambda function's execution role can restrict which resources the function can access. Queue policies can also restrict access, but attaching a precise IAM policy to the Lambda role is the most secure and direct method.

✅ Best Practice

expert

Handling Poison Messages in SQS

You have an SQS queue processing messages, but some messages cause processing failures repeatedly. What is the best practice to handle these 'poison messages' to avoid blocking the queue?

A Increase the visibility timeout indefinitely for all messages.

B Manually monitor and delete failed messages from the main queue.

C Delete messages immediately after receiving them, regardless of processing success.

D Configure a dead-letter queue (DLQ) and set a maximum receive count to move failing messages to the DLQ.

💡 Hint

Consider how SQS supports handling messages that fail processing multiple times.

Dead-letter queues allow you to isolate messages that fail processing repeatedly by moving them after a set number of receives. This prevents them from blocking the main queue and allows separate analysis or reprocessing.

Practice

1. What is the main purpose of an AWS SQS queue?

easy

A. To store messages safely between different parts of a system

B. To run code automatically when triggered

C. To host websites and web applications

D. To store large files like videos and images

Solution

1. Step 1: Understand what SQS does

   AWS SQS is designed to hold messages so different parts of a system can communicate safely without losing data.

2. Step 2: Compare options with SQS purpose

   Running code automatically is Lambda's job, hosting websites is for services like S3 or EC2, and storing large files is for S3. Only storing messages fits SQS.

3. Final Answer:

   To store messages safely between different parts of a system -> Option A

4. Quick Check:

   SQS = message storage between system parts [OK]

Hint: SQS holds messages, not code or files [OK]

Common Mistakes:

• Confusing SQS with Lambda or S3
• Thinking SQS runs code
• Assuming SQS stores large files

2. Which of the following is the correct way to create a standard SQS queue using AWS CLI?

easy

A. aws sqs create-queue --queue-name MyQueue --attributes DelaySeconds=0

B. aws sqs create-queue MyQueue --delay 0

C. aws sqs new-queue --name MyQueue

D. aws sqs make-queue --queue MyQueue --delay 0

Solution

1. Step 1: Recall AWS CLI syntax for creating SQS queue

   The correct command uses 'aws sqs create-queue' with '--queue-name' and optional '--attributes'.

2. Step 2: Check each option's syntax

   aws sqs create-queue --queue-name MyQueue --attributes DelaySeconds=0 matches the correct syntax. Options B, C, and D use incorrect commands or flags.

3. Final Answer:

   aws sqs create-queue --queue-name MyQueue --attributes DelaySeconds=0 -> Option A

4. Quick Check:

   Correct CLI syntax = aws sqs create-queue --queue-name MyQueue --attributes DelaySeconds=0 [OK]

Hint: Use 'aws sqs create-queue --queue-name' to create queues [OK]

Common Mistakes:

• Using wrong command verbs like 'new-queue' or 'make-queue'
• Missing '--queue-name' flag
• Incorrect attribute syntax

3. Given this code snippet using AWS SDK to receive messages from an SQS queue, what will be the output if the queue is empty?

const params = { QueueUrl: 'https://sqs.us-east-1.amazonaws.com/123456789012/MyQueue', MaxNumberOfMessages: 1 };
const data = await sqs.receiveMessage(params).promise();
console.log(data.Messages);

medium

A. []

B. null

C. undefined

D. An error is thrown

Solution

1. Step 1: Understand SQS receiveMessage behavior when empty

   If no messages are available, the 'Messages' property is not included in the response, so data.Messages is undefined.

2. Step 2: Check what console.log prints

   Logging undefined prints 'undefined' in JavaScript, not null or empty array. No error is thrown.

3. Final Answer:

   undefined -> Option C

4. Quick Check:

   Empty queue means data.Messages = undefined [OK]

Hint: Empty queue returns undefined Messages, not empty array [OK]

Common Mistakes:

• Assuming empty array is returned
• Expecting null instead of undefined
• Thinking an error occurs on empty queue

4. You set the VisibilityTimeout of an SQS queue to 30 seconds. A message is received and not deleted. What happens after 30 seconds?

medium

A. The message is deleted automatically

B. The message becomes visible again and can be received again

C. The message is moved to a dead-letter queue

D. The queue stops delivering messages

Solution

1. Step 1: Understand VisibilityTimeout effect

   VisibilityTimeout hides a message from other consumers for the set time after being received.

2. Step 2: What happens if message is not deleted after timeout?

   If not deleted, after 30 seconds the message becomes visible again for processing by others.

3. Final Answer:

   The message becomes visible again and can be received again -> Option B

4. Quick Check:

   VisibilityTimeout expiry = message visible again [OK]

Hint: VisibilityTimeout hides message temporarily, then shows it again [OK]

Common Mistakes:

• Thinking message deletes automatically after timeout
• Confusing dead-letter queue behavior
• Assuming queue stops working

5. You want to delay processing of messages by 10 minutes after they are sent to an SQS queue. Which configuration should you use?

hard

A. Set the VisibilityTimeout to 600 seconds

B. Set the ReceiveMessageWaitTimeSeconds to 600 seconds

C. Set the MessageRetentionPeriod to 600 seconds

D. Set the DelaySeconds attribute to 600 on the queue or per message

Solution

1. Step 1: Identify delay setting for message delivery

   DelaySeconds controls how long a message waits before becoming visible after sending.

2. Step 2: Compare other attributes

   VisibilityTimeout controls message invisibility after receipt, MessageRetentionPeriod controls how long messages stay in queue, ReceiveMessageWaitTimeSeconds controls long polling wait time.

3. Final Answer:

   Set the DelaySeconds attribute to 600 on the queue or per message -> Option D

4. Quick Check:

   DelaySeconds = message delivery delay [OK]

Hint: Use DelaySeconds to delay message visibility after sending [OK]

Common Mistakes:

• Confusing VisibilityTimeout with DelaySeconds
• Using MessageRetentionPeriod for delay
• Mistaking ReceiveMessageWaitTimeSeconds for delay