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 to Azure Blob storage

  Why it's wrong here

  Azure Blob storage is designed for storing large unstructured objects like images, videos, and backups, not for frequent, low-latency key-value read/write operations that session state requires. Blob storage lacks a built-in partition key mechanism, so you cannot control data distribution to avoid hot spots, and each access incurs network and I/O overhead that is noticeably higher than Table Storage. Additionally, Blob storage doesn't support atomic per-entity updates with conditional logic, making it awkward to handle concurrent session modifications. Therefore, moving session state to Blobs would likely worsen latency and scalability rather than improve it.

• ✗

  Store large attributes in a separate table

  Why it's wrong here

  Moving large attributes to a separate table creates a one-to-one or one-to-many split that forces the client to perform multiple queries to reconstruct a session entity, adding extra round trips and increasing total latency. This approach does not reduce the load on the original partition key or fix an uneven distribution; the same session IDs would still land on the same partitions, potentially causing hot partitions. It also complicates schema management, transaction consistency, and cleanup logic, without providing any performance benefit. The correct strategy is to keep the entity intact but ensure its partition key spreads requests across many physical partitions.

• ✗

  Switch to Azure Queue storage

  Why it's wrong here

  Azure Queue storage is a messaging service for asynchronous communication between application components, not a low-latency key-value store for session state. Queue messages are processed in FIFO order and are typically consumed and deleted, whereas session state must be directly accessible by a session ID at any time without losing data. Using a queue would require enqueuing and dequeuing messages for every state read/write, adding significant overhead and breaking the ability to perform point lookups. Therefore, switching to Queue storage is fundamentally incompatible with session state management requirements.

• ✓

  Use a partition key that distributes load evenly, such as UserID

  Why this is correct

  A partition key in Azure Table Storage determines the physical partition where an entity is stored; using a high-cardinality, evenly distributed key like UserID ensures requests are spread across many physical partitions, avoiding hot partitions that cause throttling and high latency. Session IDs often have natural randomness, but if you use a key like UserID, you guarantee that no single partition becomes a bottleneck, even when many users are active simultaneously. Even distribution is critical because Azure scales by splitting partitions, and a well-chosen partition key allows the service to handle increased load without performance degradation. This practice aligns with Azure Table Storage's design principles for scalable, low-latency key-value access.

Go deeper

Related to this question