Azure Cosmos DB Guide: Mastering NoSQL for AZ-900
Azure Cosmos DB is a globally distributed, multi-model NoSQL database service provided by Microsoft Azure. It supports multiple APIs—including Document, Key-Value, and Graph—and offers tunable consistency levels and guaranteed low latency. It uses Request Units (RUs) to manage throughput and scale globally across multiple Azure regions.
What exactly is Azure Cosmos DB?
Listen, when you're diving into the AZ-900, you'll encounter a lot of database options, but Cosmos DB is the heavy hitter for modern, scalable apps. Unlike a traditional relational database (SQL) that relies on rigid tables and schemas, Cosmos DB is a NoSQL service. This means it's designed for massive scale, high availability, and the kind of flexibility that today's rapid development cycles demand.
In plain English, it's a 'universally distributed' database. This isn't just marketing fluff; it means you can replicate your data to any number of Azure regions with a few clicks. For your exam, remember that Cosmos DB is the go-to choice when you need single-digit millisecond latency for both reads and writes, regardless of where your users are located globally.
Which multi-model APIs should you use?
One of the coolest things about Cosmos DB is that it isn't just one type of database; it's a multi-model service. Depending on the API you choose, it behaves differently. The most common is the Core (SQL) API, which uses document-based storage (JSON). If you're coming from a MongoDB background, there's a dedicated API for that too.
But it doesn't stop there. If you need a simple key-value store, you can use the Table API. If you're building a social network or a fraud detection system where the relationships between data points are more important than the data itself, you'll want the Gremlin API for graph data. Understanding which API fits which scenario is a frequent point of testing on the Fundamentals exam, so make sure you can distinguish between a 'document' and a 'graph' use case.
How does global distribution actually work?
Imagine your app is hitting a wall in Europe because your database is sitting in a data center in Virginia. That's where global distribution comes in. Cosmos DB allows you to replicate your data across Azure regions seamlessly. You don't have to manually set up complex replication pipelines; Azure handles the heavy lifting for you.
This architecture provides two massive wins: low latency and high availability. By placing data closer to the user, you eliminate the 'speed of light' problem. Furthermore, if an entire Azure region goes offline—which is rare but possible—your application can failover to another region without losing data. When studying for the AZ-900, focus on the fact that this distribution is 'turn-key,' meaning it's built into the service rather than being an add-on you have to configure from scratch.
Why are there five different consistency levels?
This is usually the part where students get tripped up. In a distributed system, there's a constant tug-of-war between data consistency (everyone sees the same data at the same time) and performance (how fast the data is returned). Cosmos DB gives you five levels to tune this balance.
At one end, you have 'Strong' consistency, which guarantees the most up-to-date data but has the highest latency. At the other end is 'Eventual' consistency, which is lightning fast but means users might see an older version of a record for a brief moment. In between, you'll find 'Bounded Staleness,' 'Session' (the most popular default), and 'Consistent Prefix.' For the exam, remember: the stronger the consistency, the higher the latency and the lower the availability.
How do you calculate throughput using Request Units (RUs)?
Forget about thinking in terms of CPU or RAM; in Cosmos DB, the currency is the Request Unit (RU). An RU is a normalized measure of the cost of a database operation. For example, a simple 1 KB read is exactly 1 RU. However, writing data, querying complex indexes, or storing larger documents will cost more RUs.
You can provision your throughput in two ways: Standard (where you set a fixed RU/s limit) or Autoscale (where Azure adjusts the RUs based on demand). If you exceed your provisioned throughput, Cosmos DB will return a '429' error, essentially telling your app to slow down. Understanding RUs is critical because it directly impacts your Azure bill. I always tell my students to think of RUs as a 'performance budget' that you manage to keep costs low while keeping the app snappy.
How can you best prepare for the AZ-900 exam?
Reading the documentation is a great start, but it's not enough to guarantee a pass. You need to apply that knowledge to the specific way Microsoft asks questions. The AZ-900 isn't just about knowing what Cosmos DB is; it's about knowing why you'd choose it over Azure SQL or Azure Table Storage in a real-world scenario.
That's where we come in. At Cert Sensei, we offer 1,000 expert-curated Microsoft Azure Fundamentals (AZ-900) practice questions. We don't just tell you if you're wrong; we provide detailed expert reasoning for every single answer. Plus, our domain-level analytics show you exactly where you're struggling—whether it's in the 'Azure Architecture and Services' domain or 'Azure Management and Governance'—so you can stop wasting time on what you already know and focus on your weak spots.
❓ Frequently Asked Questions
Is Azure Cosmos DB only for NoSQL data?
Yes, it is a NoSQL service, but because it is multi-model, it can handle various data types including documents, graphs, and key-value pairs. It is not a relational (SQL) database like Azure SQL Database.
Which consistency level should I choose for a social media feed?
Session consistency is usually the best fit. It ensures that a user sees their own updates immediately (read-your-own-writes), while other users might see those updates with a slight delay, balancing performance and consistency.
What happens if my application exceeds the provisioned RUs?
Cosmos DB will perform 'rate limiting,' returning an HTTP 429 error (Too Many Requests). Your application should be designed to handle this using a retry logic with exponential backoff.