Develop for Azure storage →mediumMultiple ChoiceObjective-mapped

AZ-204 Develop for Azure storage Practice Question

You are developing a solution that uses Azure Table Storage to store time-series data. You need to query data for a specific device within a time range efficiently. Which two properties should you use as the PartitionKey and RowKey?

⚠ Common exam trap

Many candidates assume timestamp should be the PartitionKey for time-series data, but this ignores the need for partition-level query efficiency, leading to costly cross-partition scans instead of single-partition range 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

✓

PartitionKey = deviceId, RowKey = timestamp

Using deviceId as the PartitionKey ensures all data for a specific device is stored in the same partition, enabling efficient point queries. Using timestamp as the RowKey allows range queries within a time range for that device, as RowKey is sorted lexicographically within a partition. Option A is incorrect because using timestamp as PartitionKey scatters data across partitions, requiring cross-partition queries. Option B is incorrect for the same reason, and also the RowKey is not optimized for range queries. Option D is incorrect because using reverse timestamp as RowKey does not improve range query efficiency over timestamp directly.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
PartitionKey = timestamp, RowKey = reverse deviceId
Why it's wrong here
Using `timestamp` as the `PartitionKey` would lead to hot partitions, as all data for a given second or minute would reside on the same partition server, severely limiting scalability and write throughput. Furthermore, querying by `deviceId` across different timestamps would necessitate scanning multiple partitions, making such queries highly inefficient. A `reverse deviceId` as `RowKey` offers no practical benefit for standard `deviceId` lookups or range queries.
✗
PartitionKey = timestamp, RowKey = deviceId
Why it's wrong here
Setting `PartitionKey` to `timestamp` creates hot partitions because all entities generated within the same time interval (e.g., second, minute) would be stored together, severely limiting write throughput and overall scalability. While `RowKey = deviceId` allows efficient retrieval of all data for a specific `deviceId` *within that precise timestamp*, querying for a `deviceId` across a time *range* would require scanning numerous partitions, leading to poor performance.
✓
PartitionKey = deviceId, RowKey = timestamp
Why this is correct
Designating `deviceId` as the `PartitionKey` ensures data is distributed across many partitions, preventing hot spots and maximizing scalability for both writes and reads. With `timestamp` as the `RowKey`, entities for a specific device are stored in chronological order within their partition. This enables highly efficient queries for a single device's data over a specific time range, leveraging the `RowKey`'s ordered nature for rapid range scans.
✗
PartitionKey = deviceId, RowKey = reverse timestamp
Why it's wrong here
While `deviceId` as `PartitionKey` is excellent for data distribution, using a `reverse timestamp` as `RowKey` would store data in descending chronological order. This design might slightly optimize queries for the *latest* entry for a specific device, but it complicates standard time range queries (e.g., "data from 9 AM to 10 AM") as the range would need to be specified in reverse, making them less intuitive and potentially less efficient than with a standard ascending `timestamp`.

Go deeper

AZ-204 Develop for Azure storage Practice Question

Why each option matters

Option-by-option breakdown

Related to this question