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

Q1. You are building a retrieval-augmented generation application and store text embeddings in Azure Cosmos DB for NoSQL. You need to return documents whose embeddings are closest to a query embedding. Which query capability should you use?

1. ARRAY_CONTAINS
2. DateTimeDiff
3. VectorDistance
4. IS_DEFINED

Correct Answer: 3. VectorDistance

Explanation: Azure Cosmos DB for NoSQL supports native vector search for workloads such as semantic search, recommendations, and retrieval-augmented generation. After defining the appropriate vector embedding policy and vector index, a query can use VectorDistance to calculate similarity between a stored embedding and a supplied query vector. The results can then be ordered by distance to retrieve the most semantically similar documents. ARRAY_CONTAINS operates on arrays, DateTimeDiff performs date calculations, and IS_DEFINED checks whether a property exists. Vector search matches semantic similarity rather than relying only on exact keywords.

Q2. You are designing an application where documents are frequently read and written together inside the same business aggregate. Which modeling principle is usually appropriate when the aggregate remains within item-size limits?

1. Embed the related data in the same document.
2. Store every property in a different container.
3. Use a separate Cosmos DB account for each child entity.
4. Normalize every relationship into independent documents.

Correct Answer: 1. Embed the related data in the same document.

Explanation: In Azure Cosmos DB, embedding is often appropriate when related data shares the same lifecycle and is usually read or updated together. Keeping the aggregate in one document can reduce extra reads, simplify application logic, and allow a single atomic item operation. This differs from traditional relational modeling, where normalization is often emphasized. Referencing separate documents can still be appropriate for large, independently managed, or widely shared entities. The correct design should be driven by access patterns, transactional boundaries, update frequency, duplication cost, and the maximum supported item size rather than by relational conventions alone.

Q3. You need native full-text search over a description property and want Cosmos DB to rank results by textual relevance. Which configuration should you implement?

1. A unique key policy only.
2. A composite index only.
3. TTL and analytical store.
4. A full-text policy and full-text index.

Correct Answer: 4. A full-text policy and full-text index.

Explanation: Cosmos DB includes native full-text indexing and search capabilities that apply language-aware text processing such as tokenization, stop-word handling, and stemming. A full-text policy identifies the searchable text path and language, while the full-text index provides optimized indexing for search operations. Full-text scoring can then evaluate document relevance to the search query. Traditional composite indexes optimize different scalar query patterns, unique keys enforce data integrity, and TTL manages retention. Native full-text capabilities can support search directly within Cosmos DB without always requiring a separate search service.

Q4. Your application queries data mostly by organizationId, but several organizations may grow extremely large. You want to retain organization-based routing while distributing data within large organizations. Which approach should you consider?

1. Use a constant partition key.
2. Use a hierarchical partition key.
3. Disable partitioning.
4. Use TTL as the second partitioning level.

Correct Answer: 2. Use a hierarchical partition key.

Explanation: Hierarchical partition keys allow a partitioning strategy to use multiple levels of values. For example, an organization ID can be the first level and a user, device, or other higher-cardinality attribute can be the second level. This preserves efficient routing for organization-focused requests while allowing large organizations to distribute data further. A constant partition key would create severe scalability limits, and scalable Cosmos DB containers cannot simply avoid partitioning. TTL controls document expiration and is unrelated to partition distribution. Hierarchical partitioning is useful for multitenant workloads with uneven tenant sizes.

Q5. A workload uses provisioned throughput and has predictable traffic during business hours but significantly lower traffic overnight. You want automatic scaling without switching to serverless. Which throughput model should you choose?

1. Autoscale provisioned throughput.
2. TTL throughput.
3. Integrated-cache throughput.
4. Change-feed throughput.

Correct Answer: 1. Autoscale provisioned throughput.

Explanation: Autoscale provisioned throughput automatically adjusts RU/s according to demand within the configured maximum. It is appropriate for workloads that need provisioned throughput characteristics but experience meaningful variation throughout the day. Manual provisioned throughput requires administrators or automation to adjust capacity explicitly. Serverless is a different billing model intended for suitable intermittent workloads. TTL, integrated cache, and change feed are unrelated to capacity allocation. Throughput planning should consider peak RU requirements, baseline activity, partition distribution, growth, and whether throughput is provisioned at the database or container level.

Q6. An application must write millions of independent records during a migration. Each operation can succeed independently, and maximizing throughput is the priority. What should you enable?

1. Strong consistency.
2. Transactional Batch for the entire migration.
3. Bulk support in the SDK.
4. Integrated cache.

Correct Answer: 3. Bulk support in the SDK.

Explanation: Bulk support is intended for workloads that perform large numbers of independent item operations and want the SDK to efficiently schedule them concurrently. It is useful for ingestion, migration, and large update workloads. Bulk mode does not make all operations one atomic transaction. Transactional Batch is limited to items that share a logical partition key and is appropriate when those operations must succeed or fail together. Strong consistency changes read behavior, while integrated cache accelerates eligible reads. A migration should still account for RU limits, retries, partition distribution, and validation of completed writes.

Q7. You need multiple creates and patches to succeed or fail together. All affected items share the same partition key. Which feature should you use?

1. Change feed processor.
2. Transactional Batch.
3. Integrated cache.
4. Analytical store.

Correct Answer: 2. Transactional Batch.

Explanation: Transactional Batch groups multiple item operations within the same logical partition and executes them atomically. If one operation fails, the batch does not partially commit the other operations. This makes it appropriate for related creates, replaces, patches, or deletes that share a transaction boundary and partition key. Change feed processing occurs asynchronously after changes, integrated cache serves eligible reads, and analytical store supports analytical workloads. Cosmos DB transaction scope is tied to a logical partition, making partition-key selection important when application workflows require multi-item atomicity.

Q8. Your application must accept writes in multiple Azure regions to reduce write latency for globally distributed users. What should you enable?

1. Periodic backup.
2. A composite index.
3. A dedicated gateway only.
4. Multi-region writes.

Correct Answer: 4. Multi-region writes.

Explanation: Multi-region writes allow multiple configured Azure regions to accept write operations. This can reduce write latency for geographically distributed applications and improve write availability if a region becomes unavailable. Because concurrent modifications may occur in different regions, the architecture must also consider conflict-resolution behavior. Backup, indexes, and dedicated gateway features do not make multiple regions writable. The decision should also consider consistency requirements, region costs, data residency, application deployment locations, and whether the workload genuinely benefits from active-active write capabilities.

Q9. Your application uses session consistency and requests from one user can be handled by different application instances. What should be propagated between those requests?

1. The item’s TTL.
2. A continuation token.
3. The session token.
4. The account’s backup ID.

Correct Answer: 3. The session token.

Explanation: Session tokens track the relevant data version observed within a session. When requests for the same logical user session can move between application instances, propagating the session token can preserve session consistency guarantees such as read-your-writes behavior. Continuation tokens track query pagination rather than consistency. TTL governs expiration, and backup identifiers are unrelated. Session consistency is commonly used because it gives interactive applications strong behavior within a user session while avoiding some of the latency and availability tradeoffs associated with globally strong consistency.

Q10. You need to paginate a SQL query and resume the query from the last page on a later request. What should you preserve?

1. The partition key definition.
2. The continuation token.
3. The item’s ETag.
4. The account consistency level.

Correct Answer: 2. The continuation token.

Explanation: A continuation token represents the query’s progress and allows subsequent requests to resume from the point where the previous page ended. This is useful for web APIs, large result sets, batch processing, and workflows that cannot consume all results at once. ETags are used for optimistic concurrency on individual items, while partition-key configuration and consistency level do not represent pagination state. Applications should treat continuation tokens as opaque values and return them to the SDK rather than attempting to interpret or manually modify their contents.

Q11. You need to improve query performance for a workload that repeatedly filters by category and region and sorts by updatedAt. Which indexing option should you evaluate?

1. Disable indexing.
2. TTL.
3. A unique key policy.
4. An appropriate composite index.

Correct Answer: 4. An appropriate composite index.

Explanation: Composite indexes can improve repeated query patterns involving multiple scalar properties, especially combinations of filters, range operations, and multi-property ordering. The index should be configured to match the important query’s paths and sort directions. Disabling indexing would usually make queries less efficient, while TTL and unique keys address unrelated lifecycle and integrity requirements. Because every additional index increases write-maintenance work, composite indexes should be added selectively and validated by comparing RU charges and query metrics using representative production-like data.

Q12. A source container receives new orders. You need to maintain an asynchronously updated reporting projection in another container. What should you use?

1. Change feed processing.
2. A point read after every query.
3. TTL.
4. Manual failover.

Correct Answer: 1. Change feed processing.

Explanation: The change feed provides a durable sequence of item changes that can drive asynchronous downstream processing. A change feed processor or Azure Function can consume new and updated orders and maintain a reporting projection in another container. This reduces the need for expensive repeated scans of the transactional container and separates reporting logic from the primary write path. The projection will generally be eventually consistent with the source, so lag should be monitored. TTL controls expiration, while point reads and failover do not maintain derived reporting views.

Q13. You need to determine whether your change feed processors are keeping up with the source write rate. Which feature should you use?

1. TTL monitor.
2. Change feed estimator.
3. Unique key validator.
4. Spatial index.

Correct Answer: 2. Change feed estimator.

Explanation: The change feed estimator helps determine how much unprocessed work remains for a change feed processor. This makes it useful for monitoring lag and deciding whether additional processor instances or resources are needed. If the backlog continues to grow, downstream projections, integrations, or event-driven workflows may become increasingly stale. TTL and unique-key settings do not expose processor lag, while spatial indexing is unrelated. The estimator complements the lease-based coordination performed by the change feed processor and supports operational monitoring of asynchronous processing pipelines.

Q14. You need a Spark job to read from and write back to the Azure Cosmos DB transactional store. Which integration should you use?

1. Full-text indexing.
2. Azure Monitor.
3. Continuous backup.
4. Azure Cosmos DB Spark connector.

Correct Answer: 4. Azure Cosmos DB Spark connector.

Explanation: The Azure Cosmos DB Spark connector supports distributed Spark access to the Cosmos DB transactional store for supported read and write operations. It is useful for large-scale transformation, enrichment, migration, and processing workloads. Full-text indexing supports native text search, Azure Monitor provides observability, and continuous backup supports recovery. Spark workloads that directly access the transactional store consume request units, so they should be planned carefully to avoid negatively affecting production application traffic and should use suitable partitioning and concurrency settings.

Q15. Your organization wants Cosmos DB operational data available in Microsoft Fabric with minimal custom ETL management. Which integration should you evaluate?

1. Cosmos DB Mirroring for Microsoft Fabric.
2. Transactional Batch.
3. TTL.
4. Integrated cache.

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

Explanation: Cosmos DB Mirroring for Microsoft Fabric provides a managed integration that makes operational data available for Fabric analytical workloads without requiring a traditional custom ETL pipeline for replication. This can simplify reporting and analytics architectures where Cosmos DB is the operational system of record. Transactional Batch handles same-partition atomic operations, TTL manages retention, and integrated cache accelerates eligible reads. Mirroring should be compared with the Spark connector based on whether the workload requires managed analytical replication or direct programmatic read/write processing through Spark.

Q16. An application performs the same point reads repeatedly against relatively stable reference data. You want to reduce backend RU consumption. What should you consider?

1. Strong consistency.
2. Manual failover.
3. Integrated cache through the dedicated gateway.
4. A stored procedure for every read.

Correct Answer: 3. Integrated cache through the dedicated gateway.

Explanation: Integrated cache can serve eligible reads from a cache associated with the dedicated gateway rather than repeatedly reaching the transactional backend. This can lower latency and reduce RU consumption for repeated reads and selected query patterns. The workload must be able to tolerate the configured cache staleness window. Strong consistency, failover, and stored procedures do not provide the same caching behavior. Integrated cache is most useful for read-heavy workloads where certain data changes infrequently and slightly stale results are acceptable.

Q17. Monitoring shows one physical partition consistently reaching its RU limit while others remain lightly used. What issue are you seeing?

1. Backup corruption.
2. An index transformation.
3. Session-token expiration.
4. A hot partition.

Correct Answer: 4. A hot partition.

Explanation: A hot partition occurs when request demand is disproportionately concentrated on one partition. Even if total account-level RU capacity appears sufficient, the overloaded partition can experience throttling while other partitions remain underutilized. This usually points to skewed access patterns or an unsuitable partition-key strategy. Operators should examine both throughput distribution and data distribution across partitions. Backup configuration, index transformations, and session tokens do not explain persistent localized throughput saturation. Partition-key design should distribute not only data volume but also actual request-unit demand.

Q18. Your account uses continuous backup and an application update accidentally deleted important records. What should you do first before restoring?

1. Disable indexing.
2. Identify a valid point-in-time restore point from before the deletion.
3. Change the partition key.
4. Enable integrated cache.

Correct Answer: 2. Identify a valid point-in-time restore point from before the deletion.

Explanation: Continuous backup supports point-in-time restore within the supported retention window. Before initiating recovery, administrators need to identify a restore point that predates the unwanted deletion while preserving as much valid later data as possible. The recovery scope and restored resource should then be validated before applications are redirected. Indexing, partition keys, and cache settings cannot restore deleted data. Restore procedures should be tested in advance so the team knows how to determine the correct timestamp and recover affected databases or containers efficiently.

Q19. You need security and operational logs from Cosmos DB to be searchable with Kusto Query Language. What should you configure?

1. TTL.
2. Integrated cache.
3. Azure Monitor diagnostic settings that route resource logs to Log Analytics.
4. A continuation token.

Correct Answer: 3. Azure Monitor diagnostic settings that route resource logs to Log Analytics.

Explanation: Azure Monitor diagnostic settings can route Cosmos DB resource logs to a Log Analytics workspace. Once there, Kusto Query Language can be used to investigate failures, security activity, access patterns, and operational behavior. Logs can also be correlated with telemetry from applications and other Azure resources. TTL and cache settings are unrelated to centralized logging, while continuation tokens handle query pagination. Logging and auditing are explicit DP-420 maintenance objectives because production systems need observable and investigable operational behavior.

Q20. You need an alert when Normalized RU Consumption remains above 90% for several minutes. What should you configure?

1. An Azure Monitor alert rule with an appropriate action group.
2. A unique key policy.
3. A SQL UDF.
4. TTL.

Correct Answer: 1. An Azure Monitor alert rule with an appropriate action group.

Explanation: Azure Monitor alerts can evaluate Cosmos DB metrics such as Normalized RU Consumption and trigger notifications or automated actions when a threshold remains exceeded for a configured duration. An action group can route the alert to email, SMS, webhooks, incident systems, or automation. High normalized RU consumption can indicate that a workload is approaching its available capacity and may soon experience throttling. Unique keys, UDFs, and TTL do not provide operational alerting. Proactive monitoring helps teams respond before throughput pressure becomes sustained user-facing degradation.