Sample questions
Aws Messaging EventingDifficulty 1
What is Amazon SQS primarily used for?
- aServing static websites directly to end users
- bQueuing messages to decouple producers from consumers✓
- cRunning container workloads without managing servers
- dStoring large binary objects like images and videos
Explanation:SQS (Simple Queue Service) is a managed message queue: producers send messages to a queue, consumers poll and process them independently, decoupling the two sides so they can scale and fail independently. a, c, and d describe other AWS services (S3 static hosting, Fargate/serverless compute, S3 object storage), not queuing.
Aws Messaging EventingDifficulty 1
After a consumer receives a message from an SQS queue but has not yet deleted it, what prevents other consumers from immediately picking up the same message?
- aSQS locks the entire queue until the message is deleted
- bSQS automatically deletes the message as soon as it is received
- cA visibility timeout temporarily hides it from other consumers✓
- dSQS assigns each message to exactly one consumer permanently
Explanation:When a message is received, SQS starts a visibility timeout during which the message is invisible to other consumers, giving the current consumer time to process and delete it. If it isn't deleted before the timeout expires, the message becomes visible again for redelivery. SQS does not lock the whole queue (a), does not auto-delete on receive (b), and does not permanently pin a message to one consumer (d).
Aws Messaging EventingDifficulty 1
What is the key ordering/duplication guarantee of a standard SQS queue (as opposed to a FIFO queue)?
- aBest-effort ordering with at-least-once delivery✓
- bStrict FIFO ordering with exactly-once delivery guaranteed by default
- cMessages are always delivered in the exact order they were sent, but duplicates are possible
- dNo ordering guarantee at all, and messages may be silently dropped
Explanation:A standard SQS queue provides at-least-once delivery and best-effort ordering — messages are usually delivered in order but this is not guaranteed, and a message can occasionally be delivered more than once. FIFO queues (a separate queue type) add strict ordering and exactly-once processing within a message group. Standard queues never silently drop messages (d) — messages persist until deleted or they expire per the retention period.
Aws Messaging EventingDifficulty 1
A message keeps failing to process and is redelivered many times without ever being deleted. What SQS feature is designed to catch this and move the message aside for later inspection?
- aMessage retention period
- bLong polling
- cMessage deduplication ID
- dA DLQ configured through a redrive policy✓
Explanation:A redrive policy sends a message to a dead-letter queue once it has been received (and not deleted) maxReceiveCount times, isolating poison-pill messages so they stop consuming consumer cycles and can be inspected separately. Retention period (a) just controls how long unconsumed messages live in the queue; long polling (b) reduces empty receives; deduplication ID (c) is a FIFO-queue concept for avoiding duplicate sends, unrelated to repeated processing failures.
Aws Messaging EventingDifficulty 2
What is the main architectural difference between Amazon SNS and Amazon SQS?
- aSNS is for storage, SQS is for compute
- bSNS pushes publications to subscribers; consumers poll SQS queues✓
- cSNS and SQS are two names for the exact same underlying service
- dSNS only works within a single AWS region, while SQS is global
Explanation:SNS (Simple Notification Service) is publish/subscribe: a single published message can be pushed to many subscribers (SQS queues, Lambda, HTTP endpoints, email, etc.) at once. SQS is a pull-based queue: a consumer must actively poll for messages. They are complementary, not interchangeable (c is wrong), and neither is a storage or region-locked distinction in the way a and d describe.
Aws Messaging EventingDifficulty 2
A team needs an order event to trigger three independent downstream processes (billing, shipping, analytics) that should each get their own copy of the event and process it at their own pace. Which combination best fits this need?
- aA single SQS queue with three consumers competing for each message
- bA single Lambda function that calls the three downstream systems synchronously
- cAn SNS topic with three separate SQS queues subscribed to it (fan-out pattern)✓
- dThree separate EC2 instances polling the same DynamoDB table
Explanation:This is the classic SNS fan-out pattern: publishing to an SNS topic delivers a copy of each message to every subscribed queue, so billing, shipping, and analytics each get their own queue with their own messages and consume at their own pace, independently. A single SQS queue (a) would have competing consumers race for the SAME message (only one gets each message, not all three) — the opposite of what's needed.