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.

• ✓

  Supports querying by partition key and row key

  Why this is correct

  Table Storage's underlying engine physically orders entities by partition key and row key, and it automatically creates a clustered index on this composite key. This design makes equi-joins or range scans on these keys extremely fast because the server can navigate directly to the matching rows without scanning unrelated data. In contrast, Blob Storage has no key-based query capability; blobs are located by container and name, not by user-defined key pairs.

• ✓

  Designed for key-value storage and retrieval

  Why this is correct

  Azure Table Storage is a NoSQL key-value store specifically engineered for storing and retrieving semi-structured entities via a simple two-key schema (partition key and row key). Each entity is a collection of named properties, and the primary access pattern is 'get/put/delete by key', which is ideal for metadata, logs, or user profiles. Unlike Blob Storage, which is designed for unstructured binary payloads, Table Storage provides structured but schema-flexible key-based retrieval.

• ✗

  Provides automatic indexing of all attributes

  Why it's wrong here

  Table Storage indexes exactly two attributes by default: the partition key and the row key, which together form the primary key. Any other property is not indexed, so filtering or sorting on non-key attributes requires retrieving all entities in a partition and evaluating the predicate in client code or using a scan. This lack of secondary indexes is a deliberate trade-off for predictable key-based performance, so claiming it indexes all attributes is incorrect.

• ✗

  Supports REST API access

  Why it's wrong here

  The REST API is a generic storage interface exposed by Table Storage, Blob Storage, Queue Storage, and File Storage alike, so it is not a differentiator that makes Table Storage advantageous. While Table Storage does support REST, almost every Azure Storage service does; the question asks for benefits specific to Table Storage, and REST access is a common baseline rather than a unique capability. Its value lies in protocol compatibility, not in setting Table Storage apart.

• ✗

  Offers higher throughput for large files

  Why it's wrong here

  Table Storage imposes strict size limits—each entity can be at most 1 MB and each property up to 64 KB—making it unsuitable for large files. Blob Storage, by contrast, supports blobs up to 8 TiB in a single block and is optimized for streaming and high-throughput access to bulk binary data. Thus, if you need high throughput for large files, Blob Storage is the correct service, not Table Storage.

Go deeper

Related to this question