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 the correct choice because it is a fully managed, multi-model NoSQL database with native JSON document support, schema-agnostic indexing, and an SQL-like query engine. It uniquely delivers multi-region writes with automatic failover, elastic horizontal partitioning and tunable consistency, backed by an industry-leading SLA of 99.999% availability and single-digit millisecond read/write latency at the 99th percentile. These capabilities are purpose-built for globally distributed JSON workloads requiring both durability and low-latency access.

• ✗

  Azure Table Storage

  Why it's wrong here

  Azure Table Storage is a fully managed NoSQL key-value store, but it is not designed for native JSON documents or multi-region global distribution with automatic failover. Its data model is a flat collection of entities with typed properties, and although you can serialize JSON into a string property, you cannot natively index or query inside that JSON object. Additionally, scaling and replication require manual management, and failover is not automatic, making it unsuitable for a mission-critical global JSON database.

• ✗

  Azure SQL Database

  Why it's wrong here

  Azure SQL Database is a relational database engine that stores data in normalized tables with enforced schemas, not as native, schema-free JSON documents. While it provides JSON functions and can store JSON in NVARCHAR columns, the JSON is not a first-class data type and any querying or indexing requires conversion or manual JSON paths. Because it is fundamentally relational and does not offer a document-native store with multi-region writes, it does not meet the NoSQL fully managed JSON database requirement.

• ✗

  Azure Cache for Redis

  Why it's wrong here

  Azure Cache for Redis is an in-memory data store used primarily for caching, session state, and high-throughput temporary data, not a durable NoSQL database for primary JSON persistence. Although Redis can store JSON via modules or serialization, data in the cache is volatile by default and can be lost on node failures unless you implement complex persistence and replication, which still do not provide automatic database failover or elastic multi-region write support. Its core purpose is to reduce latency for read-heavy workloads, not to serve as a globally replicated, fully managed JSON database.

Go deeper

Related to this question