Exam AZ-204 topic 3 question 35 discussion

Got this on 16/03/23. Went with proposed solution. Make sure to prepare for case study. I got city and lights case study. No Kubernetes, Search, Logic Apps questions for me.

I agree with the answer! 1. Change feed estimators monitor change feed processors' progress 2. Dead-letter queues handle errors and are able to monitor failed attempts, require failed attempts and even trigger a follow-up action (remediation or response)

Why feed estimator ? It has nothing to do with 'keeping track of failing batch'. Failing batch should be sent to dead-letter queue to keep track of it...

Got this on 04/07/2024, Went with highly voted answer, score:820

The correct answer seems to me: - Change feed estimator - Life cycle notifications You also can use the change feed estimator to monitor the progress of your change feed processor instances as they read the change feed, or you can use life cycle notifications to detect underlying failures. Life cycle notitications literally says: Register a handler for WithErrorNotification to be notified when the current host encounters an exception during processing. You need to be able to distinguish whether the source is the user delegate (an unhandled exception) or an error that the processor encounters when it tries to access the monitored container (for example, networking issues).

Got on 07/02/2024

The answers should be reversed.

On exam 3-Nov-2023. Went with proposed answer - 932/1000. 1) change feed estimator 2) dead-letter queue

1/ "Change feed estimator" solely estimates the rate of changes, number of shards, and distrubution of the feed, but not read or process documents. There's a error because by confusing with "Change feed processor". 2/ Dead-letter queue

should be vice versa

This was on the exam (July 2023). Unsure about solution....

Got this on 2023may12. my cases also: case: You need to configure authorization. case: You need to ensure the app does not time out and processes the blob data case study: VanArsdel Inc Canada

From: https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed-processor?tabs=dotnet#error-handling "To prevent your change feed processor from getting "stuck" continuously retrying the same batch of changes, you should add logic in your delegate code to write documents, upon exception, to an errored-message queue. This design ensures that you can keep track of unprocessed changes while still being able to continue to process future changes. The errored-message queue might be another Azure Cosmos DB container. The exact data store does not matter, simply that the unprocessed changes are persisted. In addition, you can use the change feed estimator to monitor the progress of your change feed processor instances as they read the change feed or use the life cycle notifications to detect underlying failures." As the questions says 'keeping track' I'd go for feed estimator.

On my exam 2023-02-25

Was on the exam 27.02.2023 Went for Lifecycle notifications and dead letter queue. Score 870

was on exam 02/2023

1. Life-cycle notifications https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed-processor?tabs=dotnet#life-cycle-notifications Register a handler for WithErrorNotification to be notified when the current host encounters an exception during processing 2. Dead-letter queue https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/change-feed-processor?tabs=dotnet#error-handling To prevent your change feed processor from getting "stuck" continuously retrying the same batch of changes, you should add logic in your delegate code to write documents, upon exception, to an errored-message queue.