Describe considerations for working with non-relational data on Azure →hardMultiple ChoiceObjective-mapped
DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
A global gaming company stores player profiles in Azure Cosmos DB. Each profile document contains PlayerID (unique), PlayerName, Email, and a nested array of Achievements. The most common query is to look up a player by PlayerID and retrieve their achievements. The company needs strong consistency for reads and writes to ensure that when a player earns an achievement, it is immediately visible. Which partition key and consistency level should they choose?
⚠ Common exam trap
A common mix-up: candidates confuse 'most common query' with 'partition key' and pick a non-query column (like Achievements or Email) or choose a weaker consistency level, not realizing that Strong consistency is required for immediate visibility and that PlayerID is the optimal partition key for the lookup pattern.
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
✓
B. Partition key: PlayerID; Consistency: Strong
PlayerID is the natural partition key for the most common query (lookup by PlayerID), ensuring efficient single-partition queries. Strong consistency is required to guarantee that when a player earns an achievement, the write is immediately visible to all subsequent reads, which is critical for the gaming scenario.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A. Partition key: PlayerID; Consistency: Eventual
Why it's wrong here
Using PlayerID as the partition key gives each player a single logical partition, so point reads by PlayerID are efficient. However, eventual consistency allows replicas to lag, meaning a read immediately after a write can return stale data; the requirement demands that committed writes are instantly visible to subsequent queries. Since the access pattern is correct but the guarantee is weaker than what the game requires, this combination fails the core requirement.
- ✓
B. Partition key: PlayerID; Consistency: Strong
Why this is correct
PlayerID is an ideal partition key because it matches the application's point-lookup pattern: every read and write for a player can be routed to a single physical partition, avoiding cross-partition queries. Strong consistency in Azure Cosmos DB ensures that a write is acknowledged only after it is durably committed, and every subsequent read that uses the same partition key returns that committed value. This directly satisfies the requirement that profile updates be immediately and reliably visible. Note that strong consistency is supported only with single-region writes, which is an appropriate choice for this workload.
- ✗
C. Partition key: Achievements; Consistency: Strong
Why it's wrong here
An array property such as Achievements cannot be used as a Cosmos DB partition key because partition key values must be a single scalar string or number; using it would either be invalid or would fragment a single player's data across many logical partitions because each achievement entry has a different value. Even with strong consistency, queries would need to be filtered or span multiple partitions to locate a specific player's profile, making point lookups by PlayerID impossible. This option fails because the partition key does not match the access pattern and is not even a legal partition key design.
- ✗
D. Partition key: Email; Consistency: Bounded staleness
Why it's wrong here
Choosing Email as the partition key forces the container to be distributed by a property that is not the application's lookup key, so retrieving a profile by PlayerID becomes a cross-partition query that scans multiple partitions unless the email address is also known. While bounded staleness is stronger than eventual consistency, it still allows reads to lag writes behind a configurable time window or K-version limit, so it cannot guarantee immediate visibility of a just-committed update. Both the partition key and the consistency level fail to meet the stated requirements, though for reasons different from options A and C.
Go deeper
Related to this question
Learn chapter
Azure SQL Services
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.
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.
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.