AZ-305 Design data storage solutions Practice Question
Which THREE factors should you consider when selecting a partition key for an Azure Cosmos DB container? (Select three.)
⚠ Common exam trap
Many candidates confuse low cardinality with efficiency, but Cosmos DB requires high cardinality to avoid storage limits and hot partitions, and they may also mistakenly think large binary properties are acceptable partition keys despite the 2 KB limit and indexing overhead.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Even distribution of request unit (RU) consumption
An even distribution of request unit (RU) consumption across physical partitions prevents hot partitions, which can throttle throughput and degrade performance. In Azure Cosmos DB, the partition key determines how data and throughput are distributed; if RU consumption is skewed, some partitions become overloaded while others remain underutilized, violating the design goal of uniform load.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Even distribution of request unit (RU) consumption
Why this is correct
An effective partition key must result in a relatively even distribution of request unit (RU) consumption across all logical partitions, not just a high number of distinct values. If a particular key value receives a disproportionate share of reads or writes, the physical partition hosting it becomes hot and triggers throttling (HTTP 429) for that traffic. Therefore, when evaluating candidate keys, you should model the expected workload and confirm that no single key value accounts for an excessive fraction of the total RU spend.
- ✗
Low cardinality to reduce overhead
Why it's wrong here
Selecting a low-cardinality property—such as a boolean or a week-day name—reduces the number of logical partitions and concentrates many items under the same key. This centralization artificially creates a high-volume partition that can exceed the 20-GB logical partition size limit and become a hot partition, causing performance bottlenecks. Lower cardinality does not 'reduce overhead'; instead, it increases the risk of throttling and makes horizontal scale-out less effective. The goal is a high-cardinality key with many unique values, not a small set.
- ✓
High cardinality (many distinct values)
Why this is correct
A high-cardinality property—one with many distinct values across documents—generally enables Azure Cosmos DB to create a large number of logical partitions, which are then spread over physical partitions. This broad distribution minimizes the chance that any single physical partition receives a disproportionate load, and it also facilitates efficient point-read and point-write operations. However, cardinality alone is not sufficient: the values should also appear with similar frequencies and produce similar RU consumption, otherwise the partition key can still cause hot partitions despite a high distinct count.
- ✗
Property with large binary data
Why it's wrong here
Large binary data (e.g., a multi-megabyte image or video blob) should never be used as the partition key because every point operation’s RU cost is partly based on the size of the partition-key value that is hashed for routing. A large key increases per-item storage and index overhead, and such blob data is rarely the predicate used in common queries anyway. Moreover, if the binary property changes or is too large, it makes partition management and query routing clumsy. Use a separate immutable, high-cardinality property (like an ID or timestamp) for the key and store the binary as an attachment or reference.
- ✓
Property frequently used as a filter in queries
Why this is correct
A property that is frequently used as a filter in query predicates should be a strong partition-key candidate because Cosmos DB can then satisfy the query from a single logical partition instead of fanning out across every physical partition. This ‘single-partition query’ avoids cross-partition query costs, which otherwise multiply RU charges and increase latency. The property should also be immutable, present in almost every document, and stable over time, since changing it later is not possible in the production API. When the key doubles as a query filter, you align routing efficiency with query efficiency.
Go deeper
Related to this question
About these practice questions
One of 795 original AZ-305 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.