A meteorological startup uses Amazon DynamoDB to store weather data and wants a new service that notifies managers of four internal teams each time a new weather event is recorded. The company does not want the new service to affect current application performance and wants the least operational overhead. What should a solutions architect do?

Enabling DynamoDB Streams on the table allows for real-time capture of item-level modifications, including new records, without impacting application performance. A Lambda function (trigger) can then process these stream records and publish a message to a single Amazon SNS topic. All four teams can subscribe to this one SNS topic, ensuring they receive notifications for new weather events. This approach offers low operational overhead as DynamoDB Streams and Lambda are serverless, and SNS simplifies fan-out messaging. DynamoDB transactions are for atomic, all-or-nothing operations on multiple items within or across tables, not for notifications. Publishing to four separate SNS topics for each event is less efficient than a single topic with multiple subscribers. A cron job scanning the table is inefficient, adds operational overhead, and introduces latency, failing to meet the real-time and low overhead requirements.