Microsoft Certified: Azure Cosmos DB Developer Specialty Advanced Practice Exam: Hard Questions 2025

You are designing an Azure Cosmos DB for NoSQL container for an IoT platform. Each device emits telemetry every second. Users query: (1) latest reading per device, (2) all readings for a device in a time range, and (3) aggregated metrics per tenant across many devices for the last 15 minutes. Writes must scale to millions of events/minute. Which data model and partition key design best balances write scalability with query efficiency and RU cost? Assume tenants are independent and must be isolated for performance.

A retail application stores Orders in a Cosmos DB for NoSQL container. Requirements: - Each order has 1–200 line items. - Queries frequently retrieve an order with all line items by orderId. - A background process updates shipment status for the entire order multiple times. - Another process updates individual line item fulfillment fields independently. - You must minimize RU and avoid write contention under high concurrency. Which modeling approach best meets these requirements?

You manage a multi-tenant SaaS storing CustomerProfiles (few writes) and CustomerEvents (high writes). Profiles are read frequently and must be strongly consistent for the tenant’s primary region. Events must be globally distributed and can be eventually consistent. Tenants should not be able to infer each other’s activity, and RU consumption must be predictable. Which approach best meets the requirements?

A gaming platform uses Cosmos DB for NoSQL to store PlayerState documents. Partition key is /playerId. Most players are evenly distributed, but a small subset of “celebrity” players generate massive traffic and cause throttling, while other partitions are underutilized. You cannot change existing playerId values, and you must keep single-player reads/writes efficient. Which strategy is the best way to mitigate hot partitions with minimal application disruption?

You have a Cosmos DB for NoSQL container partitioned by /tenantId. A new requirement needs efficient queries for a tenant’s Orders by status and createdTime range. Current queries use: SELECT * FROM c WHERE c.tenantId = @t AND c.status = @s AND c.createdTime >= @from AND c.createdTime < @to The workload is read-heavy. You add a composite index on (status ASC, createdTime DESC). However, the query still consumes high RU and sometimes scans many documents. Which additional change most likely reduces RU while keeping the partition key unchanged?

You operate a globally distributed Cosmos DB for NoSQL account with multi-region writes. A downstream service consumes changes using the change feed processor. After a failover event, you observe occasional duplicate processing and out-of-order handling for a small percentage of documents. The system must provide exactly-once effects in the downstream system. What is the best design approach to ensure correctness?

A .NET microservice uses CosmosClient to perform high-throughput point reads and patch updates. Under load, you see sporadic timeouts and increased latency, while RU consumption is below provisioned limits. Metrics show high TCP connection counts and frequent socket exhaustion on the client nodes. Which change most likely resolves the issue with minimal impact to Cosmos DB resources?

You need to implement a per-tenant distributed lock using Cosmos DB for NoSQL to coordinate background jobs across multiple instances. Requirements: - Lock acquisition must be atomic. - Locks must expire automatically if the holder crashes. - You must avoid cross-partition transactions. Which design best satisfies these requirements?

A container stores documents averaging 5 KB. A query retrieves the latest 20 items for a user: SELECT TOP 20 c.id, c.createdTime, c.title FROM c WHERE c.userId = @u ORDER BY c.createdTime DESC The container is partitioned by /userId. RU for this query is higher than expected. You already added a composite index on (userId ASC, createdTime DESC), but RU remains high. What is the most effective additional optimization?

You run analytical queries against Cosmos DB for NoSQL using the built-in analytical store and Spark. A new workload requires near-real-time dashboards where operational writes must not be impacted. You notice increased RU consumption and latency spikes on the transactional store during dashboard refreshes. Which action most directly prevents dashboard queries from consuming transactional RU while maintaining near-real-time analytics?