View Full Microsoft DP-420 Exam Dumps and Practice Test Dumps.

Q1. You are designing an Azure Cosmos DB for NoSQL container for a social application. Most requests retrieve all posts for one user, but some users can generate extremely large volumes of posts. Which partitioning strategy should you consider?

1. Use a hierarchical partition key beginning with /userId and a secondary high-cardinality property.
2. Use /visibility as the only partition key.
3. Put every post in one logical partition.
4. Use the post title as the partition key.

Correct Answer: 1. Use a hierarchical partition key beginning with /userId and a secondary high-cardinality property.

Explanation: A hierarchical partition key can preserve efficient user-based routing while allowing data belonging to very large users to be distributed further by another property. This can help avoid logical-partition limitations and reduce the risk of a hot partition. A low-cardinality property such as visibility is generally a poor partition key because many items share the same value. Putting every post in one partition limits scalability, while titles are usually unpredictable and do not align with the primary access pattern. Partition-key design should consider data growth, request distribution, and dominant query patterns together.

Q2. Your application creates many items and wants to avoid an additional read when it needs the created item and request-charge information immediately afterward. What should the application do?

1. Run a cross-partition query after every create.
2. Use the resource and metadata returned by the create operation response.
3. Read the change feed after every insert.
4. Recreate the Cosmos DB client.

Correct Answer: 2. Use the resource and metadata returned by the create operation response.

Explanation: Cosmos DB SDK create operations return response information that can include the created resource as well as metadata such as status, request charge, and diagnostic details. Reusing this response avoids an unnecessary follow-up read or query, reducing latency and request-unit consumption. Cross-partition queries would be especially inefficient for this purpose. The change feed is intended for asynchronous processing of changes, not immediate confirmation of each write. Recreating the client would add connection overhead. Efficient SDK usage depends on understanding operation responses and avoiding unnecessary network round trips.

Q3. A query contains several equality filters and an ORDER BY clause across two properties. You want to reduce RU consumption for this frequently executed query. What should you evaluate?

1. Disable indexing.
2. Switch to Strong consistency.
3. Add a composite index that matches the query pattern.
4. Increase TTL.

Correct Answer: 3. Add a composite index that matches the query pattern.

Explanation: Composite indexes are designed for query patterns that involve multiple properties, particularly multi-property ordering and combinations of equality and range predicates. An index that matches the paths and sort directions used by the query can significantly reduce request-unit consumption. Disabling indexing would generally make the query less efficient or unsupported for indexed execution. Consistency level affects read guarantees rather than query indexing, and TTL controls expiration. Composite indexes should be added selectively because they also increase index-maintenance overhead during writes and consume additional storage.

Q4. You need server-side JavaScript that performs multiple item operations in a single logical partition and rolls back all operations if any one operation fails. What should you create?

1. A change feed processor.
2. A stored procedure.
3. A UDF.
4. An analytical-store query.

Correct Answer: 2. A stored procedure.

Explanation: Stored procedures execute server-side JavaScript within the scope of a single logical partition and can perform multiple operations transactionally. If an error occurs, the transaction can be rolled back, preserving consistency among related items. User-defined functions are called from queries and return calculated values but are not intended for multi-operation transactions. Change feed processors run outside the transactional write path, while analytical-store queries serve analytics. Stored procedures are useful when transactional logic must execute near the data and within one logical-partition boundary.

Q5. You need to retrieve only documents where the metadata property is a JSON object. Which query function is most appropriate?

1. IS_OBJECT
2. ARRAY_CONTAINS
3. ABS
4. DateTimeDiff

Correct Answer: 1. IS_OBJECT

Explanation: Cosmos DB SQL includes type-checking functions that allow queries to test the JSON type of a value. IS_OBJECT returns whether a property contains a JSON object, making it suitable for variable-schema containers where a property may have different types across documents. ARRAY_CONTAINS operates on arrays, ABS is mathematical, and DateTimeDiff performs date calculations. Type-aware queries are important in document databases because documents in the same container are not required to have identical structures or property types.

Q6. Your application performs very large numbers of independent writes and wants to maximize throughput. No multi-item transaction is required. Which SDK capability should you enable?

1. Change feed pull mode.
2. Bulk support.
3. Strong consistency.
4. Integrated cache.

Correct Answer: 2. Bulk support.

Explanation: Bulk support allows the SDK to efficiently schedule and execute large numbers of independent operations concurrently, making it suitable for data ingestion, migrations, or batch updates. It does not provide atomicity across all operations. Transactional Batch would be more appropriate when multiple operations in one logical partition must succeed or fail together. Strong consistency affects read semantics, while integrated cache accelerates eligible reads. Bulk workloads still need sufficient provisioned or autoscale throughput and a well-distributed partitioning strategy to avoid throttling.

Q7. A Cosmos DB account serves users from several continents. Reads should be routed to the nearest healthy region whenever possible. Which application setting should you configure?

1. SDK preferred regions.
2. TTL.
3. A unique key policy.
4. Index transformation progress.

Correct Answer: 1. SDK preferred regions.

Explanation: Preferred regions allow the Cosmos DB SDK to prioritize specific regions for request routing. Applications can list nearby regions first to reduce network latency while still allowing fallback to another healthy region if the preferred region becomes unavailable. TTL and unique keys do not affect regional routing. Index transformation progress concerns indexing changes. Preferred regions should be coordinated with the regions configured on the Cosmos DB account and the physical deployment locations of the application so that global distribution provides the intended latency and resilience benefits.

Q8. You need a user to query Cosmos DB data but not change the account’s networking, regions, or throughput configuration. Which access design is most appropriate?

1. Assign subscription Owner.
2. Share the account primary key.
3. Grant a data-plane role without corresponding control-plane management permissions.
4. Disable authorization.

Correct Answer: 3. Grant a data-plane role without corresponding control-plane management permissions.

Explanation: Cosmos DB distinguishes between data-plane permissions and control-plane permissions. A user who needs to query application documents can be assigned a suitable data-plane role without receiving the Azure management rights required to change account configuration. This supports separation of duties and least privilege. Subscription Owner would grant excessive control, while the primary key can provide broad data access that is difficult to scope. Disabling authorization is insecure. Proper RBAC design should narrowly match each identity’s operational responsibilities.

Q9. You need to process changes from a container and automatically distribute the work among multiple application instances. Which feature should you use?

1. Transactional Batch.
2. Change feed processor.
3. TTL.
4. Composite indexing.

Correct Answer: 2. Change feed processor.

Explanation: The change feed processor is designed to process Cosmos DB changes at scale and automatically distribute feed ranges across multiple worker instances. It uses a lease container to track ownership and checkpoints, allowing the workload to rebalance as instances are added or removed. Transactional Batch handles same-partition atomic operations, TTL manages expiration, and composite indexes optimize queries. The processor is generally easier than implementing custom partition ownership and checkpoint logic with the pull model.

Q10. You need to detect whether a change feed processor is falling behind the rate of incoming writes. Which component should you use?

1. Change feed estimator.
2. Unique key policy.
3. Integrated cache.
4. Stored procedure.

Correct Answer: 1. Change feed estimator.

Explanation: The change feed estimator reports an estimate of pending changes that have not yet been processed. This is useful for monitoring backlog and determining whether change feed processor instances need more compute capacity or whether additional throughput is required. Unique keys enforce data integrity, integrated cache improves repeated reads, and stored procedures perform server-side transactional logic. Monitoring processor lag is especially important when downstream projections, event workflows, or integrations need to remain close to real time.

Q11. A multi-region write account receives concurrent updates to the same item. The business wants to use application-specific rules rather than last-writer-wins. What should you configure?

1. A custom conflict-resolution policy.
2. TTL.
3. A continuation token.
4. A backup interval.

Correct Answer: 1. A custom conflict-resolution policy.

Explanation: Multi-region writes can produce conflicts when the same item is updated concurrently in different regions. If last-writer-wins does not satisfy the business requirement, custom conflict resolution can apply application-specific rules to determine the correct outcome. Conflict handling should be defined before deploying an active-active write architecture because it directly affects data correctness. TTL, continuation tokens, and backup intervals solve unrelated lifecycle, paging, and recovery concerns. Conflict resolution is a core design area for globally distributed write workloads.

Q12. Your application requires the strongest guarantee that every read returns the latest committed write. Which consistency level should you use when supported?

1. Eventual.
2. Strong.
3. Consistent prefix.
4. Session.

Correct Answer: 2. Strong.

Explanation: Strong consistency provides the strictest Cosmos DB read guarantee, ensuring that reads return the latest committed write. This can simplify application correctness in workloads that cannot tolerate stale data, but it comes with latency, availability, and regional-distribution tradeoffs. Eventual and consistent-prefix levels allow stale reads, while session consistency provides strong session-scoped behavior rather than a global latest-write guarantee. The chosen consistency level should reflect actual business requirements rather than defaulting to the strongest level unnecessarily.

Q13. You need to create a full-text search experience over a notes property stored in Cosmos DB. Which feature should you configure?

1. A full-text policy and full-text index for the property.
2. A spatial index.
3. TTL.
4. A lease container.

Correct Answer: 1. A full-text policy and full-text index for the property.

Explanation: Full-text search capabilities in Cosmos DB rely on full-text configuration that identifies searchable text paths and creates the appropriate index. This enables optimized text-oriented query patterns over properties such as notes, descriptions, or content fields. Spatial indexes serve geographic workloads, TTL manages expiration, and lease containers coordinate change feed processing. Full-text indexes should be created only for properties that genuinely participate in search because indexing has storage and write-maintenance costs.

Q14. You are storing embedding vectors in Cosmos DB and need similarity ranking based on distance between vectors. Which capability should you use?

1. Composite indexes only.
2. Vector indexing and vector-distance query functionality.
3. TTL.
4. Change feed leases.

Correct Answer: 2. Vector indexing and vector-distance query functionality.

Explanation: Cosmos DB vector search supports storing vector embeddings in JSON documents and querying them using distance functions. A vector policy defines the embedding path and characteristics, while a vector index improves similarity-search performance. This is useful for semantic search, recommendation, retrieval-augmented generation, and other AI workloads. Composite indexes target scalar query patterns, TTL controls retention, and change feed leases support change processing. Vector indexing should be configured according to the dimensions, data type, and distance function used by the application.

Q15. You need analytical users to query Cosmos DB data at scale without consuming the same transactional RU capacity used by the application. Which capability should you enable?

1. Multi-region writes.
2. Integrated cache.
3. Analytical store.
4. Manual failover.

Correct Answer: 3. Analytical store.

Explanation: Analytical store provides a column-oriented representation of Cosmos DB data designed for analytical workloads. It helps separate analytics from the transactional request-unit workload, making it more suitable for broad scans, Spark processing, or downstream analytical integration. Multi-region writes address write availability, integrated cache reduces repeated transactional read costs, and failover manages regional roles. Analytical store is useful when an operational Cosmos DB dataset must also support business intelligence or data-science workloads.

Q16. You want Cosmos DB operational data to become available in Microsoft Fabric without maintaining a custom ETL pipeline. Which feature should you evaluate?

1. Cosmos DB Mirroring for Microsoft Fabric.
2. A SQL UDF.
3. Gateway mode.
4. Session tokens.

Correct Answer: 1. Cosmos DB Mirroring for Microsoft Fabric.

Explanation: Cosmos DB Mirroring for Microsoft Fabric provides a managed path for making operational Cosmos DB data available to Fabric analytics scenarios with less custom ETL development. This can simplify integration when the goal is analytical replication rather than direct transactional read/write processing. UDFs provide custom query functions, gateway mode affects SDK networking, and session tokens support consistency. Mirroring should be compared with alternatives such as the Spark connector based on latency, transformation, and analytical-processing requirements.

Q17. You need a Spark application to transform Cosmos DB records and write the results back into the transactional store. Which integration should you use?

1. Azure Cosmos DB Spark connector.
2. Azure Monitor.
3. Periodic backup.
4. Integrated cache.

Correct Answer: 1. Azure Cosmos DB Spark connector.

Explanation: The Azure Cosmos DB Spark connector enables Spark workloads to read from and write to the Cosmos DB transactional store. This makes it appropriate for distributed data transformation, enrichment, and migration workloads. Azure Monitor provides observability, periodic backup provides recovery, and integrated cache optimizes eligible reads. Spark writes still consume transactional request units, so throughput, concurrency, partitioning, and the impact on production application traffic should all be considered before running large jobs.

Q18. Your organization needs to restore Cosmos DB data to an exact point before a deployment introduced corruption. Which backup capability is required?

1. Periodic backup only.
2. Continuous backup with point-in-time restore.
3. Change feed only.
4. Integrated cache.

Correct Answer: 2. Continuous backup with point-in-time restore.

Explanation: Continuous backup supports restoring Cosmos DB resources to a selected point within the available retention window. This is particularly useful when an application deployment introduces logical corruption and the team needs a recovery point immediately before the incident. Periodic backup provides scheduled recovery points but not the same fine-grained point-in-time restore capability. Change feed and cache are not substitutes for backup. Recovery procedures should identify the correct timestamp, resource scope, and validation steps before restored data is put back into service.

Q19. You need to investigate whether requests are being throttled because one partition is hotter than the others. What should you monitor?

1. Per-partition normalized RU consumption.
2. Only total database storage.
3. Only account backup status.
4. Only the number of containers.

Correct Answer: 1. Per-partition normalized RU consumption.

Explanation: Partition-level RU metrics can reveal whether one physical partition is consuming a much larger share of available throughput than others. A hot partition can cause 429 throttling even when account-level utilization appears acceptable. This often indicates skewed partition-key access patterns, very active tenants, or an unsuitable distribution strategy. Storage and backup status do not show request pressure. Monitoring per-partition throughput alongside data distribution is essential for validating partition-key quality in production.

Q20. You need an automated notification whenever server-side latency exceeds an agreed service threshold. Which Azure feature should you configure?

1. TTL.
2. Azure Monitor alert rule with an action group.
3. Unique key policy.
4. Continuation token.

Correct Answer: 2. Azure Monitor alert rule with an action group.

Explanation: Azure Monitor alert rules can evaluate Cosmos DB metrics such as server-side latency and trigger actions when a condition is sustained. Action groups can notify teams through supported channels or launch automation workflows. TTL controls retention, unique keys enforce constraints, and continuation tokens support query paging. Monitoring and alerting should be based on meaningful service objectives so operations teams receive actionable notifications before sustained latency affects application users.