ExamFinch.com My Study

Study guide

5.2 Change Feed Processor for New/Updated Items

Practice this exam

Exam AI-200: Developing AI Cloud Solutions on Azure Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Audience Profile & Study Path

2 Chapter 1: Container Registry & App Service Hosting

1.1 ACR: Build, Store, Version & Manage Images 1.2 ACR Tasks: Build & Run Images 1.3 Deploy Containers to Azure App Service

3 Chapter 2: Azure Container Apps & KEDA Scaling

2.1 Azure Container Apps: Environments, Config & Revisions 2.2 KEDA Event-Driven Scaling in Container Apps

4 Chapter 3: AKS Manifests & Container Troubleshooting

3.1 Deploy & Manage Apps on AKS with Manifests 3.2 Monitor & Troubleshoot AKS and Container Apps

5 Chapter 4: Cosmos DB for NoSQL Fundamentals

4.1 Cosmos DB for NoSQL: SDK Connect & Queries 4.2 Optimize RUs: Indexing Policies & Consistency Levels

6 Chapter 5: Cosmos DB Vectors & Change Feed

5.1 Embeddings & Vector Similarity Search in Cosmos DB 5.2 Change Feed Processor for New/Updated Items

7 Chapter 6: Azure PostgreSQL Foundations for AI

6.1 Azure Database for PostgreSQL: Connect & Query with SDKs 6.2 Schema Design, Data Types & Indexing Strategies 6.3 pgvector Indexing: Latency & Compute Overhead

8 Chapter 7: PostgreSQL Vector Workloads & RAG

7.1 Configure Compute, Memory & Storage for Vector Workloads 7.2 Vector Search, Semantic Retrieval & RAG with Metadata Filters 7.3 Connection Optimization for Throughput & Latency

9 Chapter 8: Azure Managed Redis for AI Solutions

8.1 Azure Managed Redis: Caching, Expiration & Invalidation 8.2 Redis Vector Indexing for Similarity Search

10 Chapter 9: Service Bus & Event Grid for AI Pipelines

9.1 Service Bus Queues & Message Processing 9.2 Topics, Subscriptions & Dead-Letter Queues 9.3 Event Grid: Custom Events & Filters 9.4 Event Grid Retries & Event-Driven Workflows

11 Chapter 10: Azure Functions for Serverless AI Back Ends

10.1 Azure Functions: Triggers & Bindings 10.2 Build Serverless APIs with Functions 10.3 Configure & Deploy Function Apps

12 Chapter 11: Key Vault & App Configuration

11.1 Azure Key Vault: Secret Storage & Retrieval 11.2 Key Vault Secret Rotation Patterns 11.3 Azure App Configuration for App Settings

13 Chapter 12: OpenTelemetry & KQL Observability

12.1 Distributed Tracing with OpenTelemetry SDKs 12.2 Correlating Traces into Azure Monitoring 12.3 Write KQL Queries to Analyze Logs 12.4 KQL for Metrics & Troubleshooting Scenarios

5.2 Change Feed Processor for New/Updated Items

Key Takeaways Explain This Topic AI

The Azure Cosmos DB change feed exposes inserts and updates on a container in near real time for downstream processors

The change feed processor (push model) uses a lease container to checkpoint progress and distribute work across worker instances

Push mode automates polling, lease ownership, retries, and scale-out; pull mode requires the client to manage continuation tokens and pacing

AI pipelines commonly fan out change feed events to embed text, refresh vector fields, update search indexes, and trigger notifications

Separate deployment units that share a lease container must use distinct lease prefixes so processors do not steal each other’s leases

Last updated: July 2026

Change Feed as the AI Ingest Nervous System

Operational AI systems rarely load a static corpus once. Support articles, product catalogs, chat transcripts, and IoT telemetry keep changing. Azure Cosmos DB change feed gives you an ordered, per-partition log of inserts and updates so downstream code can react without scanning the whole container.

For AI-200, connect change feed to the vector story from the previous section: when an item is written or updated, a processor can call an embedding model, write contentVector back to the item (or to a derived container), and make that content immediately available to DiskANN similarity search. The same feed can fan out to Azure Functions, Azure Service Bus, Azure AI Search indexers, logging, or evaluation pipelines.

The change feed is not a full transaction log of every property-level audit event in all modes, and classic latest-version processing focuses on the current item shape after writes. Know that deletes and “all versions” behaviors depend on which change feed mode you enable; exam scenarios for AI ingest usually emphasize detecting new or updated items and running asynchronous work.

Push Model: Change Feed Processor

Microsoft generally recommends the change feed processor (often called the push model ) when you want continuous processing. Your code registers a delegate that receives batches of changes. The library handles:

  • Polling for new changes on an interval you configure
  • Persisting checkpoints so a restart resumes correctly
  • Distributing partitions/leases across multiple worker instances
  • Retrying transient failures according to processor behavior
  • Core Components
  • Component Role
  • Monitored container Source of inserts/updates; this is the feed you watch
  • Lease container Separate container that stores lease documents (checkpoints and ownership) for coordination

Processor / deployment unit name Logical name for a processing pipeline; workers that share it cooperate on the same feed

  • Instance name Unique name per running host so lease ownership can be tracked
  • HandleChanges delegate Your business logic per batch (embed, enrich, publish, etc.)

The lease container can live in the same Cosmos DB account as the monitored container or in another account. Each lease tracks progress for a portion of the feed. At any moment, a given lease is owned by at most one instance. If you run more instances than leases, extras sit idle until work is redistributed. If an instance dies, another instance can take over its leases after the lease expires or is released.

Lifecycle Sketch

Create the lease container (often with /id as partition key) if it does not exist.

Build the processor against the monitored container: set instance name, lease container, optional start time or “from beginning,” and the change handler.

Start the processor; it acquires leases and begins invoking your handler.

On success, the library checkpoints so those changes are not redelivered indefinitely under normal processing.

Scale out by adding instances with the same processor name and lease container; the library rebalances leases.

Start position matters only before leases are initialized. Options such as starting from the beginning of the container’s lifetime or from a timestamp apply when the lease set is first created. After leases exist, changing those start options typically has no effect—progress is driven by lease checkpoints.

Azure Functions Integration

A common exam-friendly pattern is the Cosmos DB trigger for Azure Functions. The trigger is built on change feed processor concepts: you point at a monitored collection/container and a lease collection. Each function invocation receives new or updated documents. That is an ideal place to:

  • Generate embeddings and patch vectors
  • Write enrichment fields
  • Send messages for further fan-out

Keep functions idempotent where possible. At-least-once delivery semantics mean a batch might be retried after a crash; embedding the same text twice should yield a safe upsert, not duplicate side effects without keys.

Pull Model Versus Push Model

The pull model lets your client request change feed pages explicitly using continuation tokens and feed ranges. You control pace, parallelism, and persistence of bookmarks yourself.

Concern Change feed processor (push) Pull model

Checkpoint storage Lease container managed for you Continuation token you store (memory, blob, another container)

  • Polling for new changes Automatic ( WithPollInterval / library polling) Manual—you must request again
  • Idle behavior Waits and rechecks You decide when to poll
  • Multi-instance load balancing Built-in via leases You design distribution across feed ranges
  • Error handling Library-oriented retries and continuation You implement retry and bookmark logic

Typical recommendation Default for continuous processors Specialized control, custom schedulers, or constrained environments

You cannot convert a pull continuation token into a lease document or vice versa. Pick a model and stay consistent for that pipeline.

Use pull when you must tightly control batch size and schedule (for example a nightly job that drains changes into a training set) or when you need fine-grained feed-range reads. Use push / change feed processor for always-on AI enrichment workers.

AI Pipeline Fan-Out Use Cases

Change feed shines when one write should trigger multiple asynchronous AI-related actions without slowing the API that inserted the item.

1. Embedding and Vector Upsert

Handler reads content from each new/updated item → calls Azure OpenAI embeddings → upserts contentVector (and maybe embeddedAt ). DiskANN indexes pick up the vector for later VectorDistance queries. This keeps write latency low for clients while search quality stays current.

2. Secondary Index / Search Projection

Fan out to Azure AI Search or another read-optimized store when you need hybrid ranking features beyond what the current Cosmos query surface provides. The change feed item is the source of truth event.

3. Evaluation, Safety, and Telemetry

Push changed content to content-safety screening, quality evaluation queues, or analytics. Failures in those branches should not corrupt lease progress for the primary embedding path—often solved with separate processors (different processor names / lease prefixes) so one pipeline’s poison message does not block another.

4. Notification and Orchestration

Publish to Service Bus or Event Grid so multi-step orchestrations (chunking → embed → evaluate → notify) run as independent consumers. Cosmos DB remains the system of record; the feed is the trigger.

Lease Prefixes for Parallel Pipelines

If two deployment units share one lease container, assign each a distinct lease prefix . Without that separation, processors can interfere by competing for the same lease documents. Separate lease containers also work and are easier to reason about in many designs.

Design and Exam Pitfalls

Hot partitions in the monitored container still affect how quickly changes appear per partition; fix partition key design rather than only adding workers.

Handler time budgets : long embedding calls may need concurrency limits, batching, or queue offload so lease processing stays healthy.

Exactly-once illusions : design upserts and downstream writes to tolerate duplicates.

Estimators : change feed estimator APIs help measure lag (how far behind processors are)—useful operationally when RU throttling or slow embedding endpoints cause backlog.

Security : processors need least-privilege access to monitored and lease containers plus whatever embedding or messaging endpoints they call; store secrets in Key Vault or managed identity patterns.

Putting It Together With Vector Search

A complete Cosmos-centric RAG ingest path for the exam:

App upserts chunk documents into the monitored container (text + metadata, vector optional at first).

Change feed processor (push) leases partitions and receives new/updated items.

Worker embeds text and writes vectors under the policy path; DiskANN maintains ANN searchability.

Query path embeds the user question and runs filtered VectorDistance top-k retrieval.

Optional second processor with another lease prefix fans out to audit or search projection without blocking embeddings.

If a question asks how to detect new or updated Cosmos DB items and run AI enrichment at scale with automatic checkpointing, the answer centers on the change feed processor , a lease container , and often an Azure Functions Cosmos DB trigger . If it stresses manual pacing and continuation tokens, look for the pull model .