Describe considerations for working with non-relational data on Azure →mediumMultiple ChoiceObjective-mapped
DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
A social media company stores user posts in Azure Cosmos DB. Posts are frequently queried by user ID and creation timestamp. To minimize Request Units (RU) per query, which property should be chosen as the partition key?
⚠ Common exam trap
A common mix-up: candidates choose a composite key (Option D) thinking it improves query efficiency, but they overlook that Azure Cosmos DB requires the partition key to be a single property in the filter for single-partition queries, and a composite key would not be used as a single partition key unless explicitly defined as such in the container.
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
✓
User ID
User ID is the correct partition key because it evenly distributes writes and reads across physical partitions, ensuring that queries filtering by user ID and timestamp are scoped to a single partition. This minimizes cross-partition queries, which consume more Request Units (RU) than single-partition queries. Azure Cosmos DB routes each query to the partition containing the matching partition key value, so choosing User ID keeps most queries efficient.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
User ID
Why this is correct
User ID is the optimal partition key because it is a high-cardinality attribute that appears in nearly every query for a social media application, such as 'retrieve all posts by a user' or 'find posts by a user within a date range'. It distributes documents evenly across logical partitions to avoid hot partitions, and because each physical partition can store up to 20GB, even high-volume users' posts are typically collocated for efficient range reads with minimal routing cost. A well-chosen partition key like User ID ensures that point reads and queries scoped to a single partition consume fewer RUs and avoid cross-partition fan-out.
- ✗
Timestamp
Why it's wrong here
Timestamp is a poor partition key because it is monotonically increasing—all new posts at a given moment are written to the same logical partition, creating a 'hot partition' that throttles throughput and degrades performance. Even if timestamps are rounded to a finer granularity, a large number of posts can share the same second or minute, further concentrating load. Conversely, queries in a social media app usually filter by user or content, not solely by timestamp, so the partition key would not align with common query patterns. This uneven distribution causes bottlenecks and increases RU consumption due to throttling and retries.
- ✗
Post content
Why it's wrong here
Post content is unsuitable as a partition key because partition key values are limited to 2KB in Cosmos DB, and a post body can easily exceed that limit, causing write failures. It also has very low selectivity—multiple posts could have identical or similar content, leading to skewed partition sizes—and application queries rarely use exact post content as a filter, so it provides no query optimization benefit. Full-text search is a separate service concern and cannot be accomplished through partition key selection, making this choice architecturally incorrect.
- ✗
A composite key of user ID and timestamp
Why it's wrong here
A composite key appended as 'userID-timestamp' would fragment each user's posts across many partitions, so a query filtering only by user ID—the most common access pattern—would need to fan out to every partition containing that user's data, dramatically increasing RU charges and latency. While it might offer high cardinality, it sacrifices the logical grouping that makes User ID efficient, and point reads require knowing the exact composite value, which is often unavailable at query time. The added complexity and overhead outweigh any theoretical distribution benefit, and Cosmos DB recommends using a single natural partition key that supports the dominant query path.
Go deeper
Related to this question
Learn chapter
Azure SQL Services
Key term
Partition key
A partition key is a value used by database systems to distribute data across multiple storage partitions, enabling faster queries and efficient scaling.
Key term
Azure Cosmos DB
Azure Cosmos DB is a fully managed, globally distributed NoSQL database service that offers fast reads and writes anywhere in the world with automatic scaling and multiple consistency models.
About these practice questions
Courseiva writes every DP-900 question from scratch — 820 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-900 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 DP-900 exam.