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 media company stores user profiles in Azure Cosmos DB using the Core (SQL) API. Each profile document contains a userId (unique), name, email, and a subscriptions array containing objects with a serviceName and startDate. The application needs to efficiently retrieve a single user by userId and also run a query to find all users who have a subscription to the service 'PremiumVideo'. Which partition key design is most appropriate for this workload?
⚠ Common exam trap
Many candidates assume partitioning on a frequently queried field like serviceName will optimize the subscription query, but they overlook that Cosmos DB requires the partition key to be a top-level property with high cardinality, and that point reads (by userId) are the most common and cost-sensitive operation in this workload.
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
✓
Partition key on userId
Partitioning on userId ensures each document is evenly distributed across physical partitions, as userId is unique and used for point reads (the most efficient operation in Cosmos DB). The query for users with a 'PremiumVideo' subscription will be a cross-partition query regardless of partition key choice, but the primary workload—retrieving a single user by userId—is optimized with this design. Partitioning on userId also avoids hot partitions and adheres to the best practice of using a high-cardinality, frequently queried field as the partition key.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Partition key on email
Why it's wrong here
Email is not the primary access pattern for this workload, and partitioning by email would make every point read by userId a cross-partition query because the partition key does not match the lookup field. This would increase latency and RU consumption for the main profile-access operation. Additionally, email addresses can change over time, which would force a partition key change and require deleting and reinserting the item, adding operational complexity.
When this WOULD be correct
This would be correct if the application's primary workload was to look up users by their email address (e.g., for login or email-based search) and the query for subscription data was secondary or could be handled by a separate index.
- ✓
Partition key on userId
Why this is correct
Partitioning by userId creates one logical partition per user, enabling efficient point reads for fetching a user's profile and subscriptions. The subscription usage query will be a cross-partition query because it scans all partitions, but that is acceptable given the workload's emphasis on low-latency profile access. This also distributes request units (RUs) evenly across partitions as user activity tends to be uniform.
- ✗
Partition key on serviceName (extracted from subscriptions array)
Why it's wrong here
Choosing serviceName as the partition key would cause hot partitions if a small number of services are extremely popular, since all users subscribed to those services would land on the same physical partition and exceed its throughput limits. Moreover, a point read by userId—the stated primary access pattern—would require a cross-partition query across every service partition, increasing both latency and request unit (RU) charges. This option optimizes for a secondary query pattern while harming the core profile-retrieval operation.
When this WOULD be correct
If the workload consisted solely of queries to find all users subscribed to a specific service (e.g., 'PremiumVideo'), and each service had a large number of users, then partition key on serviceName would make those queries single-partition and efficient.
- ✗
Partition key on a composite key combining userId and serviceName
Why it's wrong here
Azure Cosmos DB does not natively support composite partition keys; you would have to manually concatenate userId and serviceName into a single string, such as 'userId-serviceName'. This would create a separate logical partition for each user-service pair, forcing any query that retrieves a user's full profile or all subscriptions to fan out across many partitions. That defeats the primary point-read pattern and increases both latency and RU consumption compared to a simple userId key.
When this WOULD be correct
This would be correct if the workload required efficient queries for both a specific user's subscriptions and all users with a specific subscription, and the partition key was designed to distribute data evenly while supporting both query patterns with in-partition queries.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The DP-900 exam frequently reuses these exact scenarios with slightly different constraints.
✓Partition key on userIdCorrect answer▾
Why this is correct
Partitioning by userId creates one logical partition per user, enabling efficient point reads for fetching a user's profile and subscriptions. The subscription usage query will be a cross-partition query because it scans all partitions, but that is acceptable given the workload's emphasis on low-latency profile access. This also distributes request units (RUs) evenly across partitions as user activity tends to be uniform.
✗Partition key on emailWrong answer — click to see why▾
Why this is wrong here
Partitioning on email would not efficiently support the primary query (retrieving a user by userId) because queries on userId would require a cross-partition scan. Additionally, the query for users with 'PremiumVideo' subscription would also be a cross-partition query, as email is unrelated to the subscription data.
★ When this WOULD be the correct answer
This would be correct if the application's primary workload was to look up users by their email address (e.g., for login or email-based search) and the query for subscription data was secondary or could be handled by a separate index.
Why candidates choose this
Candidates may think email is a good partition key because it is unique and evenly distributed, but they overlook that the main access pattern is by userId, not email.
✗Partition key on serviceName (extracted from subscriptions array)Wrong answer — click to see why▾
Why this is wrong here
Partitioning on serviceName extracted from subscriptions array would cause most queries to be cross-partition, as retrieving a single user by userId would require fanning out across all partitions, and the query for users with 'PremiumVideo' subscription would still be a cross-partition query unless filtered by a specific partition key value.
★ When this WOULD be the correct answer
If the workload consisted solely of queries to find all users subscribed to a specific service (e.g., 'PremiumVideo'), and each service had a large number of users, then partition key on serviceName would make those queries single-partition and efficient.
Why candidates choose this
Candidates may think that since the query involves filtering on serviceName, using it as the partition key would make that query efficient, overlooking that the primary access pattern (retrieving by userId) would become inefficient.
✗Partition key on a composite key combining userId and serviceNameWrong answer — click to see why▾
Why this is wrong here
A composite key on userId and serviceName would cause queries for a single user by userId to be cross-partition, as userId alone is not the partition key. Additionally, queries for users with 'PremiumVideo' subscription would also be cross-partition unless the partition key exactly matches the filter.
★ When this WOULD be the correct answer
This would be correct if the workload required efficient queries for both a specific user's subscriptions and all users with a specific subscription, and the partition key was designed to distribute data evenly while supporting both query patterns with in-partition queries.
Why candidates choose this
Candidates may think a composite key covers both query patterns, but they overlook that Azure Cosmos DB partition key is used for data distribution and must be a single property path; composite keys are not supported as partition keys, and queries not specifying the full partition key become cross-partition.
Analysis generated from the official DP-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
Key term
Service
A service is a software component or system that performs a specific function and is available to be used by other programs or users over a network.
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.