Exam AZ-204 topic 4 question 33 discussion

Answer C & D. "What are two possible ways to achieve this goal?"

c and d ? https://docs.microsoft.com/en-us/azure/cosmos-db/read-change-feed#azure-functions https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed-pull-model#using-feedrange-for-parallelization

Azure Function with Cosmos DB Trigger: Automatically handles partitioning and parallelization, making it easier to process changes in real-time. Azure Function with FeedIterator and FeedRange: Provides manual control over change feed processing and allows for efficient parallelization.

FeedIterator is meant to be implemented in a persistent process; it runs indefinitely. A serverless environment like Functions isn't really appropriate. It should be running e.g. as a daemon that auto starts and restarts on failure etc. Which makes me question if D.

It is not D. It says that it uses the pull model on the *container*, but a change processor should pull from Cosmos, not the storage container. Good answers are B and C.

Answer C & D.

C: "Because Azure Functions uses the change feed processor behind the scenes, it automatically parallelizes change processing across your container's partitions." D: "You can use the change feed pull model to consume the Azure Cosmos DB change feed at your own pace. Similar to the change feed processor, you can use the change feed pull model to parallelize the processing of changes across multiple change feed consumers."

Answer C and D C you need to implement the lease container in the function for dynamic scaling and works with multiple partitions. See: https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed-functions. D is also correct as it is described here: https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/read-change-feed

C. Azure Function with Cosmos DB Trigger Azure Functions can be triggered by changes in Cosmos DB, allowing for immediate processing of inserts and updates. D. Azure Function with FeedIterator and FeedRange for Change Feed This method manually handles the change feed processing, allowing for detailed control over parallelization and processing logic.

Both options B and D can be used to process Azure Cosmos DB operations efficiently: B. Create a background job in an Azure Kubernetes Service and implement the change feed feature of the SDK.This option involves creating a background job using Azure Kubernetes Service (AKS) and implementing the change feed feature of the Azure Cosmos DB SDK. AKS provides scalability, and you can parallelize the processing by distributing work across multiple pods in the AKS cluster.D. Create an Azure Function that uses a FeedIterator object that processes the change feed by using the pull model on the container. Use a FeedRange object to parallelize the processing of the change feed across multiple functions. This option involves using Azure Functions with the change feed trigger for Azure Cosmos DB. By using the FeedIterator and FeedRange objects, you can parallelize the processing of the change feed across multiple Azure Functions.

B and C for me. AKS containers can scale and job just runs in background. Funcs can scale and trigger on cosmos. A is an api so whats it triggering on? D also doesnt mention what it would trigger on

isn't the change feed estimator only for monitoring? it is the change feed processor who does the work https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/how-to-use-change-feed-estimator?tabs=dotnet so it is C&D

C,D chatGPT

CD (36%) D (21%) A (21%) Other ...OMG :D

similar was on 2/23

I agree with Zulhin.

I agree with Zulhin.