BenchMark Quizzes by MDFT Pro

Implement Change Feed Processor with Error Handling

You work as a NoSQL Database Developer for MDFT Pro, a well-known training agency that provides certification courses to thousands of students worldwide. Mark, the Data Engineering Lead, has implemented an Azure Cosmos DB solution using the latest SDK to manage student enrollment records, course progress tracking, and certificate generation.

You’ve added a change feed processor to monitor a new container that stores student course completions. During testing, when you attempt to process a batch of 100 completion documents to generate certificates, the process fails when reading one specific document that has malformed data. The current implementation retries the entire 100-document batch repeatedly, causing delays in certificate generation for all other students in the batch.

You need to implement a solution that monitors how far behind the change feed processor is getting (to alert the operations team) and prevents the processor from continuously retrying the entire batch when a single problematic document is encountered, allowing successful documents to be processed while isolating the failed one for manual review.

Which two features should you implement in the change feed processor?

Choose all correct answers from the options below.

Explanations for each answer:

Change feed estimator is correct. The change feed estimator monitors the progress of change feed processor instances by measuring the lag between the last processed item (tracked in the lease container) and the latest changes. It provides visibility into how far behind the processor is, helping you identify when processing is slow or stuck.
Dead-letter queue is correct. A dead-letter queue (or errored-message queue) prevents the change feed processor from getting stuck retrying the same problematic document repeatedly. When a document fails processing, it's written to the queue, allowing the processor to continue with subsequent changes. This ensures one failed document doesn't block the entire batch.
Deployment unit is incorrect. Deployment unit is not a specific feature of Azure Cosmos DB change feed processor. While you can deploy change feed processors across multiple instances for scalability, this concept doesn't specifically address progress monitoring or preventing batch retries on failures.
Lease container is incorrect. The lease container is a required component that coordinates change feed processing across multiple workers and stores checkpoint state. However, it's a fundamental infrastructure component for the change feed processor itself, not a solution for monitoring progress or handling individual document failures. It's already being used implicitly.

Learn more about Change Feed Processor:

Cosmos DB Change Feed

Practice Exam

Implement Change Feed Processor with Error Handling

Discuss this question on social media: