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.

• ✗

  Use the same partition key for all items

  Why it's wrong here

  Assigning a single partition key to every item collapses all data into one logical partition, which Cosmos DB caps at 20 GB and which cannot exceed the throughput allocated to that one partition. All read and write requests target the same physical replica, creating a hot partition and causing 429 throttling under load. This approach forfeits horizontal scale because the request rate and storage are bounded by a single partition rather than distributed across many.

• ✓

  Use a synthetic partition key if natural keys are not suitable

  Why this is correct

  A synthetic partition key is constructed by concatenating or hashing multiple property values, such as a customer ID plus a date or location, to create a key with high cardinality and balanced frequency. This is necessary when natural keys have low cardinality (few distinct values) or are heavily skewed, causing uneven data distribution and hot partitions. For example, using a synthetic key like 'userId-OrderId' (or a hash of it) spreads traffic across many logical partitions while preserving query grouping.

• ✓

  Avoid monotonically increasing partition key values

  Why this is correct

  Monotonically increasing values like timestamps or auto-increment IDs cause all new items to be written to the same logical partition because the partition key range mapping places them in the same physical partition as the key space advances. This creates a 'hot partition' that receives all write traffic, quickly exhausting that partition's share of provisioned throughput and causing throttling. Even if the data set is large, the last partition becomes a bottleneck instead of utilizing the full distributed capacity.

• ✗

  Keep partition key values as small as possible

  Why it's wrong here

  The physical length of a partition key value affects item metadata and storage overhead, but it does not determine how requests are spread across physical partitions. A small partition key such as a two-character code has pitiful cardinality, so all documents sharing that value still land in one partition and cause hot spots. Distribution depends on the number of distinct values and their request frequency, not on whether the key is short.

• ✓

  Choose a partition key with high cardinality

  Why this is correct

  A partition key with high cardinality yields many distinct logical partitions, enabling Cosmos DB to distribute the partition-key ranges across multiple physical partitions and scale out throughput. For example, a device ID or user ID with millions of values is preferable to a status or region field that has only a handful of distinct values. Evenly distributed high-cardinality keys both avoid the 20 GB logical partition cap and spread request units across partitions, reducing the chance of throttling.

Go deeper

Related to this question