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 IntelCosmos 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 IntelIdeal 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 IntelEmbed 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 IntelStrong: 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 IntelPoint 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 IntelMulti-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 IntelChange 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 IntelStored 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 IntelEntra 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 IntelContinuous 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

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

⚡

PAS

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

🗝️

HED

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

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

🔍

IRSC

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

📜

SPT-U

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

🔔

FPP

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

🌐

LWW

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

💾

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

🔒

KER

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

📊

RU-429

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

📐

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

🚀

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

🏗️

ADCI

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

💰

1-5-Q

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.

ProvisionedvsAutoscalevsServerless

Throughput Modes Compared

Aspect	Provisioned	Autoscale
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

EmbedvsReference

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

Point ReadvsQuery

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

Single-RegionvsMulti-Region Writes

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)

ContinuousvsPeriodic Backup

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)

Change Feed ProcessorvsAzure Functions

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

Direct ModevsGateway Mode

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

KeysvsEntra ID RBAC

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)

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

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

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 ↗lucidlabs.com.au ↗Published 29-03-2026