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.

• ✗

  Azure Cosmos DB with SQL API

  Why it's wrong here

  Cosmos DB’s SQL API lacks a native time-series optimisation; its indexing model is document-centric, not optimised for the high-frequency append and timestamp-range scans required by streaming event ingestion. It is tempting because Cosmos DB offers low-latency writes and flexible schemas, making it a strong candidate for globally distributed, real-time applications such as user-profile stores or session state, where point-reads and key-based lookups dominate rather than time-windowed queries.

• ✗

  Azure SQL Database with columnstore index

  Why it's wrong here

  Azure SQL Database with columnstore indexes can compress and accelerate analytic scans, but as an OLTP engine it is not architected for sustained, high-frequency ingestion of time-series events. Each row insert incurs transaction-log writes, buffer-pool overhead, and index/columnstore maintenance, so extremely high write rates lead to contention and escalating DTU/vCore costs. While columnstore helps reporting, it neither provides the simple timestamp-range access pattern of a key-value store nor scales to the per-cost throughput of Azure Table Storage.

• ✓

  Azure Table Storage

  Why this is correct

  Azure Table Storage is a schema-less key-value store where data is addressed by PartitionKey and RowKey, making it a natural fit for IoT-style time-series data. Using a partition key such as device ID and a row key such as inverted timestamp allows efficient range scans for a given device over a time window, while inserts are cheap and highly parallel across partitions. This design delivers low latency at very low cost without the operational complexity of a SQL-based service, which is why it is the correct recommendation.

• ✗

  Azure Data Lake Storage Gen2

  Why it's wrong here

  Azure Data Lake Storage Gen2 is a Hadoop-compatible distributed file system built on Blob storage, intended for batch analytics and ETL pipelines rather than per-record, low-latency writes. It exposes a hierarchical namespace and supports massive parallel file processing, but writing millions of individual small events to append blobs would produce poor throughput and high latency, and its query engine is not optimized for transactional key- or timestamp-based range lookups. Therefore, it fails the requirements of high-frequency ingestion and immediate time-range queries.