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 smart home company stores sensor readings from thousands of devices in Azure Cosmos DB. Each reading includes a deviceID, timestamp (ISO format), sensor type, and value. The most common query retrieves all readings for a specific device within a time range. To minimize Request Units (RU) consumption and ensure even data distribution, which property should be chosen as the partition key?
⚠ Common exam trap
Test-takers frequently choose timestamp because they think it naturally orders data by time, but they overlook that the most common query filters by deviceID first, and using timestamp as the partition key would cause cross-partition queries for every device-specific time range, dramatically increasing RU costs.
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
✓
A) deviceID
DeviceID is the correct partition key because it is the primary filter in the most common query (all readings for a specific device within a time range). Partitioning by deviceID ensures that all readings for a single device are stored in the same logical partition, making queries highly efficient by targeting a single partition. It also provides even data distribution across physical partitions, as thousands of devices will have roughly equal numbers of readings, minimizing RU consumption.
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) deviceID
Why this is correct
deviceID is an ideal partition key because it exhibits high cardinality, meaning thousands of distinct values that map to separate physical partitions, ensuring even data distribution. Since the sensor queries always filter by a specific deviceID, Azure Cosmos DB can route each request directly to the partition containing that device's readings, eliminating cross-partition fan-out. This design keeps individual partitions small and balances the workload across the container, satisfying both the efficient filtering and even distribution requirements.
- ✗
B) timestamp
Why it's wrong here
Using timestamp as the partition key creates a new partition for each second or minute of data, which can quickly generate an enormous number of partitions over time. Queries that request a time range, such as 'last hour' or 'last day', cannot identify a single partition key and must fan out across all partitions, resulting in high latency and RU consumption. Additionally, all devices writing at the current moment target the same newest partition, creating a hot spot and undermining both efficient query routing and even distribution.
- ✗
C) sensor type
Why it's wrong here
Sensor type is a poor partition key because it has very low cardinality—typically just a handful of values like temperature, humidity, or motion—producing only a few large partitions that grow unevenly as different sensor types generate vastly different data volumes. A query that filters on sensor type will be confined to one massive partition, making even that single-partition query slow and expensive. This violates the core requirement of even distribution and also fails to isolate data by device, forcing cross-partition scans for common device-centric queries.
- ✗
D) value
Why it's wrong here
The value field is a continuous numeric measurement that is rarely used as a filter predicate in the query workload, so partitioning on it would not directly support the stated query for a device's readings. Because values are not unique and can repeat, the partition key distribution would become skewed, with some partitions holding many duplicate values and others nearly empty, causing unbalanced storage and throughput. Most importantly, queries that filter by deviceID or timestamp would require scanning all value-based partitions, making this choice inefficient and inconsistent with the requirement for even data distribution.
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
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
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.