Courseiva

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

A ride-sharing application uses Azure Cosmos DB for trip data. Each trip record contains TripID (unique), DriverID, RiderID, TripDate, and other details. The most common query retrieves all trips for a specific driver within a given date range. Which partition key should be chosen to minimize Request Unit (RU) consumption and ensure even data distribution?

⚠ Common exam trap

The trap here is that candidates often pick TripDate because it seems logical for date-range queries, but they overlook that the primary filter is DriverID, and partitioning by TripDate would cause cross-partition queries and potential hot spots on high-traffic dates.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

DriverID

DriverID is the optimal partition key because the most common query filters on DriverID and a date range. Partitioning by DriverID ensures that all trips for a specific driver are stored in the same physical partition, making the query a single-partition operation that consumes minimal Request Units (RUs). It also provides even data distribution across partitions because each driver generates a roughly similar number of trips, avoiding hot spots.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • TripID

    Why it's wrong here

    TripID is unique per trip, so using it as partition key would result in each trip being in its own partition. Queries filtering by DriverID would become cross-partition queries, consuming more RU and having higher latency.

  • DriverID

    Why this is correct

    DriverID aligns with the most common query pattern. All trips for a given driver are stored together, allowing single-partition queries. This minimizes RU consumption if the number of trips per driver is within the 20 GB logical partition limit.

  • TripDate

    Why it's wrong here

    Using TripDate as the partition key creates a time-series hot spot: all trips from the same day, especially peak days like holidays or weekends, land in one logical partition, causing throttled throughput and unbalanced request-unit consumption. Moreover, a driver who has trips across multiple days would require cross-partition queries for every driver-based lookup because no single partition contains that driver's complete history. Date-based keys also suffer from append-heavy access patterns, where the current day's partition becomes a bottleneck while older partitions sit idle.

  • RiderID

    Why it's wrong here

    Although RiderID offers high cardinality and would evenly distribute write operations, it fails the primary access pattern: the application queries trips by driver to compute earnings or routes, not by rider. Because each rider's trips are stored in a different physical partition, a DriverID filter forces Cosmos DB to fan out across all partitions and merge results, escalating request-unit costs and adding noticeable latency. A partition key must align with the most frequent query predicate, and RiderID only supports rider-centric workloads, not the driver-focused trip reporting this system requires.

About these practice questions

One of 820 original DP-900 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.