Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 166 discussion

The trigger is that the central user service deletes a user in the DynamoDB table. The DynamoDB Streams meets the requirement. https://aws.amazon.com/blogs/database/how-to-perform-ordered-data-replication-between-applications-by-using-amazon-dynamodb-streams/ Option B is wrong. There is no feature named DynamoDB event notifications.

C seems correct; SQS is one queue to one microservice, could not find anything on dynamodb event notifications.

it is MUCH MORE faster to send the event through eventbridge to microservices once the event of deletion needs to happen. I first read option A and thought it was the right one but have the microservices polling SQS QUEUE is less performant than the other one. AND it's impossible for SQS to have multiple consumers as this is not the main purpose of this service, this is not a fan-out architecture with SQS and SNS. Totally sure that C is the correct answer, I repeat, I thought it was A but it's not.

C, The problem with A the SQS solution ist that the "other microservices which stores data chunks seperatly". We do not know how many services are storing the userdata, and with SQS we would have one message on the queue which is processed by one of these microservices. how could the other microservices know that they have to delete the data when the message is allready consumed and processed?

SQS does not have a fan-out capability. You need SNS --> SQS to achieve the microservices to be notified. Hence A is incorrect and C is correct.

A is not viable since SQS is not used in a fan-out situation. B is not viable since there's no such thing as "DynamoDB event notifications". C is viable. D is not viable, again due to the fact that SQS is not used for fan-out.

This is tricky question. C seems to be best and feasible. Rest options are not correct as they are using SQS where messages can be delivered only to one reader while in this scenario there are multiple microservices that needs to read the same message and delete the user information.

Lets Ignore the insanity of Several other microservices store in ---- different storage services. ------ central user service deletes a user, every other microservice must also delete its copy of the data immediately. YET ALL the options attempt a delete in the OG DynamoDB Yeah OK Whatever Blue is green and Red is Orange these days. BTW ans. == C , A will work but why poll SQS when Evt Brdg can invoke Microservice. Personally I'd invoke a lambda to delete related records from the disparate data sources per KeyId and not bother the services but I'm not Architecting this mess maybe they want a clean log trail of the delete process as invoked by central user service whatever

I vote for C because the question says: Delete the user IMMEDIATELY A and D use SQS and messages in SQS can stay a pretty long time

Amazon FSx for Lustre is a fully managed service that provides cost-effective, high-performance, scalable storage for compute workloads. Powered by Lustre, the world's most popular high-performance file system, FSx for Lustre offers shared storage with sub-ms latencies, up to terabytes per second of throughput, and millions of IOPS. FSx for Lustre file systems can also be linked to Amazon Simple Storage Service (S3) buckets, allowing you to access and process data concurrently from both a high-performance file system and from the S3 API.

Option C

https://aws.amazon.com/vi/getting-started/hands-on/send-fanout-event-notifications/?nc1=f_ls

A real-world use case utterly destroyed with some of the worst possible options for solutions. Simplest solution is to have the interested parties consume events off the DynamoDB streams and delete the user information in their respective datastores. Too many red herrings in the options given, and the only relatively sane one of the lot is Option C. The bar for coming up with questions with SA professional keeps getting lowered.

Event trigger from DynamoDb -- Choose DynamoDb Streams

Where the hell is fan-out pattern? stupid answers ...

* The central user service stores sensitive data in an Amazon DynamoDB table. * Several of the other microservices store a copy of parts of the sensitive data in different storage services. Apparently only the central user service stores user data in DynamoDB. The others use "different storage services". Yet, all of the answers focus on DynamoDB...

C A would be preferable with SNS instead of SQS