AZ-204 - CosmosDB
Introduction to CosmosDB
Azure Cosmos DB is a globally distributed, multi-model NoSQL database service. It provides single-digit millisecond response times, automatic scaling, and guaranteed availability with comprehensive SLAs.
Key Features
Multi-Model Support
Cosmos DB supports multiple data models through APIs: NoSQL (Core/SQL), MongoDB, Cassandra, Gremlin (Graph), and Table.
Global Distribution
Replicate data to any number of Azure regions worldwide with turnkey global distribution. Supports multi-region writes for low-latency access globally.
Automatic Indexing
All data is automatically indexed without requiring schema or index management. Queries are fast by default.
Create a CosmosDB Account
A Cosmos DB account is the top-level resource. It defines the API type, global distribution settings, and default consistency level. You choose the API at account creation time and cannot change it later.
Resource Hierarchy
| Level | Description |
|---|---|
| Account | Top-level resource; defines API, regions, consistency |
| Database | Logical namespace for containers |
| Container | Unit of scalability; stores items (documents); has a partition key |
| Item | Individual document/record within a container |
Global Replication Options
Cosmos DB allows you to add or remove Azure regions at any time. When multiple regions are configured, data is automatically replicated. You can enable multi-region writes for active-active scenarios.
Automatic Failover
If a region becomes unavailable, Cosmos DB automatically fails over to the next prioritized region with no data loss (when using Strong or Bounded Staleness consistency).
CosmosDB Keys and Security
Each Cosmos DB account has primary and secondary keys (read-write and read-only). Use read-only keys for applications that only need to query data. For production, prefer Microsoft Entra ID (RBAC) authentication over keys.
Create a CosmosDB Container
A container is the fundamental unit of scalability. When creating a container, you must specify a partition key -- this determines how data is distributed across physical partitions.
- Choose a property with high cardinality (many distinct values)
- Distribute requests evenly across partitions
- Include the partition key in frequent queries for efficient single-partition lookups
Throughput Models
| Model | Description |
|---|---|
| Provisioned Throughput | Set a fixed number of Request Units per second (RU/s). Billed hourly. Supports autoscale. |
| Serverless | Pay per request. No provisioning. Best for intermittent workloads. |
Add Documents to CosmosDB
Items (documents) are JSON objects stored in containers. Each item must have a unique id property and the partition key value. You can add items via the Azure Portal Data Explorer, SDKs, or REST API.
Setting Data Consistency Options
Cosmos DB offers five consistency levels, ranging from strongest to weakest. This is one of the most heavily tested topics on the AZ-204 exam.
Five Consistency Levels
Strong
Reads always return the most recent committed write. Linearizable. Highest latency, lowest availability for globally distributed data.
Bounded Staleness
Reads may lag behind writes by at most K versions or T time interval. Provides a staleness bound guarantee.
Session
Within a single session, reads are guaranteed to be consistent with writes (read-your-own-writes). Default consistency level.
Consistent Prefix
Reads never see out-of-order writes. If writes are A, B, C -- reads will see A, AB, or ABC but never AC or B alone.
Eventual
No ordering guarantee for reads. Lowest latency and highest availability. Reads may return stale data.
Managing Change Feed Notifications
The change feed is an immutable, ordered log of changes to items in a container. It captures inserts and updates (not deletes by default). Use it to trigger downstream processing, event sourcing, or materialized views.
Change Feed Processor
A library-based approach that handles lease management, partitioning, and parallel processing of changes across multiple consumers.
Azure Functions Trigger
The simplest way to consume change feed -- an Azure Function automatically triggers when changes are detected in a Cosmos DB container.
Key Terms
| Term | Definition |
|---|---|
| Partition Key | A property used to distribute data across physical partitions. Chosen at container creation time and cannot be changed. |
| Request Unit (RU) | A normalized measure of throughput cost. A point read of a 1 KB item costs 1 RU. |
| Consistency Level | A configuration that determines the trade-off between read consistency, latency, and availability. Five levels: Strong, Bounded Staleness, Session (default), Consistent Prefix, Eventual. |
| Change Feed | An immutable, ordered log of insert and update operations in a Cosmos DB container. Used for event-driven architectures. |
| Container | The fundamental scalability unit in Cosmos DB. Stores items (JSON documents) and is partitioned by a partition key. |
| Multi-Region Writes | A feature that allows write operations in multiple Azure regions simultaneously for active-active scenarios. |
- Memorize the 5 consistency levels in order: Strong > Bounded Staleness > Session > Consistent Prefix > Eventual.
- Session is the DEFAULT consistency level.
- Change feed captures inserts and updates, NOT deletes (unless soft-delete pattern is used).
- Partition key cannot be changed after container creation -- choose wisely.
- 1 RU = cost of a point read of a 1 KB document.
- API type is chosen at account creation and cannot be changed.
- Azure Functions Cosmos DB trigger uses the change feed under the hood.
Practice Questions
Q1. What is the default consistency level in Azure Cosmos DB?
- Strong
- Bounded Staleness
- Session
- Eventual
Answer: C
Session consistency is the default level in Cosmos DB. It guarantees read-your-own-writes within a session and provides a good balance of consistency and performance.
Q2. Which operations does the Cosmos DB change feed capture by default?
- Inserts, updates, and deletes
- Inserts and updates only
- Only inserts
- Only updates and deletes
Answer: B
The change feed captures inserts and updates by default. Deletes are not captured unless a soft-delete pattern is implemented (updating a property before deleting).
Q3. A developer needs to choose a partition key for a Cosmos DB container storing user orders. There are millions of users, each with multiple orders. Which property is the best partition key?
- orderId (unique per order)
- userId (many orders per user)
- orderDate (same date for many orders)
- status (only a few distinct values)
Answer: B
userId provides high cardinality with even distribution. It also enables efficient queries for a specific user's orders as a single-partition query. orderId would work but makes it harder to query a user's orders. status has very low cardinality and would create hot partitions.
Q4. Which consistency level guarantees that reads never see out-of-order writes but may see stale data?
- Strong
- Session
- Consistent Prefix
- Eventual
Answer: C
Consistent Prefix guarantees that reads never see out-of-order writes. If writes are A, B, C, reads will see A, AB, or ABC but never out-of-order combinations like AC.
Q5. What is the simplest way to consume the Cosmos DB change feed?
- Azure Event Grid
- Azure Functions Cosmos DB trigger
- Azure Logic Apps
- Azure Service Bus
Answer: B
The Azure Functions Cosmos DB trigger is the simplest way to consume the change feed. It automatically triggers when changes are detected in a container, with no manual lease or partition management required.
AZ-204 Developing Azure Solutions - Table of Contents
Master all exam topics with comprehensive study guides and practice questions.