---
title: "DP-420 Study Guide — Microsoft Azure Cosmos DB Developer Specialty"
description: "An interactive study guide built on 7 memory techniques to help you pass the Microsoft Azure Cosmos DB Developer Specialty exam."
url: "https://lucidlabs.com.au/insights/dp-420"
---

# Master the DP-420

An interactive study guide built on 7 memory techniques to help you pass the Microsoft Azure Cosmos DB Developer Specialty exam.

Data Models 35-40%Distribution 5-10%Integration 5-10%Optimisation 15-20%Maintenance 25-30%

What it covers

Cosmos DB NoSQL API, partition key design, indexing policies, consistency levels, change feed, stored procedures/triggers/UDFs in JavaScript, SDK usage (C#/Java), throughput provisioning (RU/s), global distribution, replication, backup/restore, and monitoring.

Ideal for

Application developers and backend engineers who design and build cloud-native applications using Azure Cosmos DB as their primary data store.

Aspire to this if

You build globally distributed, low-latency applications and want to prove your expertise with Cosmos DB’s NoSQL, partitioning, and consistency model.

Section 1 / Spatial Memory

## The Map

Tap any component to see what you need to know for the exam.

**📄 Data Modelling**

Documents · Partitioning · Indexing

**🔍 Indexing Policies**

Range · Spatial · Composite

**⚖️ Consistency Levels**

Strong → Eventual

**⚡ Throughput & RUs**

Provisioned · Autoscale · Serverless

**📜 Server-Side Programming**

Stored Procs · Triggers · UDFs

**🔔 Change Feed**

Event-Driven · Triggers · Materialised Views

**🌐 Global Distribution**

Multi-Region · Failover · Conflict Resolution

**💻 SDK & Queries**

C# · Java · Python · SQL API

**🔒 Security & RBAC**

Keys · Entra ID · Encryption

**📊 Monitoring & Diagnostics**

Metrics · Alerts · Insights

**💾 Backup & Restore**

Continuous · Periodic · Point-in-Time

**🔗 Multi-Model APIs**

MongoDB · Cassandra · Gremlin · Table

Section 2 / Narrative Memory

## The Story

Follow the narrative to build a mental model of how everything connects.

🌌

### The Cosmos Awakens

In a world where data must be everywhere at once, Azure Cosmos DB emerges as a globally distributed, multi-model database. It promises single-digit millisecond reads, five tuneable consistency levels, and turnkey global replication. But its power demands understanding — starting with how data is modelled.

**Exam Intel**Cosmos DB is a foundational PaaS NoSQL database. Know the five APIs (NoSQL, MongoDB, Cassandra, Gremlin, Table) but focus on the NoSQL (SQL) API — it is the primary exam target. Understand the resource hierarchy: Account → Database → Container → Item.

🗝️

### The Partition Key Decision

Every container must declare a partition key — the single most critical design choice. A good partition key distributes data and queries evenly across logical partitions, avoiding hot spots. It cannot be changed after creation, making upfront analysis essential.

**Exam Intel**Ideal partition key: high cardinality, even distribution, used in most WHERE clauses. A logical partition can hold up to 20 GB. Cross-partition queries fan out to all physical partitions — expensive. Hierarchical partition keys allow compound keys (e.g., /tenantId + /userId).

📐

### Modelling for NoSQL

Unlike relational databases, Cosmos DB rewards denormalisation. Related data is embedded in a single document for fast reads. References are used only when data changes independently or grows unbounded. The goal: minimise the number of requests per user operation.

**Exam Intel**Embed when: 1:1 or 1:few, data read together, bounded growth. Reference when: 1:many unbounded, many:many, or data changes independently. Use the change feed to maintain denormalised copies. Know the trade-off: embedding = fewer reads but larger documents; referencing = more reads but smaller documents.

⚖️

### The Consistency Spectrum

Cosmos DB offers five consistency levels on a spectrum from strong (linearisable, highest cost) to eventual (fastest, lowest cost). Session consistency — the default — guarantees read-your-own-writes and is the sweet spot for most applications.

**Exam Intel**Strong: only available with single-region writes. Bounded Staleness: reads lag by K versions or T time — use for multi-region with near-strong guarantees. Session: default, cheapest “correct” choice for most apps. Consistent Prefix: no out-of-order reads. Eventual: lowest latency, no ordering guarantee. Each step down the spectrum lowers RU cost and latency.

⚡

### The RU Economy

Every operation in Cosmos DB costs Request Units (RUs). A 1 KB point read costs 1 RU. Writes cost more, queries with cross-partition fan-out cost the most. Choosing the right throughput mode — provisioned, autoscale, or serverless — controls both performance and cost.

**Exam Intel**Point read = 1 RU per 1 KB. Write = ~5-7 RU for 1 KB. Query cost depends on complexity, data scanned, and partitions hit. 429 = throttled (exceeded RU budget). Autoscale: 10%-100% of max RU/s. Serverless: max 5,000 RU/s per container. Database-level shared throughput = max 25 containers.

🌐

### Going Global

Adding a region to Cosmos DB takes one API call. Data replicates transparently, and failover can be automatic or manual. Multi-region writes enable every region to accept writes simultaneously, with Last Writer Wins resolving conflicts by default.

**Exam Intel**Multi-region writes: 99.999% SLA. Single-region writes: 99.99%. Conflict resolution: LWW (default, uses \_ts) or custom (stored procedure). Manual failover: RTO = 0, RPO = 0. Automatic failover: RTO ~minutes. You can override the automatic failover priority list.

🔔

### The Change Feed Pipeline

The change feed captures every insert and update as a persistent, ordered log. Azure Functions can react to changes in near real-time, building materialised views, triggering downstream processing, or synchronising data to other stores — the backbone of event-driven Cosmos DB architectures.

**Exam Intel**Change feed: inserts and updates only (no deletes by default). All-versions-and-deletes mode adds delete capture. Processing: Azure Functions trigger (simplest), change feed processor (SDK, more control), pull model (lowest level). Lease container tracks progress. Change feed preserves order within a logical partition.

📜

### Server-Side Logic

Stored procedures, triggers, and UDFs bring JavaScript execution inside the Cosmos DB engine. Stored procedures provide ACID transactions scoped to a single logical partition — the only way to get multi-document transactions in Cosmos DB. Triggers fire before or after operations, and UDFs extend queries.

**Exam Intel**Stored procedures: only way to get multi-document ACID transactions. Scoped to one partition key value. Written in JavaScript. Bounded execution — must complete within a time limit or all changes roll back. Pre-triggers run before create/replace/delete; post-triggers run after. UDFs are read-only and used in SELECT/WHERE clauses.

🔒

### Securing the Cosmos

Access control starts with authentication — either primary/secondary keys or Microsoft Entra ID with RBAC. Network security layers on IP firewall rules and VNet service endpoints. Data is encrypted at rest and in transit, with customer-managed keys available for additional control.

**Exam Intel**Entra ID RBAC is the recommended approach — supports built-in roles: Cosmos DB Built-in Data Reader, Data Contributor, Account Reader/Contributor. Primary/secondary keys are shared secrets — rotate regularly. Resource tokens provide scoped, time-limited access to specific containers or items. Always Encrypted (client-side) is also supported.

🛠️

### Maintaining the Cosmos

Monitoring RU consumption, detecting hot partitions, and configuring backups keep Cosmos DB healthy. Continuous backup enables point-in-time restore to the second. Azure Monitor and Cosmos DB Insights provide the dashboards, alerts, and diagnostic logs needed to operate at scale.

**Exam Intel**Continuous backup: PITR within 7 or 30 days, restores to a new account. Periodic backup: automatic snapshots, configurable interval and retention. Monitor: normalised RU consumption %, request rate, 429 count, storage, availability. Use diagnostic settings to send logs to Log Analytics for query-level troubleshooting.

Section 3 / Acronym Memory

## Mnemonic Wall

Memorable acronyms and phrases to anchor key exam concepts in your memory.

⚖️

SBSCE

**S**trong, **B**ounded Staleness, **S**ession, **C**onsistent Prefix, **E**ventual

Five consistency levels from strongest to weakest. Session is the default. “Some British Soldiers Carry Extras.”

⚡

PAS

**P**rovisioned, **A**utoscale, **S**erverless

Three throughput modes. Provisioned = fixed RU/s. Autoscale = 10%-100% range. Serverless = pay-per-request.

🗝️

HED

**H**igh cardinality, **E**ven distribution, in every **D**ocument query

Three rules for choosing a partition key. High cardinality avoids hot spots. Even distribution balances storage. Appears in WHERE clauses to avoid cross-partition queries.

📄

NMCGT

**N**oSQL, **M**ongoDB, **C**assandra, **G**remlin, **T**able

Five Cosmos DB APIs. NoSQL is the native/recommended API and the primary exam focus.

🔍

IRSC

**I**nclude/exclude paths, **R**ange indexes, **S**patial indexes, **C**omposite indexes

Indexing policy building blocks. Composite indexes required for multi-property ORDER BY.

📜

SPT-U

**S**tored **P**rocedures, **T**riggers, **U**DFs

Server-side programming in JavaScript. SPs = ACID transactions (single partition). Triggers = pre/post. UDFs = extend queries.

🔔

FPP

**F**unctions trigger, change feed **P**rocessor, **P**ull model

Three ways to consume the change feed. Functions = simplest. Processor = SDK-based. Pull = lowest-level control.

🌐

LWW

**L**ast **W**riter **W**ins

Default conflict resolution for multi-region writes. Uses \_ts (timestamp). Can be overridden with a custom stored procedure.

💾

CP

**C**ontinuous backup, **P**eriodic backup

Two backup modes. Continuous = PITR to the second (7 or 30 days). Periodic = scheduled snapshots. Restore always creates a new account.

🔒

KER

**K**eys, **E**ntra ID RBAC, **R**esource tokens

Three authentication methods. Keys = shared secret (simple). Entra ID = recommended (RBAC). Resource tokens = scoped, time-limited.

📊

RU-429

**R**equest **U**nits — HTTP **429** = throttled

When RU consumption exceeds provisioned throughput, Cosmos DB returns 429 (Too Many Requests). Monitor normalised RU % to avoid.

📐

ER

**E**mbed vs **R**eference

Core modelling decision. Embed for 1:few, co-read, bounded. Reference for 1:many unbounded, independent updates, many:many.

🚀

DG

**D**irect mode, **G**ateway mode

SDK connection modes. Direct (TCP) = lower latency, production recommended. Gateway (HTTPS) = simpler, good for firewalled environments.

🏗️

ADCI

**A**ccount → **D**atabase → **C**ontainer → **I**tem

Cosmos DB resource hierarchy. Account is top-level. Database groups containers. Container holds items (documents).

💰

1-5-Q

**1** RU point read, **5**\+ RU write, **Q**uery varies

RU cost rules of thumb. Point read (id + PK) = 1 RU/KB. Write = ~5-7 RU/KB. Queries depend on complexity and partitions scanned.

Section 4 / Contrast Memory

## Versus Arena

Side-by-side comparisons to sharpen your understanding of similar concepts.

vs

ProvisionedvsAutoscalevsServerless

Click to compare

#### Throughput Modes Compared

| Aspect | Provisioned | Autoscale | Serverless |
| --- | --- | --- | --- |
| Pricing | Fixed RU/s per hour | Peak RU/s used | Per-request |
| Scaling | Manual (change RU/s) | Auto 10%-100% | Automatic |
| Best for | Steady workloads | Variable | Dev/test, spiky |
| Max RU/s | Unlimited (manual) | Configurable | 5,000/container |
| SLA | Full SLA | Full SLA | No SLA (preview limits) |
| Shared DB | Yes (25 containers) | Yes | No |

Click to flip back

vs

EmbedvsReference

Click to compare

#### Data Modelling Patterns

| Aspect | Embed | Reference |
| --- | --- | --- |
| Read perf | Single read (fast) | Multiple reads (slower) |
| Write perf | Larger doc rewrites | Smaller targeted writes |
| Relationships | 1:1, 1:few, bounded | 1:many, many:many, unbounded |
| Data freshness | Always consistent | May need change feed sync |
| Doc size | Larger documents | Smaller documents |
| Transactions | Same partition (SP) | Eventual consistency |

Click to flip back

vs

Point ReadvsQuery

Click to compare

#### Read Operation Cost

| Aspect | Point Read | Query |
| --- | --- | --- |
| Cost | 1 RU per 1 KB | Varies (can be 10-1000+ RU) |
| Input | id + partition key | SQL-like WHERE clause |
| Partition | Single partition only | Single or cross-partition |
| Index used | No (direct lookup) | Yes (index scan) |
| Best for | Known item retrieval | Search, filtering, aggregation |
| Latency | Lowest possible | Depends on complexity |

Click to flip back

vs

Single-RegionvsMulti-Region Writes

Click to compare

#### Global Distribution Modes

| Aspect | Single-Region | Multi-Region Writes |
| --- | --- | --- |
| Write regions | One (primary) | All regions |
| SLA | 99.99% | 99.999% |
| Conflicts | None (single writer) | LWW or custom resolution |
| Strong consistency | Supported | Not supported |
| Write latency | Local to primary region | Local to any region |
| Cost | Standard RU rate | Higher (replicated writes) |

Click to flip back

vs

ContinuousvsPeriodic Backup

Click to compare

#### Backup Strategies

| Aspect | Continuous | Periodic Backup |
| --- | --- | --- |
| Granularity | Point-in-time (second) | Snapshot intervals |
| Retention | 7 or 30 days | Configurable (2+ copies) |
| Restore scope | Container or database | Full account |
| Target | New account | New account |
| Self-service | Yes (portal/CLI) | Support ticket required |
| Cost | Included + storage | Free (default) |

Click to flip back

vs

Change Feed ProcessorvsAzure Functions

Click to compare

#### Change Feed Consumption

| Aspect | Change Feed Processor | Azure Functions |
| --- | --- | --- |
| Hosting | Self-managed (SDK) | Serverless (managed) |
| Control | Full (batching, errors) | Simplified (auto-scaling) |
| Scaling | Manual partition handling | Automatic |
| Complexity | More code | Less code (binding) |
| Best for | Complex processing | Simple event reactions |
| Lease container | Required | Managed automatically |

Click to flip back

vs

Direct ModevsGateway Mode

Click to compare

#### SDK Connection Modes

| Aspect | Direct Mode | Gateway Mode |
| --- | --- | --- |
| Protocol | TCP (proprietary) | HTTPS |
| Latency | Lower | Higher |
| Connections | Direct to partitions | Via gateway endpoint |
| Firewall | Needs port range open | Only port 443 |
| Default | Yes (.NET, Java) | No (fallback option) |
| Best for | Production workloads | Restricted networks |

Click to flip back

vs

KeysvsEntra ID RBAC

Click to compare

#### Authentication Methods

| Aspect | Keys | Entra ID RBAC |
| --- | --- | --- |
| Type | Shared secret | Identity-based |
| Rotation | Manual (regenerate) | Automatic (token refresh) |
| Granularity | Full account access | Role-based (read/write/admin) |
| Audit | Limited | Full Azure AD audit logs |
| Recommended | Dev/test only | Production (best practice) |
| Setup | Simple (copy key) | More setup (role assignment) |

Click to flip back

Section 5 / Grouping Memory

## Cheat Sheet

Organised reference grouped by exam domain — everything you need on one page.

### Design & Implement Data Models

35-40%

#### Partition Key Design

-   High cardinality — many distinct values
-   Even distribution — balanced storage and RU across partitions
-   Used in WHERE clause of most queries
-   Logical partition limit: 20 GB
-   Cannot change partition key after container creation
-   Hierarchical partition keys: compound keys (e.g., /tenantId + /userId)

#### Data Modelling

-   Embed for 1:1 and 1:few relationships (co-read, bounded)
-   Reference for 1:many unbounded or many:many
-   Denormalise for read performance — accept data duplication
-   Use change feed to sync denormalised copies
-   Max document size: 2 MB
-   Every document needs unique “id” within its logical partition

#### Indexing Policies

-   Default: all properties indexed automatically
-   Exclude unused paths to save write RU cost
-   Composite index: required for ORDER BY on 2+ properties
-   Spatial index: geospatial queries (ST\_DISTANCE, ST\_WITHIN)
-   Indexing mode: Consistent (default) or None
-   Included/excluded paths use /\* and /? wildcard syntax

#### Server-Side Programming

-   Stored procedures: JavaScript, ACID transactions, single partition
-   Pre-triggers: validate or enrich before write
-   Post-triggers: run logic after write (same transaction)
-   UDFs: custom functions in SELECT/WHERE clauses
-   Bounded execution: timeout rolls back all changes

### Design & Implement Data Distribution

5-10%

#### Global Distribution

-   Add/remove regions with zero downtime
-   Multi-region writes: 99.999% availability SLA
-   Single-region writes: 99.99% SLA
-   Automatic failover with configurable priority list
-   Data replicates transparently to all configured regions

#### Conflict Resolution

-   Last Writer Wins (LWW): default, uses \_ts timestamp
-   Custom conflict resolution via stored procedure
-   Conflicts only occur with multi-region writes enabled
-   Strong consistency not supported with multi-region writes

#### Replication & Consistency

-   Consistency can be relaxed per-request (weaker than account default)
-   Session token ensures read-your-own-writes across SDK instances
-   Bounded Staleness: configure K versions or T seconds lag
-   Reads from secondary regions use account-level consistency or weaker

### Integrate a Cosmos DB Solution

5-10%

#### Change Feed

-   Persistent, ordered log of inserts and updates
-   Does not capture deletes by default — use soft-delete
-   All-versions-and-deletes mode for full history
-   Azure Functions trigger: simplest consumption model
-   Change feed processor (SDK): more control, manual hosting
-   Pull model: lowest-level, explicit partition handling

#### Integration Patterns

-   Materialised views via change feed
-   Event sourcing: change feed as event log
-   Synapse Link: no-ETL analytical store (column-oriented)
-   Azure Search: index Cosmos DB data for full-text search
-   Azure Functions bindings: input, output, and trigger

#### SDK Usage

-   CosmosClient → Database → Container → Items
-   Point reads: ReadItemAsync(id, partitionKey) — cheapest operation
-   FeedIterator for paginated query results
-   Bulk execution mode for high-throughput ingestion
-   TransactionalBatch for multi-item ACID in one partition

### Optimise a Cosmos DB Solution

15-20%

#### Throughput Optimisation

-   Provisioned: fixed RU/s, best for steady workloads
-   Autoscale: 10%-100% of max, good for variable traffic
-   Serverless: pay per RU, max 5,000 RU/s per container
-   Database-level throughput shared across up to 25 containers
-   Monitor normalised RU % to detect throttling

#### Query Performance

-   Point reads (id + PK) = 1 RU per 1 KB — always cheapest
-   Avoid cross-partition queries in hot paths
-   Use composite indexes for multi-field ORDER BY
-   Exclude unused paths from indexing to reduce write RU
-   Prefer Direct mode (TCP) over Gateway mode (HTTPS)
-   Use continuation tokens for pagination

#### Cost Management

-   Right-size RU/s based on actual consumption
-   Use reserved capacity (1 or 3 year) for 20-65% savings
-   Reduce document size — smaller docs = fewer RUs
-   TTL (time-to-live): auto-delete expired documents at no extra RU cost
-   Serverless for dev/test to avoid idle RU charges

#### Connection & SDK

-   Direct mode (TCP): lower latency, recommended for production
-   Gateway mode (HTTPS): simpler, for restricted networks
-   Singleton CosmosClient per application lifetime
-   Use regions close to your users (preferred locations)
-   Retry on 429 with SDK built-in retry policy

### Maintain a Cosmos DB Solution

25-30%

#### Monitoring & Diagnostics

-   Azure Monitor metrics: RU consumption, request rate, storage
-   Normalised RU consumption % — alert above 70% threshold
-   Diagnostic logs: query RU charge, latency, partition key stats
-   Cosmos DB Insights workbook for pre-built dashboards
-   Per-partition RU metrics to detect hot partitions

#### Backup & Restore

-   Continuous backup: PITR within 7 or 30 days
-   Periodic backup: automatic snapshots, geo-redundant storage
-   Restore always creates a new account (cannot restore in-place)
-   Continuous supports container-level or database-level restore
-   Self-service restore via portal or CLI (continuous only)

#### Security

-   Microsoft Entra ID RBAC: recommended for production
-   Primary/secondary keys: shared secret, rotate regularly
-   Resource tokens: scoped, time-limited access
-   IP firewall rules and VNet service endpoints
-   Encryption at rest (Microsoft or customer-managed keys)
-   Always Encrypted for client-side encryption

#### Operational Tasks

-   Scale RU/s up/down without downtime
-   Add/remove regions without downtime
-   TTL: set at container level (default) or per-item
-   Key rotation: regenerate primary, switch apps, regenerate secondary
-   Move between throughput modes (provisioned ↔ autoscale)

Section 6 / Method of Loci

## The Memory Palace

Walk through themed rooms — each object anchors a concept in spatial memory.

### The Partition Hall

Data Models — Where the architecture begins

🗝️

Partition Key

High cardinality, even distribution, in WHERE clauses. 20 GB logical partition limit

📄

Embed Pattern

1:1 and 1:few relationships. Co-read data. Bounded arrays. Single document reads

🔗

Reference Pattern

1:many unbounded, many:many. Separate documents. Change feed for sync

🔍

Indexing Policy

Auto-indexed by default. Exclude unused paths. Composite for multi-field ORDER BY

🏗️

Resource Hierarchy

Account → Database → Container → Item. Container = unit of scale

📜

Stored Procedures

JavaScript ACID transactions. Single partition scope. Bounded execution with rollback

### The Consistency Chamber

Distribution — Where trade-offs are made

⚖️

Strong Consistency

Linearisable reads. Highest RU cost. Single-region writes only

📏

Bounded Staleness

Lag by K versions or T seconds. Near-strong for multi-region scenarios

🎯

Session Consistency

Default. Read-your-own-writes. Most popular. Best cost/correctness balance

➡️

Consistent Prefix

No out-of-order reads. Guaranteed ordering. Lower cost than Session

🌊

Eventual Consistency

Lowest latency, lowest RU cost. No ordering guarantees. Maximum availability

🌐

Global Replication

Add regions with zero downtime. Multi-region writes = 99.999% SLA

### The Integration Engine Room

Integration — Where change flows

🔔

Change Feed

Ordered log of inserts/updates. No deletes by default. Partition-ordered

⚡

Azure Functions Trigger

Simplest change feed consumer. Auto-scaling. Lease container managed

⚙️

Change Feed Processor

SDK-based. Full control over batching and error handling. Self-hosted

🔬

Synapse Link

No-ETL analytical store. Column-oriented copy. Near real-time sync

💻

SDK Client

CosmosClient singleton. Direct mode for production. FeedIterator for queries

📦

TransactionalBatch

Multi-item ACID operations within a single partition. SDK-level transactions

### The RU Treasury

Optimisation — Where every RU counts

🎯

Point Reads

id + partition key = 1 RU per 1 KB. Always the cheapest operation

💰

RU Budgeting

Write = ~5-7 RU/KB. Cross-partition query = expensive. Monitor 429 responses

🔄

Autoscale

10%-100% of max RU/s. Good for variable workloads. No manual intervention

⏰

TTL

Auto-delete expired docs. No extra RU cost. Set per container or per item

📉

Reserved Capacity

1 or 3 year commitment. 20-65% savings over pay-as-you-go

🚀

Direct Mode

TCP connection to partitions. Lower latency. Production recommended

### The Operations Vault

Maintenance — Where reliability is ensured

📊

Azure Monitor

RU consumption %, request rate, storage, latency percentiles, 429 alerts

💾

Continuous Backup

PITR to the second. 7 or 30 day retention. Self-service restore

📸

Periodic Backup

Automatic snapshots. Geo-redundant storage. Support ticket to restore

🔒

Entra ID RBAC

Recommended auth. Built-in data roles. Full audit logging

🔑

Key Rotation

Regenerate primary → switch apps → regenerate secondary. Zero downtime pattern

🛡️

Network Security

IP firewall rules. VNet service endpoints. Private endpoints for isolation

Section 7 / Pattern Recognition

## Pattern Spotter

Decision trees and trigger-answer pairs — see the pattern, know the answer.

Which Throughput Mode?

Which Throughput Mode?  
  ├── Steady, predictable workload → Provisioned throughput (manual RU/s)  ├── Variable traffic with spikes → Autoscale (10%-100% of max)  ├── Dev/test or low-traffic spiky → Serverless (pay per request)  ├── Multiple containers sharing RUs → Database-level throughput (max 25 containers)  └── Cost savings on committed workloads → Reserved capacity (1 or 3 year)

Which Consistency Level?

Which Consistency Level?  
  ├── Single-region, must read latest write → Strong  ├── Multi-region, near-strong guarantees → Bounded Staleness  ├── Most apps, read-your-own-writes → Session (default, recommended)  ├── Need ordering, not latest → Consistent Prefix  └── Maximum throughput, no ordering needed → Eventual

Which Cosmos DB API?

Which Cosmos DB API?  
  ├── New app, JSON documents → NoSQL API (recommended)  ├── Migrating from MongoDB → MongoDB API  ├── Wide-column / Cassandra workload → Cassandra API  ├── Graph / relationship-heavy data → Gremlin API  └── Migrating from Azure Table Storage → Table API

How to Consume Change Feed?

How to Consume Change Feed?  
  ├── Simple event reaction, minimal code → Azure Functions trigger  ├── Complex processing, custom batching → Change feed processor (SDK)  ├── Lowest-level control, pull-based → Pull model  ├── Need to capture deletes → All-versions-and-deletes mode  └── Analytics on operational data → Synapse Link (analytical store)

Which Backup Mode?

Which Backup Mode?  
  ├── Need point-in-time restore (seconds) → Continuous backup (PITR)  ├── Default, simple scheduled snapshots → Periodic backup  ├── Self-service restore via portal/CLI → Continuous backup (self-service)  └── Extended retention or geo-redundancy → Periodic backup (configurable)

## Decision Cards

“partition key” or “high cardinality”→Choose a partition key with high cardinality and even distribution

“20 GB limit” on a partition→Logical partition maximum size — choose a key that prevents this

“cross-partition query” or “fan-out”→Expensive — avoid in hot paths. Queries without partition key in WHERE clause fan out

“Request Units” or “1 RU”→Point read = 1 RU per 1 KB. Writes ~5-7 RU. Queries vary by complexity

“HTTP 429” or “throttled”→Exceeded provisioned RU/s. SDK retries automatically. Scale up or optimise queries

“session token” or “read-your-own-writes”→Session consistency — default and most common. Pass session token between reads/writes

“Last Writer Wins” or “conflict resolution”→Default multi-region write conflict policy. Uses \_ts. Can be custom stored procedure

“change feed” + “deletes”→Change feed does not capture deletes by default — use soft-delete or all-versions mode

“stored procedure” + “transaction”→Only way to get multi-document ACID transactions. Scoped to single partition key value

“composite index”→Required for ORDER BY on two or more properties. Define in indexing policy

“continuous backup” or “point-in-time restore”→PITR to any second within 7 or 30 days. Restore to a new account. Self-service

“Entra ID” or “RBAC” for Cosmos DB→Recommended auth method. Built-in Data Reader/Contributor roles. Full audit trail

“Direct mode” vs “Gateway mode”→Direct (TCP) = lower latency, production. Gateway (HTTPS) = simpler, restricted networks

“Synapse Link” or “analytical store”→No-ETL column-oriented analytical store. Near real-time sync from transactional data

“hierarchical partition keys”→Compound partition keys (e.g., /tenantId + /userId) for multi-tenant scenarios

“autoscale” or “10% to 100%”→Autoscale throughput: scales between 10% and max RU/s based on demand

“TTL” or “time-to-live” in Cosmos DB→Auto-delete expired documents. No extra RU cost for deletion. Set per container or item

“transactionalBatch” or “multi-item operation”→SDK-level ACID batch within a single partition. Alternative to stored procedures

Ready to certify?

## Train with practitioners, not presenters

Lucid Labs delivers Microsoft certification training led by Microsoft Certified Trainers (MCTs) and grounded in real-world project experience. We adapt every session to your team's environment, data stack, and business objectives — because the best exam prep comes from engineers who build these solutions every day.

🎯

Tailored Content

Training built around your actual Cosmos DB workloads, partition strategies, and consistency requirements — not generic slides.

🛠️

Hands-On Labs

Design partition keys, tune indexing policies, configure change feed processors, and troubleshoot RU consumption in real scenarios.

📊

Exam + Capability

Pass the DP-420 exam and build production-ready Cosmos DB skills your team can apply from day one.

[Talk to us about Azure Cosmos DB Developer training](https://lucidlabs.com.au/#contact?service=training-consulting&message=I'm%20interested%20in%20Azure%20Cosmos%20DB%20Developer%20\(DP-420\)%20training%20for%20my%20team%20-%20covering%20NoSQL%20API%2C%20partition%20design%2C%20consistency%2C%20and%20global%20distribution.)

Custom training for teams & individuals — remote or on-site across Australia

![Keith Oak](https://lucidlabs.com.au/team/koak-400.jpg)

Keith Oak

Chief Technology Officer — Lucid Labs

Microsoft Solutions Partner architect specialising in Fabric, Azure Data & AI, and GitHub Enterprise. 18+ years delivering data platforms for Australian businesses — building the systems these exams test every day.

[LinkedIn ↗](https://www.linkedin.com/in/keithoak/)[lucidlabs.com.au ↗](https://lucidlabs.com.au/)Published 29-03-2026