{"id":16520,"date":"2026-09-19T07:49:35","date_gmt":"2026-09-19T07:49:35","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=16520"},"modified":"2026-09-19T07:49:35","modified_gmt":"2026-09-19T07:49:35","slug":"microsoft-dp-420-practice-test-questions-and-exam-dumps-part20-q381-400","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/microsoft-dp-420-practice-test-questions-and-exam-dumps-part20-q381-400\/","title":{"rendered":"Microsoft DP-420 Practice Test Questions and Exam Dumps Part20 Q381-400"},"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 logistics application. Most requests retrieve shipments by <\/b><b>warehouseId<\/b><b>, but warehouse traffic varies greatly. Which design consideration is most important when selecting the partition key?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Ensure every warehouse stores exactly the same number of documents.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Evaluate both data distribution and request-unit distribution across warehouse values.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use the lowest-cardinality property available.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use a property that is never included in queries.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Evaluate both data distribution and request-unit distribution across warehouse values.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> A good Cosmos DB partition key must distribute not only stored data but also request-unit consumption. A warehouse might hold a reasonable share of the data yet receive a disproportionate amount of traffic, creating a hot partition. Therefore, partition-key evaluation should include expected storage growth, read and write patterns, transaction boundaries, and throughput distribution. Low-cardinality keys often create concentration problems, while properties never used in routing may force cross-partition queries. Production monitoring should confirm that the original assumptions about both data and request distribution remain valid as the workload grows.<\/span><\/p>\n<p><b>Q2. A web API creates an Azure Cosmos DB client object every time a request arrives. The application experiences connection overhead and reduced throughput. What should you change?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Create a separate client for every container.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Recreate the client after every write only.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use a stored procedure instead of the SDK.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Reuse a long-lived singleton Cosmos DB client.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Reuse a long-lived singleton Cosmos DB client.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB SDK clients are designed to be long-lived and reused. A singleton client can reuse connections, routing information, caches, and other internal resources, reducing connection overhead and improving throughput. Repeatedly creating and disposing clients can lead to inefficient connection handling, socket exhaustion, and increased latency. A separate client per container is generally unnecessary because one client can work with multiple databases and containers in the same account. Stored procedures serve transactional server-side logic and do not replace proper client lifecycle management in the application.<\/span><\/p>\n<p><b>Q3. You need to measure how expensive a single item write is in request units during performance testing. Where should you obtain the value?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> From the operation response&#8217;s request-charge information.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> From the item&#8217;s TTL property.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> From the account&#8217;s region count.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> From the partition-key name.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. From the operation response&#8217;s request-charge information.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB SDK operation responses expose the request charge consumed by the operation. Capturing this value is one of the most direct ways to compare the cost of creates, replaces, patches, reads, and queries. Request-unit measurements should be collected using representative item sizes and production-like indexing policies because those factors can affect cost. TTL, region count, and the partition-key name do not report the RU consumption of an individual request. Measuring real operation charges is especially useful when sizing throughput or comparing alternative implementation strategies.<\/span><\/p>\n<p><b>Q4. You need a SQL query to return only documents where the <\/b><b>rating<\/b><b> property is a string rather than a number. Which function should you use?<\/b><\/p>\n<ol>\n<li><b><\/b> <span style=\"font-weight: 400;\">ARRAY_CONTAINS<\/span><\/li>\n<li><b><\/b> <span style=\"font-weight: 400;\">DateTimeDiff<\/span><\/li>\n<li><b><\/b> <span style=\"font-weight: 400;\">IS_STRING<\/span><\/li>\n<li><b><\/b> <span style=\"font-weight: 400;\">VectorDistance<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. <\/b><b>IS_STRING<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB for NoSQL SQL provides type-checking functions that help query flexible JSON schemas. <\/span><span style=\"font-weight: 400;\">IS_STRING<\/span><span style=\"font-weight: 400;\"> tests whether a property contains a string value, which is useful when the same property may contain different data types in different documents. <\/span><span style=\"font-weight: 400;\">ARRAY_CONTAINS<\/span><span style=\"font-weight: 400;\"> checks arrays, <\/span><span style=\"font-weight: 400;\">DateTimeDiff<\/span><span style=\"font-weight: 400;\"> performs date calculations, and <\/span><span style=\"font-weight: 400;\">VectorDistance<\/span><span style=\"font-weight: 400;\"> compares embeddings. Type-checking functions are particularly useful during schema evolution or when legacy data contains inconsistent representations. They allow the query to safely isolate documents with the expected type before applying additional logic.<\/span><\/p>\n<p><b>Q5. You are building an API that should create a new record when it does not exist but overwrite the existing record when the same identity already exists. Which operation should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Upsert Item.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Read Item.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Delete Item.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Query Items.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Upsert Item.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Upsert combines create and replace semantics. If no item exists with the specified <\/span><span style=\"font-weight: 400;\">id<\/span><span style=\"font-weight: 400;\"> and partition-key value, Cosmos DB creates it. If the item already exists, the existing document is replaced. This simplifies application code when separate insert and replacement paths are unnecessary. Create Item is preferable when duplicates must cause a failure rather than an overwrite. Read and Query operations do not mutate data, while Delete removes an item. Applications using Upsert should still consider optimistic concurrency when multiple clients can modify the same record simultaneously.<\/span><\/p>\n<p><b>Q6. A high-volume ingestion application must retry transient Cosmos DB failures safely. Which implementation principle is most appropriate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Retry every failure immediately without delay.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable SDK retry handling.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Convert all operations into cross-partition queries.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use SDK retry guidance and respect retry-after information for transient errors.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Use SDK retry guidance and respect retry-after information for transient errors.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Transient cloud failures and throttling should be handled with controlled retry behavior rather than immediate unlimited retries. Cosmos DB SDKs include retry handling for appropriate conditions, and HTTP 429 responses include retry guidance that should be respected. Aggressive retries can increase load and make throttling worse. Disabling all retries reduces resilience, while converting operations into cross-partition queries would typically increase RU cost. Reliable applications distinguish between transient and permanent failures and use bounded retries, diagnostics, and server-provided timing information to recover without creating additional pressure.<\/span><\/p>\n<p><b>Q7. You need to query an item&#8217;s nested <\/b><b>measurements<\/b><b> array and return each measurement as a separate result row. Which SQL construct should you use?<\/b><\/p>\n<ol>\n<li><b><\/b> <span style=\"font-weight: 400;\">GROUP BY<\/span><\/li>\n<li><b><\/b> <span style=\"font-weight: 400;\">JOIN<\/span><span style=\"font-weight: 400;\"> over the nested array.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL.<\/span><\/li>\n<li><b><\/b> <span style=\"font-weight: 400;\">VectorDistance<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. <\/b><b>JOIN<\/b><b> over the nested array.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB SQL supports JOIN semantics for iterating through arrays inside a single JSON item. A JOIN can flatten the elements of <\/span><span style=\"font-weight: 400;\">measurements<\/span><span style=\"font-weight: 400;\"> so each element appears independently in the query results or can be filtered by its own properties. This is different from relational joins between arbitrary containers. <\/span><span style=\"font-weight: 400;\">GROUP BY<\/span><span style=\"font-weight: 400;\"> aggregates values, TTL controls item expiration, and <\/span><span style=\"font-weight: 400;\">VectorDistance<\/span><span style=\"font-weight: 400;\"> performs similarity comparisons between vectors. JOIN is particularly useful when documents embed arrays but the application needs to analyze individual members of those arrays.<\/span><\/p>\n<p><b>Q8. You need several creates and deletes to execute atomically, but the items use different partition-key values. What is the main limitation?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Cosmos DB does not allow deletes inside transactions.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Atomic operations require Strong consistency.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Cosmos DB transactional scope does not span different logical partitions.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Transactional Batch works only with analytical store.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Cosmos DB transactional scope does not span different logical partitions.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB transactional operations such as Transactional Batch and stored procedures are scoped to a single logical partition. If the items have different partition-key values, they cannot participate in one atomic Cosmos DB transaction. This is why transaction requirements must be considered during partition-key design. Deletes are allowed in transactional operations when other conditions are met, and Strong consistency is not a requirement for Transactional Batch. Analytical store is unrelated to transactional writes. Cross-partition workflows often require application-level orchestration or eventual consistency patterns.<\/span><\/p>\n<p><b>Q9. Your organization requires a globally distributed application to continue accepting writes even if one write region becomes unavailable. Which feature should you enable?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Continuous backup.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A full-text index.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Multi-region writes.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Multi-region writes.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Multi-region writes allow more than one configured Azure region to accept write operations. This improves write availability and can reduce latency for geographically distributed users. If one region becomes unavailable, another writable region can continue processing changes. The architecture should also include a conflict-resolution strategy because concurrent updates to the same item can occur across regions. Integrated cache, backup, and full-text indexing solve different performance, recovery, and search requirements. Global write topology should be selected based on availability, latency, data-residency, and cost objectives.<\/span><\/p>\n<p><b>Q10. You need to route read requests from an application instance to a nearby Cosmos DB region whenever possible. Which SDK configuration should you use?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Preferred regions.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Unique keys.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A lease container.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Preferred regions.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Preferred-region configuration lets the Cosmos DB SDK prioritize specific account regions for request routing. An application can list regions in an order that reflects network proximity or operational preferences. If the first region is unavailable, the SDK can use another healthy region from the configured topology. TTL manages expiration, unique keys enforce integrity, and lease containers coordinate change feed processing. Preferred regions should be aligned with application deployment locations and tested together with failover settings so the intended resilience and latency characteristics are achieved.<\/span><\/p>\n<p><b>Q11. You need the complete history of updates and deletions from a container for compliance auditing. Which change feed mode is appropriate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Latest version mode.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> All versions and deletes mode.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache mode.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Analytical store mode.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. All versions and deletes mode.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> All versions and deletes mode is intended for scenarios where intermediate updates and deletion events must be available, such as audit or synchronization workloads. It provides richer history than latest-version mode, which focuses on the latest state of created and updated items and does not normally provide deletion events. This mode depends on continuous backup and its retention window. Integrated cache and analytical store are unrelated to change feed history. Applications requiring a complete change trail should also monitor processing lag so required versions are consumed while still retained.<\/span><\/p>\n<p><b>Q12. You need to maintain a reporting summary from transaction changes without recalculating the full historical dataset. Which pattern should you implement?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Re-run a full cross-partition aggregation after every change.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Store the summary only in cache.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Use change feed processing to persist incremental aggregates.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Disable indexing.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Use change feed processing to persist incremental aggregates.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Change feed processing can maintain persistent aggregates by reacting incrementally to source changes. A processor can update a daily, monthly, or customer-level summary document whenever a transaction changes, avoiding repeated scans of the entire transaction history. This improves efficiency and supports read-optimized reporting models. The processor should be idempotent and tolerate retries. Cache is not durable summary storage, while disabling indexing does not maintain aggregates. Persisted aggregation is a common NoSQL denormalization pattern because it trades some write complexity for much faster analytical reads.<\/span><\/p>\n<p><b>Q13. You need to move Cosmos DB changes into a high-throughput streaming platform so many downstream consumer groups can process them independently. Which Azure service should you use?<\/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 Bastion.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Policy.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Azure Event Hubs.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. Azure Event Hubs.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Event Hubs is built for high-throughput event ingestion and supports multiple independent consumer groups. A change feed consumer or Azure Function can publish Cosmos DB changes into Event Hubs, making them available to many downstream applications, analytics processors, or integration services. Azure DNS provides name resolution, Bastion provides secure virtual-machine access, and Azure Policy governs resource compliance. Event Hubs is a natural choice when operational database changes need to become part of a broader event-driven architecture with multiple independent consumers.<\/span><\/p>\n<p><b>Q14. A data engineering team needs distributed Spark transformations and must write the processed documents back to Cosmos DB. Which integration is appropriate?<\/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;\"> Integrated cache.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Periodic backup.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A stored procedure only.<\/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 Cosmos DB Spark connector allows Spark workloads to interact directly with the transactional store for supported reads and writes. It is useful for distributed enrichment, transformation, migration, and data-processing workflows. Integrated cache is designed for eligible application reads, while periodic backup supports recovery. Stored procedures are scoped to one logical partition and are not a general distributed-processing replacement. Spark-based writes consume transactional request units, so workloads should be tuned carefully to avoid saturating production throughput or creating hot partitions.<\/span><\/p>\n<p><b>Q15. You need Cosmos DB data to be available in Microsoft Fabric for analytics without building a custom replication pipeline. Which feature should you evaluate?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Cosmos DB Mirroring for Microsoft Fabric.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Transactional Batch.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A continuation token.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. Cosmos DB Mirroring for Microsoft Fabric.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Cosmos DB Mirroring for Microsoft Fabric provides a managed path for replicating operational Cosmos DB data into Fabric analytical scenarios with less custom ETL engineering. It can simplify reporting and analytics architectures where Cosmos DB serves as the operational data store. Transactional Batch is for atomic same-partition writes, TTL controls retention, and continuation tokens support query paging. Mirroring should be compared with Spark-based options depending on whether the requirement is managed analytical replication or direct distributed transformation and writeback.<\/span><\/p>\n<p><b>Q16. You need analytical tools to scan very large Cosmos DB datasets without placing equivalent RU pressure on the transactional store. Which capability should you enable?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Manual failover.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Strong consistency.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Analytical store.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Integrated cache only.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3. Analytical store.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Analytical store provides a column-oriented representation of Cosmos DB data optimized for analytical workloads. It helps separate large scans, reporting, and Spark analysis from the request-unit consumption of the transactional store. This improves workload isolation so analytical processing is less likely to interfere with latency-sensitive application traffic. Integrated cache is helpful for repeated operational reads but is not a substitute for analytical store. Failover and consistency address resilience and read semantics rather than analytical workload separation.<\/span><\/p>\n<p><b>Q17. You need Cosmos DB documents containing sensitive fields to be encrypted on the client before they reach the database service. Which capability should you consider?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Always Encrypted.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Composite indexing.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Change feed estimator.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Always Encrypted.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Always Encrypted provides client-side encryption for selected Cosmos DB properties so plaintext values are protected before they are transmitted to the database service. This is useful for particularly sensitive information where field-level protection is required in addition to normal encryption at rest. Encryption keys and metadata must be managed carefully, and some query behaviors may be constrained depending on the encryption configuration. Composite indexes, TTL, and change feed estimation do not provide client-side field encryption. Security architecture should also include appropriate identity, role assignments, and network controls.<\/span><\/p>\n<p><b>Q18. You need application traffic to Cosmos DB to remain inside approved private Azure networking. What should you configure?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A continuation token.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> A private endpoint through Azure Private Link.<\/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;\"> TTL.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2. A private endpoint through Azure Private Link.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> A private endpoint gives a Cosmos DB account a private IP address within a virtual network through Azure Private Link. Applications can then access the account over private Azure networking rather than relying on the public endpoint. Public network access can be restricted according to the organization&#8217;s security policy. Correct DNS configuration is essential so the Cosmos DB hostname resolves to the private endpoint. Continuation tokens, UDFs, and TTL solve query and lifecycle concerns rather than network isolation.<\/span><\/p>\n<p><b>Q19. A production account begins returning frequent HTTP 429 responses. Which metric should you inspect to determine whether the workload is approaching available throughput?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> Normalized RU Consumption.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Backup interval.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Number of Azure regions only.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> Number of stored procedures.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1. Normalized RU Consumption.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Normalized RU Consumption shows how much of the available throughput is being used relative to the account or partition capacity. Persistently high values can indicate that the workload is approaching its RU limit and may experience throttling. It is also important to inspect partition-level metrics because a hot partition can cause 429 responses even when aggregate utilization appears moderate. Backup interval, region count, and stored-procedure count do not measure throughput saturation. Monitoring should correlate normalized RU usage with status codes, latency, and partition distribution.<\/span><\/p>\n<p><b>Q20. You need an automatic operational notification when server-side latency exceeds a threshold for a sustained period. What should you configure?<\/b><\/p>\n<ol>\n<li><b><\/b><span style=\"font-weight: 400;\"> A composite index.<\/span><\/li>\n<li><b><\/b><span style=\"font-weight: 400;\"> TTL.<\/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;\"> An Azure Monitor alert rule and action group.<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4. An Azure Monitor alert rule and action group.<\/b><\/p>\n<p><b>Explanation:<\/b><span style=\"font-weight: 400;\"> Azure Monitor alert rules can evaluate Cosmos DB metrics such as server-side latency over a defined time interval and trigger an action group when conditions remain above an acceptable threshold. Action groups can send notifications or invoke automated workflows. This supports proactive operational response before sustained latency becomes a serious user-facing problem. Composite indexes may affect query performance but do not provide notifications. TTL and unique key policies serve lifecycle and integrity needs. Alerts should be based on thresholds that reflect realistic service objectives and normal workload behavior.<\/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 logistics application. Most requests retrieve shipments by warehouseId, but warehouse traffic varies greatly. Which design consideration is most important when selecting the partition key? Ensure every warehouse stores exactly the same [&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\/16520"}],"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=16520"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16520\/revisions"}],"predecessor-version":[{"id":16561,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/16520\/revisions\/16561"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=16520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=16520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=16520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}