A thistle-farm CSA backfill must replay Cosmos change history, while a live packer station should only see new changes from now on. What should the developer configure for each consumer?
Select an answer to reveal the explanation.
Short Explanation
Backfill wants the whole scrapbook; the packer only wants new pages. Point each consumer’s change-feed start where it belongs—beginning versus now. One size does not fit both jobs.
Full Explanation
A thistle-farm CSA backfill that must replay Cosmos change history and a live packer station that should only see new changes need separate change-feed start points. Point the backfill consumer at the beginning (or a historical start time) so it can replay the scrapbook of past inserts and updates. Point the live packer at now (or the current continuation) so it only processes changes from the moment it starts. Each consumer’s start and lease state should be independent so one job’s replay does not force the other to reprocess history.
Forcing both consumers onto Strong consistency does not define where in history each begins reading; consistency is orthogonal to start time. Routing both to Spark analytics notebooks treats a supporting analytics connector as the only AZ-204 start mechanism and ignores SDK processor/pull start options. Sharing one lease document so both always start from container creation time couples the workloads and makes the live packer replay the entire feed.
Exam caveat: start time and lease ownership are per consumer (or per processor host group). Reusing leases across unrelated workloads is a common cause of skipped or duplicated processing.
Operational check: give backfill and packer separate lease prefixes or containers, set start-from-beginning versus start-from-now explicitly, insert a new item after both are running, and confirm only the packer (plus any intentional backfill still in flight) handles that new change as designed.