DP-420 (Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB) scenarios describe a job — distribute writes evenly, keep read latency low, react to every insert, 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.
Exam Snapshot
Passing Score
700 / 1000
Level
Specialty (Intermediate)
Renewal
Every 12 months, free
Data Models
35–40%
Distribution
5–10%
Integration
5–10%
Optimization
15–20%
Maintenance
25–30%
Weightings from Microsoft's official DP-420 study guide, skills measured as of July 21, 2026 (checked September 7, 2026). Microsoft does not publish an exact question count, duration, or price for this exam on its public pages — 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 |
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 Connectivity and the SDK Client
| 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. |
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.
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 |
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 |
| Archive old data out of the hot container | Change Feed → Function writes to cold storage, then deletes/expires the source |
| Size how many processor instances you need | Change feed estimator |
6. Configure Backup and Restore
| Mode | Restore granularity |
|---|---|
| Periodic | Only to the fixed backup interval that was captured |
| Continuous + point-in-time restore | Any specific second within the retention window |
A restore always creates a new account or container — it does not overwrite the source in place.
7. Secure Data and Control-Plane Access
| 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) |
8. If the Question Says X, Think Y
| "Must always see my own prior writes" | Session consistency |
| "React to every insert without polling" | Change Feed |
| "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" | Stored procedure transaction |
| "Large parallel load of independent items" | SDK Bulk Support |
| "One tenant is hotter than the rest" | Hierarchical (subpartitioned) partition key |
| "Query data lake files without loading them first" | Analytical store + Synapse/Fabric query |
9. 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
ARM — Azure Resource Manager
CORS — Cross-Origin Resource Sharing
ETag — Entity Tag (optimistic concurrency)
VNet — Virtual Network
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
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 / backup mode fits?" — a decision between two or three plausible-sounding mechanisms, not a request for a definition.
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. Microsoft does not publish an exact question count, exam duration, or price for this exam on its public pages — confirm those when you register.
Do I need to memorize every consistency level's exact staleness math?
You need to match a scenario's requirement (own-writes visibility, ordering, latency tolerance) to the right level, not compute staleness bounds by hand. Know the five levels' guarantees and tradeoffs from the table above, not the underlying replication math.
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 September 7, 2026.