Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 108 discussion

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

A for sure

You have to fan out first with SNS

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.

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

Answer is D, this is a typical scenario for SQS fan-out. A can not send data to multiple targets