This post is a part of the AI-200: Developing AI Cloud Solutions on Azure  Exam Prep Hub.
This topic falls under these sections:
Develop AI solutions by using Azure data management services (25–30%)
   --> Develop AI solutions by using Azure Cosmos DB for NoSQL
      --> Implement a change feed processor to detect and handle new or updated items

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure Cosmos DB for NoSQL provides a change feed that records changes made to items in a container. Applications can consume this feed to react to data changes without repeatedly querying the entire container.

For the AI-200 exam, an important implementation pattern is the change feed processor. It provides a push-based mechanism for detecting changes and delivering them to application code for processing.

A change feed processor is particularly useful when an application needs to perform an action whenever items are created or updated, such as:

• Processing newly submitted documents
• Generating embeddings for newly created content
• Updating a search index
• Synchronizing data with another system
• Running AI processing when new data arrives
• Performing analytics or enrichment
• Triggering downstream business workflows
• Maintaining materialized or derived data

The change feed processor also handles important operational concerns such as checkpointing, load balancing, lease management, and recovery.

1. What Is the Azure Cosmos DB Change Feed?

The change feed is a persistent record of changes to items in an Azure Cosmos DB container.

Conceptually, it looks like this:

Application
    |
    | Creates/updates items
    v
Azure Cosmos DB Container
    |
    | Change feed
    v
Change Feed Processor
    |
    +--> Process new item
    +--> Generate embedding
    +--> Update search index
    +--> Call downstream service
    +--> Store derived data

Instead of repeatedly asking:

“Which items have changed since the last time I checked?”

the application can consume the change feed and process changes incrementally.

This makes the change feed especially useful for event-driven and near-real-time architectures.

2. Latest Version Change Feed Mode

For the AI-200 scenario involving detection of new or updated items, the default latest version change feed mode is particularly important.

In latest version mode:

• Creates appear in the change feed.
• Updates appear in the change feed.
• Deletes do not appear.
• If an item is changed multiple times before it is read, the feed provides the latest version rather than every intermediate version.

For example:

Item created
     |
     v
Status = "Pending"
     |
     v
Status = "Processing"
     |
     v
Status = "Completed"

If these changes occur before the consumer reads the feed, latest-version mode may expose the current version rather than every intermediate state.

Therefore, latest-version mode is appropriate when the application cares about the current state of changed items, rather than every individual mutation.

Important exam distinction

If an application must detect deletes or process every intermediate version, latest-version mode isn’t sufficient.

Azure Cosmos DB also supports all versions and deletes mode, which captures creates, updates, and deletes. That mode has additional requirements, including continuous backup, and is available for Azure Cosmos DB for NoSQL.

3. What Is a Change Feed Processor?

The change feed processor is a higher-level mechanism for consuming the Azure Cosmos DB change feed.

It uses a push model.

Rather than requiring your application to repeatedly pull batches and manage continuation state itself, the processor:

1. Reads changes from the monitored container.
2. Determines which changes need to be processed.
3. Delivers batches of changes to your application code.
4. Maintains processing state using a lease container.
5. Distributes work among multiple processor instances.
6. Recovers work when an instance fails.

The change feed processor is currently provided through the Azure Cosmos DB .NET V3 and Java V4 SDKs. Python and Node.js applications can consume the change feed using the pull model rather than the change feed processor library.

4. The Four Components of a Change Feed Processor

A key AI-200 concept is understanding the four major components.

4.1 Monitored Container

The monitored container is the Azure Cosmos DB container whose changes you want to process.

For example:

Database: AIApplication
Container: Documents
Partition key: /customerId

The processor monitors Documents.

When items are created or updated, those changes become available through the change feed.

4.2 Lease Container

The lease container stores the state used by the change feed processor to coordinate processing.

This is extremely important.

The lease container allows multiple processor instances to share the workload without processing the same lease simultaneously.

Conceptually:

                 Lease Container
                /       |       \
               /        |        \
              v         v         v
          Lease 1    Lease 2    Lease 3
             |          |          |
             v          v          v
          Worker A   Worker B   Worker C

The leases represent ownership and progress for portions of the change feed.

The lease container can be in the same Cosmos DB account as the monitored container or in a separate account.

Exam tip

If a question asks:

What component maintains the state of change feed processing?

The answer is generally:

The lease container.

5. Compute Instances

A compute instance hosts the change feed processor.

Examples include:

• Azure Kubernetes Service pods
• Azure App Service instances
• Azure Virtual Machines
• Long-running application processes
• Hosted background services

For example:

AKS Cluster
Pod 1 --> Change Feed Processor
Pod 2 --> Change Feed Processor
Pod 3 --> Change Feed Processor

Each processor instance must have a unique instance name.

The processor distributes leases among the available instances.

6. The Delegate

The delegate is your application code that processes the changes.

For example, suppose an AI application stores documents in Cosmos DB.

When a document changes, the delegate might:

1. Extract the text.
2. Generate an embedding.
3. Store the embedding.
4. Update a vector index.
5. Record processing status.

Conceptually:

Cosmos DB Change
       |
       v
Change Feed Processor
       |
       v
Delegate
       |
       +--> Extract text
       |
       +--> Generate embedding
       |
       +--> Store embedding
       |
       +--> Update AI search data

The delegate is therefore where the application’s business logic lives.

7. How the Processing Lifecycle Works

The basic lifecycle is:

Read change feed
       |
       v
Are there changes?
   /          \
 No            Yes
 |              |
 v              v
Wait          Send batch
 |              |
 +------<-------+
                |
                v
        Delegate succeeds?
           /        \
         No          Yes
         |            |
         v            v
     Retry from    Update
     checkpoint    lease

More precisely, the processor:

1. Reads the change feed.
2. Waits if no changes are available.
3. Sends a batch of changes to the delegate.
4. Waits for successful processing.
5. Updates the lease with the latest successfully processed position.
6. Continues processing.

The checkpoint is therefore advanced after successful processing.

8. Why the Change Feed Processor Uses At-Least-Once Processing

One of the most important concepts for the exam is that the change feed processor provides an at-least-once delivery guarantee.

Suppose the processor reads:

Change A
Change B
Change C

and passes them to your delegate.

If the delegate fails before the checkpoint is successfully updated, the processor can process those changes again.

Therefore:

Change A
Change B
Change C
      |
      v
   Process
      |
      X Failure
      |
      v
Retry
      |
      v
Change A
Change B
Change C

This means your application should generally be idempotent.

9. Why Idempotency Matters

An idempotent operation can safely be executed more than once without producing an incorrect final result.

For example, suppose the change feed processor receives:

{
    "id": "document-123",
    "status": "completed"
}

Your processing logic might update a downstream record:

document-123 -> completed

If the same change is processed twice, the final state remains:

document-123 -> completed

That is preferable to an operation such as:

balance = balance + 100

where processing the same event twice could incorrectly add the amount twice.

Exam rule

Design change feed handlers assuming a change may be delivered more than once.

10. Lease-Based Load Distribution

The change feed processor can distribute processing across multiple instances.

For example:

Change Feed
------------------------------------------------
Partition Range 1
Partition Range 2
Partition Range 3
Partition Range 4
------------------------------------------------
        |          |          |          |
        v          v          v          v
     Worker 1   Worker 2   Worker 3   Worker 4

The lease container coordinates ownership of these workloads.

If one worker fails, its leases can eventually be acquired by another worker.

This provides fault tolerance without requiring the developer to manually coordinate workers.

11. Scaling the Change Feed Processor

Suppose you initially have:

Worker 1

and later add:

Worker 2
Worker 3

The change feed processor can redistribute leases among the workers.

Conceptually:

Before:
Worker 1
 ├── Lease 1
 ├── Lease 2
 ├── Lease 3
 └── Lease 4
After scaling:
Worker 1
 ├── Lease 1
 └── Lease 2
Worker 2
 └── Lease 3
Worker 3
 └── Lease 4

This allows processing to be parallelized.

However, simply adding instances does not mean that processing becomes infinitely parallel.

The available workload is constrained by the number of leases/partition ranges.

The number of processor instances should not exceed the number of available leases for meaningful distribution.

12. Partitioning and Change Feed Processing

Azure Cosmos DB containers are partitioned using a partition key.

For example:

Container: Documents
Partition key: /customerId

The change feed processor works with the underlying partition ranges.

Each range can be processed independently, allowing parallel processing.

This is one reason that selecting an appropriate partition key remains important even when using the change feed.

A poor partition key can create an uneven workload.

13. Starting Position

An important implementation detail is the processor’s starting position.

When a change feed processor is initialized for the first time, its starting point determines which changes it processes.

In latest-version mode, you can configure the processor to start from a specified time or from the beginning of the container’s lifetime.

For example:

Container history
|
|---- Change A
|---- Change B
|---- Change C
|---- Change D
|---- Change E
|
             ^
             |
       Start processor

If configured to begin at Change A, the processor can process the historical changes.

If configured to start from the current point, older changes aren’t processed.

Important

The starting-position configuration is used when initializing the processor. Once the lease container has established the processor’s state, changing the starting configuration doesn’t reset the existing checkpoint.

14. Change Feed Processor vs. Pull Model

There are two major approaches to consuming the change feed.

The change feed processor is generally easier when you want Azure Cosmos DB to manage the mechanics of distributing work and maintaining processing state.

15. Change Feed Processor vs. Azure Functions Trigger

Another important distinction is between the change feed processor and the Azure Functions trigger for Cosmos DB.

Both can be used to build event-driven applications.

For example:

Cosmos DB
   |
   +----> Change Feed Processor
   |
   +----> Azure Functions Trigger

The change feed processor is useful when you need more direct control over a long-running processing application.

The Azure Functions trigger is useful when you want a serverless implementation.

The Azure Functions trigger also uses a lease container to maintain processing state.

16. Handling Processing Failures

Suppose your delegate encounters an exception:

Batch
  |
  v
Delegate
  |
  X Exception

The processor doesn’t simply assume the batch succeeded.

Because the checkpoint hasn’t advanced successfully, the processor can retry the batch.

This behavior produces the at-least-once guarantee.

Important design consideration

If a particular item consistently causes processing to fail, the processor can repeatedly encounter the same problem.

A robust application should therefore have an error-handling strategy.

For example:

Change
  |
  v
Process
  |
  X Failure
  |
  +--> Retry
  |
  +--> Persistent failure
          |
          v
     Error/DLQ storage

An application might persist information about the failed change to another Cosmos DB container or another durable store so that the processing pipeline doesn’t remain permanently blocked by one problematic change.

17. Monitoring Change Feed Lag

A change feed processor can fall behind the incoming changes.

For example:

New changes:
1000 events/sec
Processing:
700 events/sec
Result:
Change feed lag increases

The change feed estimator can be used to monitor processor progress and estimate lag.

This can help identify:

• Insufficient processing capacity
• Slow downstream services
• Throttling
• Application errors
• Lease problems
• Processing bottlenecks

18. Request Units and the Change Feed

Change feed processing isn’t free from a Cosmos DB throughput perspective.

Reading the change feed from the monitored container consumes request units (RUs).

Operations involving the lease container also consume RUs.

For example:

Monitored Container
       |
       +--> Change feed reads --> RU consumption
Lease Container
       |
       +--> Lease reads
       +--> Lease updates
       +--> Lease coordination
                    |
                    v
               RU consumption

If the monitored or lease container experiences throttling, change processing can be delayed.

This is especially important when deploying multiple processor instances or multiple processing workloads that share a lease container.

19. Lease Container Permissions

When Microsoft Entra ID authentication is used, the processor’s identity needs appropriate permissions.

The monitored container requires permissions related to:

• Reading account metadata
• Reading the change feed

The lease container requires permissions for operations such as:

• Reading items
• Creating items
• Replacing items
• Deleting items
• Executing queries

This is an important distinction:

The application doesn’t just need permission to read the monitored data; it also needs permission to maintain the processor’s lease state.

20. Using a Global Endpoint

For a change feed processor workload, Microsoft recommends using the global Cosmos DB endpoint rather than a region-specific endpoint.

For example:

Preferred:
https://contoso.documents.azure.com

rather than:

https://contoso-westus.documents.azure.com

Regional preferences should be configured through the appropriate SDK region settings.

This is important because lease documents are scoped to the configured endpoint. Changing endpoints can result in separate lease state.

21. A Typical AI Application Architecture

Consider an AI document-processing application.

A user uploads a document, and the application stores metadata in Cosmos DB.

The desired workflow is:

User
 |
 v
Application
 |
 v
Cosmos DB
 |
 | New/updated document
 v
Change Feed
 |
 v
Change Feed Processor
 |
 v
Processing Delegate
 |
 +--> Extract document text
 |
 +--> Generate embedding
 |
 +--> Store vector
 |
 +--> Update search metadata
 |
 +--> Notify downstream application

This architecture avoids repeatedly scanning the entire container looking for new work.

It also allows the processing workload to scale independently from the application that writes the data.

22. Example .NET Concept

A simplified .NET implementation conceptually looks like this:

var processor = monitoredContainer
    .GetChangeFeedProcessorBuilder<MyDocument>(
        "documentProcessor",
        HandleChangesAsync)
    .WithInstanceName("worker-01")
    .WithLeaseContainer(leaseContainer)
    .Build();
await processor.StartAsync();

The important concepts are:

• monitoredContainer — where changes originate.
• leaseContainer — where processing state is maintained.
• HandleChangesAsync — your business logic.
• WithInstanceName — uniquely identifies the processor instance.
• Processor startup — begins monitoring the change feed.

The exact SDK APIs can vary by SDK version, so the exam focus should be on understanding the architecture and responsibilities rather than memorizing every method signature. The current change feed processor documentation identifies .NET V3 and Java V4 as the SDKs that provide the processor library.

23. Important Exam Concepts to Remember

For AI-200, make sure you can distinguish the following:

Monitored container

Contains the data whose changes are being detected.

Lease container

Maintains processor state and coordinates work across instances.

Delegate

Contains the application’s processing logic.

Compute instance

Hosts the change feed processor.

Latest-version mode

Captures the latest versions of creates and updates; deletes aren’t included.

All versions and deletes mode

Captures creates, updates, and deletes, including intermediate changes.

Checkpoint

Records the latest successfully processed position.

At-least-once delivery

A change can be processed more than once, so handlers should be idempotent.

Pull model

The application manages reading, continuation state, and processing coordination.

Change feed processor

Provides a higher-level push-based processing model with lease-based coordination.

Practice Exam Questions

Question 1

An AI application stores documents in an Azure Cosmos DB for NoSQL container. Whenever a document is created or updated, the application must perform additional processing. The development team wants Azure Cosmos DB to manage checkpointing and distribute processing across multiple application instances.

Which solution should the team implement?

A. A timer-triggered Azure Function that scans the container

B. Periodic SQL queries

C. Azure Cosmos DB analytical store queries

D. Change feed processor

Answer: D

Explanation

The change feed processor is designed to process changes incrementally and provides built-in lease-based coordination and checkpoint management. It can distribute change feed processing across multiple instances.

The other approaches require the application to identify changes itself and are less appropriate for event-driven incremental processing.

Question 2

A change feed processor processes a batch of changes successfully but fails before the processing state is checkpointed. What should the application expect?

A. The changes are permanently discarded

B. The batch can be delivered again

C. The entire Cosmos DB container is automatically restored

D. The change feed is permanently disabled

Answer: B

Explanation

The change feed processor provides at-least-once delivery. If processing succeeds but the checkpoint isn’t successfully advanced, the processor can process the same changes again.

Application processing logic should therefore be designed to be idempotent.

Question 3

Which component is primarily responsible for maintaining the state and coordinating ownership of change feed processing across multiple processor instances?

A. Monitored container

B. Compute instance

C. Lease container

D. Application Gateway

Answer: C

Explanation

The lease container stores the state used by the change feed processor to coordinate processing across instances.

The monitored container provides the source data, while compute instances host the processing application.

Question 4

An application uses the default latest-version change feed mode. An item is created and then updated three times before the processor reads the changes. What behavior should the application expect?

A. Only the delete operation is returned

B. All four versions are guaranteed to be returned

C. No changes are returned because the item changed multiple times

D. The latest version of the item is available rather than every intermediate version

Answer: D

Explanation

Latest-version mode provides the latest version of an item in the feed rather than preserving every intermediate change between reads.

If the application needs every create, update, and delete operation, it should consider all versions and deletes mode instead.

Question 5

A developer is building a change feed processor application that will run on three AKS pods. What is the primary purpose of assigning each processor instance a unique instance name?

A. To identify each compute instance participating in lease distribution

B. To specify the Cosmos DB partition key

C. To determine the consistency level

D. To select the Cosmos DB database

Answer: A

Explanation

Each change feed processor instance should have a unique instance name. The processor uses the instances and leases to distribute processing work across the deployment.

The instance name is unrelated to partition-key selection, database selection, or consistency configuration.

Question 6

An AI application must react when documents are deleted from an Azure Cosmos DB for NoSQL container. Which change feed capability is most appropriate?

A. Latest-version change feed mode

B. All versions and deletes change feed mode

C. Increasing the consistency level

D. Increasing the container’s RU/s

Answer: B

Explanation

All versions and deletes mode captures creates, updates, and deletes.

Latest-version mode does not capture deletes.

All versions and deletes mode has additional requirements, including continuous backup, and is specifically available for Azure Cosmos DB for NoSQL.

Question 7

A change feed processor application experiences increasingly large processing delays. Investigation shows that the application is processing changes correctly but cannot keep up with incoming changes.

Which metric or capability is most useful for determining whether the processor is falling behind?

A. Azure DNS query count

B. Azure Storage blob count

C. Change feed estimator

D. Azure Resource Manager activity log

Answer: C

Explanation

The change feed estimator can be used to estimate the lag between the changes available in the monitored container and the progress of the change feed processor.

This can help identify processing bottlenecks and determine whether additional processing capacity may be necessary.

Question 8

A change feed processor’s delegate updates an external database. The same change may occasionally be delivered more than once. What should the developer do?

A. Disable checkpointing

B. Use an idempotent processing design

C. Increase the Cosmos DB consistency level to strong

D. Disable leases

Answer: B

Explanation

The change feed processor provides at-least-once delivery, meaning a change can be processed more than once.

The delegate should therefore be designed to handle duplicate processing safely. Idempotent operations are one of the most important techniques for doing this.

Question 9

A company runs several change feed processor instances and notices that the lease container is experiencing RU throttling. What is a likely consequence?

A. Change feed processing can be delayed

B. All documents in the monitored container are deleted

C. The Cosmos DB account automatically switches to strong consistency

D. The application automatically receives unlimited RU/s

Answer: A

Explanation

The lease container performs operations that consume request units. If the lease container is throttled, lease coordination and renewal can be delayed, which can delay change feed processing.

The monitored container’s change feed reads also consume RUs. Both the monitored and lease containers should therefore be appropriately provisioned.

Question 10

A development team wants to consume an Azure Cosmos DB change feed from a Python application. They want to use the built-in change feed processor library that automatically handles lease-based processing.

What should the team do?

A. Use the .NET change feed processor library from Python

B. Use the Java change feed processor library from Python

C. Use the change feed pull model from Python

D. Use Azure SQL Database instead

Answer: C

Explanation

The Azure Cosmos DB change feed processor library is available for .NET and Java. Python applications can consume the change feed using the pull model, where the application manages continuation state and processing.

Key Takeaways

For the AI-200 exam, the most important ideas are:

1. The change feed records changes to Azure Cosmos DB items.
2. The change feed processor provides a push-based processing model.
3. The monitored container is the source of changes.
4. The lease container stores processing state and coordinates workers.
5. The delegate contains the application’s change-processing logic.
6. Multiple processor instances can share the workload through leases.
7. Change feed processing provides at-least-once delivery.
8. Handlers should therefore be idempotent.
9. Latest-version mode captures creates and updates but not deletes.
10. All versions and deletes mode captures creates, updates, and deletes.
11. The change feed processor library is available for .NET and Java; Python and Node.js use the pull model.
12. Change feed processing consumes RUs.
13. Throttling of the monitored or lease container can delay processing.
14. The change feed estimator can help identify processing lag.
15. The lease container is fundamental to distributed, fault-tolerant change feed processing.

The exam’s scenario questions are likely to test whether you can select the right change feed mode, processing model, lease architecture, error-handling strategy, and scaling approach, rather than simply recognizing the term “change feed.”

Go to the AI-200 Exam Prep Hub main page