12 DP-420 Scenarios, Sorted by Difficulty

Correct Answer: A

A synthetic key like deviceId_date spreads writes across more logical partitions than deviceId alone (which would create one hot partition per device as reading volume grows) while still allowing efficient single-partition queries scoped to a device and date range. deviceId alone (B) is a reasonable starting point but becomes a throughput bottleneck as a single device's reading volume grows within one logical partition's RU limit. Timestamp (C) would scatter a single device's history across many partitions, making the most common query cross-partition and expensive. A random GUID (D) maximizes write distribution but makes every device-history query cross-partition — the opposite of what the access pattern needs.

Correct Answer: B

Session consistency guarantees read-your-own-writes and monotonic reads within a single client session, at latency and availability close to Eventual — matching "low latency" plus "my own writes must be visible to me" without extra configuration. Strong (A) guarantees linearizability but at the highest latency and lowest availability of the five levels, more than this scenario needs. Bounded Staleness (C) bounds how stale reads can get but does not specifically guarantee a session's own writes are visible sooner than the staleness window. Eventual (D) offers no read-your-own-writes guarantee at all, which the scenario explicitly requires.

Correct Answer: C

Direct mode connects the client straight to the backend replica over TCP, skipping the gateway hop, and gives the lowest latency when client and account are in the same region — the standard recommendation for performance-sensitive workloads. Gateway mode (A) proxies every request through a gateway service; it works everywhere (including from networks that block non-HTTPS ports) but adds a hop, so it is not the lowest-latency option. "HTTP/1.1 mode" (B) is not a real Cosmos DB SDK connectivity mode. Bypassing the SDK (D) would mean re-implementing retry, partition routing, and session-token handling yourself — not a supported performance optimization.

Correct Answer: D

Time to live is a built-in Cosmos DB feature: set a default TTL in seconds on the container (86400 for 24 hours), and Cosmos DB automatically deletes expired items in the background with no application code or extra compute. A stored procedure (A) and a scheduled Function (B) both require you to write and operate cleanup logic Cosmos DB already provides natively. Change Feed (C) is for reacting to changes, not for expiring items — using it for deletion is solving the problem the hard way when a native feature exists.

Correct Answer: A

Change Feed plus an Azure Functions trigger is the documented Cosmos DB pattern for denormalizing data across containers reactively and asynchronously, decoupling the order-writing service from anything about the summary container. Option C couples the two containers directly in application code, which is exactly what the scenario says to avoid. A stored procedure (B) runs within a single container/partition transaction scope and cannot write to a different container. A daily batch job (D) does not meet "kept in sync... every time an order is created or updated" — it introduces up to 24 hours of staleness.

Correct Answer: B

Cosmos DB indexes every property by default; excluding a specific path in a custom indexing policy stops that property from being indexed, directly reducing the RU cost of writes that include it, while leaving everything else indexed and queryable as before. Moving the field to another container (A) is a data-model change with much larger blast radius than adjusting an indexing policy. Lazy indexing (C) is a deprecated/legacy option that trades consistency of query results for indexing cost, not a targeted fix for one property. Reducing throughput (D) does not reduce the RU cost of an operation — it reduces the RUs available, which would cause throttling instead.

Correct Answer: C

Cosmos DB for NoSQL supports a custom conflict resolution policy that runs a stored procedure you write, letting you encode arbitrary business logic for merging or choosing between conflicting versions — exactly what "specific business logic for resolving exactly this kind of conflict" calls for. Last-writer-wins (A) is Cosmos DB's default and simplest policy, but it is not customizable business logic — it is a plain fallback. Strong consistency (B) is not supported across multiple write regions in Cosmos DB and would not eliminate multi-region write conflicts even if it were. Removing multi-region writes (D) would solve the conflict problem but was ruled out by the scenario's premise of an account that "accepts writes in three regions" as a requirement.

Correct Answer: D

Continuous backup with point-in-time restore is the Cosmos DB feature specifically designed to restore to any point within the retention window (up to 7 or 30 days depending on tier), satisfying "any specific second." Periodic backup (A) only lets you restore to the fixed intervals it captured — 4-hour intervals cannot hit an arbitrary second. A daily export (C) has the same granularity problem, worse. GRS (B) protects against regional storage failure and does not provide point-in-time restore to an arbitrary timestamp at all.

Correct Answer: A

A correlated subquery in Cosmos DB's SQL dialect operates on a nested array or property within a single document being evaluated — it never needs to fan out and merge results across containers or partitions the way a true JOIN-style cross-partition operation does, so its RU cost stays much closer to the cost of evaluating one document. Consistency level (B) has no bearing on subquery RU cost — that is a separate dimension entirely. Correlated subqueries do not add a partition key filter automatically (C); if the outer query still lacks one, it is still cross-partition. Every operation in Cosmos DB is RU-charged (D); nothing bypasses RU accounting.

Correct Answer: B

A hierarchical partition key lets you combine tenantId with a second property (such as a resource type or date bucket) so a single large tenant's data spreads across multiple physical partitions internally while still supporting efficient tenantId-scoped queries — this is the documented fix for exactly this "one hot tenant" problem. Switching the whole container to a random GUID (A) would fix the hot-partition problem but destroy the ability to efficiently query by tenant for every other tenant too — a much bigger change than needed. Raising throughput (C) does not help: a single logical partition has its own throughput ceiling regardless of how much total RU/s the container is provisioned with. Serverless mode (D) does not remove the per-logical-partition throughput ceiling either.

Correct Answer: C

Data plane RBAC with Microsoft Entra ID lets you grant a managed identity scoped, revocable permissions to read (or write) Cosmos DB data without that identity ever holding an account key, which is exactly "never having access to the primary or secondary keys" plus per-identity revocability. Rotating keys (A) still relies on keys existing and being distributed, and does not provide per-identity revocation. Resource tokens (B) are still derived from account keys and add operational complexity without meeting the "never has key access" requirement in the same way Entra ID RBAC does. Storing a key in an environment variable (D) still gives the process access to a key — the opposite of the stated requirement.

Correct Answer: D

Cosmos DB stored procedures execute within the scope of a single logical partition as one atomic transaction: all writes inside the procedure commit together, or none do, if the items share a partition key — which they do here. Three separate SDK calls (A) are three independent operations; a try/catch does not undo the ones that already succeeded if a later one fails. Bulk Support (C) is designed for high-throughput independent operations, not atomicity — a failure in one operation does not roll back the others. Chaining separate Azure Functions with Durable Functions (B) can achieve eventual/compensating consistency (a saga pattern) but that is different from true atomic, all-or-nothing transactional behavior in one commit.