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 sensor data from thousands of IoT devices as JSON documents in Azure Cosmos DB using the NoSQL API. Each document contains fields: deviceId (string), timestamp (datetime), temperature (float), humidity (float), and additional device-specific fields (e.g., motionDetected, CO2level). The most common query is: SELECT * FROM c WHERE c.deviceId = 'sensor-123' AND c.timestamp >= '2025-01-01' AND c.timestamp < '2025-02-01' ORDER BY c.timestamp DESC. Which indexing strategy will provide the best performance for this query?
⚠ Common exam trap
A common mix-up: candidates assume the default indexing policy is sufficient for all queries, but they miss that composite indexes are required to efficiently support queries that combine equality filters on one property with range filters and ORDER BY on another property.
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
✓
Create a composite index on (deviceId ASC, timestamp DESC)
The query filters on `deviceId` (equality) and `timestamp` (range with ORDER BY DESC). A composite index on `(deviceId ASC, timestamp DESC)` allows Cosmos DB to efficiently locate the partition for the device and then scan the timestamp range in descending order without an in-memory sort, minimizing RU consumption and latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use the default indexing policy that automatically indexes all properties
Why it's wrong here
The default indexing policy automatically creates a range index on every property, so a query on deviceId alone can use an index seek. However, when you add a timestamp range filter and then ORDER BY timestamp DESC, the database must intersect results from separate indexes and perform an explicit sort because no index structure encodes both keys together. For a high-throughput sensor workload, this per-query sort adds latency and consumes extra RUs, so a composite index is required. This option overlooks the need for multi-property index ordering.
- ✓
Create a composite index on (deviceId ASC, timestamp DESC)
Why this is correct
A composite index on (deviceId ASC, timestamp DESC) exactly matches the query pattern: it lets the query engine seek on the deviceId equality predicate, then perform a contiguous descending scan on timestamp for the range condition. Because the index is already sorted in the requested timestamp order, the results can be streamed without a separate SORT operator, reducing CPU and request-unit cost. The ASC on deviceId supports equality and the DESC on timestamp matches the ORDER BY direction, which is a required nuance in Cosmos DB composite index design.
- ✗
Disable indexing for all properties to speed up writes
Why it's wrong here
Disabling indexing entirely removes the index overhead from write paths, which can indeed increase write throughput in a pure-Ingest scenario. But every subsequent read, including the device telemetry query, becomes a full container scan across all partitions, because there is no index to seek deviceId or timestamp. For a smart-building solution that reads sensor history frequently, that means exploding request units and latency, so sacrificing indexes for write speed is not a viable trade-off here.
- ✗
Create a spatial index on the deviceId field
Why it's wrong here
A spatial index is designed for geospatial query functions such as ST_DISTANCE, ST_WITHIN, and ST_INTERSECTS that operate on GeoJSON Point, LineString, or Polygon properties. deviceId is a string identifier, not a GeoJSON object, so Cosmos DB would reject or ignore a spatial index on it, and it provides no benefit for equality or range comparisons on timestamps. This option confuses a location-aware index with a regular B-tree style composite index, so it is completely unrelated to the telemetry query.
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
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
Data
Data is raw, unprocessed information, like numbers, words, or measurements, that can be stored, processed, and analyzed by computers.
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.