AZ-305 Design data storage solutions 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.

• ✗

  Network latency between devices and Azure

  Why it's wrong here

  Network latency is a function of the device's connectivity path to Azure—edge gateways, WAN links, or IoT Hub ingestion—not of the data storage design itself. While minimizing latency can inform whether to use Azure IoT Edge for pre-processing, it does not change how you structure partitions, choose storage tiers, or manage lifecycle policies. The storage service only affects persistence and post-ingestion processing, not the round-trip delay from device to cloud.

• ✓

  Ingestion throughput limits of the storage service

  Why this is correct

  Every Azure storage service, such as Blob Storage or Data Lake Storage Gen2, publishes specific scalability targets for ingress requests per second and bandwidth. Although Azure can consume high volumes, a streaming data lake intake must be verified against peak event rates; otherwise, the service throttles writes, causing backlog and data loss if IoT devices have limited buffering. Choosing partition layouts, multiple storage accounts, or premium capacity is directly tied to these limits.

• ✓

  Data retention and archival policies

  Why this is correct

  Because IoT devices can generate gigabytes per hour, storage volume grows quickly, and costs climb sharply if all data remains in hot tiers. Lifecycle management policies should automate movement from hot to cool to archive, eventually purging raw data after a compliance window expires. These policies also affect downstream analytics, so you must design the storage schema to let archived data remain queryable using tools like Azure Synapse or Data Lake Analytics.

• ✓

  Partitioning strategy to distribute load

  Why this is correct

  Partitioning uses a key or naming convention to spread writes and reads across multiple physical servers, avoiding the 'hot partition' problem where one shard absorbs all traffic. In time-series workloads, a partition key that includes only a timestamp can inadvertently align all writes onto a single range, so you must combine device ID and time buckets. This directly determines whether the service meets its throughput targets and whether queries are efficient.

• ✗

  Data consistency levels required by downstream consumers

  Why it's wrong here

  Time-series IoT data is inherently append-only and often used for monitoring, so downstream consumers usually tolerate eventual consistency without compromising the analytics output. Strong consistency models like four-nines in Cosmos DB or ACID in relational stores are costly and unnecessary for a telemetry pipeline. Moreover, consistency is a property of the database engine and the consumer's read model, not a consideration at the data-ingestion/retention tier that this question targets.

Go deeper

Related to this question