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

  Why this is correct

  Azure Cosmos DB is a globally distributed NoSQL document database with schema-agnostic indexing, making it a natural fit for semi-structured JSON payloads commonly found in healthcare analytics. Its multiple API options (for example, the core SQL API or MongoDB-compatible API) allow direct JSON document storage and querying, while tunable consistency levels and single-digit-millisecond reads satisfy low-latency operational requirements. Multi-region writes and automatic indexing remove the need for manual schema management, which is essential when analytic event shapes evolve over time.

• ✗

  Azure Files premium shares

  Why it's wrong here

  Azure Files premium shares offer managed SMB and NFS file shares, not a document database or a query engine for semi-structured JSON. You could store JSON text inside files, but the service would not natively index, query, or globally replicate individual documents with tunable consistency, and file locks and share semantics are unrelated to document-level operations. Premium shares excel at lift-and-shift file workloads, not at serving as the online-store tier of a healthcare analytics platform.

• ✗

  Azure Data Factory

  Why it's wrong here

  Azure Data Factory is a cloud ETL/ELT orchestration service that moves and transforms data from sources to destinations; it is not an operational data store. While it can copy JSON into Cosmos DB or transform it with mapping data flows, it exposes no low-latency document read/write or query interface of its own. Using it in place of a database would mean every analytics lookup triggers pipeline execution, which is neither scalable nor appropriate for point-in-time document access.

• ✗

  Azure SQL Managed Instance

  Why it's wrong here

  Azure SQL Managed Instance is a fully managed SQL Server engine with a relational model, so although it supports OPENJSON and JSON type casting, it is not a native document database. It relies on row store tables, relational indexes, and relatively fixed schemas; it also lacks Cosmos DB's automatic indexing of arbitrary document fields and its turnkey multi-region write distribution with tunable consistency levels. For globally distributed, schema-flexible JSON workloads, it would require extra schema design and still not match a document store's horizontal agility.

Go deeper

Related to this question