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.