An aurora-watch lodge already runs a Cosmos-triggered Azure Function. A second long-running worker in Azure Container Apps must consume the same container’s changes. Which Domain 2 approach fits the Container App?
Select an answer to reveal the explanation.
Short Explanation
The Functions trigger already covers the lodge’s serverless path. The Container App needs the change feed processor (or pull model)—not another HTTP timer that lists the container, and not Redis or AKS detours.
Full Explanation
An aurora-watch lodge that already has a Cosmos-triggered Azure Function and needs a second long-running worker in Azure Container Apps should host the change feed processor (or the pull model) inside that Container App. Domain 2 treats the processor and pull model as the in-scope ways for non-Functions hosts to consume the same container’s change feed. The Functions trigger remains valid for the serverless path; the Container App simply uses the library-based processor or on-demand pull APIs instead of inventing a new polling façade.
Adding another HTTP-triggered function that queries the whole container on a schedule reintroduces polling and duplicates work the change feed already provides. Replacing Cosmos with Azure Cache for Redis pub/sub abandons Cosmos’s durable change log for a cache messaging pattern that is not this Domain 2 skill. Using kubectl to attach an AKS sidecar that watches the Cosmos REST API drifts into Kubernetes operations and custom watchers outside the AZ-204 change-feed answer.
Exam caveat: multiple independent consumers need separate lease stores or lease prefixes so the Function and Container App do not steal each other’s checkpoints.
Operational check: deploy the processor into the Container App with its own lease container, write a test item, and verify both the existing Function and the Container App worker observe the change without fighting over the same lease documents.