AZ-204 Develop for Azure storage Practice Question

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 timestamp as the partition key and device ID as the row key.

  Why it's wrong here

  Using timestamp as the partition key for telemetry data is problematic because all recent data, which is typically the most frequently written, would fall into a very small number of partitions (e.g., current hour/day). This creates "hot partitions," where a disproportionate amount of write traffic targets a single partition, leading to throttling, increased latency, and reduced overall throughput as the storage system cannot distribute the load effectively. While device ID as row key offers uniqueness, the primary bottleneck is the partition key's distribution.

• ✓

  Use device ID as the partition key and timestamp as the row key.

  Why this is correct

  This is the optimal design for telemetry data. Using the device ID as the partition key effectively distributes write operations across numerous partitions, as each unique device generates its own data stream. This prevents hot partitions and maximizes write throughput. Furthermore, using the timestamp as the row key within each device's partition ensures that data is stored in chronological order, enabling highly efficient range queries for a specific device's telemetry over a time period.

• ✗

  Use device type as the partition key and timestamp as the row key.

  Why it's wrong here

  While using timestamp as the row key is good for range queries, using device type as the partition key is generally insufficient for high-volume telemetry. Device types often have low cardinality (e.g., "sensor", "camera", "gateway"), meaning many devices of the same type would write to the same partition. This can lead to "hot partitions" for common device types, causing bottlenecks, throttling, and uneven distribution of data and workload across the storage system, hindering scalability.

• ✗

  Use a single partition key for all events and use timestamp as the row key.

  Why it's wrong here

  Employing a single, static partition key for all telemetry events severely limits the scalability and write throughput of the storage solution. All incoming data would be directed to a single logical partition, which has inherent throughput limits (e.g., 20,000 requests per second in Azure Table Storage). This design creates an immediate bottleneck, preventing the system from horizontally scaling to accommodate high-volume telemetry writes, regardless of how well the row key is chosen.