Quizzes · Service

SQS

Level 0 questions on SQS. Read about it first if it's new to you.

Works with: Lambda (3), VPC (2), ECS + Fargate (2), IAM (2), RDS (1)

15 questions, from a pool of 21
1 correct answer of 4 each
Pass line 80%

Questions and answers come in a new order every time, and every choice is explained. Your answers feed your weak spots on the exam page; they don't change your exam score.

Question 1Todo.io attaches its Lambda function to the VPC so it can reach the MySQL database in a private subnet. Since then, the function's calls to SQS time out. IAM allows sqs:SendMessage. What fixes it?

Add a NAT gateway in a public subnet, and route the private subnets' internet traffic (0.0.0.0/0) to it.Correct. A VPC-attached Lambda function can only reach what its subnet can reach. A NAT gateway lets it call out to public AWS endpoints such as SQS, while nothing can call in. (A VPC endpoint is another fix, in a later level.)Move the function's network interfaces to a public subnet.Not this one. Lambda's network interfaces never get a public IP, so a public subnet doesn't help. This is a classic exam trap.Add an outbound rule for port 443 to the function's security group.Not this one. Security groups allow all outbound traffic by default, and a timeout means there's no route out at all. An outbound rule can't create a route.Add sqs:SendMessage to the function's execution role again.Not this one. IAM already allows it. A permission problem shows up as AccessDenied, not as a timeout.

Learn it: NAT gateway · Lambda · IAM policy · ENI

Question 2Code inside Todo.io's ECS task must send messages to SQS. Which role should be allowed sqs:SendMessage?

The task role.Correct. The task role is what your code may do. Its credentials are served inside the task.The task execution role.Not this one. That is what ECS itself needs to start the task: pull the image and ship logs.An instance profile on an EC2 host.Not this one. On Fargate there is no host of yours, and the task role keeps permissions per task.A service-linked role.Not this one. Those belong to AWS services, and you can't add permissions to them.

Learn it: ECS and Fargate · IAM role

Question 3Todo.io's Fargate tasks run in private subnets. Their IAM permissions are correct, but every call they make to SQS times out. What fixes it?

A NAT gateway in a public subnet, with the private subnets routing 0.0.0.0/0 to it.Correct. SQS is a public AWS service. From a private subnet, traffic needs a way out. (VPC endpoints are another fix, in a later level.)An outbound rule in the task's security group.Not this one. Security groups allow outbound traffic by default; the problem is the missing route.A public IP on each task, left in the private subnet.Not this one. A public IP is useless without a route to the internet gateway.More permissions on the task role.Not this one. A permission problem returns AccessDenied, not a timeout.

Learn it: NAT gateway · IAM policy

Question 4Todo.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 5A 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 6Every 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 7Todo.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 8What 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 9Todo.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 10Todo.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 11One malformed message makes Todo.io's worker fail every time, so it is retried forever. How should Todo.io deal with messages like this?

Give the queue a redrive policy that moves a message to a dead-letter queue after a set number of receives (maxReceiveCount).Correct. The bad message is set aside in the DLQ for someone to inspect, fix and redrive.Raise the visibility timeout.Not this one. The message would fail just as often, only more slowly.Switch to a FIFO queue.Not this one. FIFO keeps order; it doesn't stop endless retries.Delete the queue and create a new one.Not this one. That loses every other message too.

Learn it: Dead-letter queue (DLQ)

Question 12Todo.io's source queue is a FIFO queue. What kind of queue can be its dead-letter queue?

A FIFO queue.Correct. A DLQ must be the same type as its source queue.A standard queue.Not this one. A FIFO queue needs a FIFO DLQ.Any queue in the account.Not this one. The types must match.A CloudWatch log group.Not this one. A DLQ is always another SQS queue.

Learn it: Dead-letter queue (DLQ)

Question 13Events 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 14Todo.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 15Todo.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 16What 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 17Which 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 18Which 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)

Question 19What does "Dead-letter queue (DLQ)" mean?

A side queue where messages go after failing too many times.Correct. Think of it as: The "problem orders" tray, so one bad order doesn't block the kitchen.A managed queue. One part of your system drops messages in, another takes them out later.Not this one. That describes SQS (Simple Queue Service).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: Dead-letter queue (DLQ)

Question 20Which term is this? "A side queue where messages go after failing too many times."

Dead-letter queue (DLQ)Correct. Yes. Think of it as: The "problem orders" tray, so one bad order doesn't block the kitchen.SQS (Simple Queue Service)Not this one. SQS (Simple Queue Service) is: A managed queue. One part of your system drops messages in, another takes them out later.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: Dead-letter queue (DLQ)

Question 21Which AWS term is described by this analogy? "The "problem orders" tray, so one bad order doesn't block the kitchen."

Dead-letter queue (DLQ)Correct. Yes: A side queue where messages go after failing too many times.SQS (Simple Queue Service)Not this one. SQS (Simple Queue Service) is: A managed queue. One part of your system drops messages in, another takes them out later. Its analogy: A ticket rail in a restaurant kitchen. Waiters clip orders up, cooks take them down when ready.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: Dead-letter queue (DLQ)

SQS

Worth another look

Your weak spots

Services

Concepts