SQS (Simple Queue Service) quiz · Level 0

Question 1Todo.io's worker is a Lambda function that handles messages from an SQS queue. How do the messages reach the function?

Lambda polls the queue for you (an event source mapping) and runs the function with each batch.Correct. SQS never pushes. Lambda does the polling, so you don't write any.SQS pushes each message to the function.Not this one. SQS only hands out messages to whoever asks.The team writes a scheduled job that copies messages to the function.Not this one. The event source mapping already does this.Through API Gateway.Not this one. API Gateway is for HTTP requests, not for queues.

Learn it: Lambda · SQS

Question 2A Lambda function with a 60-second timeout processes an SQS queue whose visibility timeout is 30 seconds. Some messages are processed twice. What is the fix?

Raise the queue's visibility timeout well above the function's timeout; AWS suggests at least six times.Correct. A message becomes visible again after 30 seconds, while the first run is still working on it, so a second run picks it up.Shorten how long the queue keeps messages.Not this one. Retention is how long unread messages wait; it doesn't cause repeats.Add a dead-letter queue.Not this one. A DLQ catches messages that keep failing. These ones succeed, just twice.Lower the function's memory.Not this one. That only makes each run slower, which makes it worse.

Learn it: Lambda · SQS (Simple Queue Service)

Question 3Every morning at 9:00, thousands of Todo.io users add todos within a few minutes. The app writes each todo straight to its database, which can't keep up, and some saves fail. No todo may be lost. What should Todo.io do?

Have the app send each new todo to an SQS queue, and let a worker save todos from the queue at a pace the database can handle.Correct. A queue decouples the burst from the database. Messages wait safely until the worker gets to them, so nothing is lost and the database is never overrun.Move the app from EC2 to Lambda so it can handle more requests at once.Not this one. The app isn't the bottleneck, the database is. More concurrent app code just sends the database even more writes at once.Write each todo to CloudWatch Logs first, and copy it to the database later.Not this one. CloudWatch Logs stores log lines for people to read. It isn't a work queue: nothing tracks which todos were saved, and nothing retries the ones that fail.Give the database a public IP address so it can accept more connections.Not this one. A public IP changes who can reach the database, not how much work it can do. It also exposes the database to the internet.

Learn it: SQS (Simple Queue Service) · Design Todo.io with the Queue add-on

Question 4Todo.io's worker reads jobs from a standard SQS queue. Very rarely, a todo is counted twice in a user's stats. What is the most likely cause, and the right fix?

Standard queues deliver every message at least once, so sometimes twice. Make the worker idempotent by recording each message id and skipping repeats.Correct. "At least once" is a documented property of standard SQS queues. Workers that might see a message twice must be safe to run twice.The queue lost the message and re-created it. Increase the message retention period.Not this one. Retention is how long unread messages are kept. It doesn't affect duplicates.The message failed and went to the dead-letter queue. Delete the dead-letter queue.Not this one. A DLQ holds messages that kept failing. It doesn't create duplicates, and deleting it loses the evidence.Two workers are running. Run only one worker at a time.Not this one. Even a single worker can receive the same message twice from a standard queue. One worker also throws away the scaling a queue gives you.

Learn it: SQS (Simple Queue Service) · Design Todo.io with the Queue add-on

Question 5What does it mean that an SQS queue decouples Todo.io's app from its worker?

The app drops a message and moves on; it doesn't wait for, or even know about, the worker.Correct. The queue sits between them, so either side can be slow, busy or down without breaking the other.Both must be running at the same time for messages to flow.Not this one. That is exactly what a queue removes.The queue pushes each message straight into the worker.Not this one. Workers ask the queue for messages; SQS never pushes.The app and worker must share a database.Not this one. They only share the queue.

Learn it: SQS (Simple Queue Service)

Question 6Todo.io's worker is down for three days. Messages keep arriving in its standard SQS queue, which uses the default settings. What happens to them?

They wait in the queue. The default retention is 4 days, and it can be raised to 14.Correct. When the worker comes back, it works through the backlog.They are lost after a few minutes.Not this one. Messages stay until they are deleted or their retention runs out.They are sent back to the app.Not this one. Queues never return messages to the sender.They go straight to the dead-letter queue.Not this one. A DLQ only receives messages that were received and failed too many times.

Learn it: SQS (Simple Queue Service)

Question 7Todo.io's worker receives a message, then crashes before deleting it. What happens to the message?

Once the visibility timeout passes, it becomes visible again and is retried.Correct. A received message is only hidden, not removed. Deleting it is the worker's way of saying "done".It is lost, because it was already received.Not this one. Receiving only hides it for a while.It was deleted automatically when it was received.Not this one. Only the worker deletes messages.It goes straight to the dead-letter queue.Not this one. Only after failing maxReceiveCount times.

Learn it: SQS (Simple Queue Service)

Question 8Events about each todo must be processed in exactly the order they happened, and only once. Which queue fits?

A FIFO queue.Correct. FIFO queues keep strict order and process each message exactly once.A standard queue.Not this one. Standard queues are faster, but can deliver out of order and occasionally twice.A standard queue with a longer visibility timeout.Not this one. That reduces retries, but promises nothing about order.A dead-letter queue.Not this one. A DLQ is where failed messages go, not a way to keep order.

Learn it: SQS (Simple Queue Service)

Question 9Todo.io's app gets AccessDenied when it calls SendMessage on its queue. What should be fixed?

The app's role needs a policy allowing sqs:SendMessage on the queue's ARN.Correct. Sending to a queue is an AWS API call, approved by IAM.The queue's security group.Not this one. Queues have no security groups.The queue is full and must be emptied.Not this one. A full queue isn't the cause of AccessDenied.The visibility timeout.Not this one. That affects receiving, not sending.

Learn it: SQS (Simple Queue Service) · IAM policy

Question 10Todo.io moves "send a welcome email" out of sign-up and into a queue with a worker. What changes for a user who signs up?

Sign-up answers sooner; the email is sent a moment later in the background.Correct. The slow part no longer sits between the user and their response.Sign-up takes longer, because of the queue.Not this one. Dropping a message in a queue is quick.Sign-up fails whenever the email worker is down.Not this one. The message waits in the queue until the worker is back.The email is guaranteed to arrive before the sign-up page loads.Not this one. It is sent afterwards; that is the point.

Learn it: SQS (Simple Queue Service)

Question 11What does "SQS (Simple Queue Service)" mean?

A managed queue. One part of your system drops messages in, another takes them out later.Correct. Think of it as: A ticket rail in a restaurant kitchen. Waiters clip orders up, cooks take them down when ready.A side queue where messages go after failing too many times.Not this one. That describes Dead-letter queue (DLQ).Records how your resources are configured over time and checks them against rules.Not this one. That describes AWS Config.A record of every AWS API call. Who did what, when, from where.Not this one. That describes CloudTrail.

Learn it: SQS (Simple Queue Service)

Question 12Which term is this? "A managed queue. One part of your system drops messages in, another takes them out later."

SQS (Simple Queue Service)Correct. Yes. Think of it as: A ticket rail in a restaurant kitchen. Waiters clip orders up, cooks take them down when ready.Dead-letter queue (DLQ)Not this one. Dead-letter queue (DLQ) is: A side queue where messages go after failing too many times.AWS ConfigNot this one. AWS Config is: Records how your resources are configured over time and checks them against rules.CloudTrailNot this one. CloudTrail is: A record of every AWS API call. Who did what, when, from where.

Learn it: SQS (Simple Queue Service)

Question 13Which AWS term is described by this analogy? "A ticket rail in a restaurant kitchen. Waiters clip orders up, cooks take them down when ready."

SQS (Simple Queue Service)Correct. Yes: A managed queue. One part of your system drops messages in, another takes them out later.Dead-letter queue (DLQ)Not this one. Dead-letter queue (DLQ) is: A side queue where messages go after failing too many times. Its analogy: The "problem orders" tray, so one bad order doesn't block the kitchen.AWS ConfigNot this one. AWS Config is: Records how your resources are configured over time and checks them against rules. Its analogy: A building inspector with a notebook and a camera.CloudTrailNot this one. CloudTrail is: A record of every AWS API call. Who did what, when, from where. Its analogy: The building's CCTV and visitor book.

Learn it: SQS (Simple Queue Service)

SQS (Simple Queue Service)

Worth another look

Your weak spots

Services

Concepts