DP-420 (Building AI Applications with Azure Cosmos DB) scenarios describe a job — distribute writes evenly, return the most relevant chunks for a prompt, keep a conversation's history, restore to an exact second — and ask which mechanism does it. This sheet is organized the same way: by task, not by domain, so you can jump straight to the thing you're trying to do.
What changed on October 6, 2026
- New name and level: the exam is now "Building AI Applications with Azure Cosmos DB" and leads to Microsoft Certified: Azure Cosmos DB AI Developer Associate. It replaces the Azure Cosmos DB Developer Specialty and the old "Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB" title.
- Removed: server-side JavaScript (stored procedures, triggers, UDFs), data movement (Azure Data Factory, Kafka, Stream Analytics), the DevOps process (ARM templates), Azure Synapse Link and the analytical store, and "implement solutions across services."
- Added: vector, full-text and hybrid search, sharded DiskANN, RAG, agent memory stores, Fabric mirroring and querying, Agent Kit, Fleets, dynamic data masking, copy container jobs, and all versions and deletes change feed.
Exam Snapshot
Passing Score
700 / 1000
Level
Associate
Renewal
Every 12 months, free
Design and develop database solutions
40–45%
Secure, optimize, and deploy database solutions
30–35%
Implement AI and analytics capabilities
20–25%
Weightings from Microsoft's official DP-420 study guide, skills measured as of October 6, 2026 (checked October 2, 2026). Microsoft does not publish an exact question count, duration, or price for this exam in the study guide — confirm those at registration.
1. Choose a Partition Key
| If the workload looks like | Use as partition key |
|---|---|
| Multi-tenant, one tenant much larger than others | tenantId + a hierarchical (subpartitioned) second key |
| Uniform devices, moderate per-device volume | deviceId alone |
| High-volume time-series queried by entity + date range | Synthetic key: entityId_date |
| Read-heavy catalog, queries mostly by category | categoryId |
| Maximum write distribution, queries always include the key | Random GUID per document |
| Chat or agent memory, most queries target one conversation | threadId (or tenantId + threadId as a hierarchical key for multi-tenant apps) |
Cost signal: a query without a partition key filter is cross-partition and fans out to every physical partition — always cite the missing filter, not just "the query is slow," when a scenario points at partition key design.
2. Choose a Consistency Level
| Level | Guarantee | Tradeoff |
|---|---|---|
| Strong | Reads always see the latest committed write | Highest latency, lowest availability during failover |
| Bounded Staleness | Reads lag writes by a fixed number of versions or time | Predictable staleness window, still higher latency than Session |
| Session (default) | Read-your-own-writes and monotonic reads within one session | No such guarantee across different sessions |
| Consistent Prefix | Reads never see writes out of order | Can still be stale, just never reordered |
| Eventual | Replicas converge eventually | Lowest latency and RU cost, weakest guarantee, no read-your-own-writes |
A request can override the account's default with a weaker level per-request, but never a stronger one.
Test the tables you just reviewed
Put These Tables to the Test
Scenario questions with full rationale for every option, not just the correct one.
Start Free Practice →3. Configure the SDK Client and Database Operations
| Mode | When to use |
|---|---|
| Direct | Lowest latency; client connects straight to backend replicas over TCP. Default for most SDKs. |
| Gateway | Networks that only allow HTTPS, or where TCP ports are blocked; adds a proxy hop. |
| Task | Operation |
|---|---|
| All-or-nothing writes to several items with the same partition key | Transactional batch (up to 100 operations, 2 MB payload); if one fails, the whole batch rolls back |
| Large parallel load of independent items | SDK bulk support |
| Change one property without resending the whole item | Patch operation |
| Expire items automatically | Time to Live (TTL) on the container, optionally overridden per item |
SDK client checklist
Client instance: create once per application (singleton) — a new client per request exhausts connections.
429 (Too Many Requests): the SDK retries automatically by default; scenarios about handling 429 are testing whether you know to respect Retry-After, not write custom retry loops.
Continuation tokens: use for resumable paging across query results.
ETags: use for optimistic concurrency — a write only succeeds if the ETag still matches.
Parameterized queries: pass user input as parameters, never by string concatenation.
4. Optimize RU Cost and Indexing
| Goal | Mechanism |
|---|---|
| Cut write RU cost of an unindexed/unused field | Exclude the path in a custom indexing policy |
| Speed up ORDER BY on multiple properties | Composite index covering those properties |
| Cheapest way to fetch one known item | Point read (id + partition key), not a query |
| Reduce repeat-read RU cost of hot items | Enable the integrated cache |
| See exactly what an operation cost | Read the request charge from the SDK response / query metrics |
| Find slow or expensive requests after the fact | Diagnostic logs in Log Analytics; Azure Monitor alerts for thresholds |
5. Wire Up Change Feed
| Task | Approach |
|---|---|
| React to every insert/update without polling | Azure Functions trigger bound to the container's change feed |
| Denormalize data into a second container | Change feed → Function writes the derived document |
| Automatic load distribution across instances with checkpointing | Change feed processor (.NET and Java), which stores its state in a lease container |
| Control the pace yourself and save your own position | Change feed pull model with continuation tokens (available in all four main SDKs) |
| Size how many processor instances you need | Change feed estimator |
Change feed modes
| Need | Latest version mode | All versions and deletes mode |
|---|---|---|
| Operations captured | Creates and updates, latest version only | Creates, updates and deletes, every intermediate version, including TTL expirations |
| Capture deletes | Only via a soft-delete flag plus TTL | Yes, with metadata showing the operation type |
| Start point | Beginning, a point in time, now, or a checkpoint | Now or a checkpoint only, within the continuous backup retention window |
| Prerequisite | On by default | Continuous backup on the account, then enable the feature (NoSQL API only) |
All versions and deletes requests always go through Gateway mode, regardless of the connection mode the client is configured with.
6. Copy a Container
Container copy jobs (preview, created with the portal or az cosmosdb copy create) copy all items from one container to another. Use them to change a container's partition key, update unique keys, rename a container or database, switch throughput between database and container level, or adopt features that only work on new containers, such as hierarchical partition keys.
| Mode | How it works |
|---|---|
| Offline (default) | Stop writes to the source first; updates made during the job might not be captured |
| Online | Source needs continuous backup and all versions and deletes change feed; incremental changes keep replicating until you stop source writes and call complete |
Create the target container with the settings you want (partition key, throughput, unique keys) before you start the job. Microsoft recommends target throughput of at least twice the source's.
7. Configure Backup, Multi-Region and Failover
| Mode | Restore granularity |
|---|---|
| Periodic | Only to the fixed backup interval that was captured |
| Continuous (7-day or 30-day) + point-in-time restore | Any specific second within the retention window |
| Requirement | Configure |
|---|---|
| Active-active writes in several regions | Multi-region writes (plan for conflict resolution) |
| Single write region, but fast automatic recovery when only part of a region fails | Per-partition automatic failover (PPAF): only the affected partitions move to the next region; NoSQL API, at least one read region, not Bounded Staleness |
| Watch which region each partition is writing to | The PartitionWriteGlobalStatus metric in Azure Monitor |
| Planned move of the write region while all regions are healthy | Change write region (no data loss) |
A restore always creates a new account or container — it does not overwrite the source in place.
8. Secure Data and Mask Sensitive Fields
| Requirement | Configure |
|---|---|
| Manage the account/database/container resources themselves | Control plane RBAC (Azure RBAC roles) |
| Read/write data, revocable per identity, no account keys | Data plane RBAC via Microsoft Entra ID |
| Restrict network access to specific VNets/IPs | Firewall / virtual network rules, or a private endpoint |
| Control who manages the encryption key itself | Customer-managed keys in Azure Key Vault (vs. platform-managed) |
| Hide sensitive fields from some readers without changing stored data | Dynamic data masking: a masking policy per container, plus the unmask data action for privileged users |
Dynamic data masking quick facts
| Strategy | Result |
|---|---|
| Default | Strings become XXXX, numbers become 0, booleans become false |
| MaskSubstring(Start, Length) | Masks part of a string, for example Washington → WasXXXXXon |
| Keeps the first letter and the domain ending, for example aXXXX@XXXXXXXXX.com |
Enable once: turned on in the account's Features page and can't be turned off afterward.
Identity: requires Microsoft Entra ID; account keys aren't supported.
Who sees real values: built-in Data Contributor includes unmask; Data Reader doesn't.
Reads only: masking applies to read and query results; writes act on unmasked data.
9. Implement Vector Search
| Task | Mechanism |
|---|---|
| Turn the feature on for the account | Features → Vector Search for NoSQL API, or the EnableNoSQLVectorSearch capability in Azure CLI |
| Tell the engine where vectors live and how to compare them | Container vector embedding policy (vectorEmbeddings): path, dataType (float32, float16, int8, uint8), dimensions (default 1536), distanceFunction (cosine default, dotproduct, euclidean) |
| Make vector queries faster and cheaper | vectorIndexes entry in the indexing policy, and exclude the vector path from the regular index |
| Run a similarity query | SELECT TOP N … ORDER BY VectorDistance(c.embedding, @queryVector) — always include TOP N |
| Cut vector storage roughly in half | float16 instead of float32 (some loss of accuracy possible) |
| Raise DiskANN recall for one query | Increase searchListSizeMultiplier in the VectorDistance options (more latency and RUs) |
| Keep each tenant's vector search inside that tenant's own index | Sharded DiskANN: set vectorIndexShardKey (for example ["/tenantId"]) on the diskANN index, then filter on that property in WHERE |
Vector index types
| Type | Search | Max dimensions | Pick it when |
|---|---|---|---|
| flat | Exact (brute force), 100% recall | 505 | You need exact results and vectors are small |
| quantizedFlat | Brute force over compressed vectors, slightly under 100% | 4,096 | The search is scoped to about 50,000 vectors or fewer (often via filters) |
| diskANN | Approximate nearest neighbor | 4,096 | The search spans more than 50,000 vectors; lowest latency and RU cost at scale |
Watch for: quantizedFlat and diskANN need at least 1,000 vectors indexed; below that, the query falls back to a full scan and costs more RUs. diskANN results can vary slightly between runs because the search is approximate.
10. Implement Full-Text and Hybrid Search
| Task | Mechanism |
|---|---|
| Declare which properties hold searchable text | Container full-text policy: defaultLanguage plus fullTextPaths (path and language for each) |
| Keep full-text queries cheap | fullTextIndexes entry in the indexing policy (queries run without it but cost more RUs) |
| Filter to items containing a phrase | FullTextContains in WHERE |
| Require all keywords, or any keyword | FullTextContainsAll / FullTextContainsAny |
| Rank by keyword relevance (BM25) | ORDER BY RANK FullTextScore(…) — it can't be projected in SELECT or used in WHERE |
| Tolerate typos | Fuzzy search: pass a term with a distance in FullTextContains (maximum distance 2) |
| Combine semantic and keyword results in one ranking | Hybrid search: ORDER BY RANK RRF(VectorDistance(…), FullTextScore(…)) |
| Make vector results count more than keyword results | Add a weights array as the last RRF argument, for example [2, 1] |
Hybrid search needs both sides configured on the container: a vector policy and vector index, plus a full-text policy and full-text index.
11. Build RAG and Agent Memory
| Task | Approach |
|---|---|
| Ground an LLM's answer in your own data (RAG) | Store chunks and their embeddings in the same items, retrieve the top matches with vector or hybrid search, then pass them to the model as context |
| Store chat history (recommended model) | One document per turn: the user prompt and agent reply (or tool call and result) together, with threadId and turnIndex |
| Fetch the last N turns of a conversation | SELECT TOP @k … WHERE c.threadId = @threadId ORDER BY c.timestamp DESC |
| Recall relevant memories even without shared words (semantic memory) | Embedding per turn plus VectorDistance, filtered to the thread or tenant |
| Let short-term memory expire | TTL on turn items; summarize important threads into long-term memory first |
| Avoid this model | One item per whole thread: long threads make every append an expensive update |
Agent Kit: the Azure Cosmos DB Agent Kit is an open-source set of skills (installed with npx skills add AzureCosmosDB/cosmosdb-agent-kit) that teaches AI coding assistants such as GitHub Copilot Cosmos DB best practices for data modeling, partition keys, queries, SDK use, and vector and full-text search. It gives guidance only and doesn't run operations against your database.
12. Analyze Data in Microsoft Fabric
| Task | Approach |
|---|---|
| Analytics on an existing Azure Cosmos DB account with no ETL and no RU impact | Mirror the database into Fabric OneLake (Delta format, near real time) |
| New Fabric-native app that needs operational data analytics-ready by default | Cosmos DB in Microsoft Fabric: every database is mirrored to OneLake automatically, no setup needed |
| Prerequisite for mirroring | Continuous backup on the source account (7-day tier is free); NoSQL API only; multi-region write accounts aren't supported |
| Query mirrored data with T-SQL | The mirrored database's SQL analytics endpoint; expand nested JSON with OPENJSON and CROSS APPLY |
| Query mirrored data with Spark | Add a OneLake shortcut in a lakehouse, then query it from a notebook |
| Write analytical results back for the app to serve | Azure Cosmos DB Spark connector (format cosmos.oltp) — these writes do consume RUs |
Mirroring doesn't use the analytical store, Azure Synapse Link or the change feed. Accounts with dynamic data masking need Microsoft Support to enable mirroring.
13. Manage Many Accounts with Fleets
A fleet groups many database accounts, typically one per B2B tenant, across subscriptions and resource groups. Each account belongs to a fleetspace.
| Task | Mechanism |
|---|---|
| Let spiky tenants borrow throughput instead of overprovisioning each one | Throughput pool on the fleetspace; dedicated RU/s are used first, then the pool |
| Size the pool | Minimum at least 100,000 RU/s in multiples of 1,000; maximum up to 10 times the minimum |
| Accounts that can share one pool | Same regions and same service tier (single-region write General Purpose vs multi-region write Business Critical) |
| Per-partition ceiling (default) | Up to 5,000 extra RU/s from the pool, and no more than 10,000 RU/s total per physical partition |
| Track usage and cost trends across every account | Fleet analytics (preview): hourly Delta tables in a Fabric workspace or ADLS Gen2 |
Fleet analytics only writes data after you grant the Cosmos DB Fleet Analytics service principal access to the destination (Contributor on the Fabric workspace, or Storage Blob Contributor on the storage account).
14. If the Question Says X, Think Y
| "Must always see my own prior writes" | Session consistency |
| "React to every insert without polling" | Change feed |
| "Also capture deletes and every intermediate change" | All versions and deletes change feed mode |
| "Restore to an exact second" | Continuous backup + point-in-time restore |
| "Never hold an account key" | Data plane RBAC with Microsoft Entra ID |
| "All-or-nothing across three related items, same partition" | Transactional batch |
| "Large parallel load of independent items" | SDK bulk support |
| "One tenant is hotter than the rest" | Hierarchical (subpartitioned) partition key |
| "Change the partition key of a live container" | Container copy job to a new container |
| "Exact nearest neighbors, 100% recall" | flat vector index |
| "Millions of embeddings, lowest latency and RU cost" | diskANN vector index |
| "Combine keyword matches with semantic similarity" | Hybrid search with RRF |
| "Support agents see partial card or email values only" | Dynamic data masking |
| "Power BI and T-SQL over operational data without consuming RUs" | Fabric mirroring |
| "Hundreds of tenant accounts, share spare throughput" | Fleet with a throughput pool |
15. Acronym Quick List
RU — Request Unit
TTL — Time To Live
PITR — Point-In-Time Restore
RBAC — Role-Based Access Control
SDK — Software Development Kit
CMK — Customer-Managed Key
HPK — Hierarchical Partition Key
ETag — Entity Tag (optimistic concurrency)
VNet — Virtual Network
RAG — Retrieval-Augmented Generation
ANN — Approximate Nearest Neighbor
BM25 — Best Matching 25 (full-text scoring)
RRF — Reciprocal Rank Fusion
DDM — Dynamic Data Masking
PPAF — Per-Partition Automatic Failover
Reviewed every task? Now test it under pressure.
Take the free 5-minute DP-420 readiness quiz — no signup required — or jump into 40 free practice questions.
Common Questions
What changed in DP-420 on October 6, 2026?
The exam became "Building AI Applications with Azure Cosmos DB" and now leads to the Microsoft Certified: Azure Cosmos DB AI Developer Associate certification instead of the Developer Specialty. Server-side JavaScript, data movement, DevOps and Synapse Link were removed; vector, full-text and hybrid search, RAG, agent memory, Fabric mirroring, Fleets, dynamic data masking, copy jobs and all versions and deletes change feed were added.
Is this cheat sheet enough on its own to pass DP-420?
No — treat it as a final-week review, not a first pass. DP-420 scenarios describe a workload and ask which mechanism fits; this sheet maps tasks to mechanisms fast, but building the judgment to spot the right task from a paragraph of scenario text takes practice questions and hands-on SDK time first.
What is the single most repeated question shape on DP-420?
"Given this workload description, which partition key / consistency level / vector index / backup mode fits?" — a decision between two or three plausible-sounding mechanisms, not a request for a definition.
Which vector index type should I choose?
Use flat when you need exact results and vectors have 505 dimensions or fewer. Use quantizedFlat when the search is scoped to roughly 50,000 vectors or fewer. Use diskANN when the search spans more than that and you want the lowest latency and RU cost. quantizedFlat and diskANN support up to 4,096 dimensions.
What is the difference between control plane and data plane RBAC?
Control plane RBAC governs managing the Cosmos DB account, database, and container resources themselves (create, delete, scale). Data plane RBAC governs reading and writing the actual data inside containers, and can be granted without ever exposing an account key.
What is the passing score for DP-420?
700 out of 1000, per Microsoft's official DP-420 study guide. The study guide doesn't list an exact question count, exam duration, or price — confirm those when you register.
About This Cheat Sheet
MSCertQuiz sells a 500-question DP-420 practice bank and the same team wrote this reference from Microsoft's official DP-420 study guide and Azure Cosmos DB documentation, checked October 2, 2026 against the skills measured as of October 6, 2026.