Describe considerations for working with non-relational data on Azure →hardMultiple ChoiceObjective-mapped
DP-900 Practice Question: Describe considerations for working with non-relational data on Azure
A logistics company stores sensor data from delivery trucks in Azure Table Storage. Each sensor reading includes a TruckID, Timestamp, Location, and EngineTemperature. The most common query retrieves all readings for all trucks within a specific one-hour time window (e.g., between 10:00 and 11:00 on a given day). Currently, the table uses PartitionKey = TruckID and RowKey = Timestamp (ISO format). However, queries filtering by time range are slow and consume many transactions. Which design change will most improve the performance of these time-range queries?
⚠ Common exam trap
Candidates often assume indexing on a column (like Timestamp) will speed up queries in Azure Table Storage, but Azure Table Storage does not support secondary indexes—only the PartitionKey and RowKey are indexed, so the only way to optimize time-range queries is to redesign the key schema to include the time dimension in the PartitionKey or RowKey.
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
✓
Change PartitionKey to a date-based value (e.g., YYYY-MM-DD) and RowKey to a composite of TruckID and Timestamp.
Azure Table Storage queries are most efficient when they target a specific PartitionKey and a range of RowKey values. By setting PartitionKey to a date-based value (e.g., YYYY-MM-DD), all readings for a given day are co-located in the same partition. Then, using a composite RowKey of TruckID and Timestamp allows the query to filter by time range within that partition using a single partition scan, drastically reducing the number of transactions and improving performance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Change PartitionKey to a date-based value (e.g., YYYY-MM-DD) and RowKey to a composite of TruckID and Timestamp.
Why this is correct
Changing the PartitionKey to a date-based value such as YYYY-MM-DD groups all telemetry from every truck for a single day into one partition. Because Azure Table Storage stores rows together by PartitionKey, a query that filters on a date range (e.g., the last 24 hours) will scan exactly one partition, drastically reducing read transactions and lowering cost. The RowKey is then a composite of TruckID and Timestamp, which preserves truck-level granularity and enables efficient sorting and filtering within that day's partition. This design directly aligns the queried time range with the partition structure, which is the optimal way to handle time-range queries in Table Storage.
- ✗
Change RowKey to be a composite of TruckID and Timestamp while keeping PartitionKey as TruckID.
Why it's wrong here
Keeping PartitionKey as TruckID while only changing the RowKey to a composite of TruckID and Timestamp does not alter the physical partitioning at all. A time-range query that spans multiple trucks, such as 'all readings between 10:00 and 11:00', will still require scanning every individual truck partition to find matching rows. Within a single truck's partition, the composite RowKey could help order by time, but the dominant cost of a cross-fleet temporal query is the fan-out across thousands of partitions, and that cost remains unchanged. Therefore, this change provides no meaningful performance or cost benefit for the stated use case.
- ✗
Use Azure Cosmos DB with a partition key on Timestamp instead of Azure Table Storage.
Why it's wrong here
Switching to Azure Cosmos DB does not address the root cause: the query filters by a time range, yet the proposed partition key on Timestamp would scatter each reading’s time window across many physical partitions, forcing a cross-partition fan-out that still consumes many transactions. This option is tempting because Cosmos DB offers flexible indexing and low-latency queries for time-series data, and in a scenario where the primary access pattern was querying a single timestamp value (e.g., “all readings at 10:00”), a Timestamp partition key would be correct.
- ✗
Enable indexing on the Timestamp column in Azure Table Storage.
Why it's wrong here
Azure Table Storage does not support secondary indexes on arbitrary custom properties like Timestamp. The only index in Table Storage is on the primary key, which consists of PartitionKey and RowKey; queries that filter on any other property require a full table scan or per-partition scans. There is no mechanism to 'enable indexing' on a specific column because the storage engine is schema-less and does not offer configurable indexes. Consequently, this option is not technically feasible and would not address the query efficiency problem even if it existed.
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
Table
A table is a structured collection of data organized into rows and columns, used in databases and spreadsheets to store and manage information efficiently.
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.