When a parcel record changes in DynamoDB, a search index and an audit log must update. Which integration pattern should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Treat the table’s change log like a conveyor belt. DynamoDB Streams plus Lambda picks up each parcel edit and fans it to search and audit—no minute-by-minute full-table scavenger hunts.
Full Explanation
When a parcel record changes in DynamoDB, downstream search and audit consumers should react to the change stream rather than rediscovering state by brute force. Enable DynamoDB Streams and process stream records with Lambda (or other stream consumers) to update the search index and append audit events. That change-data-capture pattern delivers ordered-ish item-level events with low lag and avoids continuous full-table reads.
Polling the entire table with Scan every minute from two Lambdas wastes read capacity, increases lag variability, and duplicates work as the parcel table grows. Asking clerks to retype changes into OpenSearch and CloudWatch is not an integration pattern. S3 inventory reports summarize S3 object inventories; they are not CDC for DynamoDB table mutations.
Exam caveat: stream shards and Lambda concurrency need error handling and idempotency—retries can deliver duplicates, so audit appends and search upserts should be idempotent. Operational check: update a test parcel, confirm a stream record arrives, verify the search document and audit entry reflect the change, and inject a deliberate consumer failure to ensure the DLQ/retry path does not lose municipal audit evidence.