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 application stores user profiles in Azure Cosmos DB using the NoSQL API. Each profile includes UserID, Name, Email, and an array of Posts. The most common query retrieves a user's profile by UserID. The application requires strong consistency for writes so that once a profile is updated, all subsequent reads see the latest data. To minimize Request Unit (RU) consumption, which partition key should be chosen?
⚠ Common exam trap
A common mix-up: candidates choose a synthetic key or a secondary attribute like Email, thinking they need to avoid hot partitions, but they overlook that the most common query pattern and the need for minimal RU consumption dictate using the primary query filter as the partition key.
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 it is the primary filter in the most common query (retrieving a profile by UserID), ensuring each query targets a single logical partition. This minimizes cross-partition queries and RU consumption. Additionally, UserID provides high cardinality and even distribution, which prevents hot partitions and supports the required strong consistency for writes.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
UserID
Why this is correct
UserID is the correct choice because it is unique and high-cardinality, producing many small, evenly distributed logical partitions that scale horizontally without hot spots. When UserID is both the partition key and the item ID, a profile lookup is a point read: Cosmos DB computes the partition from the value and reads a single document directly, consuming the fewest request units (RUs) and lowest latency. Any other partition key would force queries for a known UserID to fan out across multiple physical partitions, so UserID satisfies both even distribution and the application's dominant access pattern.
- ✗
Email
Why it's wrong here
Email is not a safe partition key because users can change their email address; partition keys in Cosmos DB are immutable, so a change would require deleting and reinserting the profile rather than an in-place update. Even if the app forces global uniqueness, email aliases or shared mailboxes can create duplicate values, and popular domains like gmail.com would skew request traffic onto a few partitions. Additionally, because the primary lookup is by UserID, using Email as the partition key turns every profile retrieval into a cross-partition query that must be routed to multiple physical partitions, raising RU consumption and latency.
- ✗
Name
Why it's wrong here
Name has very low cardinality because common first and last names are heavily duplicated, placing many profiles in the same logical partition and creating hot partitions that can approach Cosmos DB's 20 GB logical partition limit. A partition key does not need to be globally unique, but it must produce enough distinct values to spread load evenly — Name clearly fails that test. With UserID as the actual lookup key, partitioning on Name means the database cannot know which physical partition holds a profile without scanning many partitions, making every UserID query a costly cross-partition operation.
- ✗
A synthetic partition key combining UserID and Region
Why it's wrong here
A synthetic key made of UserID plus Region may seem to add evenness, but it actually fragments one user's data across multiple logical partitions whenever the same user has activity in several regions. The application's stated retrieval pattern is 'get the profile by UserID,' and without the Region value in the request Cosmos DB cannot target a single partition; the query must be fanned out to all regions' partitions, increasing RU charges and latency. This design only improves distribution if every query supplies both UserID and Region, which contradicts the requirement rather than optimizing it.
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
Key term
Data
Data is raw, unprocessed information, like numbers, words, or measurements, that can be stored, processed, and analyzed by computers.
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
One of 820 original DP-900 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 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.