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 device telemetry in Azure Cosmos DB using the NoSQL API. Each document contains: deviceId (string), timestamp (datetime), temperature (float), humidity (float). The most common query retrieves all documents for a specific deviceId within a time range, ordered by timestamp descending. This query performs well. However, a new query that finds devices with temperature > 50 in the last hour (without specifying deviceId) is extremely slow and consumes many request units (RUs). What is the most likely cause?
⚠ Common exam trap
A common mix-up: candidates assume the slowness is due to a missing index on temperature, but Azure Cosmos DB automatically indexes all fields by default, so the real issue is the cross-partition query caused by omitting 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
✓
The query does not specify the partition key (deviceId), causing a cross-partition query that scans every physical partition.
In Azure Cosmos DB NoSQL API, the partition key (deviceId) determines data distribution across physical partitions. Queries that do not include the partition key in the filter become cross-partition queries, which must fan out to every physical partition, scanning all documents. This is extremely slow and consumes many RUs, especially in large containers. The original query specifying deviceId performs well because it targets a single partition.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The temperature field is not indexed by default, so the query forces a full scan of all documents.
Why it's wrong here
Cosmos DB's default indexing policy automatically creates range indexes for every property in each item, including numeric fields like temperature. Because temperature is indexed, skipping it is not what causes the full-document scan; the scan is actually a cross-partition fan-out caused by the query missing the deviceId partition key. Even with perfect indexes on temperature, the query engine must still seek through every physical partition, so this explanation misattributes the cause.
- ✓
The query does not specify the partition key (deviceId), causing a cross-partition query that scans every physical partition.
Why this is correct
The WHERE clause filters only on timestamp and temperature, not on deviceId—the container's partition key. To satisfy the query, Cosmos DB must issue the query to every physical partition and merge results, a pattern called a cross-partition query or fan-out, which consumes significantly more request units and has higher latency than a query scoped to a single partition key. Adding deviceId to the filter, or redesigning the model to avoid needing to scan all partitions, aligns the query with the partition-key distribution and reduces scanning.
- ✗
The time range filter on timestamp cannot be combined with the temperature filter efficiently.
Why it's wrong here
Combining a time-range filter with a numeric filter is not inherently inefficient in Cosmos DB; the query engine can use range indexes and even composite indexes (e.g., deviceId + timestamp + temperature) to evaluate both predicates together. However, neither filter includes the partition key, so the real bottleneck is still the cross-partition fan-out, not the combination of predicates. If the partition key were included, this style of filter would be executed efficiently without a full scan.
- ✗
The default indexing policy only indexes strings and numbers as range indexes, but temperature is stored as a number and is indexed.
Why it's wrong here
This option's factual claim is correct—the default indexing policy does index string and numeric fields with range indexes, so temperature is indexed and queryable—but it does not explain the observed slowness. A query may still be slow even with every field indexed because the missing partition key forces the query to be distributed to every partition. Thus, this answer is a true statement that misses the actual root cause: the query is not partition-key-scoped.
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
Courseiva writes every DP-900 question from scratch — 820 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.