{"id":16501,"date":"2026-09-19T07:54:03","date_gmt":"2026-09-19T07:54:03","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=16501"},"modified":"2026-09-19T07:54:03","modified_gmt":"2026-09-19T07:54:03","slug":"microsoft-dp-420-practice-test-questions-and-exam-dumps-part2-q21-40","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-dp-420-practice-test-questions-and-exam-dumps-part2-q21-40\/","title":{"rendered":"Microsoft DP-420 Practice Test Questions and Exam Dumps Part2 Q21-40"},"content":{"rendered":"<p>&nbsp;<\/p>\n<p><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/dp-420-exam-dumps\"><b>Microsoft DP-420 Exam Dumps<\/b><\/a><b> and Practice Test Dumps.<\/b><\/p>\n<p><b><br \/>\n<\/b><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A unique key on <\/span><span style=\"font-weight: 400;\">\/userId<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A single low-cardinality partition key<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Database-level throughput only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A hierarchical partition key such as tenant ID followed by user ID<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. A hierarchical partition key such as tenant ID followed by user ID<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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&#8217;s most common access patterns.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Serverless<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual provisioned throughput<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Dedicated gateway only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Strong consistency<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Serverless<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> All queries automatically become point reads.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The container loses its indexing policy.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A hot partition can receive a disproportionate share of writes.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Multi-region writes become unavailable.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. A hot partition can receive a disproportionate share of writes.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Configure a different Azure region for each container.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Provision throughput at the database level.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable indexing on every container.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use a stored procedure to distribute request units.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Provision throughput at the database level.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Direct mode<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Gateway mode only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Offline mode<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Analytical mode<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Direct mode<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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&#8217;s session consistency guarantees. What should you propagate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> The ETag only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A continuation token<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The session token<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The database resource ID only<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. The session token<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Recreate the account with a different default consistency level.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Override consistency in the request or query options where supported.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable the partition key.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Enable TTL for the queried items.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Override consistency in the request or query options where supported.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB SDK request options can allow an application to override the account&#8217;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.<\/span><\/p>\n<p><b>Q8. Documents contain an <\/b><b>items<\/b><b> 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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Point reads only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL filters<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Array-aware SQL querying, such as JOIN or array functions<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Database-level throughput<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Array-aware SQL querying, such as JOIN or array functions<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>Q9. You want to reduce write request-unit consumption in a write-heavy container. A large property named <\/b><b>rawPayload<\/b><b> is never queried. What indexing change should you consider?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Add a unique key for <\/span><span style=\"font-weight: 400;\">rawPayload<\/span><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Exclude the <\/span><span style=\"font-weight: 400;\">rawPayload<\/span><span style=\"font-weight: 400;\"> path from indexing.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Add a composite index containing only <\/span><span style=\"font-weight: 400;\">rawPayload<\/span><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Convert <\/span><span style=\"font-weight: 400;\">rawPayload<\/span><span style=\"font-weight: 400;\"> to the partition key.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Exclude the <\/b><b>rawPayload<\/b><b> path from indexing.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB indexes properties according to the container&#8217;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.<\/span><\/p>\n<p><b>Q10. A query contains <\/b><b>ORDER BY c.category, c.createdDate<\/b><b>. It fails because the default indexing policy cannot support the requested multi-property ordering. What should you add?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A composite index for <\/span><span style=\"font-weight: 400;\">category<\/span><span style=\"font-weight: 400;\"> and <\/span><span style=\"font-weight: 400;\">createdDate<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A TTL policy<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A unique key policy<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A session token<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. A composite index for <\/b><b>category<\/b><b> and <\/b><b>createdDate<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Queries that use <\/span><span style=\"font-weight: 400;\">ORDER BY<\/span><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Pre-trigger<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Composite index<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Change feed estimator<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Continuation token<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Pre-trigger<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Stored procedure<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> User-defined function<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Post-trigger<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Change feed processor<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. User-defined function<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Automatic failover with an ordered list of regions<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Analytical store<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Bulk execution<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Unique key policy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Automatic failover with an ordered list of regions<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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&#8217;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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Serverless throughput<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A custom conflict resolution policy<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A point read<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. A custom conflict resolution policy<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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&#8217;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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual CSV exports<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Stored procedures<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB Mirroring for Microsoft Fabric<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Session-token propagation<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Azure Cosmos DB Mirroring for Microsoft Fabric<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>Q16. You need a Spark application to read and write directly against the Azure Cosmos DB transactional store. Which integration should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB Spark connector<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Monitor alert rule<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Gateway-mode SDK only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Composite index transformation<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Azure Cosmos DB Spark connector<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure AI Search integration with Azure Cosmos DB<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Strong consistency only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL expiration<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual regional failover<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Azure AI Search integration with Azure Cosmos DB<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Continuous backup<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache through the dedicated gateway<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual failover<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Transactional Batch<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Integrated cache through the dedicated gateway<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Change feed estimator<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Unique key policy<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Spatial index<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Change feed estimator<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p><b>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?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL only<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> SDK bulk mode<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Monitor resource logs<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Item-level patch operations<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Azure Monitor resource logs<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> 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.<\/span><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&nbsp; 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? A unique key on [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16501"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=16501"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16501\/revisions"}],"predecessor-version":[{"id":16579,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16501\/revisions\/16579"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=16501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=16501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=16501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}