{"id":16502,"date":"2026-09-19T07:53:49","date_gmt":"2026-09-19T07:53:49","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=16502"},"modified":"2026-09-19T07:53:49","modified_gmt":"2026-09-19T07:53:49","slug":"microsoft-dp-420-practice-test-questions-and-exam-dumps-part3-q41-60","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-dp-420-practice-test-questions-and-exam-dumps-part3-q41-60\/","title":{"rendered":"Microsoft DP-420 Practice Test Questions and Exam Dumps Part3 Q41-60"},"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 modeling a shopping-cart workload in Azure Cosmos DB for NoSQL. A cart and all of its line items are almost always read and updated together. Which data-modeling approach is most appropriate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Store every line item in a separate database account.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Store line items in unrelated containers with random partition keys.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Embed the related line items in the cart document when size and update requirements permit.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Store only references to external relational tables.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Embed the related line items in the cart document when size and update requirements permit.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Embedding related entities in the same JSON document is often appropriate when those entities are normally retrieved and updated together. A shopping cart and its line items typically share the same lifecycle and access pattern, so embedding can reduce the number of reads and avoid cross-document joins. The design must still consider document-size limits and update frequency. Separating tightly related data across unrelated containers can increase request-unit consumption and application complexity. Azure Cosmos DB data models should be designed around application access patterns rather than normalized relational modeling conventions.<\/span><\/p>\n<p><b>Q2. You need to support several versions of a JSON document schema while gradually migrating older documents. Which property should you add to each document?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A schema-version property.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A new Azure region.<\/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;\"> A session token.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. A schema-version property.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB does not require every document in a container to have an identical schema. Adding an explicit schema-version property allows application code to determine which structure a document uses and apply the appropriate deserialization, transformation, or migration logic. This is useful when applications evolve without requiring an immediate rewrite of all existing items. Regions control distribution, continuation tokens support query pagination, and session tokens support session consistency. Schema versioning provides a clear and maintainable way to evolve document structures while preserving compatibility with previously stored data.<\/span><\/p>\n<p><b>Q3. A workload has no single property that provides both even distribution and efficient query routing. You decide to combine <\/b><b>tenantId<\/b><b> and <\/b><b>month<\/b><b> into one value. What type of partitioning technique are you implementing?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Unique-key partitioning.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Read-region routing.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL-based distribution.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A synthetic partition key.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. A synthetic partition key.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> A synthetic partition key is created by combining multiple properties into a single calculated value when no existing property satisfies the workload&#8217;s distribution and query requirements. For example, combining tenant ID and month can increase cardinality and help distribute high-volume tenant data over time. The application must consistently generate the same synthetic value when creating and querying items. Unique keys enforce constraints rather than distribution. TTL controls expiration, and regional routing concerns global distribution. Synthetic keys should be planned carefully because changing a partition-key strategy later can require data migration.<\/span><\/p>\n<p><b>Q4. One container contains a mission-critical workload that requires guaranteed throughput isolation, while several other low-priority containers can share capacity. What should you do for the critical container?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Configure only database-level shared throughput for all containers.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Provision dedicated throughput on the critical container.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable its partition key.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Move all items into one logical partition.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Provision dedicated throughput on the critical container.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Container-level provisioned throughput provides dedicated request-unit capacity to a specific container instead of making that workload compete for database-level shared throughput. This can be useful for a critical workload with predictable performance or isolation requirements. Shared database throughput can be cost-effective for containers with complementary usage patterns, but it may not provide the same isolation. Removing the partition key is not an option for scalable partitioned containers, and concentrating all data in one logical partition would create scalability and hot-partition risks. Throughput scope should reflect workload criticality and resource-governance needs.<\/span><\/p>\n<p><b>Q5. You are troubleshooting intermittent connectivity problems in an application that uses the Azure Cosmos DB SDK. You need detailed client-side diagnostic information. What should you enable?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> SDK logging and diagnostics.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL on every item.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Analytical store.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A unique key policy.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. SDK logging and diagnostics.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB SDK logging and diagnostic information can provide insight into client-side request behavior, latency, retries, endpoint selection, and connection problems. These diagnostics are valuable when troubleshooting transient failures or unexpected performance. TTL controls item expiration, analytical store supports analytical workloads, and unique keys enforce data integrity. Production applications should collect appropriate diagnostics while avoiding unnecessary sensitive information. Combined with Azure Monitor metrics and resource logs, SDK diagnostics can help determine whether an issue originates in the application, network, service, or specific request patterns.<\/span><\/p>\n<p><b>Q6. Your application occasionally receives temporary network failures and service-unavailable responses. What application behavior should you implement?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Immediately delete the database.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable all retries.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use appropriate retry handling for transient failures.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Convert all writes into cross-partition queries.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Use appropriate retry handling for transient failures.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cloud applications should expect occasional transient failures caused by networking, throttling, or temporary service conditions. Azure Cosmos DB SDKs provide built-in retry behavior for certain failures, and application logic should follow documented retry guidance rather than treating every transient condition as permanent. Retrying without limits or appropriate delays can worsen service pressure, so retry behavior should consider status codes and server-provided retry information. Deleting resources or disabling retries would reduce resilience. Correct transient-error handling is an important part of building reliable cloud-native applications.<\/span><\/p>\n<p><b>Q7. You execute an expensive SQL query against Azure Cosmos DB and want to understand its request-unit charge and execution characteristics. What should you retrieve?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Only the document count.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Query metrics and request-charge information.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The container TTL value.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The account&#8217;s backup interval only.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Query metrics and request-charge information.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Query metrics and request-charge information help developers evaluate the cost and execution behavior of Azure Cosmos DB queries. They can reveal request-unit consumption and provide useful details for comparing alternative query designs or indexing strategies. This is especially important because two queries returning similar results can consume very different amounts of throughput. Document count, TTL, and backup settings do not describe query efficiency. Developers should use metrics together with knowledge of partition routing and indexing to optimize queries and reduce unnecessary RU consumption.<\/span><\/p>\n<p><b>Q8. You need a SQL query that returns products only when a related nested array contains an element matching criteria from the outer product document. Which query technique is most relevant?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual regional failover.<\/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;\"> TTL.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A correlated subquery.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. A correlated subquery.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> A correlated subquery references values from the outer query while evaluating an inner query expression. In Azure Cosmos DB for NoSQL, correlated subqueries can be useful when working with nested arrays or related document structures and when the inner filtering logic depends on the current outer item. Regional failover affects availability, unique keys enforce constraints, and TTL controls expiration. Writing efficient SQL against JSON often requires familiarity with nested data, arrays, subqueries, built-in functions, and how those constructs affect index use and request-unit cost.<\/span><\/p>\n<p><b>Q9. A container contains documents where the <\/b><b>discount<\/b><b> property can be a number, a string, or missing. You need to return only documents where <\/b><b>discount<\/b><b> is numeric. Which SQL capability should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A manual failover policy.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A stored procedure.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A type-checking function such as <\/span><span style=\"font-weight: 400;\">IS_NUMBER<\/span><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A continuation token.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. A type-checking function such as <\/b><b>IS_NUMBER<\/b><b>.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB for NoSQL provides type-checking functions that can test whether JSON values are numbers, strings, arrays, objects, booleans, or other supported types. This is valuable because JSON documents in the same container can contain variable schemas or inconsistent property types. A type predicate such as <\/span><span style=\"font-weight: 400;\">IS_NUMBER<\/span><span style=\"font-weight: 400;\"> allows a query to filter appropriately without assuming all documents have identical structures. Stored procedures provide transactional server-side logic, failover affects regions, and continuation tokens handle pagination. Type-aware queries are important when working with flexible document schemas.<\/span><\/p>\n<p><b>Q10. You need a query to return only items whose <\/b><b>description<\/b><b> property begins with the text &#8220;Premium&#8221;. Which SQL feature should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Transactional Batch.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A string function such as <\/span><span style=\"font-weight: 400;\">STARTSWITH<\/span><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Continuous backup.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Multi-region writes.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. A string function such as <\/b><b>STARTSWITH<\/b><b>.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB SQL includes string functions that allow queries to evaluate text properties. <\/span><span style=\"font-weight: 400;\">STARTSWITH<\/span><span style=\"font-weight: 400;\"> can test whether a string begins with a specified sequence, making it appropriate for filtering descriptions that begin with &#8220;Premium.&#8221; Transactional Batch handles atomic item operations within a logical partition, continuous backup supports recovery, and multi-region writes improve globally distributed write availability. Query functions should be selected based on the property type and query requirement, and their RU cost should be evaluated for high-volume workloads.<\/span><\/p>\n<p><b>Q11. You need to calculate the number of days between two date strings stored in supported ISO 8601 format directly in an Azure Cosmos DB SQL query. Which type of function should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Array function.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Spatial function.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Unique-key function.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A date\/time function.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. A date\/time function.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB for NoSQL SQL includes date and time functions that can perform operations on supported date representations, including calculations involving time intervals. Using built-in functions is generally preferable to manually parsing date strings in application code when the calculation is naturally part of query filtering or projection. Array functions operate on arrays, spatial functions process geographic values, and unique keys are container configuration rather than SQL functions. Date-based query logic should also be evaluated for indexing and request-unit efficiency when applied to large datasets.<\/span><\/p>\n<p><b>Q12. An Azure Function must run automatically whenever new or updated items appear in a Cosmos DB container. Which integration should you configure?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> An Azure Cosmos DB trigger for Azure Functions.<\/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 direct-mode client.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. An Azure Cosmos DB trigger for Azure Functions.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> The Azure Cosmos DB trigger for Azure Functions uses the change feed to invoke function code when new or updated items are available. This supports event-driven workflows such as denormalization, notifications, aggregation, archiving, or integration with other services. Unique keys enforce data constraints, direct mode is an SDK connectivity option, and integrated cache reduces eligible read latency and RU consumption. Using a trigger removes much of the custom change-feed polling logic and provides a managed way to connect serverless compute to Cosmos DB changes.<\/span><\/p>\n<p><b>Q13. You need Cosmos DB changes to be forwarded to a high-throughput event-streaming platform so multiple downstream applications can consume them independently. Which Azure service is most appropriate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure DNS.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Event Hubs.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Bastion.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Policy.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Azure Event Hubs.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Event Hubs is designed for high-throughput event ingestion and streaming. A change feed processing component or Azure Function can publish Cosmos DB changes to Event Hubs, allowing multiple downstream consumers to process the event stream. Azure DNS provides name resolution, Bastion provides secure virtual-machine access, and Azure Policy supports resource governance. Combining Cosmos DB change feed with an event-streaming service is useful when operational data changes need to feed multiple independent systems or analytics pipelines at scale.<\/span><\/p>\n<p><b>Q14. Your application stores an order document that references a customer document. You need to detect when a referenced customer is deleted and take corrective action. Which pattern should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable indexing.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Enable integrated cache.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use only point reads.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use change feed processing to enforce referential integrity in application logic.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Use change feed processing to enforce referential integrity in application logic.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Cosmos DB is a non-relational database and does not provide relational foreign-key constraints between independent documents. If an application uses references between documents, referential integrity can be enforced asynchronously through application logic. The change feed can detect relevant changes, and an Azure Function or change feed processor can update, flag, or remove dependent records as required. Indexing, cache, and point reads do not enforce references. This pattern illustrates why data-model design must account for whether related entities are embedded, denormalized, or referenced.<\/span><\/p>\n<p><b>Q15. You maintain a precomputed daily sales summary document. Every new order should update the appropriate daily summary asynchronously. Which design should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Process orders from the change feed and persist the updated aggregation.<\/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;\"> Store every summary in the integrated cache only.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use a continuation token as the aggregation value.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Process orders from the change feed and persist the updated aggregation.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Change feed processing can maintain persistent precomputed aggregations by reacting to each new or updated transactional item. A processor can calculate the required contribution and update the appropriate summary document. This reduces the need to repeatedly scan large transactional datasets when reports request aggregates. The design must account for idempotency, partitioning, and retry behavior. Disabling partitioning is not appropriate, integrated cache is not durable storage, and continuation tokens are used for query pagination. Persisted aggregation is a common change-feed optimization pattern.<\/span><\/p>\n<p><b>Q16. An application must archive older Cosmos DB records to another storage system whenever they meet a business rule. Which mechanism is suitable for detecting items that should be archived?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Composite indexing only.<\/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;\"> Change feed processing combined with application or function logic.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Preferred-region configuration.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Change feed processing combined with application or function logic.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Change feed processing can react to item changes and execute custom logic such as copying records to another system for archival. The application can decide which records meet the archive criteria and then write them to a suitable destination. Composite indexes affect query optimization, throughput settings control capacity, and preferred regions affect client routing. Change feed processing is useful for asynchronous integration patterns because it allows operational writes to remain focused on the transactional workload while downstream processing handles additional business actions.<\/span><\/p>\n<p><b>Q17. You are diagnosing high latency and want to distinguish Cosmos DB service processing time from client-side and network delays. Which metric should you review?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Document count.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL expiration count only.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Backup interval.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Server-side latency in Azure Monitor.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Server-side latency in Azure Monitor.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Server-side latency metrics measure the time Azure Cosmos DB spends processing requests within the service. Comparing server-side latency with end-to-end application latency can help determine whether delays are occurring inside the database service or elsewhere, such as in the network, application, or client configuration. Document count, TTL, and backup settings do not provide this distinction. Effective troubleshooting usually combines Azure Monitor metrics, SDK diagnostics, status codes, request charges, and network observations to identify the true source of latency.<\/span><\/p>\n<p><b>Q18. Overall RU consumption for an account appears moderate, but one physical partition repeatedly experiences throttling. What should you inspect?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Only the account display name.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Throughput distribution across partitions.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Only the backup mode.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> The unique-key count.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Throughput distribution across partitions.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> An account can experience throttling even when total RU consumption looks reasonable if traffic is unevenly distributed and one partition becomes hot. Monitoring throughput consumption across partitions helps identify whether a particular partition is receiving a disproportionate share of requests. This often points back to partition-key design, skewed workload patterns, or specific high-volume tenants or values. Backup configuration and unique keys do not explain per-partition throttling. Partition-level monitoring is essential for diagnosing hot partitions and evaluating whether the partitioning strategy distributes workload effectively.<\/span><\/p>\n<p><b>Q19. You suspect that a poor partition key has caused most data to accumulate in a small number of partitions. Which operational characteristic should you monitor?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Only the Azure subscription name.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Session tokens.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Data distribution across partitions.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> UDF execution count only.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Data distribution across partitions.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Monitoring data distribution across partitions helps determine whether the chosen partition key spreads stored data evenly or causes skew. Uneven distribution can lead to storage constraints, hot partitions, and inefficient scaling. Throughput distribution should also be monitored because evenly stored data can still experience uneven traffic. Subscription names, session tokens, and UDF counts do not reveal partition data skew. Partition-key design should be evaluated using both expected access patterns and actual production data distribution as the workload grows.<\/span><\/p>\n<p><b>Q20. Your organization wants an alert when Normalized RU Consumption remains above a defined threshold for several minutes. What should you configure?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> An Azure Monitor alert rule.<\/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 SQL UDF.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A continuation token.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. An Azure Monitor alert rule.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Monitor alert rules can evaluate Cosmos DB metrics and notify operators when defined conditions are met. An alert on sustained high Normalized RU Consumption can provide early warning that a workload is approaching available throughput and may begin experiencing throttling. Alert rules can be combined with action groups for notifications or automated responses. Unique key policies enforce data constraints, UDFs extend SQL query logic, and continuation tokens support pagination. Proactive monitoring is an important part of maintaining reliable Azure Cosmos DB production workloads.<\/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 modeling a shopping-cart workload in Azure Cosmos DB for NoSQL. A cart and all of its line items are almost always read and updated together. Which data-modeling approach is most appropriate? Store every line item in a separate database account. Store [&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\/16502"}],"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=16502"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16502\/revisions"}],"predecessor-version":[{"id":16578,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16502\/revisions\/16578"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=16502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=16502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=16502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}