The Development with AWS Services domain is the largest slice of the AWS Certified Developer – Associate (DVA-C02) exam at 32%, and a big chunk of it is about decoupling: connecting the parts of an application through queues, topics, event buses, and workflows instead of direct, synchronous calls. If you’ve read the Solutions Architect take on decoupling, you’ve seen the architecture angle — when to reach for each service on a whiteboard. The DVA-C02 tests the same services from a different seat: the developer’s. It cares about visibility timeouts, polling modes, message attributes, retry configuration, and the exact API behavior your code has to handle.
This guide covers the four services that carry most of the event-driven questions — SQS, SNS, EventBridge, and Step Functions — from that hands-on, code-first perspective. By the end you’ll know not just what each service is, but the specific parameters and failure modes the exam loves to probe.
Why Decouple at All
Synchronous, tightly-coupled calls fail together. If service A calls service B directly and B is slow or down, A blocks or errors. Decoupling inserts a buffer — a queue or a topic — so that a producer can keep working even when the consumer is unavailable, and so you can scale each side independently. On the exam, any scenario mentioning “spikes in traffic,” “the downstream system can’t keep up,” “process later,” “retry on failure,” or “don’t lose messages if a worker crashes” is pointing you toward one of these services. Recognizing that framing is half the battle.
Amazon SQS: Queues and the Parameters That Matter
SQS is a fully managed message queue. A producer sends messages; one or more consumers poll for them, process them, and delete them. That poll-process-delete loop is the source of nearly every SQS exam question.
Standard vs FIFO
| Standard | FIFO | |
|---|---|---|
| Ordering | Best-effort | Strict, per message group |
| Delivery | At-least-once (possible duplicates) | Exactly-once processing |
| Throughput | Nearly unlimited | 300 msg/s (3,000 with batching) |
| Queue name | any | must end in .fifo |
The decision rule: choose FIFO only when ordering or de-duplication is a hard requirement (financial transactions, sequential commands). Otherwise Standard, for throughput. Because Standard is at-least-once, your consumer code must be idempotent — processing the same message twice must not corrupt state. That idempotency requirement is a recurring exam theme and ties back to the request idempotency patterns in the SDK guide.
Visibility Timeout — the #1 SQS Exam Topic
When a consumer receives a message, SQS doesn’t delete it — it hides it from other consumers for the visibility timeout (default 30 seconds). The consumer processes the message, then explicitly calls DeleteMessage. If it finishes and deletes in time, the message is gone. If it crashes — or the timeout expires before processing finishes — the message becomes visible again and another consumer picks it up.
import boto3
sqs = boto3.client("sqs")
resp = sqs.receive_message(
QueueUrl=queue_url,
MaxNumberOfMessages=10, # batch up to 10
WaitTimeSeconds=20, # long polling (see below)
VisibilityTimeout=60, # override per receive if needed
)
for msg in resp.get("Messages", []):
process(msg["Body"])
sqs.delete_message(
QueueUrl=queue_url,
ReceiptHandle=msg["ReceiptHandle"], # required to delete
)The classic exam trap: “messages are being processed more than once.” The usual cause is a visibility timeout shorter than processing time — the message reappears while the first consumer is still working. The fix is to raise the timeout, or call ChangeMessageVisibility to extend it mid-processing for long jobs. Conversely, if a crashed consumer’s messages take too long to become available again, the timeout is set too high.
Long Polling vs Short Polling
By default, ReceiveMessage uses short polling — it returns immediately, sometimes with no messages even when the queue isn’t empty (it only samples a subset of servers). Long polling (WaitTimeSeconds up to 20) waits until a message arrives or the timer expires. Long polling reduces empty responses, cuts API-call cost, and is the recommended default. If a question mentions “reduce the number of empty receives” or “lower SQS costs,” the answer is long polling.
Dead-Letter Queues
A dead-letter queue (DLQ) is a separate SQS queue that receives messages a consumer repeatedly fails to process. You attach a redrive policy to the source queue specifying a maxReceiveCount; once a message has been received that many times without being deleted, SQS moves it to the DLQ.
{
"deadLetterTargetArn": "arn:aws:sqs:us-east-1:111122223333:orders-dlq",
"maxReceiveCount": 5
}DLQs isolate poison-pill messages (malformed input that always fails) so they don’t block the queue forever, and they give you a place to inspect and reprocess failures. Any scenario about “messages that keep failing,” “isolate bad messages,” or “analyze failed processing” points to a DLQ. A FIFO queue’s DLQ must also be FIFO.
Message Attributes and Batching
Messages carry a body plus optional message attributes — structured metadata (string/number/binary) the consumer can read without parsing the body. Use SendMessageBatch/DeleteMessageBatch (up to 10 per call) to cut API costs. Note SQS’s payload limit is 256 KB; for larger payloads, store the object in S3 and send a reference (the Extended Client Library pattern).
Amazon SNS: Pub/Sub and Fan-Out
SNS is a push-based publish/subscribe service. A publisher sends a message to a topic; SNS pushes a copy to every subscriber. Subscribers can be SQS queues, Lambda functions, HTTP/S endpoints, email, SMS, or mobile push. Where SQS is pull and one-message-to-one-consumer, SNS is push and one-message-to-many.
The SNS + SQS Fan-Out Pattern
The single most important event-driven pattern on the exam is fan-out: one SNS topic with multiple SQS queue subscribers. A publisher sends one message; each subscribed queue gets its own copy, and each downstream service processes independently at its own pace, with its own retries and DLQ.
┌──► SQS: fulfilment ──► worker
publisher ──► SNS topic├──► SQS: analytics ──► worker
└──► SQS: invoicing ──► workerThis combines SNS’s fan-out with SQS’s durability and buffering — the best of both. If a scenario needs “the same event delivered to several systems, each processing at its own rate, without losing messages,” SNS-to-SQS fan-out is the answer, not SNS alone (a raw HTTP or Lambda subscriber has no buffer if it’s down).
Message Filtering
By default every subscriber gets every message. A filter policy — JSON attached to a subscription — lets a subscriber receive only the messages whose message attributes match. This avoids standing up a separate topic per message type.
{ "eventType": ["order_placed"], "region": ["us-east-1", "us-west-2"] }A subscription with that policy receives only messages whose attributes match. When a question asks “how do I route different message types to different subscribers from one topic,” the answer is SNS message filtering with filter policies.
Amazon EventBridge: Event Routing and Scheduling
EventBridge (formerly CloudWatch Events) is a serverless event bus. AWS services, your own applications, and SaaS partners publish events to a bus; you write rules that match events by content and route them to targets (Lambda, SQS, SNS, Step Functions, and many more).
The distinguishing feature is content-based rules with rich event patterns — you match on the structure of the event JSON, not just a topic name:
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": { "state": ["stopped", "terminated"] }
}EventBridge also does scheduled events (cron or rate expressions), making it the modern replacement for a cron server that triggers a Lambda:
rate(5 minutes)
cron(0 8 * * ? *) # 08:00 UTC dailySNS vs EventBridge is a frequent comparison. Use SNS for high-throughput, low-latency pub/sub fan-out to many subscribers. Use EventBridge when you need to react to AWS service events, do content-based filtering across many sources, integrate SaaS partners, or schedule invocations. If the scenario says “react when an AWS service does X” or “schedule a Lambda,” it’s EventBridge.
AWS Step Functions: Orchestrating Workflows
When you have a multi-step process — several Lambdas, waits, branches, and error handling — chaining them manually with queues gets brittle. Step Functions is a managed state machine that orchestrates steps, defined in Amazon States Language (ASL) JSON. It visualizes the workflow, tracks each execution’s state, and handles retries and error branching declaratively.
{
"StartAt": "ValidateOrder",
"States": {
"ValidateOrder": {
"Type": "Task",
"Resource": "arn:aws:lambda:us-east-1:111122223333:function:validate",
"Retry": [
{ "ErrorEquals": ["States.TaskFailed"],
"IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0 }
],
"Catch": [
{ "ErrorEquals": ["States.ALL"], "Next": "HandleFailure" }
],
"Next": "ChargeCard"
},
"ChargeCard": { "Type": "Task", "Resource": "...", "End": true },
"HandleFailure": { "Type": "Fail", "Cause": "ValidationFailed" }
}
}Two exam essentials here:
- Retry and Catch give you declarative error handling — automatic retries with exponential backoff (
BackoffRate) and a fallback branch on failure — without writing that logic in every Lambda. This mirrors the retry-with-backoff pattern from the SDK, but managed by the workflow. - Standard vs Express workflows: Standard for long-running, auditable workflows (up to a year, exactly-once); Express for high-volume, short-duration event processing (up to 5 minutes, at-least-once, much cheaper at scale).
If a scenario describes “coordinate multiple steps with branching and error handling” or “visualize a long-running business process,” Step Functions is the answer — not a tangle of queues.
Choosing the Right Service
| Need | Service |
|---|---|
| Buffer work; decouple producer/consumer; process later | SQS |
| Same message to many subscribers (push, pub/sub) | SNS |
| Same event to many systems, each buffered & retryable | SNS → SQS fan-out |
| React to AWS service events / SaaS / scheduling / content filter | EventBridge |
| Orchestrate multi-step workflow with branching & retries | Step Functions |
Exam Scenario Clues
| Scenario wording | Points to |
|---|---|
| ”messages processed more than once” | Visibility timeout too low |
| ”reduce empty receives / lower cost” | Long polling (WaitTimeSeconds) |
| “isolate messages that keep failing” | Dead-letter queue + maxReceiveCount |
| ”strict ordering / no duplicates” | FIFO queue |
| ”deliver one event to several systems” | SNS fan-out (to SQS) |
| “route message types to different subscribers” | SNS filter policy |
| ”run a Lambda on a schedule” | EventBridge scheduled rule |
| ”react to an EC2/S3 state change” | EventBridge rule with event pattern |
| ”coordinate multi-step workflow with retries” | Step Functions |
How to Practice
Reading service descriptions won’t build the reflexes the exam rewards — you need to see the behaviors. In your own AWS account (all of this fits comfortably in the free tier for light use):
- Prove the visibility timeout. Send a message, receive it without deleting, and watch it reappear after the timeout. Then raise the timeout and confirm it stays hidden longer.
- Trigger a DLQ. Set
maxReceiveCount: 2, send a poison message, receive-without-delete twice, and watch it land in the DLQ. - Build fan-out. Create one SNS topic with two SQS subscribers, publish once, and confirm both queues receive a copy. Add a filter policy and watch one queue stop receiving non-matching messages.
- Schedule a Lambda with an EventBridge
rate(2 minutes)rule. - Wire a two-step Step Functions state machine with a
Retryand aCatch, then make the first task fail to watch the error branch run.
For the exam-topic map and how the domains weigh against each other, start with the DVA-C02 exam guide for 2026 and the exam topics breakdown. These decoupling services also connect tightly to the serverless and Lambda guide — SQS, SNS, and EventBridge are the most common Lambda triggers — and their failures surface in the monitoring and troubleshooting guide via CloudWatch metrics like ApproximateAgeOfOldestMessage.
When you want to test this knowledge under realistic, exam-weighted conditions, the Sailor.sh AWS Developer Associate (DVA-C02) Mock Exam Bundle runs eight full mock exams with a detailed explanation for every option — including the visibility-timeout, fan-out, and Step Functions scenarios covered here — so you learn why the DLQ answer beats “increase the instance size,” not just that it does. Start free with the Developer Associate free resources and practice questions to get used to the scenario framing before committing to a full mock.
Frequently Asked Questions
What’s the difference between SQS and SNS in one sentence?
SQS is a pull-based queue — one message is processed by one consumer, then deleted; SNS is push-based pub/sub — one message is delivered to every subscriber at once. Combine them (SNS fan-out to SQS queues) when you need one event delivered durably to several independent consumers.
How does the visibility timeout actually work?
When a consumer receives a message, SQS hides it from other consumers for the visibility-timeout period. The consumer must finish processing and call DeleteMessage before the timeout expires; otherwise the message becomes visible again and may be processed twice. Set the timeout longer than your worst-case processing time.
When should I use a FIFO queue instead of Standard?
Only when strict ordering or exactly-once processing is a hard requirement, because FIFO caps throughput (300 messages/second, or 3,000 with batching). Standard queues offer far higher throughput but are best-effort ordering and at-least-once delivery — so make consumers idempotent.
SNS message filtering vs EventBridge rules — which do I pick?
Use SNS filter policies for simple attribute-based routing within a high-throughput pub/sub topic. Use EventBridge when you need content-based matching across many event sources, reactions to AWS service events, SaaS integrations, or scheduling. EventBridge is the more powerful router; SNS is the leaner, higher-throughput fan-out.
What does a dead-letter queue solve?
It captures messages that fail processing repeatedly (past maxReceiveCount), preventing a single “poison-pill” message from blocking the queue and giving you a place to inspect and reprocess failures separately.
Is Step Functions on the DVA-C02 exam?
Yes. You should recognize it as the answer for orchestrating multi-step workflows with branching and declarative error handling (Retry/Catch), and know the difference between Standard workflows (long-running, auditable) and Express workflows (high-volume, short-duration).
Wrapping Up
Event-driven design is the backbone of the DVA-C02 Development domain, and the exam rewards developers who know the parameters, not just the service names: the visibility timeout that stops double-processing, the long polling that cuts cost, the DLQ that quarantines failures, the fan-out that delivers durably to many consumers, and the Step Functions Retry/Catch that makes workflows resilient. Learn the scenario clues in the tables above until each maps to a service on sight, drill the five hands-on exercises, and these questions become some of the most reliable points on the exam. For the architecture-level view of the same services, the SAA-C03 decoupling guide is a useful companion read.