Microsoft Certified: Azure Cosmos DB Developer Specialty — Practice Set 1

Question 1

A developer is designing an Azure Cosmos DB for NoSQL data model for an e-commerce application. Orders and their line items are always retrieved together and line items are never queried independently. Which design approach best optimizes read performance?

Accepted Answer

When related entities are always read together and child entities are not queried independently, embedding them in the parent document eliminates cross-document reads and reduces RU consumption per request. Separate containers (A, D) would require cross-partition queries or application-side joins. Stored procedures (C) with relational joins are not a pattern in Cosmos DB for NoSQL.

Question 2

A Cosmos DB container must automatically delete session documents 30 minutes after they are created. Which feature should the developer configure?

Accepted Answer

Setting a default TTL on the container to 1800 seconds (30 minutes) causes Cosmos DB to automatically delete documents after that duration with no application code required. A stored procedure timer (A) and a Change Feed Function (B) are unnecessarily complex and incur additional RU cost. Cosmos DB does not have a built-in trigger type that schedules future deletion (D).

Question 3

A product catalog application stores products across 12 distinct categories. Each category has between 500 and 50,000 products, and product reads are almost always filtered by category. The team wants to minimize cross-partition queries. Which partition key should the developer choose?

Accepted Answer

The partition key should align with the most common query predicate so that most queries are single-partition. Since reads are always filtered by category, using category as the partition key maximizes in-partition query efficiency. Using productId (A) would scatter products across many partitions, forcing cross-partition scans for category queries. createdDate (C) creates hot partitions for recent writes and is not aligned with read patterns. A synthetic key (D) adds complexity and does not improve in-partition access for category-level queries.

Question 4

A developer uses the Azure Cosmos DB .NET SDK to perform a point read of an item by its id and partition key. The application later performs a query using a SQL WHERE clause. Which statement correctly describes when to prefer a point operation?

Accepted Answer

A point read (ReadItemAsync) uses the id and partition key to retrieve a single item directly at a cost of approximately 1 RU, regardless of document size, and with single-digit millisecond latency. A query using WHERE must traverse the index and incurs higher RU cost. Point reads require knowing both the id and partition key; they are not suitable for filtering on non-partition-key properties (C) or multi-item retrieval across partitions (A). The index (D) is irrelevant to the point read vs. query choice.

Question 5

A developer needs to implement a multi-item bank transfer that debits one account and credits another within the same logical partition in Azure Cosmos DB for NoSQL. Which TWO SDK features should the developer use to ensure atomicity? Choose 2.

Accepted Answer

Both SDK Transactional Batch and stored procedures guarantee all-or-nothing atomicity for multiple operations within the same logical partition. The Transactional Batch groups operations into a single atomic request on the client side; a stored procedure encapsulates the logic server-side. Two separate SDK calls (C) are not atomic — a failure between them leaves data inconsistent. Azure Event Hubs (D) is an event streaming service and provides no ACID guarantees. ETags (E) provide optimistic concurrency on a single item, not multi-item atomicity.

Question 6

A team migrates an existing workload to Azure Cosmos DB and needs to construct a synthetic partition key. The source data has two candidate fields: tenantId (low cardinality, ~10 values) and deviceId (high cardinality, millions of values). What is the correct approach for constructing the synthetic key?

Accepted Answer

A synthetic partition key combining tenantId and deviceId achieves high cardinality (preventing hot partitions) while still allowing efficient single-partition queries when both values are known. Using only tenantId (A) creates hot partitions for tenants with many devices. Using only deviceId (B) maximizes distribution but requires cross-partition fan-out for tenant-level queries. Hashing createdDate (D) distributes writes randomly but makes all queries cross-partition.

Question 7

A developer implements a stored procedure in Azure Cosmos DB for NoSQL that processes a batch of 500 items. During testing, the stored procedure times out before processing all items. What is the correct pattern for handling this situation in a stored procedure?

Accepted Answer

Stored procedures in Cosmos DB are bounded execution — they must complete within a fixed time limit. The recommended pattern is to check the remaining execution time or response quota inside the procedure loop, save state as a continuation token, and return it to the client to re-invoke the procedure where it left off. Increasing RUs (A) does not extend the time limit. Multiple separate stored procedures (B) are not atomic across invocations. Bulk Support (D) is a good alternative but does not make stored procedures work correctly — the question is specifically about fixing the stored procedure pattern.

Question 8

An Azure Cosmos DB for NoSQL application needs to implement optimistic concurrency to prevent lost updates when two clients read and modify the same document concurrently. Which SDK feature should the developer use?

Accepted Answer

Cosmos DB implements optimistic concurrency using ETags. Each document has a system-assigned _etag property. By setting IfMatchEtag in the request options on a replace or delete operation, Cosmos DB will reject the operation with a 412 Precondition Failed if the document was modified since it was last read. Cosmos DB does not support pessimistic locking (A, C). Session consistency (D) ensures read-your-own-writes but does not prevent concurrent update conflicts.

Question 9

A developer needs to choose between serverless and provisioned throughput for a new Cosmos DB container that supports a development workload with sporadic, unpredictable traffic and very low sustained RU/s consumption. Which option is most cost-effective?

Accepted Answer

Serverless Cosmos DB charges only for the RUs actually consumed per request with no hourly minimum. For dev/test workloads with sporadic, low-volume traffic, this is the most cost-effective option. Provisioned throughput at 400 RU/s (A) charges continuously even when idle. Autoscale (B) has a higher minimum cost than serverless for very low utilization. Free tier (D) is limited to one per Azure account and is not applicable if the account already uses it for production.

Question 10

An Azure Cosmos DB account is configured for multi-region writes in East US and West Europe. A write conflict occurs when two clients in different regions simultaneously update the same document. Which conflict resolution policy should the developer implement to use a custom server-side merge function?

Accepted Answer

Cosmos DB supports a Custom conflict resolution policy where a stored procedure is registered as the merge handler. The stored procedure receives conflicting versions and can implement domain-specific logic to produce the final winning document. LWW (A, B) uses a numeric property's maximum value as the tiebreaker — it does not allow custom merge logic. Manual conflict resolution via the conflict feed (D) defers resolution to the application asynchronously and is not a server-side automatic approach.

Question 11

A global application requires strongly consistent reads for its financial module. The Cosmos DB account has four read regions. The developer enables Strong consistency. What is the expected impact on read latency and availability compared to using Session consistency?

Accepted Answer

Strong consistency in Cosmos DB requires that reads observe the latest committed write, which means every read must contact the primary write region (or wait for quorum acknowledgement across regions). This increases read latency, especially for clients geographically far from the write region. Session consistency (C) allows reads from the nearest replica after the client's own writes are visible, giving much lower latency. Strong consistency does limit availability under regional partitions (D) but is not identical to Bounded Staleness latency-wise.

Question 12

A developer needs to trigger an Azure Function every time a document is inserted or updated in a Cosmos DB container to fan out notifications. Which integration pattern should they implement?

Accepted Answer

The Azure Cosmos DB trigger for Azure Functions is powered by the Change Feed and is the recommended, event-driven pattern. It invokes the Function automatically when documents are created or updated, with at-least-once delivery and ordered delivery within a partition key. Polling with a Timer trigger (A) introduces latency and wastes RUs. Logic Apps polling (C) is hourly and not near-real-time. Event Grid (D) can be used for control-plane events but not for per-document data changes.

Question 13

A data engineering team wants to run complex analytical queries over the Cosmos DB transactional store without impacting the production OLTP workload. They prefer to use Azure Synapse Analytics SQL serverless pools. Which feature should they enable?

Accepted Answer

Azure Synapse Link enables the Cosmos DB Analytical Store — a column-oriented, auto-synced copy of the transactional data that allows Azure Synapse SQL serverless pools or Spark pools to query historical and current data without impacting OLTP performance. Mirroring for Fabric (A) targets Microsoft Fabric Lakehouse, not Synapse SQL serverless. Nightly ADF exports (C) introduce latency and operational overhead. Point-in-time restore (D) is for disaster recovery, not analytics.

Question 14

An application executes a Cosmos DB query that returns 10,000 documents and the team observes that it consumes 5,000 RUs per execution. The query does not use the partition key in the WHERE clause and includes an ORDER BY on a non-indexed property. Which two changes would most reduce RU consumption?

Accepted Answer

Cross-partition queries fan out to all physical partitions and multiply RU cost by the number of partitions. Adding the partition key to the WHERE clause converts the cross-partition query to a single-partition query, drastically reducing RU cost. Adding a composite index (B) helps ORDER BY performance within a partition but does not eliminate cross-partition fan-out. Increasing throughput (C) raises capacity limits but does not reduce the RUs consumed per query. The integrated cache (D) reduces cost for repeated identical queries but does not fix the underlying query inefficiency.

Question 15

A developer needs to exclude a large binary property (thumbnailData) from the Cosmos DB index to reduce index storage and write RU costs. The property is never used in query predicates. How should the developer configure the indexing policy?

Accepted Answer

Cosmos DB indexing policies support fine-grained path-level exclusions. Adding /thumbnailData/* to excludedPaths tells the indexer to skip this property, reducing index size and write RU cost while leaving all other properties indexed and queryable. Disabling indexing entirely (A) would make all queries perform full scans. Removing the property from the document (C) changes the data schema and loses the stored data. Stored procedures do not bypass the indexer (D).

Question 16

A developer implements a Change Feed processor in a .NET application. After several hours, the processor falls significantly behind the live write stream. The team wants to know whether to add more processor instances. Which API should the developer use to measure the Change Feed lag?

Accepted Answer

The Change Feed estimator is a built-in SDK API that reports the estimated number of remaining changes (the lag) between the current processor position and the tip of the change feed, per partition. This directly answers whether the processor is falling behind and whether additional processor instances are needed. Normalized RU Consumption (A) measures throughput utilization, not change feed lag. Server Side Latency (C) measures request latency. Partition key statistics (D) report data distribution, not feed processing lag.

Question 17

A read-heavy Cosmos DB workload executes the same parameterized product query thousands of times per minute. The query results change only every few minutes. A developer wants to reduce RU consumption on repeated identical queries. Which feature is most appropriate?

Accepted Answer

The Azure Cosmos DB integrated cache is a server-side, in-memory cache on the dedicated gateway tier that caches item reads and query results. Repeated identical queries that hit the cache return results at 0 RU cost, which significantly reduces both RU consumption and latency for high-frequency repeated queries. A composite index (A) reduces per-query cost but does not cache results — identical repeated queries still consume RUs each time. Multi-region reads (C) distribute load but each replica still executes the query. Autoscale (D) increases capacity but does not reduce the RUs consumed per query.

Question 18

A Cosmos DB application is receiving HTTP 429 responses from the service. What does this status code indicate and what is the recommended SDK-level handling?

Accepted Answer

HTTP 429 (Too Many Requests) in Cosmos DB means the application has exceeded the provisioned RU/s for the container or database. The response includes a Retry-After-Ms header indicating how long to wait before retrying. The Cosmos DB SDK has built-in retry logic that honors this interval. 429 is not an authentication error (A), a network timeout (C), or a partition split indicator (D) — partition splits return no error; they are transparent to the client.

Question 19

An operations team needs to detect when a Cosmos DB container's provisioned throughput is consistently over-utilized, as indicated by the Normalized RU Consumption metric exceeding 80% for more than 5 minutes. Which Azure Monitor capability should they configure?

Accepted Answer

Azure Monitor metric alert rules allow teams to configure proactive notification when a metric breaches a threshold for a specified evaluation window. Configuring an alert on Normalized RU Consumption > 80% for 5 minutes triggers an action group (email, webhook, etc.) automatically. Log Analytics queries (A) are reactive and manual. Diagnostic settings for PartitionKeyStatistics (C) measure data distribution, not throughput saturation. Azure Advisor (D) provides periodic recommendations but not real-time alerts.

Question 20

A team needs to implement data-plane security for an Azure Cosmos DB account. They want to avoid using primary/secondary account keys and instead use identity-based access. Which TWO approaches achieve this? Choose 2.

Accepted Answer

Microsoft Entra ID–based data plane access uses Cosmos DB built-in RBAC roles (e.g., Cosmos DB Built-in Data Contributor) assigned to users, service principals, or managed identities — eliminating the need for account keys entirely. Storing the key in Key Vault (B) still uses account keys and doesn't eliminate them. IP firewall rules (D) control network-level access but still require key or Entra ID credentials for authentication. CORS (E) restricts browser origins for web clients but is not an authentication mechanism.

Question 21

A production Cosmos DB container was accidentally dropped by a developer 4 hours ago. The account was configured with continuous backup (7-day retention). The team needs to recover the container with minimal data loss. What is the correct recovery approach?

Accepted Answer

Continuous backup with point-in-time restore allows restoring to any point within the retention window. Restoring to 5 hours ago (1 hour before the deletion) recovers the container with minimal data loss. The restore targets a new account to avoid overwriting existing data. A regional failover (B) does not recover deleted containers — deletion is replicated to all regions. Periodic backup (C) is a separate mode not applicable when continuous backup is configured. Reloading from Change Feed (D) does not work for deleted containers as the feed also records the deletion.

Question 22

A developer needs to move 50 million documents from an on-premises MongoDB database to Azure Cosmos DB for NoSQL. The migration must be completed within a weekend and the source system remains online during migration. Which tool is best suited for this bulk data movement?

Accepted Answer

Azure Data Factory's Copy activity with Cosmos DB as a sink supports large-scale bulk migrations from heterogeneous sources (including MongoDB) with configurable parallelism and throughput controls. It is the recommended managed service for scheduled, time-bounded migrations. SDK Bulk Support (A) requires writing and maintaining custom code and managing parallelism manually. Azure Stream Analytics (C) processes streaming data, not bulk historical migration. The Spark connector (D) requires an active Databricks cluster and is better suited for continuous or analytical workloads.

Question 23

A DevOps engineer needs to provision an Azure Cosmos DB account, database, and container as infrastructure-as-code so that the same configuration can be deployed consistently across dev, test, and production environments. Which approach should they use?

Accepted Answer

ARM templates and Bicep are declarative infrastructure-as-code tools that describe the desired state of Cosmos DB resources and support repeatable deployments across environments via CI/CD pipelines. The Azure portal (A) is manual and error-prone across multiple environments. A PowerShell script using the REST API (C) is imperative, harder to diff and review, and less idempotent. Creating resources from application startup code (D) mixes infrastructure provisioning with application logic and is not suitable for production governance.

Question 24

A security audit requires that an Azure Cosmos DB account implement encryption with customer-managed keys (CMK) using Azure Key Vault. Which TWO requirements must be met when configuring CMK for Cosmos DB? Choose 2.

Accepted Answer

For CMK with Cosmos DB, the Key Vault must have soft-delete and purge protection enabled to prevent accidental or malicious deletion of the encryption key, which would render the database permanently inaccessible. Additionally, the Cosmos DB account's system-assigned or user-assigned managed identity must be granted the specific Key Vault access policy permissions: Get, Wrap Key, and Unwrap Key. The Key Vault does not need to be in the same region (D). CMK can be added to existing accounts (E is false — Microsoft supports enabling CMK on existing accounts in some scenarios). Answer C is false as CMK is account-level, not container-level.

Question 25

A team monitors a Cosmos DB container and notices uneven data distribution — one partition key value (customerId='enterprise-1') holds 80% of all data. Which TWO actions should the developer take to address this hot partition problem? Choose 2.

Accepted Answer

A hot partition caused by low-cardinality or skewed data requires a partitioning redesign. Choosing a higher-cardinality or synthetic partition key (A) distributes data evenly across partitions. Hierarchical partition keys (B) allow a two-level partition scheme where the first level (customerId) can be combined with a second level (e.g., orderId) to distribute sub-items within a logical tenant, preventing single-partition saturation. Increasing RUs (C) raises the global throughput limit but does not solve the per-partition 10,000 RU/s cap. Geo-replication (D) copies all data to more regions but does not redistribute data within a region's partitions. TTL (E) reduces data volume over time but does not fix the structural distribution problem.

DP-420 — Azure Cosmos DB Developer Specialty