DP-900 Practice Question: Describe considerations for working with non-relational data on Azure

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, multi-model NoSQL database service that stores data as schema-agnostic JSON documents, making it a natural fit for a product catalog. It provides turnkey global distribution across Azure regions, automatic indexing of all properties, and read and write latencies in the single-digit milliseconds at the 99th percentile. Cosmos DB also offers multiple consistency levels (strong, bounded staleness, session, consistent prefix, eventual) so you can tailor data freshness versus performance. For a retail catalog that must be always available and queried at scale, Cosmos DB's document API and dedicated throughput (RU/s) deliver both flexibility and predictable performance.

• ✗

  Azure Table Storage

  Why it's wrong here

  Azure Table Storage is a NoSQL key-value store that stores data as entities with a partition key, row key, and properties, but it lacks the querying power needed for a product catalog. It supports only simple queries using point lookups or range scans on the partition/row keys, and it does not allow arbitrary property-based filtering, secondary indexes, or aggregation. While Table Storage is cheap and can be replicated to a secondary region (RA-GRS), it does not offer multi-region writes, automatic failover, or customizable consistency models like Cosmos DB. Thus, a catalog requiring complex searches (by category, price, or attributes) would hit severe limitations.

• ✗

  Azure Blob Storage

  Why it's wrong here

  Azure Blob Storage is designed for storing massive amounts of unstructured binary data—such as images, videos, or backups—not for frequently updated, queryable product records. It lacks a document model, built-in property indexing, and query engine; you would have to read the entire blob to inspect individual items, which is inefficient and non-transactional. Although you can store JSON files in blobs, updating a single product would require rewriting the entire file, and there is no concurrency control for fine-grained edits. Consequently, blob storage is unsuitable as a primary store for a dynamic product catalog, although it could hold catalog images or static files.

• ✗

  Azure Cache for Redis

  Why it's wrong here

  Azure Cache for Redis is an in-memory data store (based on open-source Redis) that is primarily used as a low-latency cache layer, not as a durable, authoritative database. By default, data is volatile and can be lost on a cache server reboot or on failure, unless you enable Redis persistence (RDB or AOF), which is still not intended for the same durability and transactional guarantees as a database. It also lacks the ability to run ad hoc queries or aggregations over product catalog data with complex filters—Redis data structures (hashes, sorted sets) require custom application logic to query. Using it as the sole store for a product catalog would risk data loss and provide poor operational querying, making it an incorrect choice for this scenario.

Go deeper

Related to this question