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 travel booking application stores user itineraries in Azure Cosmos DB using the NoSQL API. Each itinerary document contains: UserID (unique to user), ItineraryID, Destination, BookingDate, and a nested array of Activities. The most common query is: 'Retrieve all itineraries for a specific UserID sorted by BookingDate descending.' To minimize Request Unit (RU) consumption, which partition key should be chosen?
⚠ Common exam trap
Many exam-takers choose a unique identifier like ItineraryID as the partition key, thinking it ensures even distribution, but they overlook that the query pattern (filtering by UserID) requires the partition key to match the filter to avoid expensive cross-partition queries.
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
✓
UserID
UserID is the correct partition key because the most common query filters on UserID, ensuring that all itineraries for a specific user are stored in the same physical partition. This allows the query to target a single partition, minimizing cross-partition queries and reducing Request Unit (RU) consumption. A partition key that aligns with the primary query filter is essential for optimal performance and cost efficiency in Azure Cosmos DB.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
ItineraryID
Why it's wrong here
ItineraryID is a unique, high-cardinality key, but choosing it as the partition key causes every document to be placed in its own logical partition. Any query that filters by UserID or other common attributes must fan out across all physical partitions, and because each cross-partition query consumes RUs on every touched partition, both latency and cost scale with the entire container's data instead of just the target user's documents. This makes everyday itinerary lookups extremely expensive.
- ✓
UserID
Why this is correct
UserID is the ideal partition key here because it is both the most common filter in the application's queries ("show me my itineraries") and a high-cardinality value that naturally distributes data across many logical partitions. All documents for a given user are co-located in a single logical partition, so queries for that user's itineraries are single-partition operations, consuming minimal RUs and returning quickly. This directly matches the access pattern and avoids the cross-partition overhead that the other options create.
- ✗
Destination
Why it's wrong here
Destination fails as a partition key because it creates a severe distribution skew: popular destinations like 'Paris' accumulate a disproportionately large number of itineraries, while less-visited destinations have very few. This leads to oversized logical partitions that can approach the 10 GB limit and create hot partitions that throttle write throughput. Additionally, because a single user may book trips to many destinations, any query for a specific user's itineraries still spans multiple partitions, making the partition key useless for the primary read pattern.
- ✗
BookingDate
Why it's wrong here
BookingDate is a poor partition key due to temporal hot-spotting: all itineraries booked on the same date write to a single logical partition, so current dates receive heavy write traffic while historical dates sit idle, causing throughput throttling and uneven storage. Queries by UserID are inherently cross-partition because a user's itineraries span many different dates, requiring a fan-out that multiplies RU consumption and latency. The key also fails to match the most frequent filter, which is the user's identity, not the date.
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
This DP-900 question is part of Courseiva's 820-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam 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.