DP-420 Building AI Applications with Azure Cosmos DB Study Guide¶

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 team refresh reconciles the complete guide and detailed objectives with current public exam, product and learning evidence. See the current group report and the sources-and-objectives record. Known source conflicts and unexecuted exercises remain explicit. This is not human review or live product validation. The official blueprint is authoritative.

Study guide at a glance

Start here

Report an issue with DP-420

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading1 hr 45 min–2 hr 45 min

Prerequisites: Application development in C# or Python; Azure Cosmos DB data modeling, NoSQL queries and SDK operations; Azure service fundamentals, generative AI concepts, retrieval-based systems and application development practices. Older Java material is supplementary foundation.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1: model and partition an order workload, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Skills measured as of October 6, 2026; the current three-domain outline is accepted.
Blueprint reconciliation (October 28, 2026): The October 6 outline governs current preparation. Database development is 40–45%, secure/optimized deployment 30–35%, and AI/analytics 20–25%. The old July domain organization below is retained as a labeled foundation, not current exam weighting. The live study guide still contains future-tense transition copy; the effective-date heading and credential notice are recorded separately. Historical objective bytes and review records are preserved.
Lifecycle status: Active. The credential changed to Azure Cosmos DB AI Developer Associate on October 6, 2026; DP-420 remains the exam code. See the official credential notice.
Exam page: Azure Cosmos DB AI Developer Associate · 100-minute assessment · annual renewal.
Official course: DP-420T00 Build AI applications with Azure Cosmos DB · four instructor-led days.
Practice routing — VERIFY CURRENT (October 28, 2026): The credential page routes Practice Assessment to AI Skills Navigator with sign-in. No assessment was launched or its question content inspected. Recheck the vendor launch route before relying on an older direct link below; a practice result does not establish coverage of another exam code.

How to use this guide¶

DP-420 is a database-development and distributed-systems exam, not a portal tour. For every design, trace this chain:

access pattern -> item boundary -> partition key -> operation/query -> RU and latency
business invariant -> logical partition -> transaction mechanism -> concurrency condition
user location -> region routing -> consistency guarantee -> failure behavior -> recovery evidence
identity -> network path -> data-plane permission -> SDK request -> diagnostic evidence
source change -> change feed/mirroring/connector -> checkpoint -> target effect -> replay behavior

Practice with a current Azure Cosmos DB for NoSQL SDK. The current audience profile names C# or Python; older C#/Java examples can still teach foundations, so learn to recognize SDK object lifetimes, request options, partition-key arguments, pagination, diagnostics, and failure handling even if you write labs in only one language. Record prerequisites, item and partition shape, request charge, latency, status/substatus, retry count, correctness evidence, and cleanup cost for every lab.

About related items: A Related item: callout adds prerequisite, architectural, migration, security, operational, or adjacent context that makes the objective easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in Microsoft's published exam objectives.

Current October 6 objective map¶

The published October blueprint renames the exam to Building AI Applications with Azure Cosmos DB and the credential to Azure Cosmos DB AI Developer Associate. Its three areas are database development (40–45%), secure/optimized deployment (30–35%), and AI/analytics (20–25%). The three-domain map here governs preparation; the July structure farther below is historical organization for reusable foundations.

The current audience profile names C# or Python, replacing the earlier C#/Java reading expectation. Select material by your exam date and language; a familiar DP-420 course title or practice score does not establish coverage of the new AI domain.

October area	Reuse from this guide	Additional preparation
Database development	Models, partitions, SDK operations, throughput, change feed	Agent Kit, copy-container jobs, explicit latest/all-versions-and-deletes change-feed choices
Secure/optimized deployment	Identity, networking, availability, indexes, diagnostics	Dynamic masking, partition failover, Fleet throughput and analytics
AI and analytics	Integration and correctness principles	Full-text/vector/hybrid retrieval, sharded DiskANN, RAG, durable agent memory, conversation state, semantic memory, Fabric mirroring and Spark integration

Original design exercise: take a two-tenant support assistant from ingestion through retrieval and conversation storage. For each operation, record partition key, tenant authorization, consistency, RU/latency evidence, retry behavior and retention. Test a request for the other tenant's data and a replayed update. Explain how recovery of the source database differs from rebuilding its retrieval index. This exercise connects the database foundations to current AI scope; verify implementation details against current product documentation before running it.

Retrieval, grounding and durable agent memory¶

Treat retrieval as a measured pipeline: approved source → chunk/version → embedding → stored content/index → authorized query → selected evidence → generated answer. Record embedding model/version, dimensions, data type, distance metric and source identity. Re-embedding is a migration requiring comparison and rollback, not a silent replacement of numbers in an unchanged schema.

The vector-search guide distinguishes exact flat, compressed quantizedFlat and approximate diskANN indexes. Check dimensions and index eligibility before creating a container; flat supports fewer dimensions. The current minimum-data requirement for the latter two means a tiny lab can scan instead of exercising the intended index. Use real embeddings and measure recall as well as RU and latency. Approximate results can vary across replicas without a consistency failure.

Full-text search uses text-language policy and index paths for lexical matching/ranking. Choose language deliberately; additional language support has preview limitations. Hybrid retrieval combines lexical and vector rankings, for example through reciprocal rank fusion. Compare lexical-only, vector-only and hybrid results on the same questions, corpus and authorization scope. A relevant answer is not evidence that unauthorized source material was excluded.

Worked example — routing is not authorization: Two tenants both use thread ID support-7. A filter on thread ID alone can mix their records. Derive tenant identity from the authenticated application context, enforce allowed tenant/thread access server-side, and include that scope in point addresses and retrieval predicates. Sharded DiskANN narrows the vector index searched; the partition key routes data. Neither replaces access control when a shared service identity can read the container. Test a forged tenant value and deliberately similar cross-tenant documents. Current docs request product-team guidance for vector search with hierarchical keys; verify that combination before promising a supported deployment.

Agent-memory guidance separates conversation turns, summaries and semantically retrieved memories. Keep source/provenance, tenant/thread, ordering/version and retention metadata. Use ETags for concurrent state updates and deterministic IDs for replay. A summary can be stale or incorrect even when durably stored; expired source material can survive in derived summaries or embeddings unless your deletion process covers them. Treat retrieved user/tool content as data with provenance, not as permission to execute instructions.

Worked example — compare quality before cost: For one held-out question with ten known relevant documents, a candidate returns eight of those ten. Recall@10 is 0.8 for this example. A cheaper query that retrieves only five has recall 0.5. Compare the same authorized candidate set and aggregate over representative questions; one query is not a benchmark. Then test grounding citations, stale/deleted content and an unanswerable question separately from retrieval recall.

Worked example — a valid embedding can have an invalid index design¶

Confirmed — VERIFY CURRENT (October 28, 2026). A synthetic 1536-dimensional embedding cannot use a flat index, whose documented maximum is 505; quantizedFlat and diskANN allow up to 4096. An 800-vector test can still scan instead of exercising either compressed index, and current vector search excludes shared-throughput accounts. Check the vector-policy and limitation tables before interpreting successful queries as evidence the intended index worked. Record dimensions, policy, throughput model, data size, recall and RU/latency.

Proposed practice extension — not executed: Use real model embeddings; compare an eligible configuration with the dimension/throughput cases as a worksheet. Do not provision thousands of paid records only to satisfy the exercise.

Answer checkpoint: Does a successful 800-vector DiskANN query prove ANN indexing was exercised? No; below the documented threshold it can scan.

Change-feed modes, copy jobs and AI-assisted development¶

Read the change-feed mode matrix. Latest-version mode can start at the beginning but does not preserve every intermediate version or deleted item. All-versions-and-deletes mode requires continuous backup, has a bounded retention window and currently starts from now or a valid checkpoint, not an arbitrary historical timestamp. Select supported SDK/processor/pull APIs explicitly; pull mode leaves checkpointing and work distribution to your application, while the processor coordinates leases.

Container copy jobs remain preview. Online copy requires the documented backup/change-feed prerequisites and supported account/region configuration. Preconfigure the target's partition key, indexes and container TTL; copying items does not copy every container setting. The completion procedure includes stopping source updates, allowing remaining changes to drain and completing the job. Reconcile content, deletes and original transactions before switching callers. A processed-event count is not a count of distinct matching items or proof of a safe cutover.

The Cosmos DB Agent Kit supplies development guidance for AI coding assistants; it is different from an application's runtime agent-memory store. In a disposable project, record the kit revision and SDK version, request a partition/model/query review, and inspect every proposed change. Test parameterization, client lifetime, tenant access, concurrency and RU/latency. Keep suggestions that pass those checks; a generated explanation or installed skill is not a deployment test. This review did not install or execute the kit.

Masking, Fleet capacity and analytics boundaries¶

Dynamic data masking changes read/query projections while original values remain stored. Current guidance requires Entra managed identity and distinguishes unmask permission; built-in Data Contributor includes it. Account enablement is irreversible, although policy paths can be removed. Change feed requires unmask permission; backups retain original data. Write responses can expose original values, and complex queries can permit inference. Test those paths and current mirroring compatibility before selecting it.

Worked example — a masked screen does not prove confidentiality: A support role sees redacted email in a query. That proves this read path only. Check effective roles, write access/response bodies, logs, exports and downstream copies. If the requirement is that the database service cannot process plaintext, use the eligible client-encryption design from Section 6; masking does not establish that boundary.

Fleets group accounts and expose pooled throughput and aggregated analytics. Pool rules retain dedicated capacity and require matching region/write configurations; capacity is not shared across regions. Pool headroom does not remove a hot physical-partition limit. Record dedicated versus pooled demand and throttling. Fleet analytics provides hourly trends for cost/usage/configuration; use operational monitoring for immediate incident detection. Verify preview/support and billing boundaries before enabling a paid pool.

Distinguish an Azure Cosmos DB account mirrored into Fabric from a Cosmos DB database created inside Fabric. The latter uses Fabric workspace/capacity governance, automatic OneLake mirroring and currently requires gateway-mode connections; it is not a drop-in match for Azure account topology, identity or throughput settings. Query mirrored JSON through the SQL analytics endpoint or Spark over OneLake and validate replication freshness. The Cosmos DB Spark connector instead reaches the operational endpoint for reads/writes, including reverse ETL. Record endpoint, identity, destination, cost and freshness for each notebook.

Historical July objective organization¶

Published domain	Weight	Developer question
Design and implement data models	35–40%	Can the item, partition, throughput, SDK, query, transaction, and server-side design satisfy the known access patterns at scale?
Design and implement data distribution	5–10%	Can the region, consistency, failover, routing, and conflict design meet latency, availability, and durability requirements?
Integrate an Azure Cosmos DB solution	5–10%	Can operational changes reach analytics, search, functions, eventing, and derived models through the right current integration?
Optimize an Azure Cosmos DB solution	15–20%	Can you measure RU and latency, then improve query, index, cache, and change-feed behavior without breaking correctness?
Maintain an Azure Cosmos DB solution	25–30%	Can you observe, secure, restore, move, and deploy the solution repeatably?

1. Build the mental model first¶

Separate the resource, distribution, and request models¶

The Azure resource hierarchy is account -> database -> container -> item. The container is the principal unit for partitioning and scalable throughput; an item is uniquely addressed by its id plus partition-key value. A database can optionally share provisioned throughput among its containers, but a container still owns its partition-key and indexing policies. Start with the Azure Cosmos DB resource model and partitioning overview.

Keep these boundaries distinct:

Management/control plane: create accounts, regions, databases and containers; set account networking, default consistency, backup, encryption, failover, and throughput; authorize with Azure RBAC.
Data plane: read/query/write items, consume change feed, execute stored procedures, and manage conflicts; authorize with keys or Azure Cosmos DB native data-plane RBAC.
Logical partition: all items sharing a partition-key value. It is the transaction and targeted-routing boundary for the API for NoSQL.
Physical partition: service-managed compute/storage unit holding ranges of partition-key hashes. Throughput is distributed across physical partitions; applications do not pin an item directly to one.
Request unit (RU): normalized cost of database work. Point-read, query, write, indexing, item size, consistency, and replication choices affect consumed capacity and cost.
Client path: SDK -> preferred region/routing cache -> gateway metadata path and gateway or direct data path -> replica. Client CPU, sockets, DNS, retries, serialization, and region placement can dominate end-to-end latency even when server-side latency is healthy.

The request-unit model makes operations comparable, but it is not a latency guarantee. Capture both RequestCharge and SDK diagnostics.

Use an evidence-led design loop¶

List read and write operations with frequency, latency, consistency, item count, selectivity, sort, transaction, and retention requirements.
Model the JSON returned or changed by each operation; choose embedding, denormalization, references, and container boundaries.
Select a partition-key strategy and project per-key storage, request concentration, fan-out, and growth.
Estimate storage and RU/s, then choose serverless or provisioned throughput and manual or autoscale behavior where applicable.
Select regions, write topology, consistency, conflict behavior, and SDK preferred regions from SLO/RPO requirements.
Define identity, network, encryption, key, backup, logging, alert, and deployment controls.
Test with realistic data distribution, concurrency, item sizes, query parameters, failure injection, and region distance.
Measure request charge, normalized RU, throttles, diagnostics, latency, replication, storage distribution, and recovery.
Change one factor, repeat the same workload, and retain before/after evidence.

Related item: NoSQL schema flexibility moves schema responsibility into the application and governance process. A container accepts varied JSON shapes, but clients, indexes, analytical projections, encryption policies, and change consumers still depend on deliberate schemas and version compatibility.

Recognize the central tradeoffs¶

Choice	Usually improves	Usually costs or constrains
Embed related data	one-request reads, same-item atomic updates	larger items, duplicated data, broader write contention
Reference related data	independent lifecycle, smaller items	extra reads/queries, client joins, consistency coordination
Highly distributed partition key	write scale and even RU distribution	fan-out for queries that omit the key
Co-locating a transaction	atomic batch/stored procedure in one logical partition	potential hot or oversized partition
Broad default indexing	query flexibility	write RU and index storage
Narrow indexing	lower write/index cost	unsupported or expensive future query shapes
Stronger consistency	simpler read correctness	read RU/throughput, latency, availability constraints
Multi-region writes	local writes and regional resilience	conflicts, governance, cost, unsupported combinations
Continuous backup	self-service point-in-time restore	feature constraints and possible storage/restore cost
Fabric mirroring	near-real-time analytics without transactional RUs	Fabric capacity, source eligibility, schema and security constraints

2. Data-model foundations — historical July grouping¶

Model from access patterns, not relational tables¶

The authoritative starting point is data modeling in Azure Cosmos DB. Write an access-pattern table before creating containers:

Operation	Key/filter and sort	Cardinality/size	Frequency and SLO	Correctness boundary
Get order	tenant + order ID	one item	very high / low latency	latest accepted order state
List recent orders	tenant, status, time descending	tens	high	pagination must be stable enough for UI
Update order and outbox record	tenant + order	two items	medium	all succeed or all fail
Product lookup	SKU	one item	high	product can change independently
Global sales report	time/product/region	millions	periodic	analytics can lag

Then decide:

Embed bounded child data that is read and updated with the parent, fits item-size/growth limits, and shares lifecycle. One item write is atomic.
Denormalize small, read-heavy values into multiple items when eliminating joins is worth the update fan-out. Define the source of truth and repair/replay process.
Reference independently changing, unbounded, many-to-many, or separately secured entities. Budget the extra point reads or queries.
Store multiple entity types in one container when they share distribution/access needs. Use a discriminator such as type, collision-safe IDs, and type-aware index paths. Containers are not relational tables.
Use separate containers when partitioning, throughput, retention, indexing, encryption, access control, or lifecycle materially differs. Cross-container transactions are not provided.

Example aggregate:

{
  "id": "order-1842",
  "tenantId": "northwind",
  "type": "order",
  "schemaVersion": 3,
  "status": "paid",
  "placedAt": "2026-08-30T14:22:11Z",
  "customer": { "id": "c-19", "displayName": "A. Customer" },
  "lines": [
    { "sku": "p-7", "nameAtPurchase": "Widget", "quantity": 2, "unitPrice": 12.50 }
  ]
}

The copied name and price preserve the order fact; the customer ID remains a reference for the current profile. This is intentional denormalization, not accidental duplication.

Design keys, uniqueness, TTL, and versioning¶

`id`, partition key, and unique keys¶

id is a string and is only unique within a logical partition. A point read needs both id and the partition-key value.
Make IDs stable, deterministic where idempotency needs it, and collision-safe across co-located entity types—for example order|1842 and outbox|1842|paid.
A partition key is chosen when a container is created and cannot be changed in place. Moving to a new key requires a migration/new container or a supported partition-key-change capability whose constraints must be checked.
A unique-key policy enforces uniqueness for specified paths within each logical partition, not globally. It is defined at container creation and increases write RU.

Do not call id a relational primary key without qualification. In Azure Cosmos DB for NoSQL the address is effectively (partitionKey, id).

Transactional TTL¶

Time to live can be enabled at the container and overridden per item. A positive item TTL counts seconds from the last-modified timestamp; -1 means no expiration when TTL is enabled. Expired items stop appearing in query results even when physical deletion is delayed. Background deletion uses spare provisioned RUs; serverless deletion is charged. Use TTL for ephemeral sessions, telemetry windows, caches, or retention rules—not as a precise workflow scheduler.

Distinguish:

transactional TTL on operational items;
analytical TTL for analytical-store retention;
backup retention, which protects recoverability;
change-feed retention/mode behavior;
Fabric warehouse time-travel retention.

They solve different problems.

Item and schema versioning¶

Use a schemaVersion and readers that can tolerate known old versions. Common strategies:

Lazy/read repair: transform old items when read; cheap rollout, unpredictable migration completion.
Write-new/read-both: new writers emit the new form while readers accept both; useful for rolling deployment.
Change-feed migration: project items into a new form/container with checkpointed progress. A latest-version feed started from the beginning can bootstrap extant items; a consumer started from now needs a separate existing-data backfill. Neither reconstructs deleted or overwritten historical versions.
Bulk backfill: deterministic migration at throughput cost; needs idempotency, checkpoints, throttling, reconciliation, and rollback.

Never reuse a property with an incompatible meaning while mixed application versions are running. Version event payloads and derived models separately from stored aggregate versions.

Choose a partition-key strategy¶

A good key has high cardinality, distributes both storage and RU demand, appears in important request paths, supports transaction boundaries, and remains stable. Evaluate distribution and routing, not cardinality alone.

For each candidate key, estimate:

items/key × average item size × retention = projected logical-key storage
operations/key/second × RU/operation = projected per-key RU demand
requests without complete key × partitions touched = fan-out exposure
items in one invariant = transactional co-location requirement

Test skew at peak, not only average. A million dormant tenants do not offset one tenant receiving most writes.

Natural, synthetic, and hierarchical keys¶

Strategy	Use when	Watch for
`/tenantId`	most work is tenant-scoped and tenant sizes/load are bounded	large/noisy tenant can dominate one logical partition
`/deviceId`	ingestion and reads are device-scoped	fleet-wide time query fans out; hot device remains hot
synthetic `tenantId\|bucket`	one natural key is too hot/large	callers must derive bucket; reads may query several buckets
random/hash suffix	maximum write spreading is required	point routing needs a lookup or deterministic suffix; reads fan out
time bucket	retention and time-window access align	current bucket can be hot; boundary and late-arrival logic
hierarchical `/tenantId`, `/userId`, `/sessionId`	prefix routing plus subpartition scale fits access patterns	prefix order is fixed; incomplete prefixes can still touch many ranges

Synthetic partition keys combine fields or append calculated/random suffixes when no single property distributes and routes well. They add application logic and must be reproducible for targeted operations.

Hierarchical partition keys support up to three levels. A leading-prefix query can route to the subset belonging to that prefix, while deeper components distribute a large tenant. They do not make arbitrary alternate-key queries targeted. Preserve the most important routing hierarchy in prefix order and verify current SDK/feature limitations.

Multiple partition-key access needs¶

One container has one partition-key definition. When two high-volume patterns need unrelated keys, choose deliberately:

optimize the dominant pattern and accept/measure fan-out for the other;
maintain a lookup item from alternate key to (partitionKey, id);
materialize a second container shaped for the alternate pattern through change feed;
use Fabric mirroring or another analytical integration for broad scans/reporting;
consider separate aggregates/containers if lifecycle and consistency allow it.

Do not promise synchronous cross-container referential integrity. Derived copies are eventually consistent unless the application coordinates another explicit mechanism.

Related item: Partitioning is simultaneously a scalability, cost, query-routing, and transaction design. A key that makes one query cheap can make an invariant impossible to update atomically; a key that co-locates everything can create an unscalable hot tenant.

Plan sizing and scaling¶

Estimate throughput and storage¶

Measure representative operations with realistic item sizes and index policy. A capacity estimate is:

peak RU/s = Σ (operation rate/second × measured RU/operation)
           × headroom for bursts, retries, skew, and change consumers

stored GB = live data + index + derived/lease data + growth and retention margin

Use the Azure Cosmos DB capacity planner for an initial model, then load-test the actual SDK and data distribution. Reads by id plus partition key are typically the cheapest lookup shape; broad queries and large/index-heavy writes cost more. Multi-region cost includes each configured region.

Serverless versus provisioned throughput¶

Model	Best fit	Key constraints to verify
Serverless	intermittent, low-volume, unpredictable development or small workloads	supported regions/features, storage and burst limits, per-request billing, no reserved capacity
Manual provisioned RU/s	steady predictable utilization and direct control	pay for provisioned capacity even when idle; size for partition distribution
Autoscale provisioned throughput	variable production demand with meaningful peaks	configured maximum, billing behavior, hot-partition limits, minimum/maximum rules
Database-level shared throughput	several small containers with noncoincident demand	shared pool/noisy neighbors; dedicated-throughput containers are separate
Container-level throughput	isolation and independent scale for important container	minimums and cost per container

Review serverless, provisioned throughput, autoscale, and free tier before deployment. Free tier is an account-level discount with eligibility constraints, not a separate database engine.

VERIFY CURRENT: limits, minimum RU/s, dynamic/autoscale behavior, feature compatibility, regional availability, pricing, free-tier benefit, and large-partition capabilities change. Use the service quotas and limits and pricing page for the target design date.

Granular scale and resource governance¶

Create separate containers when a workload needs independent throughput, partitioning, index, TTL, encryption, or operational ownership. Shared database throughput is useful for small containers, but a single busy container can consume the shared pool. Use Azure Policy, deployment validation, budgets, tags, role scopes, and throughput limits to constrain accidental scale. Monitor per-partition demand because increasing total RU/s does not correct a single hot logical key indefinitely.

Implement SDK connectivity¶

The current .NET SDK best practices apply a few durable rules:

create one CosmosClient per account for the process lifetime; repeated construction causes connection, CPU, metadata, and socket pressure;
place the application in the same Azure region as the preferred database region when possible;
use direct mode for lowest latency where its TCP network requirements are allowed; use gateway mode for HTTPS-only/proxy-constrained paths or emulator limitations;
configure preferred regions so the SDK can route to nearby healthy replicas;
avoid blocking asynchronous calls; size application CPU and concurrency before increasing database throughput;
log SDK diagnostics for slow/failing requests, but do not parse diagnostic strings as a stable contract;
handle transient failure with the SDK retry behavior and application-level idempotency.

Direct versus gateway¶

Mode	Data path	Strength	Operational consideration
Direct	SDK opens TCP connections to replicas after gateway metadata/routing calls	lower latency and fewer data-path hops	more connections/ports; firewall/private endpoint must permit required range
Gateway	all requests use HTTPS through gateway	proxy/firewall simplicity and lower connection count	added hop and gateway connection limits

Private endpoints change DNS/routing, not the need to authenticate. Direct mode through Private Link has broader port requirements documented in the Private Link guide.

Local development¶

The Azure Cosmos DB emulator supports local development without Azure cost, but it does not emulate global distribution, scale, all APIs, all consistency/failure behavior, or all service features. The new Linux-based emulator vNext supports the API for NoSQL in gateway mode with a documented feature subset. Use it for deterministic unit/integration work; use a controlled Azure test account for RU, direct connectivity, identity/network, multi-region, backup, and production-like performance tests.

Query with the NoSQL query language¶

Use the current Cosmos DB query language documentation rather than assuming full SQL Server semantics. JSON property names are case-sensitive; missing and null are different states.

SELECT VALUE {
    "orderId": c.id,
    "total": ARRAY_SUM(ARRAY(SELECT VALUE l.quantity * l.unitPrice FROM l IN c.lines))
}
FROM c
WHERE c.tenantId = @tenantId
  AND c.type = "order"
  AND IS_DEFINED(c.placedAt)
ORDER BY c.placedAt DESC

Know how to:

project whole items, selected properties, or VALUE scalars;
traverse nested objects and arrays; use JOIN as an intra-item array cross-product, not a cross-container relational join;
use aggregates and ORDER BY, including the index requirements of multi-property order/filter patterns;
use type-checking and array, string, mathematical, and date/time functions;
parameterize queries rather than concatenate values;
use correlated and scalar subqueries to avoid repeated expensive expressions and filter array expansions;
supply the partition key in query request options when the caller knows it;
inspect request charge, retrieved/output counts, index utilization/metrics, continuation token, and SDK diagnostics.

A cross-partition query is not automatically wrong. It is wrong when its fan-out, frequency, latency, and RU cost violate requirements. Measure with production-like partition counts and selectivity.

Implement SDK data access¶

Point operations and queries¶

Use a point read when both id and partition-key value are known. Do not issue SELECT * WHERE c.id = ... merely to retrieve an addressable item: the query uses the query engine and can fan out if the key is absent.

For writes:

Create fails if the address exists—useful for duplicate detection.
Upsert creates or replaces—convenient, but can hide whether a create versus replacement was expected.
Replace sends the full item and is appropriate for complete aggregate updates.
Patch changes selected paths and can reduce payload/serialization, but still needs a concurrency and invariant plan. See partial document update.
Delete requires id and partition key; consider dependent denormalized data and change consumers.

Optimistic concurrency¶

Every item has an _etag. Read it, calculate a change, and send If-Match; a concurrent change produces HTTP 412 rather than silently overwriting it. Decide whether to reload/re-evaluate, surface conflict, or apply a commutative merge. Blind retry of the same stale replacement defeats the invariant. The transactions and optimistic concurrency documentation relates ETags to the logical-partition transaction boundary.

Transactional batch versus bulk¶

Transactional batch groups supported operations sharing one partition-key value; all commit or roll back. It protects an invariant such as order + outbox item. A failed operation causes the batch to fail; inspect per-operation results.

Bulk mode increases throughput by scheduling many independent operations efficiently across partitions. It does not make them one transaction and result ordering/completion must be handled. Prefer current SDK bulk support over the legacy .NET bulk executor library; Microsoft’s migration guidance documents the current path.

Pagination and continuation¶

Iterators return pages, including potentially empty pages before completion. A continuation token represents query progress, not a snapshot-isolation promise across arbitrary concurrent changes. Pagination guidance says tokens do not expire while using the same SDK version; SDK/query support still varies. Bind stored tokens to the exact query, parameters and authorized scope, and test SDK upgrades. Set a page size to control response shape, not total RU cost magically.

Consistency overrides and session tokens¶

The account defines default consistency. A request can use a supported weaker consistency override, not a stronger guarantee than the account provides. Under session consistency, the SDK session token carries read-your-writes context. If requests move across stateless front ends or client instances and require the same session guarantee, propagate the appropriate token deliberately. Do not expose it as an authorization token.

Transient failures and 429s¶

Classify before retrying:

Signal	Meaning/action
429	rate limited; SDK respects server retry-after within configured limits; inspect partition skew and capacity
408 / timeout	outcome can be uncertain; inspect diagnostics, connectivity, CPU, request size and idempotency before retry
412	ETag precondition failed; reload and re-evaluate business change
409	conflict such as duplicate ID/unique key or multi-write conflict path; do not treat as generic transient
404	wrong address, deleted/expired item, stale region/session context, or resource issue; inspect substatus and request context
403	identity/key/permission/network/account restriction; retry rarely fixes configuration
5xx/503	service or path issue; bounded backoff, regional resilience, diagnostics, and idempotency apply

Use exponential backoff with jitter where the SDK does not already own the retry, cap total latency, and make commands idempotent with deterministic IDs, ETags, state machines, or an inbox/outbox pattern. See 429 troubleshooting and query troubleshooting.

Implement server-side JavaScript¶

Azure Cosmos DB supports stored procedures, pre/post triggers, and user-defined functions described in server-side programming and the writing guide.

A stored procedure runs transactionally within one logical partition. The caller supplies that partition key. It is bounded by execution time and RU availability, so continuation/resume logic may be needed.
A trigger is not an autonomous database event listener. The client explicitly names a pre- or post-trigger on an operation. Triggers share the operation’s logical-partition scope.
A UDF is compute-only JavaScript called from a query. Prefer built-in query functions where possible because UDF execution can add cost and cannot use indexes to replace a missing indexed predicate.
Server-side JavaScript cannot import arbitrary modules. Deploy/version scripts with the application or infrastructure process and test rollback compatibility.

Use transactional batch for straightforward same-key operation groups; use a stored procedure when server-side conditional iteration/logic truly needs the partition transaction. Use change feed for asynchronous effects outside the logical partition.

3. Design and implement data distribution — historical July grouping¶

Derive topology from user and failure requirements¶

Add regions to reduce distance, improve read availability, and/or enable regional write resilience—not because “global” is inherently better. Each region adds replicated storage and throughput cost and changes consistency/failure behavior.

Requirement	Candidate design	Validate
local reads, centralized writes	single write region plus read regions	write latency to primary, read routing, failover RTO/RPO
local writes in several geographies	multiple write regions	conflicts, supported consistency/features, application reconciliation
zero data-loss expectation across regional failure	strong consistency with supported topology	write latency and availability tradeoff, distance restrictions
read-your-writes per user/session	session consistency and token continuity	load-balancer/client behavior and token propagation
highest availability/lowest read cost	consistent prefix or eventual as semantics allow	stale/order behavior visible to users

Review reliability in Azure Cosmos DB and global distribution internals. Preferred regions tell the SDK where to try; they do not create regions or replace application-tier traffic routing.

Choose consistency from observable guarantees¶

The five consistency levels are ordered from strongest to weakest:

Level	Core application guarantee	Typical fit/consideration
Strong	reads return the latest committed version	strict cross-client correctness; higher read cost/latency and topology constraints
Bounded staleness	lag bounded by configured versions or time, with ordering	controlled stale window; read cost similar to strong
Session	read-your-writes and ordered guarantees within a session	common user/session workloads; token continuity matters
Consistent prefix	reads never see writes out of order, but can lag	ordered feeds where freshness can vary
Eventual	no ordering guarantee, replicas converge	counters/feeds where temporary reordering/staleness is acceptable

Write a testable statement: “After a successful cart write, that user must see it on the next request even after the web request lands on another instance.” That implies session-token handling; “use session consistency” alone does not prove it.

Stronger consistency affects more than correctness. Strong and bounded-staleness reads involve more replicas and therefore have different RU/read-throughput economics. Strong multi-region writes are not a valid combination. Verify current distance/region restrictions and durability behavior.

Configure failover and application routing¶

For single-write accounts, configure region priorities and service-managed failover as requirements permit. A manual failover changes the write region intentionally for testing/maintenance. Do not initiate conflicting topology changes during a live regional incident without following current guidance; preserve evidence and understand whether the operation risks data.

Build and rehearse:

regional application routing and health probes;
SDK preferred-region order and multi-region endpoint discovery;
remaining-region throughput capacity;
consistency/session behavior through failover;
write/read transaction and dependency validation;
alerting on availability, replication, SDK failures, and business SLO;
failback and post-event reconciliation.

Per-partition automatic failover is a newer resilience capability whose eligibility and behavior should be verified in current documentation; do not confuse it with changing the data model or consistency guarantee.

Current PPAF guidance targets provisioned-throughput NoSQL accounts with one write region and configured failover regions. It redirects affected partitions while healthy partitions retain their route. Bounded staleness, serverless and same-account restore are among the documented exclusions; review the full matrix before enabling it. Record region priorities, compatible SDK routing and original application behavior through recovery. A documented recovery target is not evidence that your application's dependencies recovered within it.

Design multi-region writes and conflict resolution¶

Concurrent writes to the same logical item can conflict. Select a policy from business semantics:

Last writer wins: resolves using _ts by default or another numeric path. Simple, but a clock/number winning does not mean the business-correct update won.
Custom merge procedure: server-side resolution implements domain logic within supported constraints.
Conflict feed/application resolution: retain conflicts for an application to reconcile; requires an owner, idempotent processing, backlog monitoring, and deterministic convergence.

Test create/create, replace/replace, delete/update, partition-key identity, offline client, regional outage, replay, and resolution failure. Counter increments, set union, reservations, and balance transfers need domain-specific logic; overwriting the whole item with LWW can lose valid concurrent intent. Use the current conflict-resolution policy guide.

Related item: Availability-zone redundancy protects datacenter-level failure inside a region; multiple regions address regional failure; backup addresses corruption/deletion and historical recovery. None substitutes for the others.

4. Integrate an Azure Cosmos DB solution — historical July grouping¶

Choose the analytical path intentionally¶

The July 2026 blueprint names both current and transitional technologies:

Need	Prefer/consider	Data path and caveat
current near-real-time Fabric analytics	Azure Cosmos DB Mirroring for Microsoft Fabric	incrementally replicates supported NoSQL data into OneLake/SQL analytics endpoint; requires eligible account, continuous backup, Fabric capacity and supported security/topology
existing Synapse Link project	analytical store + Synapse Spark/serverless SQL	analytical copy separated from transactional RU path; reconcile support notice and constraints
custom Spark transformations or transactional reads/writes	Azure Cosmos DB Spark connector	select transactional versus analytical endpoint deliberately; Spark jobs consume corresponding resources
operational derived views/events	change feed + SDK/Functions	ordered per logical partition, checkpointed consumer; design replay/idempotency

Fabric mirroring for Azure Cosmos DB replicates changes to OneLake without consuming transactional RUs for the mirrored analytics queries. It is not zero cost: Fabric capacity and other services apply, and the mirroring limitations include source-account, backup, multi-write, nested-schema, security, and region constraints.

LEGACY / TRANSITIONAL: Microsoft’s current analytical-store CDC documentation says Azure Synapse Link for Cosmos DB is no longer supported for new projects and directs new designs to Fabric mirroring. The DP-420 blueprint still explicitly includes analytical store, Synapse Spark/serverless SQL, the Spark connector, and analytical-store CDC. Learn these for existing deployments and the published objective, but choose Fabric mirroring for a new project unless current requirements/documentation say otherwise. See the analytical-store overview and CDC transition notice.

Fabric mirroring and time travel¶

For a mirrored source:

verify API for NoSQL/account/topology/continuous-backup and Fabric region support;
grant the minimum source data permissions and configure network ACL bypass/private access as currently supported;
choose database/containers and start mirroring;
monitor initial snapshot and replication freshness/row counts;
query the SQL analytics endpoint or OneLake with SQL/Spark;
validate nested JSON/type evolution and semantic-model behavior;
alert on stalled replication and test recovery/reseed consequences.

The blueprint’s “time travel in Warehouse” refers to Fabric SQL analytics endpoint/Warehouse capability, not Cosmos DB point-in-time restore. Fabric time travel uses historical warehouse table versions for read-only queries within retention; it is not a method to restore the source operational container.

Existing analytical-store path¶

Analytical store is a column-oriented copy populated by auto-sync and governed by analytical TTL. Synapse Spark and serverless SQL can read it without consuming transactional RU/s. Spark can also query/write the transactional store via the OLTP connector—those operations do consume transactional resources. Know which endpoint a notebook uses.

Analytical-store change data capture can drive ADF/Synapse mapping data flows and include deletes according to its mode/configuration. It is distinct from the operational change feed and currently has preview/legacy constraints. Preserve checkpoints and target idempotency.

Implement event-driven derived models¶

The Azure Cosmos DB change feed is an ordered record of changes within each logical partition. It is not a single global total order. Default/latest-version mode emphasizes creates and updates; all-versions-and-deletes mode has continuous-backup prerequisites and retention limits.

Use it to:

denormalize into a query-optimized container;
update an aggregate/materialized view;
enforce a cross-item or cross-container relationship asynchronously;
archive or project operational events;
feed downstream functions, event hubs, search, or reporting.

Change feed processor¶

The change feed processor coordinates workers through lease documents:

monitored container: source changes;
lease container: ownership, checkpoints, and load balancing;
processor name: identifies a consumer group; separate logical consumers need separate names/leases;
instance name: identifies one worker;
delegate/handler: processes a batch and must be idempotent.

A checkpoint advances after successful delegate completion, but failures, lease movement, or side-effect timing can produce replay. Exactly-once business effects require idempotent target writes/deduplication, not belief that the feed invokes once. Monitor lag/backlog with the change feed estimator.

Azure Functions’ Cosmos DB trigger hosts the processor model. Configure source, leases, identity/connection, batch and polling behavior; scale testing must include lease partitioning, downstream capacity, poison/failure handling, and replay. See Azure Functions change-feed integration.

Common projections¶

Denormalization: upsert deterministic target ID from source ID/version; prevent an older replay overwriting a newer projection.
Referential enforcement: detect missing/invalid reference and compensate/quarantine; it is eventual, not an atomic foreign key.
Aggregation: store contribution/version or make updates conditionally idempotent; simple total += value double-counts replay.
Archiving: retain source identity/version/time and validate target durability before advancing; change feed is not itself long-term backup.

Functions and Event Hubs¶

Use a function trigger for compute tied to change-feed checkpoints. Send durable integration events to Event Hubs when independent consumers, replay retention, partitioned streaming, or decoupling is required. A transactional outbox item written in the same logical-partition batch as the aggregate prevents “database commit but event not recorded”; a change-feed worker publishes that outbox idempotently.

Integrate Azure AI Search¶

An Azure AI Search indexer for Azure Cosmos DB can pull documents and incrementally track changes. Define:

source container/query and identity/network access;
stable document key and field mappings;
index schema, analyzers, vector/enrichment path where required;
deletion detection strategy—ordinary indexing does not infer every deletion automatically;
schedule/freshness SLO, high-watermark behavior, errors, and reset/rebuild plan;
data classification: the search index is another governed copy.

Do not use search as the authoritative transactional read store. Validate source-to-index counts, representative content, deletes, schema changes, throttling, and query relevance.

Related item: An integration is not complete when data merely arrives. Define ordering scope, delivery/replay semantics, checkpoint ownership, poison handling, target idempotency, reconciliation, observability, retention, and security for every hop.

5. Optimize an Azure Cosmos DB solution — historical July grouping¶

Optimize from measured request evidence¶

For a slow or expensive operation, collect:

operation, id, partition-key availability, query text/parameters, page count and item size;
request charge per page/operation and total;
output count versus documents/index entries retrieved;
SDK diagnostics: regions, retries, gateway/direct calls, client CPU and timing;
index utilization/metrics and current indexing policy;
normalized RU by physical partition and logical-key distribution;
server-side versus end-to-end latency and status/substatus;
concurrency and change from a known baseline.

Then classify: routing/fan-out, poor filter selectivity, missing/wrong index, expensive sort/aggregate, large result/payload, hot key, insufficient throughput, client resource/connectivity, region distance, or downstream latency. Increasing RU/s cannot fix every class.

Improve query and operation cost¶

Use this order:

Replace query with a point read when the address is known.
Supply the complete partition key or useful hierarchical prefix.
Return only required fields and bound result sets.
Parameterize filters and avoid functions that prevent useful index paths where applicable.
Inspect indexing metrics for recommended used/potential paths.
Add the necessary single/composite index, wait for transformation, then retest.
Revisit model/partition or create a derived view if the high-value access pattern fundamentally conflicts.
Consider cache only for eligible read semantics after correctness and invalidation expectations are clear.

Request charge for the same deterministic query/data/index configuration is a useful regression signal. Compare total RU across all pages—not only page one.

Define an indexing strategy¶

The default indexing policy indexes all properties with range indexes. That favors flexible reads but increases write RU and index storage.

Policy components¶

Included/excluded paths: exclude large never-filtered payloads or use an explicit include strategy for stable write-heavy schemas. Remember path syntax and undefined-value behavior.
Range indexes: support equality/range and many order operations on strings/numbers.
Composite indexes: support certain multi-property ORDER BY and improve combinations of equality/range/order. Property order and ascending/descending direction matter.
Spatial indexes: support geometry operations for configured paths/types.
Vector indexes: relevant to vector workloads, but only where the current objective/workload requires them; verify feature and policy details.
Indexing mode: consistent is normal; none can support bulk load patterns but queries then need a deliberate reindex path.

For a read-heavy container, retain indexes for frequent routes and sorts. For a write-heavy container, exclude unused paths and large opaque subtrees. Never remove an index because a tiny test query still runs: it may scan and become catastrophic at production scale.

When replacing an index, add the new index, wait for online transformation to complete, prove queries use it, then remove the old one. Removing first can break or degrade live queries. Track the transformation described in managing indexing policies.

Use integrated cache where semantics permit¶

The integrated cache is available through a dedicated gateway for supported API for NoSQL scenarios. It caches point reads and queries, reducing backend RU for cache hits. Configure maximum integrated cache staleness per request/default and understand that:

it is not a general application cache or write-through source of truth;
populated results are dependent on exact query/request shape;
staleness can be greater than the application accepts if configured poorly;
dedicated gateway capacity/cost, availability, region placement, private access, and SDK gateway routing matter;
a cache miss still consumes backend RUs.

Use it for read-heavy, repeatable, staleness-tolerant access. Measure hit behavior, RU reduction, response correctness after writes, and behavior during gateway disruption.

Design change-feed throughput¶

Change-feed processing consumes source read RUs and lease-container RUs, plus target-service capacity. Scale by partition-key ranges and lease ownership—not arbitrary duplicate processors with the same identity. Use separate processor names for independent consumers; otherwise instances cooperate on one workload.

Estimate lag and recovery:

net drain rate = sustainable successful processing rate - new work arrival rate
backlog drain time ≈ pending work / net drain rate, only when net drain rate > 0

Include target throttling, handler time, retries, batch size, source partitions, and lease acquisition. The estimator measures pending work; it does not prove side effects succeeded. Alert on lag plus handler failures and target reconciliation.

Worked example — keep up while recovering: A synthetic backlog contains 6,000 work units, new work arrives at 400 units/s, and successful processing sustains 1,000 units/s. Net drain is 600 units/s, so the idealized recovery is 10 seconds, not six. At 400 units/s processing, it never drains while arrivals continue. Real timing also needs startup, skew, retries and downstream evidence.

6. Maintain an Azure Cosmos DB solution — historical July grouping¶

Monitor the whole request path¶

Azure Cosmos DB insights surfaces throughput, requests, storage, availability, latency, system, and management signals. Build a layered view:

Layer	Evidence	What it distinguishes
application	business success, dependency duration, retries, saturation	user impact and caller behavior
SDK	diagnostics, contacted regions, request charge, retry/connection timeline	client versus service path
account/container	total requests by code/operation, RU, availability, latency	service-side demand/failure
partition	normalized RU, physical/logical partition consumption, storage	hot/skewed keys hidden by averages
integration	change-feed lag, leases, function failures, mirror freshness	derived-data health
control/security	activity log, diagnostic resource logs, RBAC/network/key changes	configuration and access events

Normalized RU consumption is the maximum utilization percentage across partition-key ranges for the interval, not an average of total provisioned RU. One hot range can reach 100% while account-wide consumed RU appears low.

Status-code triage¶

Start from status + substatus + SDK diagnostics + operation context:

high 429 with balanced partitions: capacity/burst/concurrency or inefficient operations;
high 429 isolated to one range/key: skew/hot key; more total RU may only postpone the design limit;
healthy server latency but slow application: client CPU/thread/socket/DNS/proxy/region/downstream path;
elevated server latency with stable client: service workload/query/index/partition or regional condition;
403 after security change: distinguish RBAC data actions, management role, firewall/private DNS, disabled keys, and tenant/token audience;
replication lag: inspect topology/consistency/region state and application routing before claiming data loss.

Enable resource-specific diagnostic logs to a governed destination and query request/control-plane/audit categories. Logs cost storage/ingestion and can expose identifiers/query details, so apply retention and access control. Alerts need actionable thresholds, window, severity, owner, runbook, and recovery notification—not every metric spike.

Implement backup and restore¶

Azure Cosmos DB has continuous and periodic backup modes:

Mode	Restore model	Design implication
Continuous	self-service point-in-time restore within selected supported retention tier; current capabilities include new-account and supported same-account scenarios	one-way migration from periodic; feature/topology/CMK/mirroring constraints; restore permissions and cost
Periodic	scheduled platform backups; restoration is requested through Azure support	interval/retention/redundancy configuration; longer operational workflow

The current continuous-backup documentation describes 7-, 30-, and preview 35-day tiers; treat exact tiers, preview status, support matrix, and prices as VERIFY CURRENT. A backup is not a read replica, failover region, change feed, or Fabric time-travel table.

Recovery plan¶

Derive RPO/RTO for deletion, corruption, account loss, and region loss separately.
Choose backup mode/tier and redundancy; inventory unsupported feature combinations.
Grant minimum restore/list-restorable permissions to a controlled recovery identity.
Locate deletion events/latest restorable timestamp in the correct region.
Restore account, database, or container using a supported current target mode.
Reapply or validate resources not restored: network, identities/RBAC, keys/CMK access, diagnostic settings, integrations, scripts, throughput/topology, and application configuration.
Reconcile data at the chosen point, run representative business transactions, and validate indexes/change consumers.
record actual RPO/RTO and securely remove the test target.

Periodic backup restoration and some continuous restore modes create a new account/resource. Never assume every control-plane setting or external dependency is included. Practice same-account deleted database/container restore only in a disposable environment and within current concurrency/retention rules.

Related item: Multi-region replication rapidly copies valid writes—including damaging application updates. Backup/PITR is the recovery control for corruption or deletion; replication is the availability control for service/region failure.

Implement layered security¶

Use the Azure Cosmos DB security guidance as a checklist.

Control plane versus data plane¶

Azure RBAC roles on the account govern management operations but do not automatically grant item read/write. Native Azure Cosmos DB data-plane roles define dataActions and scopes down to account/database/container. Conversely, a data-plane reader cannot modify firewall or regions. Test both paths separately.

Prefer Microsoft Entra authentication and managed identity over stored account keys. Data-plane RBAC can grant built-in/custom permissions at an appropriate scope and allows disabling key-based authentication where all clients support it. Data Explorer also needs the correct control-plane visibility and data-plane role—portal access is not proof of item permission.

If legacy clients require keys:

store them in Key Vault or another approved secret store, never source/configuration logs;
rotate primary and secondary without downtime and inventory all consumers;
use read-only keys for readers where supported;
restrict network access because possession of a key is powerful;
migrate to Entra/RBAC and consider disabling local authentication.

Network and browser controls¶

public endpoint + IP firewall restricts source public IPs but still requires authorization;
virtual-network service endpoints identify allowed subnets while traffic reaches the service endpoint;
Private Link gives private IP connectivity; private DNS, region-specific records, routing, and direct-mode ports are part of the design;
disabling public network access prevents unintended public paths;
CORS only controls which browser origins may call an endpoint; it is not identity, authorization, or a boundary for non-browser clients.

Avoid the broad “allow Azure services” exception unless its cross-customer scope is accepted. IP firewall guidance explicitly warns about breadth.

Encryption boundaries¶

service-managed keys encrypt at rest by default;
customer-managed keys add a Key Vault-controlled encryption layer and operational dependencies for identity, key permissions, soft delete/purge protection, rotation, regional availability, backup, and recovery;
Always Encrypted performs property-level client-side encryption so plaintext/key is not exposed to the service; it affects queryability, index policy, SDK support, item size, and key lifecycle.

Always Encrypted uses data-encryption keys wrapped by Key Vault keys and a container encryption policy. Deterministic encryption can support equality comparisons for eligible fields but reveals equality patterns; randomized encryption provides stronger pattern protection but prevents equality query. Never encrypt the partition key or required system fields without verifying current support.

CMK protects service-side at-rest encryption; Always Encrypted protects selected values from the service boundary. They are not interchangeable. Test key disable/delete, rotation, restored-account key access, and break-glass recovery.

Choose and execute data movement¶

Select from volume, rate, downtime, transform, ordering, delete handling, source/target support, network, identity, checkpoint, and validation requirements:

Mechanism	Good fit	Important behavior
current SDK bulk support	controlled app migration/backfill	parallel independent operations; partition and throttle-aware client; own checkpoint/reconciliation
Azure Data Factory / Synapse pipeline	scheduled copy and transforms	connector/source/sink support, DIU/integration runtime, schema mapping, retries and parallelism
Kafka connector	Kafka ecosystem streaming	source/sink offset, partition mapping, delivery semantics and target idempotency
Azure Stream Analytics	streaming query/window transformation	input/output compatibility, late/out-of-order events, partitioning, retries
Spark connector	large Spark read/write/transform	transactional versus analytical source, Spark partitioning, RU/capacity pressure
IoT Hub custom Cosmos DB endpoint	direct routed device messages	synthetic partition-key template, identity/network and downstream throughput
change feed	continuous projection/migration	latest-version from beginning can bootstrap extant items, but not deleted/intermediate history; leases/replay/idempotency
Fabric mirroring	analytical replica in OneLake	not an operational container-to-container migration

For bulk movement:

inventory source count/size/schema/keys/TTL/system fields and target limits;
provision target partition/index/throughput/network/identity before copying;
create deterministic IDs and preserve or intentionally transform partition semantics;
checkpoint source ranges/pages and make target writes idempotent;
throttle to protect production and record rejected/dead-letter items;
reconcile counts by partition, hashes/aggregates, representative queries, TTL, permissions, index policy, and business reads;
if online, capture changes during the backfill and define a cutover high-water mark;
retain rollback and delete neither source nor logs until acceptance.

The older bulk executor library remains documented, but new .NET work should use SDK v3 bulk support. Treat that as a legacy implementation detail, not the concept of bulk operations itself.

Implement DevOps and infrastructure as code¶

Use declarative deployment for stable desired resource state and imperative commands for operational transitions that should not be re-applied blindly.

Operation	Preferred pattern
account/database/container, regions, consistency, backup, network, throughput, index policy, RBAC	ARM/Bicep (or governed equivalent), parameterized and version-controlled
data seeding/migration, conditional restore, one-time failover test, backfill	idempotent imperative workflow with approval/checkpoint/evidence
standard -> autoscale throughput migration	explicit CLI/PowerShell operation after compatibility/cost checks
regional failover	controlled runbook with health gates, application validation and audit

The ARM template examples cover multi-region accounts, throughput, analytical store, server-side code, and Entra/RBAC. Azure PowerShell examples include throughput migration and custom index policy.

Safe indexing-policy deployment¶

export/baseline policy and important query metrics;
add new required indexes without removing old coverage;
deploy and monitor index transformation progress/RU impact;
run representative old and new application versions;
compare query charge, results and latency;
only then remove obsolete indexes in a later change;
retain rollback definition and transformation monitoring.

Pipeline gates¶

lint/validate template and policy-as-code;
preview/what-if and detect destructive resource recreation;
deploy to isolated environment;
run emulator tests plus cloud integration tests for identity/network/RU behavior;
validate item address, query/index, transactional batch, concurrency and retry paths;
test change consumer replay and target idempotency;
confirm diagnostic settings, alerts, backup mode and restore permissions;
deploy progressively, observe, and preserve rollback.

Do not place items or secrets in ARM templates. Resource deployment success proves desired control-plane state, not application correctness.

7. Integrated design scenarios¶

Scenario A: global multitenant commerce¶

Requirements: customers read/write locally; each order plus outbox event must commit atomically; tenants vary greatly in size; regional outage must preserve service; analytics can lag minutes.

Model order and bounded line snapshots in one item; keep mutable catalog separately. Use deterministic IDs and schema version.
Use hierarchical partitioning such as tenant/order grouping only after testing prefix routing and per-tenant scale. Co-locate the outbox item under the same complete logical key needed by the transactional batch.
Use session consistency and propagate session tokens when the same user moves between stateless app instances.
Evaluate multi-region writes only with explicit order-state conflict semantics. If concurrent order mutation is unsafe, a single write-home per order/tenant with failover may be simpler.
Process outbox through change feed to Event Hubs with idempotent publication and checkpoint only after accepted side effect.
Mirror eligible containers to Fabric for analytics; model nested JSON and continuous-backup/topology limitations before committing.
Alert on p95/p99 application latency, 429 by key/range, change-feed lag, conflict backlog and mirror freshness.
Test regional routing, duplicate change delivery, stale ETag, restore to a point before an accidental mass update, and reconciliation.

Failure trap: a hierarchy beginning with tenant improves tenant routing but does not automatically make all tenant data one transaction. The complete hierarchical key defines the finest logical partition transaction boundary.

Scenario B: IoT telemetry and device state¶

Requirements: bursty writes, per-device recent history, 30-day retention, fleet-wide analytics, latest state lookup, and replay-safe alerts.

Partition telemetry by device plus time bucket or a justified hierarchical/synthetic strategy; load-test the noisiest device and current bucket.
Set item/container TTL for 30-day transactional retention; do not assume the delete occurs at the exact second.
Maintain latest device state as a deterministic item/projection. Make change-feed updates conditional on source timestamp/version so replay cannot regress state.
Use autoscale or measured provisioned throughput for sustained production bursts; serverless only after verifying limits and cost shape.
Route IoT Hub messages directly or through event processing with a synthetic key template aligned to the container. Validate identity, firewall, and route errors.
Use Fabric mirroring for broad time/fleet analytics when eligible, rather than repeatedly scanning the operational container.
Track normalized RU per partition, data size per key, ingestion retries, change lag and expired-data/storage trend.

Failure trap: /deviceId distributes a large fleet but one malfunctioning device remains a hot logical key. Adding account RU does not remove that single-key concentration.

Scenario C: secure customer profile service¶

Requirements: profile lookup by tenant/user, selected fields invisible to database operators, no account keys, private access, auditable recovery, and full-text discovery on approved fields.

Use (tenantId,userId) hierarchical partitioning only if tenant-prefix and exact-user patterns justify it; use deterministic user IDs.
Authenticate the managed workload with Entra and a minimum data-plane custom role. Disable key-based auth after every consumer is migrated.
Disable public access and configure Private Link/DNS/direct-mode ports. Test negative paths from unapproved networks.
Apply Always Encrypted only to sensitive eligible fields; leave partition/id and approved search fields available according to policy. Protect Key Vault permissions and rotation.
Feed only approved fields to Azure AI Search, with managed identity, private connectivity, deletion handling and index access governance.
Use continuous backup and test restore with CMK/client-encryption/key dependencies. Reapply data-plane roles and private endpoints if the restore target requires them.
Audit control changes and diagnostic requests without leaking encrypted plaintext or secrets.

Failure trap: customer-managed server-side encryption does not hide plaintext from the database service during processing. Property-level client encryption is the boundary for that requirement.

8. Hands-on labs¶

Use a disposable account and budget. Save commands/code, test data generator, before/after metrics, diagnostics, screenshots or query results, failure evidence, and cleanup proof. Do not run destructive/failover/restore experiments against shared production resources.

Lab 1: model and partition an order workload¶

Write ten concrete access patterns and invariants for orders, customers, products, and recent-order lists.
Produce embedded/reference and single/multiple-container alternatives.
Generate at least 100,000 items with deliberately skewed tenant sizes.
compare /tenantId, synthetic bucket, and hierarchical candidates using routed/fan-out queries.
Record storage distribution, normalized RU, request charge, page count and latency.
Defend the selected model and state the migration trigger if a tenant outgrows it.

Lab 2: SDK address, concurrency, batch, bulk, and TTL¶

Create one singleton client with current recommended settings and logging.
Compare a point read with an ID query using identical item/result.
implement create/read/replace/patch/delete and record status, ETag, RU and diagnostics.
Cause an ETag 412 with two concurrent writers and implement a correct reload/merge path.
Atomically write an aggregate and outbox record in a transactional batch under one key.
Bulk-load independent items and prove partial failures are not transactional.
Set per-item TTL overrides and observe expiration without assuming exact scheduling.

Lab 3: query and index experiment¶

Create nested arrays, optional/mixed-type properties and time-ordered items across partitions.
Write targeted and cross-partition parameterized queries using arrays, self-join, aggregate, subquery, type checks, strings, math and date functions.
Capture every page’s RU, continuation token, output/retrieved counts and index metrics.
Add a composite index for a real filter/order pattern; wait for transformation.
Exclude a large unqueried payload path and compare write RU/index storage.
demonstrate a query that becomes unsupported or expensive when its required index is removed, then restore safely.

Lab 4: region, consistency, and failure behavior¶

In an approved test account, add a second region and configure SDK preferred regions.
Compare permitted consistency levels with a read-after-write harness and record RU/latency.
Propagate and omit a session token across two simulated application instances.
Perform a planned failover using the documented runbook; validate endpoint routing and business transaction.
If multi-write is available, create a controlled conflict and observe the configured resolution.
Record achieved RTO/RPO indicators and restore original topology.

Lab 5: replay-safe change-feed projection¶

Create monitored, lease and materialized-view containers.
Run two processor instances with one processor name and observe lease balancing.
Use deterministic target IDs/source versions to make the handler idempotent.
fail after the target write but before checkpoint, restart, and prove replay does not duplicate/regress data.
use the estimator to record lag while stopped and drain rate after restart.
add a second consumer with a separate processor name and prove independent checkpoints.

Lab 6: analytical integration and search¶

Check Fabric-mirroring eligibility before enabling anything.
Mirror a test container, monitor initial sync, and reconcile counts/freshness.
Query nested JSON through the SQL analytics endpoint and document schema limitations.
execute an eligible time-travel query in the Fabric analytical target and explain why it is not source PITR.
Create an Azure AI Search indexer for approved fields; update and delete source data.
prove incremental update and configured deletion behavior; capture errors and reset/rebuild steps.
Document how an existing Synapse Link design differs and the “not for new projects” notice.

Lab 7: security and observability¶

Give a managed identity a minimum custom data-plane role and a separate operator minimum control-plane role.
connect with DefaultAzureCredential; prove denied operations remain denied.
configure private access and validate DNS plus gateway/direct connectivity; then disable public access.
enable diagnostic logs and query requests by status, operation and partition-key RU category.
create alerts for sustained normalized RU, 429/failure rate, availability and replication/change lag with action ownership.
apply client-side encryption to a supported field in a separate lab container and test allowed/disallowed query shapes.
remove temporary roles/endpoints/log destinations safely.

Lab 8: IaC, migration, backup, and recovery¶

Deploy account/database/container, consistency, regions, backup, network, throughput, index policy, identity and diagnostics through ARM/Bicep.
use a checkpointed SDK bulk script to backfill a newly partitioned container while a change consumer captures new writes.
reconcile counts and sampled content per partition; execute a rehearsed cutover and rollback.
migrate throughput between supported standard/autoscale modes with PowerShell or CLI and record state/cost implications.
run a planned regional failover command with health gates.
delete a disposable container after noting a restorable time; perform the supported PITR flow.
validate restored items, index, TTL, roles, network, keys, integrations and application transaction.
destroy only verified lab resources and retain the recovery report.

Lab 9: tenant-safe retrieval and memory¶

Before provisioning, choose an eligible account, supported vector/partition combination and real embedding model; record versions, dimensions, corpus size, cost limit and cleanup plan.
Use synthetic records for two tenants with colliding thread IDs and deliberately similar content. Enforce tenant/thread authorization from trusted application context.
Compare lexical, vector and hybrid queries with the same held-out relevance set. Record recall, RU, p95 latency, index state and scope; distinguish a tiny-data scan from the intended index.
Test a forged tenant value, stale summary, deleted source and replayed turn. Capture expected denial, deletion propagation, ETag conflict and idempotent result.
Build a grounded response with source references and an unanswerable case. Retain retrieval and answer-quality results separately.

Evidence: policy and SDK versions, authenticated scope, queries, measured results, failed access attempts and cleanup. Without a compatible cloud environment, complete the design worksheet and label execution pending; arithmetic alone does not validate the service.

Lab 10: review generated changes and operational boundaries¶

In a disposable project, review an Agent Kit proposal against the same access-pattern and failure tests used for a manual change. Record the kit revision, proposed diff, accepted/rejected suggestions and measured evidence.
Design a copy-job cutover with mode prerequisites, target TTL/index settings, source-write pause, drain/completion, reconciliation and rollback. Execute only on disposable resources when prerequisites are available.
Draft a masking test matrix for reader, unmask and writer identities, including write responses and downstream copies. Account enablement is irreversible; use a dedicated disposable account for an executed test.
Evaluate a Fleet design on paper before provisioning: account/region/write compatibility, dedicated demand, pool headroom, partition caps and hourly versus incident monitoring.

Evidence: distinguish design-only decisions from executed requests. Do not enable paid Fleet capacity merely to complete a worksheet.

9. Original knowledge checks¶

These are original prompts, not recalled exam questions. Answer with the decision, dependency chain, evidence, failure mode, and corrective action.

Why can a high-cardinality partition key still create a hot partition?
An item is always fetched by tenant and order ID. Why is a point read preferable to WHERE id = @id, and what address must the caller know?
When should bounded children be embedded, and what two growth/concurrency signals would make you reference them instead?
A tenant may exceed a single logical partition but most queries start with tenant. Compare synthetic buckets with a hierarchical key.
Why does a transactional batch require the same partition-key value, and how would you atomically record an outbox message?
A bulk import reports 98% success. Why is the container not transactionally consistent, and how do you resume safely?
Two writers replace the same profile. Show how _etag prevents lost update and why blind retry is wrong.
When can an item-level TTL override help, and why is TTL not an exact-time workflow trigger?
What does a continuation token guarantee, and what does it not guarantee about a changing result set?
Why should CosmosClient normally be a singleton, and what diagnostics reveal excessive client creation?
Compare direct and gateway mode for a private-endpoint workload behind a restrictive firewall.
The average RU use is 30%, but 429s are high. Which partition metric and data distribution evidence do you inspect?
State an application requirement suited to each of strong, bounded staleness, session, consistent prefix, and eventual consistency.
A session-consistent user does not read their write after switching web servers. What state may need propagation?
When do multi-region writes create a business conflict, and why may last-writer-wins be unsafe?
Distinguish service-managed failover, manual failover, per-partition automatic failover, and application traffic routing.
A Fabric report is stale but source queries are current. Which mirror prerequisites, replication signals and schema constraints do you check?
Why is Synapse Link knowledge still in this guide even though it is not recommended for new projects?
What is the difference between operational change feed, analytical-store CDC, and Fabric mirroring?
A change-feed handler writes its target and crashes before checkpoint. How do you avoid duplicate business effect?
Why do two independent projections need separate processor names/lease state?
How do included paths, excluded paths and composite indexes change read/write RU tradeoffs?
Why add a replacement index before removing the old one in production?
When can integrated cache reduce RU, and which staleness/capacity behavior must be tested?
Compare control-plane Azure RBAC with Azure Cosmos DB data-plane RBAC and Data Explorer access.
Contrast customer-managed keys and Always Encrypted in terms of who can see plaintext and what queries remain possible.
Why are replication, backup, change feed, Fabric time travel and TTL five different controls?
A restored account contains data but the application fails. Which external/control settings must be revalidated?
Choose among SDK bulk, ADF, Kafka, Stream Analytics, Spark, IoT Hub routing and change feed for three different movement patterns.
Why is a successful ARM deployment insufficient evidence that the application works?

Answer checkpoints¶

Use these to check your reasoning after attempting the questions.

Cardinality counts distinct values; one value can still dominate storage or requests. Inspect peak demand by logical key and physical range.
Supply both id and the complete partition key. A point read addresses the item directly; an ID query adds query work and may fan out.
Embed bounded children read/updated with the parent. Unbounded size and independent/highly contended updates favor references.
Synthetic buckets require deterministic routing or multiple bucket reads. A hierarchy supports prefix routing and deeper distribution; the complete key still governs transactions.
The batch transaction is scoped to one logical partition. Put aggregate and outbox under the same complete key and inspect both operation results.
Bulk operations commit independently. Resume failed work with stable IDs, checkpoints and reconciliation; do not replay side effects blindly.
Send the read ETag as an If-Match condition. On 412, reread and reevaluate the business change before another write.
Item TTL supports different retention periods when container TTL is enabled. Query disappearance and eventual physical deletion are separate; neither invokes your workflow exactly on schedule.
It marks supported query progress, not a frozen result set or authorization. Bind it to query/scope; same-SDK tokens do not expire by time alone.
Reuse the account client to avoid repeated metadata, connection and CPU work. Inspect client counts, connection churn and SDK timelines.
Direct mode needs the documented TCP connectivity in addition to metadata access; gateway uses HTTPS. Validate private DNS and the selected SDK's support.
Inspect maximum normalized RU by range, hot logical keys and request skew. An account-wide average hides saturation of one range.
Strong: latest committed value; bounded: bounded ordered lag; session: that session's read-your-writes; prefix: ordered but possibly stale; eventual: convergence with possible reordering. Match each to the business tolerance.
Preserve the appropriate session token across the application's client instances. Preferred region alone does not carry session context.
Concurrent regional changes to one logical item can conflict. Last-writer-wins can discard a valid business update; test domain-specific reconciliation.
Service-managed and manual failover choose regional recovery paths with different triggers; partition failover has a narrower supported scope. Application traffic routing separately sends users to a healthy application instance.
Check source eligibility, permissions/network, replication status/lag and nested-schema mapping; test a known source update at the analytical endpoint.
It remains in the July baseline for existing deployments. Follow the current new-project transition notice and your exam date.
Operational feed drives item-change consumers; analytical CDC concerns the analytical-store path; mirroring maintains a Fabric analytical copy. Compare each path's retention, deletes and replay behavior.
Deduplicate or condition target writes by stable source identity/version; the crash window can replay a successfully written target.
Shared processor names/leases cooperate on one consumer. Independent projections need independently advancing checkpoints.
Wider indexing supports more queries at write/storage cost; exclusions save work but may break routes. Composite path order/direction must match supported query shapes.
Keep the old query path working while the new index transforms, then prove both application versions before removing old coverage.
Eligible repeated reads through the dedicated gateway can hit the cache. Measure staleness after writes, request-shape matching, capacity, failures and total cost.
Management roles govern resources; native data roles govern items/queries. Portal visibility does not prove either every management action or item access.
CMK adds control of at-rest key dependencies; the service still processes plaintext. Client encryption hides eligible plaintext from the service and constrains searchable fields/operators.
Replication serves availability, backup historical recovery, change feed derived processing, Fabric time travel analytical history and TTL expiration. None supplies all five guarantees.
Revalidate endpoint/configuration, roles, network/DNS, key access, diagnostics, integrations and actual application transactions.
Examples: SDK bulk for controlled idempotent backfill; Spark for large transformations; change feed for replay-safe projections. Other choices depend on streaming ecosystem, source/sink support and operational ownership.
ARM success establishes resource deployment. Data-path identity, queries, indexes, retries, consistency and business behavior still need execution evidence.

October scenario checks¶

Does a vector shard enforce tenant authorization? No. It scopes index search; validate caller-to-tenant access and server-side query scope separately, especially with a shared service identity.
Does a masked query prove a writer cannot see the original field? No. Current masking documentation excludes write responses from that guarantee and describes other inference/exposure paths.
Can latest-version feed recover every deleted or intermediate item version? No. Starting from the beginning can bootstrap surviving latest items; select the appropriate mode/checkpoint and recovery mechanism for history.
What is the idealized drain time for 6,000 pending units, 1,000 processed/s and 400 arriving/s? Ten seconds using the net 600 units/s. It does not drain if processing only matches arrivals.
Why can two vector queries return slightly different top results without a data-consistency defect? Approximate search and independently built replica indexes can vary. Measure recall and ground truth before blaming consistency.
Does installing Agent Kit give an application durable memory? No. It supplies coding guidance; persisted state, retrieval, authorization, retention and runtime tests remain application work.

10. Final readiness checklist¶

Places to learn¶

October 28 learning route and evidence task¶

The official DP-420 course is now Build AI applications with Azure Cosmos DB, still four instructor-led days. The Pluralsight path still advertises the older five-domain structure and 9 hours, with its latest displayed update in January 2026. Use it selectively for database foundations and map AI retrieval, memory and authorization gaps against the October 6 blueprint. The Agent Kit article’s improved constructor is now balanced; keep its load-distribution caveat rather than repeating an unsupported syntax defect.

Original retrieval-resource worksheet (about 45–60 minutes, editorial estimate): For a two-tenant corpus, record partition-routing choice, vector-shard choice, authenticated scope, relevance target and RU/latency measurement. Add one skewed-tenant counterexample to a proposed year-based key. Separate an article’s measured example from the result your own workload would need to demonstrate.

Answer checkpoint: Partition routing and vector-index sharding solve different parts of the request path; neither replaces application authorization. A benchmark percentage is not a guaranteed improvement.

This is not a complete list, and it is not a recommendation to consume everything. Pick the formats and gaps that work for you: one current primary path, hands-on labs, targeted documentation, and one ethical readiness check are usually more useful than passively completing every course. Times are page-published durations where available; otherwise they are clearly labeled estimates. Catalogs, durations, prices, access, and blueprint alignment change—verify them before purchase. Practice products should teach and explain; do not use brain dumps or material claiming real exam questions.

Start with Microsoft¶

Resource	Access	Estimated time	Best use
Official DP-420 study guide	Public	45–75 min for blueprint mapping	Current October 6 scope; July organization is historical foundation
DP-420 Microsoft Learn course page	Public self-study; paid instructor option	4 instructor-led days; roughly 25–40 hours self-study plus labs (estimate)	Primary structured path across the published domains
Azure Cosmos DB documentation	Public	15–30 hours selectively (estimate)	Current product truth, limits, SDK guidance and deep remediation by objective
Microsoft free Practice Assessment, linked on the credential page	Public; sign-in may be required	45–90 min per attempt plus review (estimate)	Diagnostic baseline and gap review; explanations are more valuable than memorizing answers
Microsoft exam sandbox	Public	20–30 min	Question-interface familiarity, not technical coverage
Azure Cosmos DB for NoSQL .NET samples	Public	4–12 hours selectively (estimate)	Current .NET SDK patterns to run, alter, instrument and break safely

Video and expert learning¶

Resource	Access	Estimated time	Best use and freshness note
Pluralsight DP-420 path	Paid/trial depending plan	9 hours published, plus labs/review	Five-domain path with a practice exam; page showed course updates through January 2026. Gap-check all October AI retrieval, memory, security and analytics objectives.
O'Reilly Azure Cosmos DB Developer Specialty course	Paid subscription/trial	4h34m published, plus practice	Mohit Batra, January 2025; broad exam course with quizzes. Reconcile legacy Synapse Link and the current October AI-focused outline.
O'Reilly DP-420 crash course	Paid; schedule/access varies	Four hours published when scheduled	Reza Salehi live overview; verify next event dates and treat older “Core/SQL API” wording as API for NoSQL terminology.
Udemy DP-420 hands-on course	Paid; price varies	6h47m / 64 lectures published, plus labs	Page showed July 2026 update and many demos, but also an older “October 2023 topics” claim; gap-check every current October objective.
Microsoft Azure Cosmos DB YouTube channel	Public	3–10 hours selectively (estimate)	Product announcements, engineering explanations and demos; select videos by weak objective and date.
Microsoft Reactor YouTube channel search for Cosmos DB	Public	2–8 hours selectively (estimate)	Workshops and developer sessions; verify product version and avoid treating any one playlist as full exam alignment.
John Savill Azure Cosmos DB channel search	Public	1–4 hours selectively (estimate)	Supplemental Azure architecture explanations; not a complete DP-420 course. Check video descriptions for linked whiteboards/resources.

Books, practice, and labs¶

Resource	Access	Estimated time	Best use and caution
Microsoft Press DP-420 video by Tim Warner	Paid	11+ hours published	Hands-on 2023 course. Strong foundation, but reconcile all current October 6 objectives, Fabric mirroring, hierarchical keys, and current product notices.
Whizlabs DP-420 training and practice	Paid; offering varies	Approximately 8–15 hours for course/labs/practice (estimate; page did not expose reliable counts)	Additional labs and readiness checks; verify counts, update date and October 2026 alignment before purchase.
MeasureUp DP-420 practice test	Paid; demo available	2–4 hours per full attempt and explanation review (estimate)	Page listed 120 questions but a June 2022 release and older objective terminology. Use for reasoning practice only after verifying current alignment.
Udemy DP-420 topic catalog	Paid catalog; price varies	Varies	Compare recent course/practice options, instructor updates, previews and explanations. Reject any product claiming leaked/real exam content.
Azure Cosmos DB design-pattern samples	Public	6–15 hours selectively (estimate)	Implement and benchmark patterns such as hierarchical partitioning; turn examples into measured labs rather than copying blindly.

A practical study sequence¶

Spend 45–75 minutes mapping the official blueprint to what you can demonstrate today.
Complete the Microsoft Learn path or one current structured alternative; do not stack several passive courses.
Build Labs 1–5 and retain RU, diagnostics, partition, index, consistency, and replay evidence.
Read the exact official docs for every failed experiment and uncertain answer; complete Labs 6–8.
Take the free Microsoft Practice Assessment once, review every option, and map gaps to the blueprint for your exam date. Do not infer October coverage merely from the DP-420 label.
Use one paid practice product only if explanations and current-objective alignment add value.
Recheck the official study guide, credential page, lifecycle, support notices, limits and pricing immediately before the exam.

For the current October outline, include Labs 9–10 and targeted C#/Python practice. Allow an estimated 12–20 additional hours for the new material and evidence collection, with more time if embeddings, Fabric or authorization testing are new to you. Older course durations above are historical catalog observations; three paid pages were access-blocked during this review and other catalog access does not prove lesson access or October alignment.

Focused blog reading¶

Introducing the Azure Cosmos DB Agent Kit, Sajeetharan Sinnathurai, Microsoft, January 22, 2026. Estimate 20–30 minutes with the current repository. Read for a review workflow, then identify which suggestions need measurements. The constructor in the current public body is balanced; the earlier syntax-defect observation is historical. A tenant/year key can still concentrate current-year writes. Treat examples and performance claims as proposals to test; the kit was not installed or executed here.
Sharded DiskANN for multitenant vector search, James Codella, Shivam Atri and Haiyang Xu, Microsoft, April 24, 2025. Estimate 25–40 minutes with current search docs. Useful for separating partition routing from index sharding and comparing recall, latency and RU. Published benchmark gains are workload-specific; some query samples put WHERE after ORDER BY, so use current query syntax. Exercise: design an authorized-tenant comparison with identical data and a held-out relevance set. Samples and benchmark were not executed here.

This guide is an independent public-source synthesis. It is not affiliated with or endorsed by Microsoft, GitHub, HashiCorp, or any training provider.