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

Q1. You are designing an Azure Cosmos DB for NoSQL container for a SaaS application. Data is accessed first by tenant and then frequently by user within each tenant. Some tenants are very large. Which partitioning feature should you consider?

1. A unique key on /userId
2. A single low-cardinality partition key
3. Database-level throughput only
4. A hierarchical partition key such as tenant ID followed by user ID

Correct Answer: 4. A hierarchical partition key such as tenant ID followed by user ID

Explanation: Hierarchical partition keys can provide multiple levels of partitioning for workloads where one property alone may not distribute data sufficiently. In a multi-tenant application, using tenant ID as the first level and user ID as another level can help preserve tenant-based access while providing better distribution for very large tenants. A low-cardinality key can create hot partitions, while a unique key enforces uniqueness rather than controlling physical distribution. Database-level throughput affects RU allocation but does not solve partition-key design. Partitioning should always reflect both data distribution and the application’s most common access patterns.

Q2. Your workload has an unpredictable number of requests and is used only intermittently. You want to avoid paying for provisioned request units when the database is idle. Which throughput model should you consider?

1. Serverless
2. Manual provisioned throughput
3. Dedicated gateway only
4. Strong consistency

Correct Answer: 1. Serverless

Explanation: Serverless Azure Cosmos DB is designed for workloads with intermittent or unpredictable traffic where customers prefer to pay for the request units actually consumed rather than provisioning throughput continuously. It can be a good fit for development, testing, small applications, and bursty workloads within supported limits. Manual provisioned throughput reserves RU/s regardless of whether all capacity is used. Dedicated gateway relates to integrated cache and connectivity, while consistency level controls read semantics. Throughput model selection should reflect workload intensity, predictability, latency requirements, and expected cost characteristics.

Q3. A container experiences very uneven traffic because many new items are written with partition keys based only on the current month. What is the main risk of this partitioning strategy?

1. All queries automatically become point reads.
2. The container loses its indexing policy.
3. A hot partition can receive a disproportionate share of writes.
4. Multi-region writes become unavailable.

Correct Answer: 3. A hot partition can receive a disproportionate share of writes.

Explanation: A partition key based on a value such as the current month can concentrate a large amount of new traffic into one logical partition or a very small number of logical partitions. This can create a hot partition, where throughput demand is uneven even if total account throughput appears sufficient. A strong partition key should distribute both data and request-unit consumption over time. The problem does not affect indexing policy or multi-region write availability directly. Partitioning design must account for future growth and write patterns rather than only present data organization.

Q4. You need to distribute provisioned throughput across several containers that have variable workloads and do not all peak at the same time. Which design can simplify shared throughput management?

1. Configure a different Azure region for each container.
2. Provision throughput at the database level.
3. Disable indexing on every container.
4. Use a stored procedure to distribute request units.

Correct Answer: 2. Provision throughput at the database level.

Explanation: Database-level provisioned throughput can be shared by containers within the database, allowing workloads to draw from a common RU/s pool. This can be efficient when multiple containers have varying usage patterns and do not peak simultaneously. Container-level throughput provides more isolated performance but may be less flexible for shared capacity scenarios. Regions, indexing, and stored procedures do not distribute throughput in this way. The appropriate approach depends on whether workloads need dedicated capacity or can efficiently share a common throughput allocation.

Q5. A high-performance application runs in the same Azure region as its Azure Cosmos DB account. You want the SDK to use the lowest-latency native connectivity mode when possible. Which connectivity mode should you configure?

1. Direct mode
2. Gateway mode only
3. Offline mode
4. Analytical mode

Correct Answer: 1. Direct mode

Explanation: Direct mode allows the Azure Cosmos DB SDK to communicate directly with backend replicas using optimized connections, which generally provides lower latency and higher throughput for performance-sensitive applications. Gateway mode routes traffic through an intermediary gateway and can be useful where firewall or networking restrictions make direct connectivity difficult. Offline mode is not a production connectivity mode, and analytical mode is unrelated to SDK transport. Client connectivity should also consider connection reuse, preferred regions, retry behavior, and networking configuration for reliable production performance.

Q6. Your application uses session consistency. A request is handled by one application instance and then the next related request is routed to another instance. You need the second request to preserve the first request’s session consistency guarantees. What should you propagate?

1. The ETag only
2. A continuation token
3. The session token
4. The database resource ID only

Correct Answer: 3. The session token

Explanation: Session tokens track the version of data observed during a session and can be passed between application instances to preserve session consistency semantics when requests do not remain on the same process. This is particularly relevant in distributed web applications with load balancing. An ETag supports optimistic concurrency on an individual item, while a continuation token resumes paginated query execution. Resource IDs do not provide session-consistency guarantees. Session tokens help ensure read-your-writes and related ordering behaviors are maintained across application instances when session consistency is being used.

Q7. The Azure Cosmos DB account uses session consistency by default, but one specific query requires a weaker consistency level to reduce latency. What should you do?

1. Recreate the account with a different default consistency level.
2. Override consistency in the request or query options where supported.
3. Disable the partition key.
4. Enable TTL for the queried items.

Correct Answer: 2. Override consistency in the request or query options where supported.

Explanation: Azure Cosmos DB SDK request options can allow an application to override the account’s default consistency level for specific supported operations, provided the requested level is not stronger than what the account configuration permits. This makes it possible to tailor latency and consistency behavior to particular reads without changing the entire account. Recreating the account is unnecessary, and partition keys or TTL do not control consistency. Applications should choose consistency levels deliberately because they affect read guarantees, latency, availability, and request-unit cost.

Q8. Documents contain an items array, and you need a SQL query that returns only documents where at least one array element has a quantity greater than 10. Which query capability should you use?

1. Point reads only
2. TTL filters
3. Array-aware SQL querying, such as JOIN or array functions
4. Database-level throughput

Correct Answer: 3. Array-aware SQL querying, such as JOIN or array functions

Explanation: Azure Cosmos DB for NoSQL SQL supports querying arrays through constructs such as JOINs and array functions. These capabilities let queries inspect nested array elements and apply conditions to them. A point read retrieves a known item by ID and partition key but does not express arbitrary array predicates. TTL controls automatic expiration, while throughput configuration has no bearing on query semantics. Understanding arrays and nested objects is important because Cosmos DB documents frequently use rich JSON structures rather than flat relational rows.

Q9. You want to reduce write request-unit consumption in a write-heavy container. A large property named rawPayload is never queried. What indexing change should you consider?

1. Add a unique key for rawPayload.
2. Exclude the rawPayload path from indexing.
3. Add a composite index containing only rawPayload.
4. Convert rawPayload to the partition key.

Correct Answer: 2. Exclude the rawPayload path from indexing.

Explanation: Azure Cosmos DB indexes properties according to the container’s indexing policy. If a large property is never used by queries, excluding its path from indexing can reduce index maintenance during writes and may lower request-unit consumption. This is especially relevant for write-heavy workloads with large unqueried properties. A unique key enforces uniqueness and adds constraints, while a composite index is intended to support specific multi-property query patterns. Changing the partition key to an unqueried payload would generally be inappropriate. Indexing should be based on actual read and write access patterns.

Q10. A query contains ORDER BY c.category, c.createdDate. It fails because the default indexing policy cannot support the requested multi-property ordering. What should you add?

1. A composite index for category and createdDate
2. A TTL policy
3. A unique key policy
4. A session token

Correct Answer: 1. A composite index for category and createdDate

Explanation: Queries that use ORDER BY across multiple properties require an appropriate composite index. Composite indexes define two or more scalar property paths and their sort directions in a specific order. They can also improve some equality-plus-range query patterns. TTL and unique keys address lifecycle and integrity rather than sorting, while session tokens relate to consistency. Composite indexes are not created automatically and should be added based on observed query patterns.

Q11. You need to execute validation logic before a document is created and reject the operation if the document does not satisfy a business rule. Which server-side programming object can support this scenario?

1. Pre-trigger
2. Composite index
3. Change feed estimator
4. Continuation token

Correct Answer: 1. Pre-trigger

Explanation: A pre-trigger is server-side JavaScript that executes before a requested create, replace, or delete operation when the trigger is explicitly invoked by the client. It can inspect or modify the item and reject the operation when validation rules are not satisfied. Composite indexes optimize queries, change feed estimators help monitor change feed processing, and continuation tokens support query pagination. Triggers should be used selectively because application-side validation is often simpler, but server-side logic can be useful when transactional validation must occur close to the data operation.

Q12. You need reusable server-side JavaScript logic that can be invoked from Azure Cosmos DB SQL queries to calculate a custom value. Which object should you create?

1. Stored procedure
2. User-defined function
3. Post-trigger
4. Change feed processor

Correct Answer: 2. User-defined function

Explanation: User-defined functions, or UDFs, are JavaScript functions that can be invoked from Azure Cosmos DB SQL queries to perform custom calculations or transformations not directly provided by built-in query functions. Stored procedures are designed for server-side transactional operations within a logical partition, while triggers execute before or after specific item operations. A change feed processor consumes data changes asynchronously. UDFs should be used carefully because built-in query functions are often more efficient, but they can be useful when specialized reusable query logic is required.

Q13. Your account has one write region and several read regions. You want Azure Cosmos DB to automatically promote another region if the write region becomes unavailable. What should you configure?

1. Automatic failover with an ordered list of regions
2. Analytical store
3. Bulk execution
4. Unique key policy

Correct Answer: 1. Automatic failover with an ordered list of regions

Explanation: Automatic failover allows Azure Cosmos DB to promote another region to become the write region if the current write region becomes unavailable in a single-write-region configuration. The account’s failover priorities determine the preferred ordering of regions. Analytical store supports analytics, bulk execution improves high-volume independent writes, and unique keys enforce data constraints. Failover configuration is a key part of designing for resilience and regional availability in globally distributed Azure Cosmos DB applications.

Q14. You enable multi-region writes and need conflicts on a specific property to be resolved by custom application logic rather than using the default conflict policy. What should you implement?

1. Serverless throughput
2. A custom conflict resolution policy
3. A point read
4. Integrated cache

Correct Answer: 2. A custom conflict resolution policy

Explanation: Multi-region writes can create conflicts if the same logical data is modified concurrently in different regions. Azure Cosmos DB supports conflict-resolution strategies, including custom resolution logic where the application’s business rules require behavior beyond default resolution. Serverless throughput affects billing, point reads retrieve known items, and integrated cache accelerates eligible reads. Conflict handling should be designed before enabling global write patterns because the correct strategy depends on the semantics of the data and how concurrent changes should be reconciled.

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

1. Manual CSV exports
2. Stored procedures
3. Azure Cosmos DB Mirroring for Microsoft Fabric
4. Session-token propagation

Correct Answer: 3. Azure Cosmos DB Mirroring for Microsoft Fabric

Explanation: Azure Cosmos DB Mirroring for Microsoft Fabric is designed to make operational Cosmos DB data available in Fabric analytics scenarios without requiring traditional custom ETL pipelines. This capability is part of the current DP-420 analytical workload objectives. Manual exports increase operational overhead, while stored procedures and session tokens address transactional or consistency concerns rather than analytics integration. The choice between Mirroring and other approaches such as Spark connectors should be based on analytical requirements, latency expectations, supported features, and the desired level of pipeline management.

Q16. You need a Spark application to read and write directly against the Azure Cosmos DB transactional store. Which integration should you use?

1. Azure Cosmos DB Spark connector
2. Azure Monitor alert rule
3. Gateway-mode SDK only
4. Composite index transformation

Correct Answer: 1. Azure Cosmos DB Spark connector

Explanation: The Azure Cosmos DB Spark connector enables Spark workloads to interact with Cosmos DB data, including reading from and writing back to the transactional store. It is suitable when Spark-based processing or transformation logic is required. Azure Monitor alerts provide monitoring, while gateway connectivity and index transformations do not provide Spark integration. Spark connectors and Fabric Mirroring serve different analytical patterns, so the correct choice depends on whether the workload needs Spark processing and direct transactional-store interaction or managed analytical replication.

Q17. You need Azure AI Search to index data stored in Azure Cosmos DB so users can perform full-text search through a separate search experience. Which integration should you implement?

1. Azure AI Search integration with Azure Cosmos DB
2. Strong consistency only
3. TTL expiration
4. Manual regional failover

Correct Answer: 1. Azure AI Search integration with Azure Cosmos DB

Explanation: Azure AI Search can integrate with Azure Cosmos DB to create a search-oriented index over operational data, enabling full-text and other search experiences that differ from normal Cosmos DB query patterns. This is useful for applications requiring search relevance, tokenization, or dedicated search capabilities. Consistency, TTL, and failover do not provide a search index. The integration pattern lets Cosmos DB remain the operational data store while Azure AI Search provides specialized search functionality for end users.

Q18. Your application performs many repeated point reads for relatively stable data. You want to reduce latency and request-unit consumption by caching eligible reads near the application. Which feature should you use?

1. Continuous backup
2. Integrated cache through the dedicated gateway
3. Manual failover
4. Transactional Batch

Correct Answer: 2. Integrated cache through the dedicated gateway

Explanation: Azure Cosmos DB integrated cache can serve eligible repeated reads from a cache associated with the dedicated gateway, reducing backend request-unit consumption and often lowering read latency. It is useful for read-heavy workloads where some data can tolerate configured cache staleness. Continuous backup protects data, manual failover changes regional write roles, and Transactional Batch provides atomic operations in one logical partition. Cache behavior should be designed according to freshness requirements because applications may accept slightly stale values depending on the configured cache policy.

Q19. You operate several change feed processor instances. You need to determine whether processors are keeping up with changes or accumulating lag. Which feature should you use?

1. Change feed estimator
2. Unique key policy
3. Integrated cache
4. Spatial index

Correct Answer: 1. Change feed estimator

Explanation: The change feed estimator helps determine how much work remains for change feed processor instances by estimating the number of pending changes. This can be used to monitor lag, scale processor instances, and determine whether the current processing capacity is sufficient. Unique keys enforce constraints, integrated cache accelerates eligible reads, and spatial indexes support geographic queries. Monitoring change feed backlog is especially important when change processing drives downstream projections, integrations, or business workflows that need to remain close to real time.

Q20. You need detailed operational logs for Azure Cosmos DB so you can investigate failed requests and query them centrally. Which Azure capability should you configure?

1. TTL only
2. SDK bulk mode
3. Azure Monitor resource logs
4. Item-level patch operations

Correct Answer: 3. Azure Monitor resource logs

Explanation: Azure Monitor resource logs provide detailed diagnostic information that can be sent to supported destinations such as Log Analytics for centralized querying and investigation. They are useful for troubleshooting failures, monitoring security-related events, and analyzing operational behavior beyond high-level metrics. TTL manages item expiration, bulk mode optimizes high-volume writes, and patch operations modify document properties. Resource logs complement Azure Monitor metrics such as latency, request counts, and normalized RU consumption and are an important part of production monitoring and troubleshooting.