Event-driven messaging and cross-account event routing: SAP-C03 study notes and practice questions
What to know about Event-driven messaging and cross-account event routing for the SAP-C03 exam, from the Architecture Design and Implementation Built for the Cloud domain (25% of the exam guide), then 1 free question to test it. Part of the SAP-C03 study guide.
SAP-C03 asks you to pick the messaging service that gives the right delivery guarantee and ordering, to make consumers safe against duplicates, and to route events between accounts and Regions without custom forwarders.
Delivery and ordering by service
Service
Delivery
Ordering
Fits
SQS standard
At least once
Best effort
Buffering work, nearly unlimited throughput
SQS FIFO
Exactly-once processing within the 5-minute deduplication window
Strict per message group ID
Order-sensitive work, such as per-account ledger updates
SNS standard / FIFO
Fan-out to many subscribers; FIFO topics keep order into FIFO queues
FIFO only
One event, many consumers
EventBridge
At least once, with retries and a dead-letter queue per target
None
Content-based routing of events to many targets
Kinesis Data Streams
At least once
Per partition key (records with the same key go to the same shard)
Ordered, replayable streams with several readers
Idempotency
At-least-once delivery means every consumer must tolerate duplicates. Use an idempotency key (an order ID or event ID) and a conditional write to DynamoDB, or the Powertools for AWS Lambda idempotency utility. FIFO deduplication helps on the send side, but it lasts only 5 minutes and doesn’t cover downstream retries. Use dead-letter queues and a sensible maxReceiveCount so poison messages don’t block a queue or a FIFO message group.
Ordering at scale
In SQS FIFO, ordering is per message group; more distinct group IDs mean more parallel consumers.
In Kinesis, a hot partition key overloads one shard. Pick a key with high cardinality that still keeps related records together.
Cross-account and cross-Region routing
A rule can target an event bus in another account or another Region. The receiving bus’s resource policy allows events:PutEvents from the sender account or the whole organization (aws:PrincipalOrgID).
A rule can also deliver directly to SQS, SNS, Lambda, Kinesis Data Streams or API Gateway in another account, in the same Region, using an execution role in the bus account plus a resource policy on the target.
Events aren’t forwarded twice: an event that arrived from another bus won’t be sent on to a third bus. To reach a third account, the original sender needs its own rule.
Common pattern: every workload account forwards selected events to a central bus in an operations or security account, where rules fan out to tooling.
How to choose
Scenario wording
Choose
“Process orders in the order received per customer”
SQS FIFO with customer ID as message group ID
“Several teams react to the same event, filtered by content”
EventBridge rules (or SNS with filter policies)
“Replay the last 24 hours of data to a new consumer”
Kinesis Data Streams, or EventBridge archive and replay
“Collect events from every account in one place”
Cross-account event bus with an organization resource policy
“Deliver to a queue in another account with no extra bus”
EventBridge direct cross-account target
Common traps
Assuming exactly-once delivery from SQS standard, SNS or EventBridge and skipping idempotency.
Using SQS FIFO for throughput-heavy work that doesn’t need order.
Chaining buses across three accounts and expecting the events to arrive.
A Lambda function that polls and forwards events between accounts when bus-to-bus delivery does it natively.
One partition key for everything, which serializes the whole stream onto one shard.
A logistics firm's warehouse management system sends a "parcel scanned" event each time a parcel passes a scanner, about 40,000 events an hour at peak. Three services consume every event: billing, customer notifications and an analytics loader.
Billing must process the events for each parcel in the order they were scanned. Every consumer must receive every event, and a message that a consumer cannot process after several tries must be set aside without stopping later events for that parcel.
The team wants no message broker to patch or size, and new consumers in other accounts must be added without changing the producer.
Which solution meets these requirements?
Choose one answer.
AA. Publish each event to one standard Amazon SQS queue that all three services poll, and give each service its own dead-letter queue for failed messages.
BB. Send each event to an Amazon EventBridge custom event bus with one rule for each consumer, and give every rule target its own retry policy and dead-letter queue. Consumers in other accounts receive events through cross-account rules.
CC. Publish each event to an Amazon SNS FIFO topic with one Amazon SQS FIFO queue per consumer, using the parcel ID as the message group ID. Each queue has a redrive policy to its own dead-letter queue, and new consumers simply subscribe to the topic.
DD. Run an Amazon MQ for ActiveMQ broker with a topic and one durable subscriber for each consumer, so every consumer receives every message in order, and use the broker's redelivery policy to move failed messages to a dead-letter queue.
Show the answer and explanation
Answer: C
A. Wrong: A standard queue does not keep order, and each message is received by only one poller. Each consumer would miss most of the events, so this breaks the requirement that every consumer receives every event.
B. Wrong: EventBridge fans out events well and supports per-target retries, so it covers the fan-out and dead-letter needs. It does not guarantee ordering per parcel, which billing depends on.
C. Right: Correct. SNS FIFO topics deliver to SQS FIFO queues, so each consumer gets every event, and the message group ID keeps each parcel's events in order. A poison message moves to the consumer's dead-letter queue after its redrive limit, and the new subscribers need no producer change.
D. Wrong: A durable subscriber in Amazon MQ meets the delivery and ordering needs, so the design is viable. It conflicts with the requirement for no broker to patch or size, which is why it is not the best fit.
Explanation
Fan-out, per-parcel ordering, isolated retries and dead-letter handling, and no broker to run all point to SNS FIFO feeding one SQS FIFO queue per consumer. A standard queue shares messages between consumers, EventBridge does not order events, and Amazon MQ adds broker operations.
With SNS FIFO and SQS FIFO, each consumer gets its own ordered queue, and a new consumer just subscribes.
Want more on Event-driven messaging and cross-account event routing? The 5 full-length practice sets have 6 more Event-driven messaging and cross-account event routing questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Event-driven messaging and cross-account event routing