AZ-DEV-140: Cosmos DB for NoSQL - A .NET Developer's Guide
Build production-grade applications on Cosmos DB (NoSQL API) with .NET 10. Cover data modeling for NoSQL, partitioning strategy, RU/s tuning, change feed processor patterns, global distribution, integrated vector search, and a capstone building a global multi-tenant Cosmos backend with change feed projections and semantic search.
About This Course
Cosmos DB is Azure's globally distributed multi-model database. This course focuses on the NoSQL API the most-used API and the one most .NET developers meet first with an emphasis on the design decisions that determine whether a Cosmos application costs $100/month or $10,000/month: data modeling, partition-key selection, and indexing strategy.Beyond modeling, the course covers what a working developer needs in production: change feed processors for materialized views and event sourcing, multi-region writes with conflict resolution, consistency-level tradeoffs measured empirically, and integrated vector search for RAG scenarios. Every lab uses the modern Microsoft.Azure.Cosmos v3 SDK with DefaultAzureCredential.By the end of this course you will be able to design a Cosmos NoSQL data model with the right embedding vs referencing tradeoffs, pick a partition key that avoids hot partitions, tune indexing policy to cut RU cost by an order of magnitude, build change-feed processors for materialized views, configure multi-region writes with conflict resolution, and ship a global multi-tenant Cosmos backend with integrated vector search.
Course Curriculum
20 Lessons
AZ-DEV-140 M1L1 - Cosmos DB fundamentals - accounts, APIs, RU/s, and throughput modes
Learn the Cosmos DB mental model before writing a line of code. This lesson covers the account/database/container/item hierarchy, the API family (NoSQL vs MongoDB vs Cassandra vs Table vs Gremlin), the RU/s throughput model that determines your bill, and the three throughput modes (manual, autoscale, serverless). By the end you can pick the right API and throughput mode for a workload and defend the choice on cost and latency.
AZ-DEV-140 M1L2 - Provision Cosmos DB (NoSQL) and probe RU costs from .NET 10 - Lab Exercises
Note: This lab pre-provisions an empty resource group at start — allow up to 3 minutes for it to become ready before beginning the exercises.
Take Cosmos DB end-to-end. Create an Azure Cosmos DB (NoSQL, serverless, Session consistency) account yourself using the Azure CLI, grant your lab user Cosmos DB Built-in Data Contributor at the data plane, connect from .NET 10 using Microsoft.Azure.Cosmos v3 SDK + DefaultAzureCredential, then perform CRUD and observe the exact RequestCharge for each operation. By the end you have hands-on numbers for how many RUs a point-read, upsert, and query cost in your specific account.
AZ-DEV-140 M2L3 - Data modeling for NoSQL - embedding, referencing, and schema evolution
The single most consequential decision on any Cosmos project is how you model the data. This lesson covers when to embed related data in one document (one-to-few, read-heavy) versus reference it (one-to-many, write-heavy or unbounded), how to reason about denormalization, and how to evolve schemas over time in a schemaless store. By the end you can defend an embed-vs-reference choice on RU cost, read latency, and consistency implications.
AZ-DEV-140 M2L4 - Load the same domain in two models and measure RU cost - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Take an e-commerce domain — Customer, Order, OrderLine, Product — and load it two ways: option A embeds order lines in the order document; option B keeps line items in a separate container referenced from the order. Load 5,000 orders in each model, then run the "get customer's last 10 orders" access pattern and measure the RU delta. Target: option A wins by 5-20x depending on line count per order.
AZ-DEV-140 M3L5 - Partitioning strategy - logical partitions, hot partitions, and hierarchical keys
Partition key choice is the single decision most likely to determine whether your Cosmos workload scales or throttles. This lesson covers logical vs physical partitions, the 20 GB soft cap per logical partition, hot-partition symptoms and fixes, synthetic partition keys, hierarchical partition keys (GA), and how to reason about query targeting. By the end you can pick a partition key that avoids hot partitions and enables efficient queries.
AZ-DEV-140 M3L6 - Fix a hot partition by refactoring to a hierarchical partition key - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Load documents with a bad partition key (/eventType, low cardinality), observe hot-partition throttling under load, then refactor to a hierarchical partition key (/tenantId/customerId) and reload. Measure the RU-per-operation reduction and confirm the load spreads across physical partitions. Target: 70%+ reduction in per-op RU cost.
AZ-DEV-140 M4L7 - Query optimization - indexing policy, query metrics, and composite indexes
Cosmos DB indexes every property by default. That's expensive on writes. This lesson covers the query metrics header that tells you where RUs are going, tuning the indexing policy with included and excluded paths, adding composite indexes for multi-column ORDER BY, and reasoning about when cross-partition queries are unavoidable. By the end you can cut RU cost on a slow query by 10x with the right indexing policy.
AZ-DEV-140 M4L8 - Cut a 250 RU query to under 20 RU with a composite index - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Take a slow query, use IndexMetrics to identify the missing composite index, add it to the container's indexing policy, and verify the RU cost drops by an order of magnitude. Sustain the improvement over 100 executions.
AZ-DEV-140 M5L9 - Change feed - materialized views and event sourcing patterns
Change feed is Cosmos's ordered log of insert/update operations - the primitive that unlocks materialized views, event sourcing, real-time projections, and out-of-band integrations. This lesson covers the change feed processor (push model), pull model, lease containers, backfill scenarios, and the Azure Functions Cosmos DB trigger. By the end you can build a change feed processor that projects raw events into a read-optimized view container.
AZ-DEV-140 M5L10 - Build an OrderSummary change feed processor - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Build a change feed processor that watches an orders container and projects a per-customer summary (order count + running total) into a separate container. Verify the projection catches up after a burst of 10k writes; kill the processor mid-run and confirm it resumes from the last checkpoint.
AZ-DEV-140 M6L11 - Global distribution, multi-region writes, and conflict resolution
Cosmos DB is globally distributed by design. This lesson covers adding read regions, enabling multi-region writes, priority-based failover, last-writer-wins vs custom conflict resolution, and TTL for auto-expiring documents. By the end you can design a topology across three regions and know how conflicts will resolve.
AZ-DEV-140 M6L12 - Add a second write region and simulate a conflict - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.
Enable multi-region writes on a Cosmos account, deliberately write to the same document from two regions within seconds, observe LWW resolution, then swap in a custom conflict resolver stored procedure to prove a business rule can win over "latest timestamp."
AZ-DEV-140 M7L13 - Consistency levels - Strong, Bounded Staleness, Session, Consistent Prefix, Eventual
Cosmos DB offers five distinct consistency levels, each with a different latency and RU cost profile. This lesson covers the semantics of each level, the latency/RU/availability tradeoffs, session tokens for read-your-writes, and how to override the account default per request. By the end you can pick a consistency level per workload and defend it with numbers.
AZ-DEV-140 M7L14 - Empirically measure latency and RU across five consistency levels - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Run the same read/write pattern at each of the five consistency levels; produce a table showing latency (p50/p99), RU cost, and observed behavior. Then apply a per-request override on a hot read path to reduce cost without changing the account default.
AZ-DEV-140 M8L15 - Transactions and bulk operations - TransactionalBatch, bulk executor, ETags
Cosmos DB has ACID transactions inside a single logical partition (TransactionalBatch), high-throughput ingest (AllowBulkExecution), point-write patch operations, and optimistic concurrency via ETags. This lesson covers when each applies. By the end you can build a parent+child atomic write, ingest 1M docs at 5000/sec, and use ETag concurrency to prevent lost updates.
AZ-DEV-140 M8L16 - Bulk-ingest 100k docs then place an atomic order via TransactionalBatch - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 10 minutes for the environment to become ready before beginning the exercises.
Ingest 100,000 docs with the bulk executor pattern (measure sustained throughput), then implement a same-partition TransactionalBatch that atomically writes an order + its line items. Force a failure mid-batch to prove rollback.
AZ-DEV-140 M9L17 - Integrated vector search and RAG patterns
Cosmos DB's integrated vector store is generally available. This lesson covers the vector embedding policy, the DiskANN index type for large-scale ANN search, storing embeddings alongside your operational data, and the RAG pattern (retrieve → augment → generate) with Cosmos as the vector store. By the end you can enable vector indexing and design a semantic-search backend.
AZ-DEV-140 M9L18 - Enable vector search on a product container and run a semantic query - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.
Enable Cosmos DB's integrated vector search on a container, load 200 Anchorline product documents each with a pre-computed embedding (deterministic mock embeddings for the lab), then run a semantic-search query with a sample query embedding. Observe RU cost and top-10 similar products.
AZ-DEV-140 M10L19 - Multi-tenant Cosmos SaaS architecture
Bring the course together. Multi-tenant Cosmos patterns: container-per-tenant vs shared-container-with-partition-key, hierarchical partition key strategies, backup/restore per tenant, migration paths, cost modeling at 10M documents. By the end you can architect a global multi-tenant Cosmos backend and defend every design decision on cost, isolation, and blast-radius.
AZ-DEV-140 M10L20 - Ship the Anchorline global multi-tenant Cosmos backend - Capstone - Lab Exercises
Note: This lab pre-provisions Azure resources at start — allow up to 12 minutes for the environment to become ready before beginning the exercises.
Build a global multi-tenant Cosmos backend for Anchorline: hierarchical partition key /tenantId/customerId, MI-authenticated ASP.NET Core API, TTL for stale data, an integrated vector-search endpoint for product recommendations, and a change-feed projector maintaining per-tenant order summaries. Prove tenant isolation, cross-tenant analytics, and end-to-end latency.