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 building company stores IoT sensor data in Azure Cosmos DB using the NoSQL API. Each document contains fields: deviceId (partition key), timestamp, temperature, and humidity. The most common query is to retrieve all readings for a specific device within a time range, which runs efficiently. However, the analytics team occasionally runs a query to find all devices that reported a temperature above 50 degrees Celsius in the last hour, without specifying deviceId. This query is very slow and consumes a high number of request units (RUs). What is the most likely reason for the slow performance and high RU consumption?
⚠ Common exam trap
Candidates often assume indexing is the culprit (Option B) because they think a missing index causes slow queries, but Azure Cosmos DB indexes all fields automatically, so the real issue is the missing partition key forcing a cross-partition scan.
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 use the partition key, causing a cross-partition scan.
The query does not include the partition key (deviceId) in the filter, so Azure Cosmos DB cannot route it to a single physical partition. Instead, it must fan out the query to every partition, scanning all documents across the container. This cross-partition query consumes significantly more RUs and takes longer because each partition must be queried sequentially or in parallel, and the results are merged server-side.
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 query does not use the partition key, causing a cross-partition scan.
Why this is correct
In Azure Cosmos DB, a query's RU cost and latency heavily depend on whether its filter includes the partition key. When the WHERE clause lacks the partition key, the request cannot be routed to a single physical partition, so the query is fanned out to every partition and scans each one for matching documents. This cross-partition scan multiplies the amount of data read and the RU consumption, and it also introduces network round-trips across partitions, which is why the query is slow and expensive. Including the partition key in the filter would constrain the query to one partition and avoid this overhead.
- ✗
The query is not using an index on the temperature field.
Why it's wrong here
Cosmos DB automatically indexes every property of a JSON document by default, so the temperature field already has an index and can be used for filtering. Even with that index available, a query that filters only on temperature and a time range still does not know which physical partition holds the data, because the partition key is absent from the predicate. Therefore, the index is applied individually within each partition, but the query still has to visit all partitions, making the index useful yet insufficient to prevent the cross-partition scan. The real bottleneck is partition-key omission, not a missing index.
- ✗
The time range filter is too large, causing a full table scan.
Why it's wrong here
A large time range can increase the number of documents scanned, but the main issue is that the query is cross-partition. Even with a small time range, the query would still need to search each partition for matching documents.
- ✗
The document size is too large, increasing RU per read.
Why it's wrong here
Document size does affect RU consumption, since Cosmos DB charges a baseline fee for reading an item plus additional RUs proportional to the document and index size. However, that cost is a per-item, per-read charge and would not suddenly escalate just because a time-range query is run. The sudden RU spike is explained by the cross-partition scan, which causes the query to read from every partition and evaluate many more items than necessary; document size is a constant multiplier, not the root cause. If the same documents were queried with the partition key, the RU cost would be far lower regardless of size.
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
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
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.