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 analytical store

  Why it's wrong here

  Azure Cosmos DB with analytical store is designed for multi-model NoSQL workloads with predictable low-latency reads and writes, and its analytical store is a columnar representation for operational analytics on live transactions, not a bulk ingestion target for append-only telemetry. It incurs request-unit (RU) charges per write and index maintenance overhead, so ingesting petabytes of IoT sensor events would be prohibitively expensive and still lacks the scale-out storage and SQL query elasticity of a data lakehouse. The analytical store does not provide the file-based, format-agnostic (e.g., Parquet) data lake foundation needed for massive parallel analytical workloads.

• ✗

  Azure SQL Database with columnstore indexes

  Why it's wrong here

  Azure SQL Database, even with columnstore indexes, is a fully managed OLTP/relational database with a fixed scaling model and storage limits—the largest service tiers top out at far below petabyte scale, unlike distributed data lakes. Columnstore compression and column-level batch processing improve query performance on large fact tables, but the engine remains tied to database size, transaction log, and compute-storage coupling, making it unsuitable for absorbing continuous, append-only IoT telemetry at exabyte-scale volumes. It also enforces a strict schema, which conflicts with the flexible, schema-on-read approach typically required for raw telemetry streams.

• ✗

  Azure Blob Storage with Azure Cognitive Search

  Why it's wrong here

  Azure Blob Storage provides massively scalable object storage, but without the hierarchical namespace enabled it lacks genuine directory-level operations and optimized path-based security, which is why a data lake still needs ADLS Gen2 for production-scale analytics. Adding Azure Cognitive Search brings full-text search and relevance ranking over blob content, not SQL-based analytical querying—it cannot perform aggregations, joins, or predicate pushdown over petabytes of telemetry in Parquet. Cognitive Search is designed for document retrieval scenarios like website search or content discovery, so the combination still fails to deliver the SQL analytical engine that the company requires for data analysis.

• ✓

  Azure Data Lake Storage Gen2 with Azure Synapse SQL pool

  Why this is correct

  Azure Data Lake Storage Gen2 is the correct storage foundation because it blends the object storage scalability of Blob Storage with a hierarchical namespace, POSIX permissions, and built-in support for storing data in open formats like Parquet—making it ideal for petabyte- and exabyte-scale IoT telemetry ingestion. Azure Synapse SQL pool (dedicated or serverless) provides a distributed, massively parallel processing (MPP) engine that executes T-SQL directly over the files in ADLS Gen2, enabling schema-on-read analytics without moving and re-loading data. This architecture natively handles append-only telemetry streams, accelerates queries via partition elimination and columnar storage, and separates storage from compute to independently scale ingestion throughput and query concurrency.

Go deeper

Related to this question