A salt-marsh nursery wants every insert and update on plant items, in modification order, without polling the Cosmos container. Which Cosmos mechanism should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Stop ringing the greenhouse every minute asking “anything new?” The change feed is Cosmos’s built-in change log for inserts and updates in order. Event Grid and Event Hubs are Domain 5 messaging—not this Domain 2 notification skill.
Full Explanation
A salt-marsh nursery that wants every insert and update on plant items in modification order without polling should use the Azure Cosmos DB change feed. The change feed is Cosmos’s persistent, ordered log of inserts and updates for a container. Consumers read changes incrementally instead of listing the whole nursery inventory on a timer, which is the Domain 2 notification pattern AZ-204 emphasizes for Cosmos.
An Event Grid subscription on the storage account firewall watches storage control-plane or blob events, not Cosmos item mutations, and mixes Domain 5 Event Grid thinking with the wrong resource. An Event Hubs capture job that scans every partition key nightly is batch messaging/analytics, not the live Cosmos change log. A timer that lists all items every minute is classic polling: costly, easy to miss concurrency edges, and exactly what change feed is meant to replace.
Exam caveat: by default, latest-version change feed surfaces inserts and updates; deletes need all-versions-and-deletes (with continuous backup) or an application soft-delete property if consumers must react to removals.
Operational check: enable a change feed consumer against the plant container, insert and update a test item, and confirm the consumer receives those operations in per-partition-key order without a full container scan.