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.

• ✓

  Change the partition key to a synthetic key combining userId and postId

  Why this is correct

  A synthetic partition key that concatenates userId and postId (for example, "user_12345_post_67890") gives every individual post its own logical partition. Because a single post document is typically a few kilobytes at most, no logical partition can realistically approach the 20 GB limit, regardless of how many posts a single user creates. This high-cardinality key distributes data evenly across physical partitions and is the standard pattern for avoiding hot partitions in Cosmos DB when one entity can have unbounded data growth.

• ✗

  Increase the RU/s

  Why it's wrong here

  Increasing the provisioned throughput (RU/s) affects only request rate, latency, and throttling—it has no impact on the storage capacity of a logical partition. The 20 GB limit is a hard storage constraint per logical partition, independent of how many request units you allocate to the container. Even with unlimited RU/s, the application would still fail when a user's partition grows beyond 20 GB, so this merely relieves performance symptoms without touching the actual fault in the data model.

• ✗

  Split the container into multiple containers by userId range

  Why it's wrong here

  Splitting the container into multiple containers by userId range is a form of manual sharding that is unsupported and unnecessary in Cosmos DB. The service already manages physical partition splitting automatically; however, a logical partition (defined by the partition key) can never be split across physical partitions, so each new container would still need a partition key—and if you keep userId as that key, you'll recreate the same 20 GB limit per user. This approach also complicates cross-container transactions, queries, and consistency management, and it fails to address the core design flaw that the original partition key lacks sufficient cardinality.

• ✗

  Use a different API like MongoDB

  Why it's wrong here

  Switching the Cosmos DB account to the MongoDB API only changes the wire protocol and SDK compatibility layer; the underlying engine still enforces the exact same 20 GB logical partition limit. The MongoDB API does not alter how partition keys are hashed or how data is stored, so the same userId-based partition key would continue to create oversized logical partitions for active users. This would require a significant application rewrite to a different API without addressing the root cause, making it a purely cosmetic change with no architectural benefit.

Go deeper

Related to this question