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

Q1. You store customers, suppliers, and employees in the same Azure Cosmos DB for NoSQL container. The application must easily identify the entity type of each document. What should you include in the documents?

1. A different consistency level for each entity.
2. A discriminator property such as type.
3. A separate partition key definition for every item.
4. A continuation token.

Correct Answer: 2. A discriminator property such as type.

Explanation: When multiple entity types share a container, a discriminator property such as type, entityType, or documentType allows application code and queries to identify the logical type of each document. This supports efficient filtering and keeps the data model understandable while still allowing related entity types to share throughput and partitioning. Consistency is configured at the account or request level rather than per document type. A container has one partition-key definition, and continuation tokens are used for query pagination. Multi-entity containers work best when the entity types share compatible access patterns and partitioning requirements.

Q2. Your application has version 1 and version 2 documents in the same container. Version 2 introduces renamed properties. You want the application to process both formats during migration. Which design is best?

1. Delete all version 1 documents immediately.
2. Disable indexing until every item is migrated.
3. Use separate Azure subscriptions for each schema version.
4. Store a schema-version property and handle each version appropriately.

Correct Answer: 4. Store a schema-version property and handle each version appropriately.

Explanation: Cosmos DB allows documents in the same container to have different JSON structures. Adding a schema-version property lets application code determine how each document should be interpreted and supports gradual migrations without requiring all existing data to be rewritten at once. The application can read older versions and transform them as needed while new writes use the latest structure. Disabling indexing does not solve compatibility, and separate subscriptions would add unnecessary complexity. Explicit schema versioning is especially useful in cloud-native applications where document models evolve over time while production data remains available.

Q3. A workload frequently queries data by tenantId, but several individual tenants generate extremely large volumes. You cannot use hierarchical partition keys for this existing design. What strategy can improve distribution?

1. Create a synthetic partition key that combines tenant identity with another suitably distributed value.
2. Use a constant partition-key value for the entire tenant population.
3. Use a Boolean property as the partition key.
4. Remove the partition key.

Correct Answer: 1. Create a synthetic partition key that combines tenant identity with another suitably distributed value.

Explanation: A synthetic partition key combines multiple business properties into one generated partition-key value. For example, an application might combine tenant ID with a bucket, month, region, or another value that increases cardinality and distributes a high-volume tenant across more logical partitions. The application must consistently generate and use the synthetic value when writing and querying items. Constant or Boolean keys have very low cardinality and can cause hot partitions. Partitioning cannot simply be removed from a scalable container. Synthetic keys are useful when no single existing property provides an acceptable balance of routing and distribution.

Q4. Your application has two important query patterns that require fundamentally different partition keys, and neither pattern can tolerate frequent cross-partition queries. What should you consider?

1. Force both workloads into one low-cardinality partition.
2. Disable indexing.
3. Maintain separate containers or projections optimized for each access pattern.
4. Use TTL to switch partition keys at runtime.

Correct Answer: 3. Maintain separate containers or projections optimized for each access pattern.

Explanation: A container has a defined partitioning strategy, so fundamentally different access patterns may not be optimizable with one partition key. Separate containers or denormalized projections can allow each workload to use a partition key aligned to its own dominant queries. Change feed processing can help synchronize projections when duplicated data is required. Disabling indexes does not change routing, while TTL manages expiration rather than partition-key selection. Modeling multiple projections is common in NoSQL systems because data duplication can be an intentional tradeoff when it substantially improves query efficiency and scalability.

Q5. You are estimating the throughput required for a new Cosmos DB application. Which workload characteristic should have the greatest influence on the estimate?

1. Expected request patterns, RU cost per operation, and peak request rate.
2. The number of Azure subscriptions owned by the company.
3. The number of developers on the project.
4. The name of the Cosmos DB account.

Correct Answer: 1. Expected request patterns, RU cost per operation, and peak request rate.

Explanation: Cosmos DB throughput planning should be based on the operations the application performs, the request-unit cost of those operations, and the expected request rate during peak periods. Reads, queries, writes, indexing policies, item sizes, and consistency choices can all affect RU consumption. Multiplying representative RU costs by expected workload volume provides a much more meaningful estimate than organizational metadata. Capacity planning should also consider uneven partition usage, future growth, autoscale requirements, and regional replication because an apparently sufficient overall RU allocation can still suffer from localized hot partitions.

Q6. You need custom conflict resolution for multi-region writes. The business rule must decide which version wins when concurrent updates occur. What should you implement?

1. A TTL policy.
2. A query continuation token.
3. An integrated cache.
4. A custom conflict-resolution policy.

Correct Answer: 4. A custom conflict-resolution policy.

Explanation: Multi-region writes can create conflicts when the same logical item is updated concurrently in different regions. If the default last-writer-wins behavior does not match the business requirement, a custom conflict-resolution policy can implement application-specific reconciliation logic. The chosen approach should be deterministic and carefully tested because conflict behavior directly affects data correctness. TTL governs document expiration, continuation tokens handle query paging, and integrated cache accelerates eligible reads. Conflict-resolution design is an important part of any active-active architecture where concurrent writes to the same data are possible.

Q7. A Cosmos DB account uses several readable regions. Your application is deployed in West Europe and should prefer nearby reads while still failing over if the region is unavailable. What should you configure?

1. A unique key.
2. SDK preferred regions.
3. A TTL override.
4. An analytical store.

Correct Answer: 2. SDK preferred regions.

Explanation: Preferred regions allow the Cosmos DB SDK to prioritize specific account regions when routing requests. An application deployed in West Europe can list nearby regions first, reducing network latency during normal operation while still allowing the SDK to use another healthy region when necessary. The configured list should correspond to actual Cosmos DB regions and the application’s deployment topology. Unique keys enforce data constraints, TTL controls expiration, and analytical store supports analytics. Region-aware SDK configuration complements Cosmos DB’s global distribution and failover capabilities.

Q8. You need to query documents where an optional property can contain different JSON types. The query should return only items where the property is an array. Which approach should you use?

1. A stored procedure.
2. Manual failover.
3. A type-checking SQL function such as IS_ARRAY.
4. Continuous backup.

Correct Answer: 3. A type-checking SQL function such as IS_ARRAY.

Explanation: Flexible JSON schemas mean that the same property can be missing or contain different types across documents. Cosmos DB SQL includes type-checking functions that let queries test whether a value is an array, object, string, number, Boolean, or another supported type. This allows queries to safely filter heterogeneous documents before applying array-specific logic. Stored procedures handle server-side transactional work, failover controls regional roles, and backup handles recovery. Type-aware query expressions are especially useful in containers that intentionally support multiple document versions or entity shapes.

Q9. You want a SQL query to return the absolute value of a numeric difference calculated from document properties. Which type of built-in function should you use?

1. Backup function.
2. Change feed function.
3. Geographic function only.
4. Mathematical function.

Correct Answer: 4. Mathematical function.

Explanation: Cosmos DB SQL provides built-in mathematical functions that operate on numeric expressions. A function such as ABS can calculate the absolute value of a difference directly as part of a query projection or filter. Built-in functions are typically preferable to transferring all records to application code solely to perform simple calculations. Change feed and backup capabilities do not perform query mathematics, while spatial functions are specifically intended for geographic calculations. As with all query expressions, developers should evaluate request-unit cost and index usage for large workloads.

Q10. You need server-side logic that runs after an item has been created and is explicitly requested by the client during the operation. Which server-side object should you use?

1. A post-trigger.
2. A UDF used in a SELECT statement.
3. A continuation token.
4. A composite index.

Correct Answer: 1. A post-trigger.

Explanation: A post-trigger is server-side JavaScript that executes after a supported item operation when the client explicitly specifies the trigger. It can be useful for certain logic that needs to run after the primary mutation while remaining within the supported server-side execution model. Triggers are not automatically invoked for all writes; the application must request them. A UDF is called from queries and returns calculated values. Continuation tokens support paging, while composite indexes optimize queries. Triggers should be used carefully because explicit application-side logic is often easier to maintain.

Q11. Your application must retrieve query results in pages and expose an API that lets callers resume later. What should the API return with each nonfinal page?

1. The account’s primary key.
2. The item’s TTL.
3. A continuation token.
4. The conflict-resolution policy.

Correct Answer: 3. A continuation token.

Explanation: A continuation token represents the position of a paginated Cosmos DB query and allows a later request to continue from that point. An API can return the token to its caller or store it as part of application state. Continuation tokens help applications handle large query result sets without retrieving everything in a single response. The account key authenticates requests and should never be exposed to clients. TTL controls item expiration, while conflict policy determines multi-region conflict behavior. Continuation-token handling is a core SDK pattern for scalable pagination.

Q12. You perform many independent creates and updates and want the SDK to group work efficiently for maximum throughput. Atomicity across operations is not required. Which capability should you enable?

1. Strong consistency.
2. Bulk support.
3. A single-partition stored procedure for every request.
4. Integrated cache.

Correct Answer: 2. Bulk support.

Explanation: Bulk support improves throughput for large numbers of independent operations by allowing the SDK to schedule them efficiently and execute work concurrently across partitions. It is suitable for migrations, imports, or large update workloads where individual requests do not need to form one transaction. Transactional Batch should be used instead when multiple same-partition operations must succeed or fail together. Strong consistency affects reads, stored procedures add unnecessary complexity for independent work, and integrated cache optimizes eligible reads rather than writes. Bulk workloads must still respect available throughput and partition distribution.

Q13. You need to continuously maintain a reporting summary container from operational order changes. The summary must not slow down the original order write transaction. Which pattern is most appropriate?

1. Use change feed processing to update the reporting summary asynchronously.
2. Perform a cross-partition query after every order write.
3. Increase TTL on all order documents.
4. Put the summary only in integrated cache.

Correct Answer: 1. Use change feed processing to update the reporting summary asynchronously.

Explanation: Change feed processing allows downstream logic to react to order changes after the transactional write is committed. A processor or Azure Function can maintain aggregated summary documents without forcing the original write request to calculate and update reporting data synchronously. This is a common materialized-view or persisted-aggregation pattern. Cross-partition queries after every write could be expensive and add latency. TTL is unrelated, and integrated cache is not durable storage. Asynchronous projections should be designed for idempotency and eventual consistency because retries can occur.

Q14. You need Cosmos DB changes to invoke serverless code automatically. Which Azure integration is most direct?

1. Azure Bastion.
2. Azure Functions with a Cosmos DB trigger.
3. Azure Policy.
4. Azure DNS.

Correct Answer: 2. Azure Functions with a Cosmos DB trigger.

Explanation: The Azure Cosmos DB trigger for Azure Functions uses the change feed to invoke serverless function code when new or updated items become available. It provides a convenient managed integration for event-driven workflows such as notifications, archiving, aggregation, or integration with external systems. Azure Bastion provides secure VM connectivity, Azure Policy governs resource compliance, and Azure DNS provides name resolution. Function triggers simplify change feed consumption by handling much of the coordination required for scalable processing.

Q15. You want Cosmos DB operational data replicated into Microsoft Fabric for analytical use with minimal custom ETL work. Which capability should you choose?

1. Integrated cache.
2. A JavaScript UDF.
3. TTL.
4. Azure Cosmos DB Mirroring for Microsoft Fabric.

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

Explanation: Cosmos DB Mirroring for Microsoft Fabric provides a managed integration that makes operational Cosmos DB data available to Fabric analytics scenarios without requiring developers to build and maintain conventional ETL pipelines for replication. This can simplify architectures where operational data needs to feed reporting or analytical workloads in Fabric. The Spark connector is another option when Spark-based processing or direct transactional-store access is required. Integrated cache, UDFs, and TTL address unrelated application concerns. Mirroring is particularly useful when managed analytical replication is preferred over custom data movement.

Q16. A Fabric Warehouse contains mirrored analytical data. An analyst needs to query how the warehouse looked at a previous point in time. Which capability should be used?

1. Point reads.
2. Manual failover.
3. Time travel in Fabric Warehouse.
4. Session consistency.

Correct Answer: 3. Time travel in Fabric Warehouse.

Explanation: Time travel in Microsoft Fabric Warehouse allows supported analytical queries to inspect historical states of warehouse data. This can help with auditing, debugging, historical comparison, or investigation of changes. It is different from Cosmos DB point-in-time restore, which is a database recovery feature. Point reads retrieve current Cosmos DB items, manual failover changes write-region roles, and session consistency governs transactional read behavior. Candidates should distinguish transactional recovery from analytical historical-query capabilities in the broader Cosmos DB and Fabric ecosystem.

Q17. You need to minimize the impact of repeated identical read operations against relatively stable data. Which Cosmos DB performance feature should you consider?

1. Multi-region writes.
2. Unique key policy.
3. Periodic backup.
4. Integrated cache.

Correct Answer: 4. Integrated cache.

Explanation: Integrated cache can reduce request-unit consumption and improve latency for eligible repeated reads by serving results from the dedicated gateway cache instead of repeatedly accessing the transactional backend. This works best when the application can tolerate configured cache staleness for the cached data. Multi-region writes improve global write availability, unique keys enforce integrity, and periodic backup handles recovery. Cache configuration should be aligned with freshness requirements because not every workload can accept potentially stale results.

Q18. You want to determine whether a production container has uneven storage distribution across partitions. Which information should you monitor?

1. Only the account’s consistency level.
2. Data distribution across partitions.
3. Only the number of Azure regions.
4. Backup frequency.

Correct Answer: 2. Data distribution across partitions.

Explanation: Monitoring data distribution across partitions helps identify whether partition-key values are evenly spreading stored items or causing a disproportionate concentration of data. Uneven storage can indicate that the partition key has insufficient cardinality or that a small set of values dominates the workload. Throughput distribution should also be monitored because storage can be balanced while request volume remains skewed. Consistency level, region count, and backup frequency do not directly indicate partition data skew. Production observations are valuable because real data distributions may differ from assumptions made during design.

Q19. A Cosmos DB account is experiencing elevated latency. Azure Monitor shows normal server-side latency, but application requests are much slower. What is the most likely area to investigate next?

1. Client-side or network latency and SDK diagnostics.
2. TTL expiration configuration only.
3. Unique key definitions only.
4. Backup retention.

Correct Answer: 1. Client-side or network latency and SDK diagnostics.

Explanation: If server-side latency is normal but end-to-end application latency is high, the delay likely occurs outside the Cosmos DB service processing path. Possible causes include network distance, DNS, connection setup, client resource exhaustion, inappropriate connectivity mode, retries, or application processing. SDK diagnostics can provide detailed timing information that helps isolate these factors. TTL, unique keys, and backup retention do not normally explain a large gap between server-side and application-observed latency. Comparing service metrics with client diagnostics is an important troubleshooting technique.

Q20. You need to recover a single container after an accidental deletion, and the account has continuous backup enabled. Which operation is appropriate?

1. Change the partition key and wait.
2. Disable indexing.
3. Restore the container from a point before the deletion.
4. Enable integrated cache.

Correct Answer: 3. Restore the container from a point before the deletion.

Explanation: Continuous backup supports point-in-time restore within the supported retention window. After an accidental container deletion, administrators should identify a restore point immediately before the unwanted operation and restore the affected resource according to the supported recovery workflow. Changing partition keys, disabling indexes, or enabling cache cannot recreate deleted data. Restore processes should be tested in advance, and restored data should be validated before applications are redirected. Backup and restore planning is essential for protecting against operational mistakes as well as application-level corruption.