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 manufacturing company stores IoT sensor data as JSON documents in Azure Cosmos DB. Each document has fields: deviceId (high cardinality, many unique values), timestamp, temperature, and humidity. The most frequent query is: 'Retrieve all readings for a specific deviceId from the last hour.' To minimize Request Unit (RU) consumption, which combination of partition key and indexing policy should be chosen?
⚠ Common exam trap
The trap here is that candidates often pick timestamp as the partition key because it seems logical for time-range queries, but they overlook that the most frequent query filters on deviceId, making deviceId the correct partition key to avoid 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
✓
Partition key: deviceId, Indexing: automatic on all properties
DeviceId is the most frequently filtered attribute (in the WHERE clause), making it an ideal partition key that ensures queries are scoped to a single physical partition, minimizing cross-partition fan-out. Automatic indexing on all properties allows efficient filtering on timestamp within the partition, while the index on deviceId is not strictly needed since the partition key itself routes the query, but it does not harm RU consumption significantly. This combination balances query performance and RU cost for the described workload.
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: deviceId, Indexing: automatic on all properties
Why this is correct
Choosing deviceId as the partition key is optimal because it has high cardinality and aligns directly with the query's equality filter (WHERE deviceId = ?). Automatic indexing on all properties ensures the timestamp field is indexed, so the time-range filter within the selected partition uses a precise index seek rather than a scan, minimizing request-unit (RU) consumption. This combination targets a single physical partition and uses an index for the most selective predicates, making it the most efficient design for this IoT workload.
- ✗
Partition key: timestamp, Indexing: automatic on all properties
Why it's wrong here
Using timestamp as the partition key is a poor choice because all devices writing at roughly the same time would land on the same timestamp partition, creating a hot partition that throttles throughput and skews RU usage. Additionally, because a query filters on deviceId (not timestamp as the equality filter), Azure Cosmos DB must fan out across every partition to find that device's data, turning an otherwise point read into a costly cross-partition query. Even with automatic indexing, the query cannot avoid scanning multiple partitions, so RUs increase significantly.
- ✗
Partition key: deviceId, Indexing: none
Why it's wrong here
Although deviceId is the right partition key, setting indexing to 'none' means the timestamp range filter cannot be evaluated with an index. The query engine is forced to perform a full scan of every document in that device's partition, reading each JSON document to check the timestamp condition, which consumes far more RUs than an indexed lookup. Automatic indexing is essential to make the time-filter efficient because Cosmos DB's per-item RU charge is directly tied to the number of documents scanned versus index seeks.
- ✗
Partition key: temperature, Indexing: automatic on all properties
Why it's wrong here
Temperature is unsuitable as a partition key because it has low cardinality (typically a small range of numeric values) and is heavily skewed—some temperatures occur far more frequently than others, causing uneven partition sizes. More importantly, a query for a specific deviceId cannot be scoped to a single partition, since that device's data is scattered across many temperature-partition values, so the database must query every partition and then filter by deviceId. This cross-partition fan-out, combined with poor distribution, dramatically increases RU consumption compared to using deviceId.
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
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.