How Should RDS Sale Data Reach Multiple Targets?

SAA-C03 By islever Editorial Last updated

Design scalable and loosely coupled architectures.

Short answer

A Create an AWS Lambda function triggered by the RDS data update to send the sold-car listing to an SQS queue for the target systems to consume.

Question

A company has an automobile sales website that stores its listings in a database on Amazon RDS. When an automobile is sold, the listing needs to be removed from the website and the data must be sent to multiple target systems.
Which design should a solutions architect recommend?
  1. Create an AWS Lambda function triggered when the database on Amazon RDS is updated to send the information to an Amazon Simple Queue Service (Amazon SQS) queue for the targets to consume. Correct Answer
  2. Create an AWS Lambda function triggered when the database on Amazon RDS is updated to send the information to an Amazon Simple Queue Service (Amazon SQS) FIFO queue for the targets to consume.
  3. Subscribe to an RDS event notification and send an Amazon Simple Queue Service (Amazon SQS) queue fanned out to multiple Amazon Simple Notification Service (Amazon SNS) topics. Use AWS Lambda functions to update the targets.
  4. Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets.

Key Takeaways

The question tests whether you know RDS event notifications cover instance-level operational events, not INSERT/UPDATE/DELETE, while the common trap is choosing the SNS fan-out option that cannot detect a sale.

This SAA-C03 scenario asks how to propagate an Amazon RDS listing removal to multiple downstream systems. The page establishes that AWS Lambda triggered by the database update is the correct answer (A), because RDS event notifications do not fire on row-level data changes.

Common mistake: Many learners pick D for its SNS-to-SQS fan-out, but RDS event notifications never trigger on the data modification that signals a sold automobile.

Expert Analysis

Why the Answer Is Correct

Option A is the only design that can react to the row-level event that actually signals a sold automobile: a change inside the RDS database. A Lambda function invoked from that data update can write the listing-removal payload to an SQS queue, decoupling the website from the downstream consumers. The queue lets target systems consume at their own pace, and FIFO ordering is not part of the requirement. Although a single SQS queue is not a broadcast fan-out, the exam's decisive discriminator is the trigger: RDS event notifications cannot detect INSERT/UPDATE/DELETE.

Why the Other Options Are Wrong

Option B adds FIFO semantics that the scenario never asks for and still relies on the same data-update trigger. Option C reverses the fan-out direction by trying to fan an SQS queue out to multiple SNS topics, which is not how SNS/SQS integration works. Option D has the correct SNS-to-SQS fan-out shape, but it starts with an RDS event notification, and those notifications cover operational events such as instance, parameter group, security group, and snapshot changes—not row-level data modifications. That makes D unable to fire when a car is sold.

Community Comment Notes

romko captures the key point with the RDS events documentation, noting that RDS event notification "doesn't support any notification when data inside DB is updated." ksolovyov reinforces that RDS events are limited to instance, parameter group, security group, and snapshot events, not the data-modifying statements this scenario needs. ruqui and BlueVolcano1 raise a fair design caveat about how a single SQS queue reaches multiple targets, but that objection does not rescue D because its RDS event trigger never fires on the sale.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When an option relies on 'RDS event notification,' check the event category before comparing fan-out patterns. Eliminate any design that uses RDS events to detect row-level data changes, then choose the remaining option that decouples the update from its consumers.

Frequently Asked Questions

Why can't RDS event notifications detect a sold automobile?

RDS event notifications are for operational events like instance, parameter group, security group, and snapshot changes, not row-level INSERT, UPDATE, or DELETE operations.

Is FIFO SQS required for sold-car listing updates?

No. FIFO adds ordering and deduplication that the scenario does not require; a standard SQS queue is sufficient for the Lambda-to-target decoupling.

More SAA-C03 FAQ →

Discussion 154 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 154

  1. romko 👍 91 Answered A
    Interesting point that Amazon RDS event notification doesn't support any notification when data inside DB is updated. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html So subscription to RDS events doesn't give any value for Fanout = SNS => SQS B is out because FIFO is not required here. A is left as correct answer
  2. ruqui 👍 22
    I don't think A is a valid solution ... how do you send the data to multiple targets using a single SQS?
  3. ocbn3wby 👍 16
    Romko, you are right pal. Nice research. There is RDS Fanout to SNS, but not specifically for DB level events (write, reads, etc). It can fan out events at instance level (turn on, restart, update), cluster level (added to cluster, removed from cluster, etc). But not at DB level. More detailed event list here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html Correct answer is A.
  4. ksolovyov 👍 15 Answered A
    RDS events only provide operational events such as DB instance events, DB parameter group events, DB security group events, and DB snapshot events. What we need in the scenario is to capture data-modifying events (INSERT, DELETE, UPDATE) which can be achieved thru native functions or stored procedures.
  5. BlueVolcano1 👍 13
    To add to that though, A also states to only use SQS (no SNS to SQS fan-out), which doesn't seem right as the message needs to go to multiple targets?
Show 25 more comments
  1. Tofu13 👍 8 Answered D
    Question to who thinks A is correct: How is sending data to "multiple target systems" possible with a single SQS?
  2. bignatov 👍 7 Answered D
    RDS Event Notification: Amazon RDS supports event notifications, which can trigger actions when specific events occur, such as a record update or delete operation. In this case, an event would be triggered when a listing is removed. Amazon SNS: SNS allows the event to be published to a topic that can then be fanned out to multiple SQS queues. This is useful when you have multiple target systems that need to receive the data. SNS can push the message to all subscribed SQS queues simultaneously. Amazon SQS: SQS provides reliable message queuing. Each target system can consume messages from its respective SQS queue at its own pace, ensuring that no messages are lost. AWS Lambda: Lambda functions can be triggered by the SQS queues to process the messages and update the target systems accordingly. This approach allows for asynchronous processing and decouples the RDS update from the target system updates, improving scalability and reliability.
  3. PaPi_z 👍 6 Answered D
    The best design is D. Subscribe to an RDS event notification and send an Amazon SNS topic fanned out to multiple Amazon SQS queues. Use AWS Lambda functions to update the targets. - SNS fan-out enables sending data to multiple SQS queues for different target systems. - Lambda can process messages from each SQS queue and update the targets. ### Why not others: - A and B: No fan-out mechanism, making it harder to deliver to multiple targets. - C: Reverses the typical fan-out pattern (SQS to SNS) and is less efficient. Option D offers better scalability and decoupling.
  4. rlaisqls 👍 6 Answered D
    I thing D is more recommended by AWS then C. It should be send data to multiple consumer, A is definitely not. https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html
  5. Tsige 👍 5
    Option A suggests creating an AWS Lambda function triggered when the database on Amazon RDS is updated to send the information to an Amazon Simple Queue Service (Amazon SQS) queue for the targets to consume. While this approach can work, it has a few limitations compared to Option D: Scalability and Fan-out: Option A uses a single SQS queue, which means all target systems would need to poll the same queue. This can become a bottleneck if multiple systems need to process the data simultaneously. Option D, on the other hand, uses an SNS topic to fan out the event to multiple SQS queues, allowing each target system to have its own queue. This improves scalability and ensures that each target system can process the data independently. Option D offers a more scalable, decoupled, and flexible solution for handling the event notifications and distributing the data to multiple target systems.
  6. slimen 👍 5
    the question not very clear, 2 points to consider: - record delete - send to multiple systems if you go for A you will violate the 2nd point as SQS wan't send to multiple targets at the same time is you go dor D you violate the 1st point as the RDS events doesn't intecept database level changes instead it intercept the changes of the resource itself: DB instance DB snapshot DB parameter group DB security group RDS Proxy Custom engine version https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html so I'm a bit confused here!!
  7. aadityaravi8 👍 5
    Answer should be C When an automobile is sold, the listing needs to be removed from the website and the data must be sent to multiple target systems - it can be done through SQS polling option, as soon as it is processed, it will be removed and won't be pickedup by another node of lambda for further processing. i.e Amazon Simple Queue Service (Amazon SQS) queue fanned out to multiple Amazon Simple Notification Service (Amazon SNS) topics
  8. mknarula 👍 5
    But... SQS is a queue and is incapable of sending messages to "multiple target systems". SNS is pub/sub and topics can be subscribed by multiple apps to update when such an even occurs. Moreover Amazon RDS uses native capabilities of DBs like Postgres, MS SQL for change data capture. This can be used to send notifications to SNS
  9. zdi561 👍 5 Answered D
    A is not right because one SQS consumed by multiple targets with different process is not possible. Ideally it should be sent to multiple SQS. D is working ok.
  10. anminfang 👍 5 Answered D
    Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets
  11. Buruguduystunstugudunstuy 👍 4 Answered D
    The correct design for this scenario would be Option D: Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets. In this design, Amazon RDS can be configured to send a notification to an Amazon SNS topic when a specific event occurs, such as an update to the database. The Amazon SNS topic can then be configured to fan out the notification to multiple Amazon SQS queues, which allows the targets to consume the data asynchronously. AWS Lambda functions can be triggered by the messages in the Amazon SQS queues to process the data and update the target systems.
  12. Amitabha09 👍 4
    The correct answer is D. Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets. This design is the most scalable and reliable way to send the data to multiple target systems. It also decouples the database from the target systems, which makes the system more resilient to failures. Amazon RDS event notifications allow you to publish events to Amazon SNS topics when certain events occur in your RDS database. For example, you can publish an event when a new record is inserted, updated, or deleted.
  13. MatAlves 👍 4 Answered D
    A and C cannot be correct: "an (one) SQS queue for the targets (multiple) to consume". "an (one) SQS queue fanned out to multiple SNS" That would be one-to-many relationship, which is not supported by SQS. "SQS has a many-to-one relationship. You can send messages to a queue from many different producers but only one consumer can be defined." https://blog.awsfundamentals.com/aws-sns-vs-sqs-what-are-the-main-differences#heading-many-to-many-vs-many-to-one-number-of-consumers
  14. CristiaNNN 👍 4 Answered D
    Option D: Subscribe to an RDS event notification and send an Amazon Simple Notification Service (Amazon SNS) topic fanned out to multiple Amazon Simple Queue Service (Amazon SQS) queues. Use AWS Lambda functions to update the targets. Correct Choice: This approach leverages RDS event notifications and SNS for fanning out updates to multiple SQS queues. Each target can then independently process updates using Lambda functions, making it scalable and modular.
  15. tom_cruise 👍 4 Answered C
    A is wrong because once the message in SQS consumed by one target, it is gone. What about the rest targets? D is wrong, fan out to multiple SQS queues does not make sense. It can be done by the SNS.
  16. Moo 👍 4
    Rule of thumb: don't assume requirements and don't overthink what is being asked. While everything you said might be true, the question doesn't mention any concerns about duplication or ordering.
  17. Vic_d_gr8 👍 4 Answered D
    Amazon RDS uses the SNS to provide notification when an Amazon event occurs https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html
  18. Jesuisleon 👍 4 Answered D
    A is WRONG. the question requires message to " multiple target systems", how message in sqs to route to multiple systems, you need sns to fan-out.
  19. JayBee65 👍 4
    Please provide reference for this claim: " event notification by RDS stream or advance audit DML"
  20. Jiang_aws1 👍 4
    The key is "Fanned out" due to "Multiple target systems" need to update
  21. Omariox 👍 4 Answered D
    You have to fan out first with SNS
  22. Lilibell 👍 4
    The answer is D
  23. whosawsome 👍 4 Answered D
    D if in doubt
  24. dipenich 👍 3 Answered D
    The requirement is to remove automobile listings from the website after a sale and send the data to multiple target systems in a decoupled, reliable, and scalable manner. Here’s how Option D meets the requirements: Event Notification from RDS: Amazon RDS can publish event notifications to Amazon SNS topics. When a record is updated (e.g., when a sale is recorded), this triggers an event. Fan-out to Multiple SQS Queues: The SNS topic fans out the event notification to multiple SQS queues, allowing parallel processing for different target systems. Each target system consumes messages from its respective queue, ensuring reliable and independent data delivery. AWS Lambda for Target Updates: Lambda functions subscribed to the SQS queues process the messages and perform updates in the target systems. Decoupled Design: The use of SNS for fan-out and SQS for message queuing decouples the systems. This ensures that issues with one target system do not impact the others.
  25. dkw2342 👍 3
    To sum up: There seems to be sth wrong with this question. D: Sounds plausible, but RDS events only provide operational events, e.g. shutdown, failover, config change. C: see D, also makes no sense since fanout is SNS -> SQS B: No mention of FIFO requirement. A: Invoking an AWS Lambda function is possible, albeit only from Postgres-flavored RDS[1]. However, this solution lacks fanout architecture (SNS -> multiple SQS) to enable multiple consumers as required. [1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL-Lambda.html

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Scheduled scaling for a predictable morning EC2 traffic spike

S-grade

Improving RDS Performance with Provisioned IOPS SSD

S-grade

S3 Multi-Region Access Point and Replication Strategy

S-grade

Securing NLB with Security Groups for Minimal Change

S-grade

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide