How Should RDS Sale Data Reach Multiple Targets?
Answer
Correct 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.
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?
Community Insight
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.
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.
Community Discussion (154 comments)
faeshal
👍 1
Selected: D
"data must be sent to multiple target systems.”. So SNS → SQS × N
Satheeshsivan
👍 2
Selected: D
SNS topic fanned out to multiple SQS queues + Lambda functions is the correct pattern for reliably delivering one event to multiple independent target systems.
39f3859
👍 2
Selected: D
Per CHAT GPT: Subscribe to an RDS event notification and send an Amazon Simple Notification Service topic fanned out to multiple Amazon Simple Queue Service queues. Use AWS Lambda functions to update the targets. Why D is Correct The key requirement is: “data must be sent to multiple target systems” This is a classic fanout architecture. The ideal AWS pattern is:
46e1a46
👍 2
Selected: D
A and B describe a Lambda function pushing data to a single SQS queue for "the targets (plural) to consume". An SQS queue delivers each message to exactly one consumer. If three target systems are reading from the same queue then: - Target 1 picks up message -> marks it as processed -> message is gone - Target 2 and 3 never see the message - Only one target gets the data Hence a fan out architecture works best here
MrBret077
👍 2
Selected: D
RDS Event Notification: Can notify you when a change occurs in the database (like a deletion or modification). SNS Topic: Acts as a pub-sub mechanism to fan out the event. SQS Queues: Each target system can consume the data from its own queue, ensuring decoupled, scalable architecture. Lambda: Each SQS queue can trigger a Lambda function to process and forward the data to its specific target system.
bmmbmm
👍 1
Selected: D
FanOut(SNS->SQS) to distribute to multiple systems, generating multiple messages
Jess94
👍 2
Selected: D
Why D is correct RDS event notifications can detect changes or actions in the database, such as updates or deletes. Amazon SNS allows you to fan out messages to multiple subscribers (in this case, multiple SQS queues). SQS queues then decouple the delivery, ensuring each target system processes the message independently and reliably. AWS Lambda functions can process messages from each SQS queue and update the target systems without affecting others. This design provides scalability, fault isolation, and loose coupling, which are best practices for event-driven architectures.
LucV3
👍 2
Selected: D
None is perfectly correct. The fan-out pattern in D (SNS → SQS) is right, but the trigger must not be an RDS event. The correct design is “app publishes to SNS,” which isn’t one of the options. If you’re on Aurora, you could do: DB trigger → Lambda → SNS → SQS, which aligns with the fan-out part while keeping least-privilege and decoupling.
aszd
👍 1
Selected: D
A & B: These suggest triggering Lambda directly from RDS updates, which is not natively supported. Also, a single SQS queue (standard or FIFO) does not support multiple consumers efficiently—fan-out is needed. C: This reverses the correct pattern—SQS queues cannot fan out to SNS topics. The correct approach is SNS fanning out to SQS queues. D: Correctly uses RDS Event Notifications → SNS (fan-out) → Multiple SQS queues → Lambda for processing.
a0c03ac
👍 1
Selected: D
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. ✅ Explanation: This solution provides a scalable, decoupled, and event-driven architecture that meets the requirement of sending data to multiple target systems when a listing is sold: RDS event notifications can be configured to publish to an SNS topic. SNS supports fan-out to multiple SQS queues, allowing each target system to receive the event independently. Lambda functions can be triggered from each SQS queue to process and forward the data to the respective target systems. This design ensures: Loose coupling between components. Scalability and fault tolerance. Asynchronous processing for better performance and reliability
Charlesvg
👍 1
Selected: A
i really hesitated between A & D. But it is really not posssible for RDS event notifications to send messages about a delete row. An option A only says to use a SQS, event if multiple targets can not consume from one SQS message, you can set up an SNS with the SQS queue to implement the fan out
kaleido
👍 2
Selected: D
I prefer answer D because "data needs to be sent to targets". SNS is more efficient.
bora4motion
👍 2
Selected: D
going with d as you need sns to fan out to multiple systems
Kp002
👍 2
Selected: D
Why not A or B: Lambda cannot be directly triggered by Amazon RDS data changes unless you’re using Amazon Aurora with the advanced Aurora MySQL features, which support Aurora database triggers to invoke Lambda. If it’s standard RDS, you’d need to build this logic into the application itself or poll the database — not ideal. • FIFO queues (Option B) are only needed if message order is critical, which isn’t indicated in the question.
c6ee0dd
👍 2
Selected: D
D : event publishes message to a topic making it available to multiple consumers A : Its a single SQS queue which can lead to problems when multiple consumers are consuming the data concurrently
TEC65
👍 2
Selected: D
D - RDS cannot send notification to lambda
network_enthusiast
👍 1
Selected: B
B is the correct answer
CloudExpert01
👍 1
Selected: A
RDS event notifications won't capture row-level changes directly, and adding complexity with SQS and SNS may be unnecessary.
ChhatwaniB
👍 3
Selected: D
SQS won’t work for multiple targets. Once a message is consumed by a target it will be removed from the queue
Saloniip
👍 1
Selected: D
We need to send same msg to multiple targets that a data bas been removed. Not different msgs to different targets. so option d is much better solution.
zdi561
👍 5
Selected: 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.
CristiaNNN
👍 4
Selected: 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.
Rcosmos
👍 1
Selected: D
Conclusão: A opção D (SNS para distribuição e SQS para entrega confiável) é a solução mais adequada, escalável e resiliente para lidar com a necessidade de envio de dados a vários sistemas de destino após a venda de um automóvel.
4729e6c
👍 3
Selected: D
Option D is the best choice because it uses RDS event notifications to trigger an SNS topic that fans out to multiple SQS queues, enabling each target system to process events independently and reliably. This approach ensures scalability, decoupling, and durable message storage. Option A is not ideal because RDS does not natively trigger Lambda functions; an external polling mechanism would be required, increasing complexity and operational overhead.
Mischi
👍 2
Selected: D
The combination of Amazon SNS and Amazon SQS together with AWS Lambda provides a robust, scalable and efficient solution for distributing RDS events to multiple target systems. This architecture ensures that data is transmitted reliably and that each target system can process the information independently, optimally meeting business requirements.
dipenich
👍 3
Selected: 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.
EllenLiu
👍 2
Selected: D
key point: Even though lambda is integrated with RDS, it is not best practices for multiple consumers. SNS + SQS Fan-Out should be chosen https://aws.amazon.com/getting-started/hands-on/send-fanout-event-notifications/?nc1=h_ls
f51a8bd
👍 3
Selected: D
D is correct A and B: AWS Lambda cannot be triggered directly from Amazon RDS. Additionally, FIFO (in B) is not necessary unless there is a strict requirement for order.
0de7d1b
👍 1
Selected: A
Explanation: AWS Lambda: Lambda functions can be used to automatically trigger actions in response to updates in your database. You can create a Lambda function that listens for changes in the RDS database (e.g., when a listing is marked as sold) and sends that information to other systems. Amazon SQS: The Lambda function would send the information to an SQS queue, which allows asynchronous message processing. Multiple target systems (consumers) can then read from the SQS queue and process the data as needed. SQS ensures the delivery of messages and can handle scaling to multiple consumers.
Mish
👍 2
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.
ChymKuBoy
👍 1
Selected: A
A for sure
Omariox
👍 4
Selected: D
You have to fan out first with SNS
PaPi_z
👍 6
Selected: 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.
MatAlves
👍 4
Selected: 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
anminfang
👍 5
Selected: D
Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets
PaulGa
👍 2
Selected: C
Ans C - using SQS means events are time-order preserved and then can be sent to multiple consumers using SNS
Johnoppong101
👍 1
Selected: A
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html
bignatov
👍 7
Selected: 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.
ensbrvsnss
👍 3
Selected: D
Fan out needs SNS
Hamza_005
👍 1
Why not answer (B) because the car sold first should be updated on the target system first so that more than one customers cannot purchase the same car
DavidNgTan
👍 2
Selected: D
Fan-out pattern chose D
RahulBro
👍 2
Selected: B
I can't understand why people are opting for A but not B. Using a standard SQS queue (non-FIFO) does not guarantee message order and can lead to potential duplicate processing if not handled carefully. This might not be suitable when precise order and exactly-once processing are required, as in the case of removing automobile listings and sending data to multiple systems simultaneously.
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.
jatric
👍 3
Selected: D
confuse with A and D as both violate one of the another. But Options D looks more appropriate to fan out to multiple targets using SNS
Duckydoo
👍 3
Selected: B
I am not sure why the folks who selected A don't select B instead. Given that this is basically e-commerce, you would want the action to be processed "exactly once" (i.e. you can only sold a car once). In that case, FIFO will give "exactly once" behavior over standard, so you don't accidentally carry out an action multiple times for the same sale.
RahulBro
👍 2
Exactly
Grandsumi
👍 2
Selected: A
D could have been a perfect solution but RDS does not create event notifications based on database updates .. You can refer to the link below to the kind of events RDS triggers notifications for => https://dzone.com/articles/how-can-i-know-what-happens-inside-amazon-rds#:~:text=an%20event%20subscription.-,AWS%20RDS%20Event%20Categories%20and%20Messages,-Amazon%20RDS%20generates A is a good alternative that lacks fanning out which will not be necessary if the visibility timeout is adjusted properly and the targets are not many. A is the near best alternative so I GO in for A.
soufiyane
👍 1
Selected: A
RDS event notification doesn't support any notification
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
Ikki77
👍 1
The most suitable design for the scenario described 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 leverages RDS event notifications to trigger a fan-out mechanism through Amazon SNS. Subsequently, AWS Lambda functions can be used to process these messages and update the multiple target systems efficiently. This approach allows for decoupling the components and provides flexibility in managing the integration with different target systems.
shwelin
👍 1
Answer is C , multiple subscribers.
wyejay
👍 1
Option A: Triggering a Lambda function directly from RDS updates isn't straightforward without using an intermediary service like SNS or SQS to handle the messaging. Option B: While SQS FIFO queues ensure order, they aren't necessary unless the application requires strict order in processing sales data, and they don't inherently support multiple targets without additional configuration. Option C: RDS event notifications typically signal RDS instance events (like backups or maintenance) rather than data-level changes within the database.
thewalker
👍 3
Selected: D
D is the right option When asked Amazon Q: Can I create an event notification for a delete row action for a table in the RDS Database? The answer was: Yes, it is possible to create an event notification for delete row actions in an RDS database table. When a row is deleted from an RDS database table, it will trigger a "Delete" event. You can subscribe to these events by creating an Amazon RDS event notification subscription. Hence, for the remaining architecture, D is the best way forward.
06042022
👍 1
Selected: D
Fanout->SNS->SQS
awsgeek75
👍 1
Selected: A
From language perspective A looks better than D but the implementation in D is much closer to what A should be. It is confusing either way.
SohamSLP
👍 1
Wouldn't we want to process orders in FIFO manner?
sirasdf
👍 1
If you understood FIFO you would ask that question.
pentium75
👍 2
Why should we?
djgodzilla
👍 1
Selected: A
AWS RDS Event Categories and Messages Amazon RDS generates several different events. The key event categories include : DB instance created/deleted/restarted/shutdown Maintenance , patching , backup & Recovery Configuration changes, snapshot actions https://dzone.com/articles/how-can-i-know-what-happens-inside-amazon-rds
Fizbo
👍 1
Selected: 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 i.e delete. Usually, you can do it through a native function or stored procedure
xdkonorek2
👍 1
Selected: B
RDS event notification can't send notifications about state of tables If this data is about selling automobile and target systems process this sale FIFO queue would be desired to avoid duplicates Multiple consumers can process single message from queue
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!!
liux99
👍 2
RDS event is database level event, not table level event, so record delete is not considered as event, C, D are out. FIFO queue is not required here, B is out. A is the only possible right answer.
wearrexdzw3123
👍 2
In my opinion, there is no complete solution provided, whether it is d or a
tom_cruise
👍 1
Selected: A
"If you don’t delete the message, Amazon SQS will deliver it again when it receives another receive request." https://aws.amazon.com/sqs/faqs/#:~:text=If%20you%20don't%20delete,No.
lqw
👍 2
Selected: D
1 SNS to multiple SQS, each SQS has a subscriber application...
tom_cruise
👍 4
Selected: 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.
David_Ang
👍 2
Selected: A
In option C and D from the original question, the use of Amazon SNS and Amazon SQS together might not be necessary, and it could introduce complexity. These options involve sending RDS event notifications to SNS topics and then fanning out to multiple SQS queues. While this approach can work, it adds an additional layer of complexity and might not be the most straightforward solution for the use case described. Option A, on the other hand, directly uses AWS Lambda functions triggered by RDS updates to send data to an SQS queue. It simplifies the architecture and is often more straightforward for scenarios where you need to process and send data to multiple consumers when a database is updated. so "A" is correct.
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.
pentium75
👍 1
"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." Are you sure? Where is that stated?
rlaisqls
👍 6
Selected: 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
xyGGXH
👍 1
It's deletion of the instance , not the record
BartoszGolebiowski24
👍 2
RDS event notification does not send an event when a record is deleted. RDS event notifications are used to provide notification when an Amazon RDS event occurs. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_Events.overview.html
mtmayer
👍 3
Selected: D
..... data must be sent to multiple target systems. = SNS
Guru4Cloud
👍 1
Selected: A
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
cookieMr
👍 3
Selected: D
Fanout -> SNS + SQS
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
Mia2009687
👍 2
Selected: D
SNS Fan out to multiple SQS
Anmol_1010
👍 3
Sqs, does not send notification to multiple targets Answer is D
northyork
👍 2
D: RDS event to SNS notification https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html
zmaster
👍 2
Option D is the most suitable for this scenario: AWS Lambda can then process these messages in SQS to update the target systems. The other options aren't as suitable because: Option A and B: Lambda functions are not directly triggered by Amazon RDS updates. Option C: SQS does not fan out to multiple SNS topics. It's the other way around; an SNS topic can fan out to multiple SQS queues.
PrasanthVarada
👍 1
Answer is D. Fanout pattern is basically from SNS -> to -> multiple SQS. Option C is wrong - because SQS doesn't support push.
Jesuisleon
👍 4
Selected: 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.
Siva007
👍 1
Selected: A
RDS event notification subscription doesn't support any notification when data is removed\deleted. SQS FIFO doesn't make sense. So, A is the most closest answer
ealpuche
👍 1
Selected: C
The answer is C
bedwal2020
👍 2
Selected: D
For me "Multiple target systems" and SNS is the key
kruasan
👍 2
Selected: A
RDS resources eligible for event subscription -DB instance -DB snapshot -DB parameter group -DB security group -RDS Proxy -Custom engine version
sam20231
👍 2
Correct ans is D RDS event notification subscription can be set up to trigger an event. This event will an SNS topic, which can fan out to multiple SQS queues to be processed by Lambda. This design is highly scalable, fault tolerant and ensures the data is delivered to multiple targets. Also, it decouples the different components of the system to scale independently. Option A and B are viable but do not leverage SNS which provides fucntionality like fan-out and topic filtering Option C is not recommended as it involves additional layer of complexity
dobiseo
👍 1
Selected: A
AAAAAAAAAAAAAAAA
Dr_Chomp
👍 1
Has to be D - how do you manage which of the multiple systems in option A get which message? multiple queues can subscribe to either specific topics OR difference application targets can consume from different SQS instances - preferrably both! So D for me
linux_admin
👍 1
Selected: A
This option provides a clean separation of concerns, where the Lambda function is responsible for sending the updated data to the SQS queue, and the targets can consume the messages from the queue at their own pace. This can help with scaling and reliability, as the targets can handle messages independently and can be scaled up or down as needed.
nauman001
👍 3
Listing the Amazon RDS event notification categories. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.ListingCategories.html
alexiscloud
👍 1
Answer D: RDS uses the SNS to provide notification
asoli
👍 2
Selected: D
it says different target systems. So, we need a multiple sqs queue. With only 1 SQS, we cannot have multiple deliveries to different targets. So, it needs SNS fan out to multiple SQS and then each sqs has a target system to consume
asoli
👍 1
when I read others' answers, I changed my mind. The answer is A. as mentioned, the updating data does not triggering any event in RDS. So, D is not correct. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html
CapJackSparrow
👍 1
I mean, it is not saying any changes have been made to the DB... the condition "sold" becomes true, which triggers the event. I'm inclined to go with D on this with that logic... Although I can not say for sure.
Tofu13
👍 8
Selected: D
Question to who thinks A is correct: How is sending data to "multiple target systems" possible with a single SQS?
bdp123
👍 2
Selected: D
https://docs.aws.amazon.com/lambda/latest/dg/services-rds.html https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html
UnluckyDucky
👍 2
Selected: D
Weird question... Answer A - only one system will be able to poll the SQS message not multiple which doesn't meet the requirements. Answer D - Amazon RDS event notifications don't provide Insert/Update/Delete notifications, they only provide notifications for the instance itself. Not really sure what's the right answer here... the key imho is that it requires processing by multiple systems therefore fanout makes most sense.
dexpos
👍 1
for me is D
dexpos
👍 2
this question is tricky. I can undestand from the links provided that the RDS event notification can not be used for the modification of a data in the DB but the SQS alone is not enough to update several systems.
tinkeringpuncturing
👍 1
what is your take, what is your answer dexpos, please advise?
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?
remand
👍 1
Selected: D
Multiple Target system could consume from its own SQS via SNS fanout make sense
mj61
👍 1
A Lambda function could be triggered by an RDS event notification, which would be set up to trigger when a new record is inserted, updated, or deleted in the database, sending the data to an SQS queue for the targets to consume. SQS can provide an asynchronous messaging service that allows the targets to process the data at their own pace and can buffer the data in case of high traffic.
ksolovyov
👍 15
Selected: 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.
BlueVolcano1
👍 1
I agree with it requiring a native function or stored procedure, but can they in turn invoke a Lambda function? I have only seen this being possible with Aurora, but not RDS - and I'm not able to find anything googling for it either. I guess it has to be possible, since there's no other option that fits either. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html
aba2s
👍 2
Selected: 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. So C and D is out. order doesn't matter here, so B is also out. I vote for A
Zerotn3
👍 1
Selected: D
To design a solution that sends data from an Amazon RDS database to multiple target systems when an automobile is sold, you can use a combination of Amazon Simple Notification Service (Amazon SNS) and Amazon Simple Queue Service (Amazon SQS).
arseyam
👍 2
Selected: A
You can create a procedure in your RDS database to invoke a Lambda function https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL-Lambda.html
NV305
👍 1
Selected: D
Since RDS sends notification to SNS. IT HAS TO BE D. :) https://docs.aws.amazon.com/lambda/latest/dg/services-rds.html https://docs.aws.amazon.com/lambda/latest/dg/with-sns.html
FNJ1111
👍 1
D says, "AWS Lambda functions to update the targets." However, the question only asks that the data be sent to target systems. A doesn't update targets.
career360guru
👍 1
Selected: D
D is the right option. RDS event notifications can be configured to SNS topic.
Buruguduystunstugudunstuy
👍 4
Selected: 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.
Buruguduystunstugudunstuy
👍 2
Option A is incorrect because it does not include the use of Amazon SNS to fan out the data to multiple targets. Option B is incorrect because it uses a FIFO (first-in, first-out) queue, which is not necessary for this scenario. Option C is incorrect because it uses an Amazon SQS queue as the initial event notification, rather than Amazon SNS.
duriselvan
👍 1
A is correct ANs :- https://aws.amazon.com/getting-started/hands-on/send-fanout-event-notifications/
career360guru
👍 2
Selected: D
D is the right answer RDS sends event notification to SNS (direct notification into SQS queue is not supported) so A is wrong answer.
csrlima
👍 2
hi team , just for reference , for example in this one we have answer C as suggested asnwer and also marked with green square, but then most voted one is A and D, what answer should i take in case of i had also doubts about it?
JayBee65
👍 4
Please provide reference for this claim: " event notification by RDS stream or advance audit DML"
Jiang_aws1
👍 4
The key is "Fanned out" due to "Multiple target systems" need to update
markvonwaffen
👍 2
Selected: A
A is correct, see romko comment
sanyoc
👍 2
Selected: A
A is correct
lapaki
👍 2
Selected: A
Explanation from romko checks out
invaderfr
👍 2
Selected: A
Answer is A, already explained by others but there is no way to know if table is updated (create, read, write) with RDS event, https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.overview.html So A is the only possible answer
royboy13
👍 3
Selected: D
Answer is D. https://docs.aws.amazon.com/lambda/latest/dg/services-rds.html
Aamee
👍 2
Selected: A
Definitely it's 'A'.
Incognito013
👍 2
Selected: A
Answer is A! Haven't heard of an RDS event feature for DB level
AjithKumar3
👍 1
Check documentation
Wajif
👍 2
Selected: A
Why need Lambda to update targets when the whole thing can be achieved with A?
bgingrich
👍 2
Selected: A
Agreed, no event notifications for database level events, so D can't be correct. The other way to accomplish this would be A.
Qjb8m9h
👍 1
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html To subscribe to RDS event notification Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/. In navigation pane, choose Event subscriptions. In the Event subscriptions pane, choose Create event subscription.
mj98
👍 2
Selected: A
There is no event notifications for DB level events for RDS. A is the right answer. Custom stored proc can be used to trigger lambda but there is no default option like RDS event notification. Pls do research. ANS is A
ocbn3wby
👍 2
Selected: A
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 RDS event list here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html Correct answer is A.
anhdao1211
👍 2
Selected: A
A RDS event notification ?
Vic_d_gr8
👍 4
Selected: 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
JayBee65
👍 1
But there is no event notifications for DB level events for RDS, so D is wrong!
Wpcorgan
👍 1
D is correct
romko
👍 91
Selected: 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
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.
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
Evonne_HY
👍 3
RDS event notification is supporting object deletion. What's more, it is saying the listing will be removed rather than update, so D is correct. Here's the link for event notification categories link: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.ListingCategories.html
ruqui
👍 22
I don't think A is a valid solution ... how do you send the data to multiple targets using a single SQS?
studynoplay
👍 2
Wow, great find romko. Didn't realize that Event notification doesn't notify when the data is changed, it notifies when major changes at DB level occur like settings etc
Jiang_aws1
👍 2
D is connect RDS event notification by RDS stream or advance audit DML so it is possible
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.
PS_R
👍 2
Selected: D
Cannot be C as Fanout = SNS + SQS.
Merchant
👍 2
Selected: D
DDDDDD!
Hunkie
👍 3
Selected: D
The RDS event notifications sends the notification using SNS not SQS. Similar to old question
PS_R
👍 1
Agree, Also Fanout means SNS + SQS, which rules out option C, So the answer is D
dokaedu
👍 1
answer should be D https://betterprogramming.pub/how-to-fan-out-to-different-sqs-queues-using-sns-message-filtering-84cd23ed9d07
Six_Fingered_Jose
👍 2
Selected: D
answer should be D > the data must be sent to multiple target systems. Fanning out -> SNS
whosawsome
👍 4
Selected: D
D if in doubt
Moonus
👍 3
Answer is D
Lilibell
👍 4
The answer is D
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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
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.
Related Analysis
Practice All SAA-C03 Questions
Access 120 questions with complete answers and detailed explanations.
View Full SAA-C03 Practice Test →