AZ-104
Deep Dive
Azure's multi-model, globally distributed NoSQL database. The AZ-104 tests consistency concepts, partitioning, RU/s, global distribution, and the available APIs.
Contents
Azure Cosmos DB is a fully managed, multi-model NoSQL database service designed to scale globally with single-digit millisecond latency. It guarantees comprehensive SLAs covering availability, throughput, consistency, and latency.
Unlike relational databases, Cosmos DB is schemaless — documents or entities don't need to follow a fixed schema.
Latency SLA
<10ms read, <10ms write (P99) in the local region
Availability SLA
99.999% for multi-region write. 99.99% single-region
Scalability
From kB to PB. Millions of requests/second with no redesign
Global distribution
Replicate to any Azure region with one click
Cosmos DB resource hierarchy
Cosmos Account
Top-level unit. Defines the API, consistency configuration, and regions.
Database
Logical container of containers. Can have shared throughput.
Container
Unit of scalability. Defines partition key, throughput, TTL, and indexes.
Item
JSON document (NoSQL API), row (Cassandra), node/edge (Gremlin), etc.
Cosmos DB uses a unified engine with multiple API "fronts." The API defines the data model and the wire protocol. It cannot be changed after the account is created.
| API | Data model | Protocol | Migrate from | Best for |
|---|---|---|---|---|
| NoSQL (native) | JSON documents | HTTP/HTTPS REST | MongoDB, DynamoDB (with changes) | New apps, JSON, frequent schema changes |
| MongoDB | BSON documents | MongoDB wire protocol | MongoDB on-prem/Atlas | Lift-and-shift of MongoDB apps without changing driver code |
| Cassandra | Wide-column rows | CQL (Cassandra Query Language) | Apache Cassandra on-prem | Existing Cassandra apps, time series, IoT |
| Gremlin (Graph) | Graphs (vertices and edges) | Gremlin over WebSocket | Neo4j, TinkerPop | Social networks, knowledge graphs, fraud detection |
| Table | Key-value (table) | OData / REST | Azure Table Storage | Migrating from Azure Table Storage with higher throughput |
| PostgreSQL (distributed) | Distributed relational | PostgreSQL wire | PostgreSQL on-prem | Relational apps that need horizontal scale (Citus) |
For the AZ-104 exam
The AZ-104 doesn't go deep into every API. Focus on: NoSQL API (the native one, with all of Cosmos's features), MongoDB API (driver compatibility, lift-and-shift). The Table API is the migration path from Azure Table Storage with more scale.
Cosmos DB's consistency model is one of the most heavily tested topics. It defines the balance between data consistency and latency/availability. It's configured at the account level and can be relaxed per read operation.
Strong
Guarantees always reading the most recent version (linearizability)
Not available on accounts with multi-region writes. The most expensive.
Latency
Higher latency — must read from a majority of replicas
Bounded Staleness
Reads can lag by K versions OR T seconds (you define the limits)
Good for apps that tolerate some lag but need global ordering. Write order is guaranteed.
Latency
High latency for reads outside the region, similar to Strong within the write region
Session (default)
Guaranteed consistency for the client (session) that writes. Other clients may see an earlier version.
The default and recommended for most apps. "Read-your-writes" for the writing client.
Latency
Low — the most-used level
Consistent Prefix
You never see out-of-order reads. If A, B, C are written — you will never see C without B.
Doesn't guarantee reading the most recent, but the order is consistent.
Latency
Low
Eventual
No guarantee of order or of reading the most recent. Only 'will eventually converge'.
For cases where order doesn't matter: approximate counters, like counts, etc.
Latency
Minimum latency, maximum availability
Mnemonic rule
From strongest to most eventual: Strong → Bounded Staleness → Session → Consistent Prefix → Eventual. The stronger the consistency, the higher the read latency and the lower the availability. The default (Session) is the optimal balance for 90% of cases.
How partitioning works
Cosmos DB divides data into logical partitions based on the partition key value. Multiple logical partitions map to physical partitions that Cosmos manages automatically.
Limits per logical partition
Max. 20 GB of data
Max. 10,000 RU/s of throughput
Each physical partition has a max of ~10,000 RU/s and ~50 GB. Cosmos automatically redistributes (repartitions) as data grows.
Good Partition Key
Bad Partition Key
Synthetic partition key
If no natural field is a good PK, create one by combining several fields. E.g.: UserId + DateTime → "user123_2024-01"
A Request Unit (RU) is Cosmos DB's performance currency. 1 RU = reading a 1 KB item with session consistency. Writes, complex queries, and cross-partition queries consume more RUs. The cost depends on item size, consistency, and operation type.
Provisioned throughput (manual)
You set a fixed number of RU/s (min 400 RU/s per container). You always pay for that throughput whether it is used or not.
When to use
Predictable load, strict latency SLA.
Autoscale (automatic throughput)
You set a maximum RU/s. Cosmos scales between 10% and 100% of that maximum based on demand. You are billed for the highest level reached each hour.
When to use
Variable or unpredictable loads. Ideal for dev/test and production with spikes.
Serverless
No provisioning — you pay only for the RUs consumed. No cost when there is no activity. No latency SLA guarantee at peaks.
When to use
Intermittent workloads, low traffic, early development.
Approximate cost of common operations (1 KB items)
| Operation | Approx. RU | Notes |
|---|---|---|
| Point read (id + partition key) | 1 RU | The cheapest operation. Always use point read when possible. |
| Write (insert/replace) | 5 RU | More expensive than a read because it updates all indexes. |
| Query with partition key | 2-3+ RU | Varies with complexity, number of results, and indexes. |
| Cross-partition query | Much higher | Fans out to all partitions — avoid when possible. |
Cosmos DB can replicate data to any Azure region with a single click. Global distribution enables local reads (low latency) and is key to global availability.
Multi-region write modes
Single-write region
Only one region accepts writes. The others are read replicas. Automatic or manual failover if the write region fails.
Multi-region writes (Multi-master)
All configured regions accept writes. Minimal write latency in any region. Requires managing write conflicts.
Conflict resolution (multi-write)
Last-Write-Wins (LWW)
The item with the highest _ts (timestamp) wins. Default. Can use any numeric field in the document.
Custom (Stored Procedure)
A Cosmos stored procedure decides which version prevails. Maximum flexibility for business logic.
Manual (Conflict Feed)
Conflicts are written to the "conflict feed" for the app to resolve manually.
Time-to-Live (TTL)
Lets items expire automatically after N seconds. Cosmos deletes them in the background without consuming write RUs from the user.
→ TTL on container: applies to all items that don't have their own TTL
→ TTL = -1: immortal (does not expire even if the container has TTL)
→ TTL = 0 or null: inherits the container's TTL
→ TTL on item: overrides the container's TTL for that specific item
Ideal for: user sessions, temporary data caches, expiring messages.
Change Feed
An ordered stream (by partition key) of all inserts and updates in a container. Lets you build event processing pipelines without polling.
Use cases: materializing views, syncing caches, audit logs, replication to other systems.
Control plane vs Data plane
Control plane (ARM)
Create/delete accounts, databases, containers. Manage configuration. Authorized with standard Azure RBAC (Owner, Contributor, Cosmos DB Account Reader).
Data plane
Read/write documents. Two methods: 1) Cosmos DB RBAC (built-in roles: Cosmos DB Built-in Data Reader, Data Contributor) — recommended. 2) Master Keys / Resource Tokens — legacy.
Encryption and networking
• Encryption at rest: automatic AES-256, not user-configurable
• Customer-managed keys (CMK): in Azure Key Vault. If the key is revoked, data becomes inaccessible
• Encryption in transit: TLS required
• Private Endpoints: same as Storage and SQL — private IP in a VNet
• IP Firewall: list of allowed IPs or CIDR ranges
• Virtual Network ACLs: restrict access to specific subnets
Resource Tokens — granular access
For temporary, granular read/write access (per container or item): the app generates a resource token with specific permissions and hands it to the client. Expires in max. 5 hours. Doesn't expose the master keys to the client.
Did you get this topic?
Test what you just learned
A global application needs users in Europe to read data with the lowest possible latency. The exact consistency of data between regions can tolerate a lag of up to 30 seconds. Which Cosmos DB configuration should you use?
Put what you learned to the test with original AZ-104 exam questions.
Start AZ-104 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.