This chapter covers Azure Cosmos DB, a fully managed NoSQL database service designed for modern, globally distributed applications. For the AZ-900 exam, understanding Cosmos DB is part of Domain 2 (Azure Architecture and Services), specifically Objective 2.4: Describe database services. While this objective area carries about 5-10% of the exam weight, Cosmos DB is a frequently tested service because of its unique global distribution and multi-model capabilities. By the end of this chapter, you'll know what Cosmos DB is, its key features, use cases, and how it compares to other Azure database services.
Jump to a section
Imagine you run a chain of bookstores across the world. You need a catalog system that lets any customer in any store instantly find and reserve any book, no matter which warehouse holds it. A traditional database is like a single card catalog cabinet in one store—if a customer in Tokyo asks for a book stored in New York, a clerk must call New York, wait for a search, and then mail the book. Azure Cosmos DB is like a fully automated, globally distributed library system. Every bookstore has a local copy of the entire catalog, updated in real time via a high-speed network. When a customer in Tokyo requests a book, the local catalog instantly shows availability and the book is printed on demand from a nearby warehouse. The system automatically replicates any change (like a new bestseller or a returned copy) to all stores within milliseconds, so every location sees the same data. It also offers multiple ways to look up books: by title, author, ISBN, or even by reading level—this is like Cosmos DB's multiple APIs (SQL, MongoDB, Cassandra, Gremlin, Table). You pay only for the storage and throughput you use, and you can scale up during holiday rushes without any manual intervention. The key mechanism is that the system doesn't rely on a single master catalog; it uses a multi-master replication model, meaning any store can accept a change and the system resolves conflicts automatically. This is exactly how Cosmos DB works: it is a globally distributed, multi-model database service that offers turnkey global distribution, elastic scaling of throughput and storage, and multiple consistency models to balance performance and data freshness.
What is Azure Cosmos DB?
Azure Cosmos DB is a fully managed NoSQL database service that provides turnkey global distribution, elastic scaling of throughput and storage, and single-digit millisecond latencies at the 99th percentile. It is designed for applications that need to scale globally and serve data to users anywhere in the world with low latency. Unlike traditional relational databases, Cosmos DB is schema-agnostic and supports multiple data models, including documents, key-value, graph, and column-family. This flexibility makes it ideal for modern applications like IoT, gaming, retail, and web/mobile apps.
The Business Problem It Solves
Traditional databases are often deployed in a single region. If your application grows globally, users far from the database experience high latency. Moreover, if that single region goes down, the entire application becomes unavailable. Cosmos DB solves these problems by allowing you to replicate your database across any number of Azure regions with a single click. It handles automatic failover, multi-master writes, and provides multiple consistency levels so you can choose the right balance between performance and data freshness.
How It Works – Step-by-Step Mechanism
Global Distribution: When you create a Cosmos DB account, you select one or more Azure regions. Azure automatically replicates your data to all selected regions. You can add or remove regions at any time with zero downtime.
Multi-Master Writes: Cosmos DB supports multiple write regions. This means any region can accept writes, and the service synchronizes the data across all regions. This is a key differentiator from other databases that only allow a single master for writes.
Consistency Levels: Cosmos DB offers five well-defined consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual. Each level provides a different trade-off between consistency and performance. For example, Strong consistency ensures that reads always see the latest write, but it increases latency. Eventual consistency offers the lowest latency but may return stale data.
Request Units (RUs): Throughput is measured in Request Units per second (RU/s). One RU roughly equals the cost of reading a 1KB document. You provision RUs at the database or container level, and you can scale them up or down at any time. RUs are consumed by read, write, and query operations.
Multiple APIs: Cosmos DB provides multiple APIs to support different data models and existing application stacks. These include SQL API (document), MongoDB API, Cassandra API, Gremlin API (graph), and Table API (key-value). This means you can use Cosmos DB with your existing NoSQL skills and tools.
Key Components
Cosmos DB Account: The top-level resource that contains all your databases. You define the regions and consistency level at the account level.
Database: A logical container for one or more containers (tables, collections, graphs).
Container: The fundamental unit of scalability. All data is stored in containers, which are automatically partitioned. Each container has a partition key that determines how data is distributed across physical partitions.
Item: A single record in a container (document, row, node, etc.). Items are automatically indexed.
Pricing Models
Cosmos DB offers two pricing models: - Provisioned Throughput: You specify a number of RUs per second. You pay for the provisioned RUs, regardless of actual usage. This is ideal for predictable workloads. - Serverless: You pay only for the RUs consumed by your operations. This is ideal for intermittent or unpredictable workloads. Serverless mode has a maximum storage limit (currently 1TB) and a maximum throughput per operation (currently 5,000 RU/s).
Comparison to On-Premises Equivalent
An on-premises NoSQL database like MongoDB or Cassandra requires significant effort to set up replication, handle failovers, and scale. You need to manage servers, networking, storage, and software updates. With Cosmos DB, all of this is abstracted. You simply configure the desired regions and consistency level, and Azure handles replication, failover, and patching. Additionally, Cosmos DB offers a 99.999% availability SLA for multi-region writes, which is nearly impossible to achieve on-premises without enormous cost and complexity.
Azure Portal and CLI Touchpoints
In the Azure portal, you can create a Cosmos DB account by searching for "Azure Cosmos DB" and clicking "Create." You can then choose the API, configure regions, and set the consistency level. The portal provides a Data Explorer to query and manage your data. With the Azure CLI, you can create a Cosmos DB account using the following command:
az cosmosdb create --name mycosmosdbaccount --resource-group myResourceGroup --kind GlobalDocumentDB --locations regionName=eastus failoverPriority=0 isZoneRedundant=falseTo add a region:
az cosmosdb update --name mycosmosdbaccount --resource-group myResourceGroup --locations regionName=westus failoverPriority=1You can also use ARM templates or Bicep to deploy Cosmos DB as part of your infrastructure as code.
Concrete Business Scenarios
E-commerce Product Catalog: A global online retailer uses Cosmos DB to store product information. Data is replicated to regions where customers are located, ensuring fast product search and retrieval. During Black Friday, they can scale up RUs to handle high traffic, then scale back down.
IoT Telemetry: A manufacturing company collects sensor data from machines worldwide. They use Cosmos DB with the Cassandra API to store time-series data. Multi-master writes ensure that data from any factory can be ingested locally, and global replication provides a unified view.
Gaming Leaderboards: A game developer uses Cosmos DB with the Gremlin API to manage social graphs. Players' scores and relationships are stored in a graph, and the low-latency reads ensure real-time leaderboard updates across regions.
Create a Cosmos DB Account
In the Azure portal, navigate to 'Create a resource' and select 'Azure Cosmos DB'. Choose the API you want (e.g., Core (SQL) for document data). Fill in the subscription, resource group, and account name. Select the regions for global distribution. You can choose a single region initially and add more later. Set the default consistency level (Session is recommended for most applications). Review and create. Behind the scenes, Azure provisions the account and sets up the underlying infrastructure for replication and indexing.
Create a Database and Container
Inside your Cosmos DB account, click 'Data Explorer' and then 'New Container'. Specify the database id (or create a new one), container id, and partition key. The partition key is critical for performance; it should be a property that has high cardinality and even distribution of values. For example, for a user profile container, use '/userId'. Set the throughput (RUs) – start with 400 RU/s for development. The container will be automatically partitioned based on the partition key, and each physical partition can hold up to 20GB of data.
Add Data Items
In Data Explorer, select your container and click 'New Item' (for SQL API). Enter a JSON document. For example: { "id": "1", "name": "Alice", "city": "Seattle" }. Cosmos DB automatically indexes all fields. You can also upload multiple items via the portal or programmatically using SDKs. Each item must have a unique 'id' field within the partition key value. The system automatically generates a system-generated '_rid' and '_ts' (timestamp).
Query Data Using SQL
In Data Explorer, you can run SQL queries against your container. Cosmos DB's SQL API supports SELECT, WHERE, JOIN, and even user-defined functions. For example: SELECT * FROM c WHERE c.city = 'Seattle'. The query engine uses the index to efficiently retrieve data. If your query includes the partition key in the WHERE clause, it is a 'single-partition query' and is most efficient. Queries that cross partitions are 'cross-partition queries' and may consume more RUs.
Configure Global Distribution
In the Cosmos DB account blade, go to 'Replicate data globally'. You can add or remove Azure regions. You can also enable 'Multi-region writes' to allow writes in multiple regions. Azure automatically replicates data to all selected regions. For failover, you can set a failover priority list. If a region fails, Cosmos DB automatically promotes the next priority region as the write region. You can also manually trigger a failover for testing.
Real-World Scenarios
Scenario 1: Global E-commerce Platform
A multinational e-commerce company uses Cosmos DB to power its product catalog and shopping cart. The catalog data (product descriptions, prices, inventory) is replicated to Azure regions in North America, Europe, and Asia. When a user in London searches for a product, the request is routed to the nearest region (UK South) for low-latency reads. The shopping cart uses multi-master writes so that a user can add items from any device, and the cart is synchronized globally. The team provisions 10,000 RU/s during peak shopping seasons and uses autoscale to automatically adjust. A common mistake is choosing a poor partition key (e.g., product category) that leads to hot partitions, causing throttling. The correct partition key is the product ID, which has high cardinality.
Scenario 2: Real-Time IoT Data Ingestion
A smart building company collects sensor data (temperature, humidity, occupancy) from thousands of sensors across multiple buildings. They use Cosmos DB with the Cassandra API to store time-series data because their existing applications use Cassandra drivers. Data is written to the nearest region (e.g., West US for buildings in California) using multi-master writes. A downstream analytics service reads the data using a change feed to process alerts. The team uses serverless mode because the write traffic is sporadic. They set TTL (time-to-live) on the container to automatically expire data older than 30 days. A challenge is managing the partition key: they use '/buildingId' but if one building has many more sensors, that partition becomes hot. They mitigate by using a composite partition key like '/buildingId_sensorId'.
Scenario 3: Social Media Application
A startup building a social network uses Cosmos DB with the Gremlin API to store user relationships as a graph. Each user is a vertex, and friendships are edges. The graph is replicated to multiple regions to serve users worldwide. The application uses session consistency to ensure that a user always sees their own updates. The team uses the change feed to update a search index (Azure Cognitive Search) in near real-time. A misconfiguration: they initially set the consistency level to Strong, which increased write latency and RU consumption. They switched to Session consistency, which is the default and provides good balance. They also underestimated the need for RUs during viral events; now they use autoscale to handle spikes.
Exam Focus for AZ-900
This section addresses Objective 2.4: Describe database services. On the exam, expect 2-3 questions about Cosmos DB. The questions typically ask you to identify Cosmos DB's features, use cases, and how it differs from other database services like Azure SQL Database or Azure Database for PostgreSQL.
Common Wrong Answers and Why Candidates Choose Them
"Cosmos DB is a relational database." This is wrong because Cosmos DB is a NoSQL database. Candidates confuse it because of the SQL API. Remember: Cosmos DB supports multiple APIs, but it is fundamentally a NoSQL, schema-agnostic database.
"Cosmos DB only supports eventual consistency." Wrong. Cosmos DB offers five consistency levels. Candidates might think it's only eventual because they associate NoSQL with eventual consistency. However, you can choose Strong, Bounded Staleness, Session, Consistent Prefix, or Eventual.
"Cosmos DB requires you to manage indexing." Wrong. Cosmos DB automatically indexes all fields by default. Candidates familiar with traditional databases might think you need to create indexes manually. In Cosmos DB, indexing is automatic, though you can customize it.
"Cosmos DB cannot be used for globally distributed applications." This is the opposite of the truth. Global distribution is Cosmos DB's key feature. Candidates may think it's only for single-region use.
Specific Terms and Values
Request Unit (RU): The unit of throughput. Know that 1 RU = 1KB read. Provisioned throughput is in RU/s.
Consistency levels: Strong, Bounded Staleness (100,000 operations or 5 seconds), Session, Consistent Prefix, Eventual. Know that Session is the default.
SLA: 99.999% availability for multi-region writes, 99.99% for single-region writes.
Multi-model: Supports document (SQL API, MongoDB), key-value (Table API), graph (Gremlin), column-family (Cassandra).
Turnkey global distribution: You can add/remove regions with a click, no downtime.
Edge Cases and Tricky Distinctions
The exam may ask which consistency level provides the strongest guarantees. Answer: Strong consistency. But note that Strong consistency cannot be used with multi-region writes (it requires a single write region).
The exam may ask which API is best for migrating an existing MongoDB app. Answer: MongoDB API.
The exam may ask about serverless vs provisioned throughput. Serverless is for intermittent traffic; provisioned is for predictable.
Memory Trick
Use the acronym GRAMS to remember Cosmos DB's key features: Global distribution, Request Units, Automatic indexing, Multi-model APIs, Scalability (elastic). Another trick: "Cosmos DB is like a Swiss Army knife for NoSQL – it has many APIs and global reach."
Azure Cosmos DB is a globally distributed, multi-model NoSQL database service.
It offers five consistency levels: Strong, Bounded Staleness, Session, Consistent Prefix, and Eventual (Session is default).
Throughput is measured in Request Units per second (RU/s). 1 RU = 1KB read.
Cosmos DB supports multiple APIs: SQL, MongoDB, Cassandra, Gremlin, and Table.
It provides turnkey global distribution: add/remove regions with no downtime.
SLA: 99.999% availability for multi-region writes, 99.99% for single-region writes.
Automatic indexing of all fields by default; can be customized.
Serverless and provisioned throughput pricing models available.
These come up on the exam all the time. Here's how to tell them apart.
Azure Cosmos DB
NoSQL database (schema-agnostic)
Globally distributed with multi-master writes
Multiple APIs (SQL, MongoDB, Cassandra, Gremlin, Table)
Throughput measured in Request Units (RU/s)
Automatic indexing of all fields
Azure SQL Database
Relational database (schema-on-write)
Single region by default; geo-replication available but not turnkey
Only supports SQL/T-SQL
Throughput measured in DTUs or vCores
Manual index management
Mistake
Cosmos DB is just a Microsoft version of MongoDB.
Correct
Cosmos DB is a multi-model database that supports multiple APIs, including a MongoDB-compatible API. However, it is not a fork of MongoDB. It has its own engine with features like global distribution, multiple consistency levels, and automatic indexing that MongoDB does not natively have.
Mistake
You must use the SQL API with Cosmos DB.
Correct
Cosmos DB supports five APIs: Core (SQL), MongoDB, Cassandra, Gremlin, and Table. You choose the API when you create the account. You can also use multiple APIs in the same account by creating separate databases with different APIs, but each account is configured for one API at creation.
Mistake
Cosmos DB is expensive and only for large enterprises.
Correct
Cosmos DB has a serverless pricing model that charges only for consumed RUs, making it cost-effective for small or intermittent workloads. The provisioned model can be scaled down to 400 RU/s, which is affordable for development. It also offers a free tier (first 1000 RU/s and 25GB storage free) for one account per subscription.
Mistake
Cosmos DB does not support ACID transactions.
Correct
Cosmos DB supports ACID transactions for operations within a single partition (using stored procedures or transactional batches). For multi-partition transactions, you can use the transactional batch API (preview) which provides atomicity across multiple items within the same partition key. However, it does not support distributed transactions across partitions.
Mistake
You need to manually manage partitioning in Cosmos DB.
Correct
Cosmos DB automatically manages physical partitions based on the partition key you specify. You do not need to create or manage partitions yourself. However, you must choose a good partition key to ensure even data distribution. The system creates new partitions as data grows.
Azure Cosmos DB is a NoSQL database designed for global distribution, flexible schemas, and multi-model support. Azure SQL Database is a relational database with a fixed schema. Cosmos DB uses Request Units (RUs) for throughput, while SQL Database uses DTUs or vCores. Cosmos DB offers turnkey global distribution with multi-master writes; SQL Database supports geo-replication but with a single master. Choose Cosmos DB for globally distributed, low-latency applications with varied data models; choose SQL Database for traditional relational workloads with strong consistency and complex queries.
Yes. Cosmos DB provides a MongoDB API that is wire-protocol compatible with MongoDB drivers. You can migrate your MongoDB application to Cosmos DB by changing the connection string. However, not all MongoDB features are supported (e.g., some aggregation pipeline stages, indexes). Check the compatibility documentation. Cosmos DB's MongoDB API offers additional benefits like global distribution and automatic indexing.
A Request Unit (RU) is a normalized unit of throughput that abstracts the system resources (CPU, IOPS, memory) required to perform a database operation. One RU roughly equals the cost of reading a 1KB document. Write operations consume more RUs than reads. You provision RU/s at the container or database level. If you exceed your provisioned throughput, requests are throttled (return HTTP 429). You can monitor RU consumption in Azure Monitor.
When you configure multiple regions for a Cosmos DB account, Azure automatically replicates your data to all selected regions. You can enable multi-region writes to allow writes in any region. The service uses a multi-master replication protocol that synchronizes data across regions with low latency. You can set a failover priority list for automatic failover. Consistency levels apply globally; for example, Strong consistency requires quorum reads from the primary region, while Eventual consistency allows reads from any region.
Cosmos DB offers five consistency levels: 1) Strong: reads always see the latest write. 2) Bounded Staleness: reads may be stale by a defined number of operations or time (e.g., 100,000 operations or 5 seconds). 3) Session: guarantees monotonic reads/writes within a single client session. 4) Consistent Prefix: reads never see out-of-order writes. 5) Eventual: no ordering guarantee. The default is Session. Strong consistency cannot be used with multi-region writes.
Both. Cosmos DB offers two throughput models: provisioned throughput (you specify RU/s) and serverless (you pay per operation). Serverless is ideal for intermittent or unpredictable workloads with low traffic (max 5,000 RU/s per operation and 1TB storage). Provisioned is better for predictable, high-throughput workloads. You can also use autoscale to automatically adjust provisioned throughput within a range.
The partition key determines how data is distributed across physical partitions. Choose a property with high cardinality (many distinct values) and even distribution of read/write requests. For example, '/userId' for a user table. Avoid partition keys that cause hot spots, like '/date' (all writes go to one partition). The partition key cannot be changed after the container is created. Test with representative data to ensure even distribution.
You've just covered Azure Cosmos DB — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?