Microsoft DP-420: Designing and Implementing Cloud-Native Applications Using Azure Cosmos DB Practice Exam

Correct: A — high cardinality that spreads requests evenly and aligns with the common query filter. A good partition key distributes storage and throughput evenly and matches the dominant access pattern (here, device), avoiding hot partitions and cross-partition queries — exactly what this workload needs.

Why not the others: a single fixed value (B) and a low-cardinality status field (D) concentrate load into few partitions (hot partitions); a random GUID (C) spreads writes but forces expensive cross-partition queries because it does not match the query filter.

Correct: B — a hierarchical partition key (tenantId then userId). Hierarchical (sub-)partition keys let Cosmos DB target queries efficiently at multiple levels and avoid a single large logical partition per tenant — exactly the multitenant pattern described.

Why not the others: a single system-wide key (A) creates hot partitions; no partition key (C) is not viable at scale; a database account per tenant (D) is heavy operational overhead and is not the partitioning mechanism the exam targets here.

Correct: B — a request-rate-too-large (throttling) error; retry after the recommended interval or increase RU/s. A 429 means the request exceeded provisioned request units; the SDK surfaces a recommended retry-after, and you either let the SDK retry or provision more throughput (or use autoscale) — exactly the correct handling.

Why not the others: a 429 is not a permission error (A), a network timeout (C), or a schema failure (D) — those are unrelated conditions with different remedies.

Correct: C — a stored procedure. Stored procedures run server-side JavaScript and execute atomically within a single logical partition, making them the right tool for multi-item transactional logic on the server — exactly the requirement.

Why not the others: a UDF (A) only computes values inside queries and cannot write; a change feed processor (B) reacts to changes asynchronously, not atomically; an analytical store query (D) reads the column store for analytics and does not write transactionally.

Correct: D — Strong. Strong consistency provides linearizable reads — readers always see the most recent committed write — at the cost of higher latency and RU consumption, and it constrains write-region topology. That matches the requirement exactly.

Why not the others: Eventual (A) is the weakest and lowest-cost; Session (B) guarantees consistency only within a client session; Consistent prefix (C) guarantees ordering but not the latest value. None gives linearizable reads.

Correct: C — the change feed, consumed via an Azure Functions trigger. The change feed emits a persistent, ordered record of inserts and updates; an Azure Functions trigger processes it to drive downstream denormalization, aggregation, and search indexing in near real time — exactly the integration described.

Why not the others: a backup restore (A) is a recovery operation; a composite index (B) speeds queries but does not stream changes; a manual regional failover (D) is an availability action. None reacts to item changes.

Correct: C — customize the indexing policy to exclude paths that are never used in queries. For write-heavy workloads, excluding unqueried paths from the indexing policy reduces the indexing work per write and therefore write RU cost — exactly the optimization the scenario needs.

Why not the others: indexing every property (A) increases write RU; changing consistency (B) affects reads and availability, not indexing cost; continuous backup (D) is a recovery setting with no effect on write RU.

Correct: B — autoscale (or serverless) throughput that adapts to demand. For spiky, unpredictable traffic with idle periods, autoscale scales RU/s up for bursts and down when idle (and serverless bills per request), avoiding paying for peak capacity around the clock — exactly the cost-optimization goal.

Why not the others: fixed RU/s sized for peak (A) wastes capacity during idle periods; disabling indexing (C) breaks queries; Strong consistency (D) is unrelated to throughput cost.

Correct: D — use Microsoft Entra ID with Azure RBAC role assignments for data-plane access. Entra ID identities with RBAC role assignments grant least-privilege, auditable access without distributing account keys — exactly the key-free model the policy requires.

Why not the others: sharing the primary key (A) and embedding it in source (C) are exactly the key-based patterns the policy forbids; disabling authentication (B) is insecure and not a real option.

Correct: A — continuous backup with point-in-time restore. Continuous backup lets you restore to any point in time within the retention window, which is what recovering to the moment just before an accidental bulk delete requires — exactly the scenario.

Why not the others: periodic backup (B) only restores to fixed snapshot intervals, not any second; a composite index (C) speeds queries; the analytical store (D) supports analytics, not restore.