My most logical choices here are:
1a: AWS Aurora - Seems database management related, can also trigger Lambda functions, and transactional related looking at the STAC catalog.
1b: CloudWatch - Seems to trigger lambda on a certain monitoring job, especially with the “clock” icon.
Next to the DynamoDB endpoint: SNS - Seems like the notification service. it also fans out.
Other services I’ve tried:
1a: AWS Glue, but there is no data being fed to AWS Glue
Next to the DynamoDB endpoint: SQS, but isn’t a “notification system” and can’t fan out.
AWS Redshift on 1a seems unlikely since 1a requires a service that can write data to S3 buckets.
Can anyone help me with this challenge and rationale?
You’re definitely on the right track, those SAA-C03 design challenges can be confusing at first, but you’re thinking in the right direction. The key is always to look at what AWS wants you to optimize for: scalability, decoupling, and event-driven design.
About that part next to DynamoDB, SNS actually makes a lot of sense there. It’s often used as a notification or fan-out mechanism to push messages to multiple subscribers, like Lambda or SQS. That fits perfectly if the design is supposed to react to data changes or events in real time.
Aurora would be great when the question is more about relational data or transactions, especially if triggers or stored procedures are mentioned. CloudWatch is more for monitoring and alarms rather than moving or processing data, so you can usually rule that out in data flow designs.
And yeah, Redshift usually comes in only when there’s a need for analytics or reporting on big data, not in this kind of operational flow.
So in short, your logic is solid! DynamoDB → SNS (for notifications or fan-out) → Lambda/SQS (for further processing) is a common AWS pattern, and that’s likely what they’re testing for in this challenge.
Hope that helps you connect the dots, you’re almost there!
