Question 1

What is Amazon SQS?

Accepted Answer

SQS is a fully managed message queue. Producers send messages, consumers poll and receive them, and the message stays hidden but not deleted until the consumer explicitly deletes it. It decouples components in time and scale — the producer does not wait for the consumer, and a slow consumer does not block production. The delete-after-processing model is the important mechanic: receiving a message does not remove it, so a consumer that crashes mid-processing causes the message to reappear after the visibility timeout. That is what makes SQS reliable and why idempotency is required.

Question 2

What is the difference between a standard and a FIFO queue?

Accepted Answer

Standard queues offer nearly unlimited throughput, at-least-once delivery and best-effort ordering. FIFO queues guarantee exactly-once processing within a deduplication window and strict ordering within a message group, at lower throughput — though high-throughput mode raises that considerably. The message group ID is the key concept: ordering is per group, so choosing groups at the right granularity — per customer or per entity rather than one global group — is what preserves both ordering and parallelism. A FIFO queue with one group processes strictly serially.

Question 3

What is the visibility timeout?

Accepted Answer

When a consumer receives a message it becomes invisible to other consumers for the visibility timeout, defaulting to 30 seconds. If the consumer deletes it in time, it is gone; if not, it becomes visible again and another consumer receives it. Consumers can extend the timeout for long-running work. The classic failure is a handler taking longer than the timeout, so the message is redelivered while still being processed — producing duplicates and, at worst, an expensive loop. Setting the timeout above the worst-case processing time, or extending it heartbeat-style, is the fix.

Question 4

What is a dead-letter queue and how do you configure one?

Accepted Answer

A DLQ receives messages that have been received more than a configured maximum number of times without being deleted, so a permanently unprocessable message is moved aside rather than retried forever. You attach it via a redrive policy with a maxReceiveCount, and DLQ redrive lets you move messages back after fixing the cause. Alerting on messages arriving in the DLQ is the operational requirement — a DLQ nobody watches is equivalent to dropping the messages. The redrive capability is worth naming because it turns the DLQ from a graveyard into a recovery mechanism.

Question 5

What is long polling and why use it?

Accepted Answer

Long polling makes ReceiveMessage wait up to 20 seconds for a message to arrive rather than returning immediately, which reduces empty responses, lowers API request cost and reduces latency because the message is returned as soon as it arrives. Short polling also samples only a subset of servers, so it can return empty even when messages exist — a genuinely confusing behaviour. Setting ReceiveMessageWaitTimeSeconds to 20 on the queue is the default recommendation.

Question 6

What is the difference between SQS and SNS?

Accepted Answer

SQS is a queue: one message is processed by one consumer, pulled at the consumer's pace, with buffering and retry. SNS is publish-subscribe: a message is pushed to all subscribers of a topic — SQS queues, Lambda functions, HTTP endpoints, email, SMS — with no buffering of its own. The canonical pattern is fan-out: SNS to multiple SQS queues, so each consumer gets its own copy with independent retry, buffering and dead-lettering. Direct SNS-to-Lambda is simpler but loses the buffer, so a downstream outage drops events.

Question 7

Explain the SNS to SQS fan-out pattern and why it is preferred.

Accepted Answer

A publisher sends one message to an SNS topic; each consumer subscribes with its own SQS queue. Each consumer then has independent buffering, retry, visibility timeout and dead-letter queue, so a slow or failing consumer does not affect the others or the publisher. The alternative — SNS delivering directly to each consumer — couples them to the publisher's delivery attempts and offers only limited retry. The queue in between is what absorbs a downstream outage, which is the reason this is the standard architecture.

Question 8

What is Amazon Kinesis Data Streams and how does it differ from SQS?

Accepted Answer

Kinesis is an ordered, replayable log partitioned into shards. Records are retained for up to 365 days and multiple consumers can read the same records independently at their own position. SQS deletes a message once processed and does not support replay or multiple independent consumers of the same message. Replayability and multiple consumers are the distinguishing properties. If you need to reprocess yesterday's events after fixing a bug, Kinesis or Kafka is the answer and SQS is not — that is usually the deciding requirement.

Question 9

What is a Kinesis shard and how does it limit throughput?

Accepted Answer

A shard is a unit of capacity supporting 1 MB or 1,000 records per second in and 2 MB per second out shared across consumers, or 2 MB per consumer with enhanced fan-out. Records are assigned to shards by a hash of the partition key, and ordering is guaranteed within a shard. The partition key choice determines distribution, so a low-cardinality key creates a hot shard that throttles while others idle. On-demand mode removes manual shard management, and enhanced fan-out gives each consumer its own read throughput with lower latency.

Question 10

What is the difference between Kinesis Data Streams and Data Firehose?

Accepted Answer

Data Streams is a durable, replayable stream you consume yourself with full control over position and processing. Firehose is a fully managed delivery service that buffers and writes to S3, Redshift, OpenSearch or third-party destinations, with optional Lambda transformation and format conversion, and no shards or consumers to manage. The rule is Firehose when you only need to land data in a destination with near-real-time latency, and Data Streams when you need custom processing, replay or multiple independent consumers. Firehose buffers by size or time, so its latency floor is in the tens of seconds.

Question 11

What is Amazon EventBridge?

Accepted Answer

EventBridge is a serverless event bus that routes events from AWS services, custom applications and SaaS partners to targets, matching on the full event content with rich pattern rules. It adds a schema registry, scheduled rules, archive and replay, and pipes for point-to-point integration with filtering and enrichment. Archive and replay is the capability that most justifies EventBridge over SNS for an event-driven architecture — after fixing a consumer you can replay the events it mishandled. Content-based routing on any field, rather than only message attributes, is the other differentiator.

Question 12

When would you choose EventBridge over SNS?

Accepted Answer

EventBridge when you need routing on the event body rather than attributes, integration with AWS service events or SaaS partners, scheduled events, archive and replay, or a schema registry. SNS when you need simple high-throughput fan-out with the lowest latency, or delivery to SMS, email or mobile push. SNS has lower latency and higher throughput and remains the better choice for pure fan-out at scale. The honest answer names both directions rather than treating EventBridge as a universal replacement.

Question 13

What is EventBridge Pipes?

Accepted Answer

Pipes provides point-to-point integration between a source — SQS, Kinesis, DynamoDB Streams, MSK — and a target, with optional filtering to discard irrelevant events before invocation and optional enrichment through a Lambda, Step Functions or API destination, all without writing glue code. The filtering step is where the cost benefit lies: discarding events before they reach a Lambda means you do not pay to invoke a function that immediately returns. That is a common and easily-missed optimisation in event-driven systems.

Question 14

How do you guarantee ordering in an AWS messaging system?

Accepted Answer

Use a FIFO SQS queue with a message group ID per entity, or Kinesis with a partition key per entity so records for that entity land on one shard. In both cases ordering is per key, not global, which is what preserves parallelism. The cost of ordering is head-of-line blocking: a message that cannot be processed blocks everything behind it for that key. The better design, where possible, is order-independent messages carrying full state or a version number so stale updates can be discarded.

Question 15

What delivery guarantee do these services provide?

Accepted Answer

SQS standard, SNS, EventBridge and Kinesis all provide at-least-once delivery, so duplicates are possible. SQS FIFO provides exactly-once processing within a five-minute deduplication window. Regardless, consumers should be idempotent, since a producer republishing the same logical event creates a genuine duplicate no service can detect. The distinction between delivery duplicates and logical duplicates is the substance: exactly-once delivery does not mean exactly-once processing, which also requires the consumer's side effects to be transactional or idempotent. Interviewers ask this specifically to see if you conflate the two.

Question 16

How do you make a consumer idempotent?

Accepted Answer

Use a stable business identifier from the message, record processed identifiers in DynamoDB with a conditional write so a duplicate fails cheaply, and check before performing side effects. Prefer naturally idempotent operations such as conditional writes over increments. Deduplicating on a business key rather than the message ID is the important detail, because a genuine republish produces a new message ID for the same logical event. Lambda Powertools provides a ready implementation of this pattern.

Question 17

What is SQS message deduplication in FIFO queues?

Accepted Answer

FIFO queues deduplicate using either a content-based hash of the message body or an explicit MessageDeduplicationId, discarding duplicates sent within a five-minute window. It prevents a retried send from creating a second message. The five-minute window is the limit: a duplicate sent six minutes later is accepted, so this is producer-side retry protection rather than a general guarantee. Application-level idempotency is still needed for anything with a longer horizon.

Question 18

How does Lambda scale when consuming from SQS?

Accepted Answer

Lambda polls with an initial set of concurrent pollers and increases them as the backlog grows, up to the function's concurrency limit. For FIFO queues, concurrency is bounded by the number of active message group IDs, since ordering must be preserved within each group. The FIFO limitation surprises people: a FIFO queue with few message groups will not scale regardless of the configured concurrency. Designing group IDs for parallelism is therefore a throughput decision, not just a correctness one.

Question 19

What is partial batch response and why does it matter?

Accepted Answer

When Lambda processes a batch from SQS or Kinesis, a failure returns the entire batch for retry by default, reprocessing messages that already succeeded. Reporting batch item failures lets the function return only the identifiers that failed, so only those are retried. Without it, one poison message in a batch of ten causes the other nine to be reprocessed indefinitely alongside it, which both wastes work and can cause duplicate side effects. Enabling ReportBatchItemFailures is a small change with a large reliability benefit.

Question 20

What is the maximum SQS message size and how do you send larger payloads?

Accepted Answer

The maximum is 256 KB. For larger payloads, use the claim-check pattern — write the body to S3 and send a reference in the message — which the Extended Client Library implements transparently, storing the payload in S3 and passing a pointer. The claim-check pattern also reduces cost and improves throughput, since queue services charge by payload size and fan-out multiplies it. Naming the pattern by name, and the library that implements it, is what shows practical familiarity.

Question 21

How is SQS priced and where does cost hide?

Accepted Answer

By request, with each 64 KB chunk of a payload counting as a separate request, so a 256 KB message costs four requests. Polling itself consumes requests, which is why long polling matters — short polling with an aggressive loop generates a large number of empty receives that are all billed. Empty receives from short polling are the classic hidden cost, and switching to long polling can reduce request volume dramatically for a low-traffic queue. Batching sends and receives is the other lever.

Question 22

What is Amazon MQ and when would you use it over SQS?

Accepted Answer

Amazon MQ is managed ActiveMQ or RabbitMQ, supporting standard protocols such as JMS, AMQP, MQTT and STOMP. Use it when migrating an existing application that depends on those protocols or on broker features like message selectors and transactions, where rewriting to SQS is not justified. The trade-off is that Amazon MQ is a managed broker with instances to size and scale, unlike SQS which is fully serverless with effectively unlimited throughput. For new development SQS or EventBridge is the better default, and saying so is the balanced answer.

Question 23

What is Amazon MSK?

Accepted Answer

Managed Streaming for Apache Kafka runs open-source Kafka clusters with AWS handling provisioning, patching, scaling and availability, while you keep the Kafka API, Connect, Streams and the surrounding ecosystem. MSK Serverless removes capacity management entirely. The reason to choose it over Kinesis is portability and ecosystem — existing Kafka applications, Kafka Streams, or a multi-cloud requirement. Kinesis is simpler and more deeply AWS-integrated, so the decision is usually about existing investment rather than capability.

Question 24

How do you handle a poison message?

Accepted Answer

Configure a dead-letter queue with a maxReceiveCount so it is moved aside automatically, alarm on DLQ depth, and in the consumer distinguish transient failures — which should be retried — from permanent ones such as a validation error, which should be acknowledged and routed to a quarantine store rather than retried forever. The transient-versus-permanent distinction inside the handler is the part most candidates omit, and it matters because retrying a malformed payload a hundred times achieves nothing. Deciding that in code, rather than relying solely on delivery counts, is the more robust design.

Question 25

What is the transactional outbox pattern and why does it matter?

Accepted Answer

It solves the dual-write problem: writing to a database and publishing an event are separate operations and either can fail after the other succeeds. The outbox pattern writes the event into an outbox table in the same transaction as the business change, and a separate process publishes from the outbox and marks it sent. On AWS, DynamoDB Streams or DMS change data capture can replace a hand-built outbox by publishing changes directly from the data store. Naming both the classic pattern and the managed alternative is a strong architectural signal.

Question 26

What is a saga and how would you implement one on AWS?

Accepted Answer

A saga manages a distributed transaction as a sequence of local transactions each with a compensating action, since there is no distributed two-phase commit. On AWS, Step Functions is the natural orchestrator — each step invokes a service, and a catch handler triggers compensation for the steps already completed. Orchestration with Step Functions is preferable to choreography for sagas because the compensation logic and current state are visible in one place. Naming that compensations must themselves be idempotent, since they can be retried, is the detail that shows depth.

Question 27

How do you throttle calls to a fragile downstream system?

Accepted Answer

Put an SQS queue in front and control the consumer's rate — reserved concurrency on a Lambda consumer, or a fixed number of worker tasks — so the downstream sees a bounded request rate regardless of the input burst. Add exponential backoff with jitter and a circuit breaker. Reserved concurrency as a rate limiter is the AWS-specific mechanism worth naming, since neither SQS nor Lambda provides rate limiting on its own. The queue absorbs the burst; the concurrency cap meters the release.

Question 28

What CloudWatch metrics would you alert on for SQS?

Accepted Answer

ApproximateAgeOfOldestMessage as the primary signal that you are falling behind; ApproximateNumberOfMessagesVisible for backlog depth; NumberOfMessagesSent versus deleted to spot processing failures; and DLQ message count, which should normally be zero. Age of the oldest message is the right alerting signal because backlog depth alone is misleading during a legitimate spike, while a growing age means you are permanently behind. Alerting on DLQ arrivals is what catches silent data loss.

Question 29

What is SQS delay and message timers?

Accepted Answer

A delay queue applies a delay of up to 15 minutes to every message before it becomes visible. A message timer applies a per-message delay, overriding the queue default. Both are useful for deferring work briefly, such as waiting for an eventually-consistent write to settle. The 15-minute maximum is the constraint: anything longer needs Step Functions wait states, EventBridge Scheduler, or a scheduled sweep over a table of pending items. Reaching for a delay queue for a one-hour delay is a common mistake.

Question 30

What is EventBridge Scheduler and how does it differ from a scheduled rule?

Accepted Answer

EventBridge Scheduler is a purpose-built scheduler supporting one-time and recurring schedules at very large scale, with time zones, flexible time windows, retries and a dead-letter queue, and it can invoke a very wide set of targets directly. Scheduled rules on an event bus are the older mechanism with lower limits. The one-time schedule capability is what makes it useful for per-entity timers — scheduling a reminder for a specific order rather than sweeping a table every minute. That pattern replaces a lot of custom polling code.

Question 31

How do you secure messaging services on AWS?

Accepted Answer

Resource policies on queues and topics restricting principals; IAM policies scoped to specific queue and topic ARNs; encryption at rest with SSE-SQS or a customer-managed KMS key; TLS in transit enforced by a deny on aws:SecureTransport false; VPC endpoints so traffic stays off the internet; and validating that HTTPS SNS subscriptions verify the message signature. The SNS signature verification point is the one people miss: an HTTPS endpoint subscribed to a topic must verify the signature, otherwise anyone who discovers the URL can post fake events. That is a real vulnerability rather than a theoretical one.

Question 32

What is the difference between polling and event-driven consumption?

Accepted Answer

Polling means the consumer asks for work — SQS receive loops, Kinesis GetRecords — giving the consumer control over rate and natural backpressure. Event-driven push means the source invokes the consumer — SNS to Lambda, EventBridge to a target — which is simpler but gives the consumer no control over arrival rate. The backpressure difference is the substance: a pull consumer that is slow simply pulls less, while a push consumer under load throttles and relies on the source's retry behaviour. Choosing pull for anything with a constrained downstream is the design implication.

Question 33

What happens if a Kinesis consumer falls behind?

Accepted Answer

The iterator age grows, and if it exceeds the stream's retention period — 24 hours by default, up to 365 days — records are lost before they are read. Scaling consumers, adding shards, or reducing per-record work are the remedies, and enhanced fan-out gives each consumer dedicated read throughput. Alerting on iterator age is the specific operational answer, because it is the only metric that tells you data loss is approaching. Extending retention buys recovery time but does not fix the underlying throughput shortfall.

Question 34

How would you design a system to process 100,000 events per second?

Accepted Answer

Kinesis Data Streams in on-demand mode, or MSK if Kafka semantics are required, with a partition key that distributes evenly. Consumers with enhanced fan-out, either Lambda with parallelisation factor or a KCL application on Fargate. Firehose in parallel for raw landing in S3. Aggregate in the stream rather than per-record where possible, and buffer downstream writes. Aggregating records before publishing — the KPL aggregation feature — is the specific technique that keeps you within record-per-second limits, since Kinesis limits records as well as bytes. Naming that distinction is a strong signal of real streaming experience.

Question 35

What is the difference between choreography and orchestration?

Accepted Answer

In choreography each service reacts to events independently and emits its own, giving loose coupling but making the overall flow hard to see and debug. In orchestration a coordinator such as Step Functions drives each step explicitly, giving visibility, error handling and compensation at the cost of a central component. The criterion to name is whether the process has compensation logic and a business meaning: a multi-step order fulfilment saga benefits from orchestration, while independent reactions to an event suit choreography. A blanket preference either way is the weaker answer.

Question 36

How do you replay events after fixing a consumer bug?

Accepted Answer

With Kinesis, reset the consumer to an earlier position within the retention window. With EventBridge, use an archive and replay events matching a rule over a time range. With SQS there is no replay — messages are gone once deleted — so a durable event log or an S3 archive is needed if replay is a requirement. That SQS cannot replay is the design consequence people discover too late. Landing every event in S3 via Firehose alongside the operational queue is the cheap insurance, and naming that pattern is what shows you have planned for it.

Question 37

What is a circuit breaker and how would you implement one?

Accepted Answer

A circuit breaker tracks failures to a dependency and, past a threshold, stops sending requests for a cooling period, failing fast instead of exhausting threads or connections waiting on a broken service, then allows a trial request to test recovery. Implement it in the client library, or approximate it with concurrency caps and aggressive timeouts. The failure it prevents is cascading collapse, where retries against a slow dependency consume all capacity and take down the healthy parts too. Naming that retries alone make a slow dependency worse is the insight interviewers listen for.

Question 38

How do you decide between SQS, SNS, EventBridge and Kinesis for a given problem?

Accepted Answer

SQS when one consumer processes each message with buffering and retry. SNS when many consumers need the same message at high throughput and low latency. EventBridge when you need content-based routing, AWS or SaaS event sources, scheduling, or archive and replay. Kinesis or MSK when you need an ordered, replayable log with multiple independent consumers reading at their own position. Framing it as four questions — one consumer or many, do you need replay, do you need routing, do you need ordering — turns a service list into a decision procedure. That structure is what interviewers reward over reciting features.

Question 39

Design an event-driven order processing system on AWS.

Accepted Answer

The order service writes to DynamoDB and emits an order-created event via DynamoDB Streams or a transactional outbox to an EventBridge bus. Rules route to per-consumer SQS queues for payment, inventory, notification and analytics, each consumed by an idempotent Lambda keyed on the order ID, with exponential backoff, a dead-letter queue and alarms. Step Functions orchestrates the multi-step fulfilment saga with compensation. Firehose lands every event in S3 for replay and analytics, and Cloud Tasks-style rate limiting is achieved with reserved concurrency on the consumer calling the external logistics API. The closing scenario. The senior markers are solving the dual-write problem explicitly, one queue per consumer rather than a shared one, idempotency on a business key, archiving events for replay, and using concurrency limits to protect the fragile external dependency.

AWS SQS, SNS, Kinesis & EventBridge Interview Questions and Answers

How to use this set