View Full Microsoft DP-420 Exam Dumps and Practice Test Dumps.
Q1. You have a write-heavy Azure Cosmos DB container. Only the /customerId and /createdAt properties are used in queries. Many other large properties are never queried. What should you consider to reduce write RU consumption?
- Add composite indexes for every property.
- Enable Strong consistency.
- Increase the number of unique keys.
- Exclude unnecessary property paths from the indexing policy.
Correct Answer: 4. Exclude unnecessary property paths from the indexing policy.
Explanation: Azure Cosmos DB automatically maintains indexes according to the container’s indexing policy. In a write-heavy workload, indexing properties that are never queried creates unnecessary index-maintenance work and can increase request-unit consumption. Excluding unused paths while keeping the properties required for filters, sorting, and other query patterns can improve write efficiency. Composite indexes should be added only when they support important query patterns. Strong consistency changes read guarantees rather than indexing overhead, and unique keys enforce data-integrity constraints. Indexing policies should always be designed around the actual balance of read and write operations.
Q2. A container has a default TTL of 3,600 seconds. One specific item must never expire. What should you configure on that item?
- Set the item’s TTL value so it overrides the default and prevents expiration.
- Remove the item’s id.
- Change the account consistency level.
- Add a unique key.
Correct Answer: 1. Set the item’s TTL value so it overrides the default and prevents expiration.
Explanation: Azure Cosmos DB allows an individual item to override the container’s default time-to-live behavior. This is useful when most items share a standard retention period but specific documents must persist longer or indefinitely. Item-level TTL provides lifecycle flexibility without requiring a separate container solely for exceptional records. The item’s ID must remain present because it is required for Cosmos DB items. Consistency levels affect read guarantees, and unique keys enforce uniqueness rather than retention. TTL is an efficient alternative to custom cleanup processes for temporary data and can be customized when individual document retention differs.
Q3. Some documents in a Cosmos DB container contain “middleName”: null, while others do not contain the middleName property at all. You need to distinguish between these two cases in a query. Which capability should you use?
- ORDER BY
- TTL
- Type and existence functions such as IS_NULL and IS_DEFINED.
- Transactional Batch
Correct Answer: 3. Type and existence functions such as IS_NULL and IS_DEFINED.
Explanation: In JSON, a property explicitly set to null is different from a property that is completely undefined. Cosmos DB SQL provides functions such as IS_NULL and IS_DEFINED that allow queries to distinguish between these states. This is particularly important in containers with flexible schemas, evolving document versions, or optional properties. ORDER BY changes result ordering, TTL manages expiration, and Transactional Batch performs atomic operations within a logical partition. Understanding the distinction between null and undefined values helps developers write more accurate queries against heterogeneous document structures.
Q4. A product document contains a tags array. You need to return products whose array contains the exact value “premium”. Which Cosmos DB SQL function is most appropriate?
- IS_NUMBER
- ARRAY_CONTAINS
- DateTimeDiff
- ABS
Correct Answer: 2. ARRAY_CONTAINS
Explanation: ARRAY_CONTAINS can test whether a Cosmos DB JSON array contains a specified value or, depending on usage, an object that matches the requested criteria. It is useful when array elements do not need to be flattened into separate result rows. A JOIN is more appropriate when you need to enumerate individual elements. IS_NUMBER checks value types, DateTimeDiff performs date calculations, and ABS is a mathematical function. Array-aware query functions allow applications to work naturally with denormalized JSON documents and reduce the need for application-side filtering after retrieving data.
Q5. Documents contain startTime and endTime values in supported ISO 8601 format. You need the difference between the two timestamps in minutes directly in a query. Which function should you use?
- ARRAY_LENGTH
- CONTAINS
- DateTimeDiff
- IS_OBJECT
Correct Answer: 3. DateTimeDiff
Explanation: Cosmos DB SQL provides date and time functions that support calculations on compatible date string values. DateTimeDiff can calculate the difference between two timestamps using a specified interval such as minutes, hours, or days. This can be useful for duration-based filtering or projections without moving all calculations into application code. ARRAY_LENGTH operates on arrays, CONTAINS searches text, and IS_OBJECT tests JSON types. Query-side date calculations should still be evaluated for cost and selectivity, particularly when they are applied across large numbers of items.
Q6. A document contains a numeric viewCount property. You need to increase the value by 1 without reading and replacing the full document. Which operation should you use?
- Delete the item and recreate it.
- Run a cross-partition query.
- Replace the complete document.
- Use a Patch increment operation.
Correct Answer: 4. Use a Patch increment operation.
Explanation: Azure Cosmos DB Patch operations support targeted modifications to document properties, including incrementing numeric values. Incrementing viewCount through Patch avoids reading and replacing the complete item when only one field changes. This can simplify application code and reduce network payload. A full replacement can still be appropriate when many fields change together, but it is unnecessary for a simple counter update. Cross-partition queries retrieve data rather than performing this targeted update. Patch is particularly valuable for status fields, counters, timestamps, and other small updates to otherwise large documents.
Q7. You are writing an SDK operation that creates an item and immediately needs to use information returned by Cosmos DB about the created resource. Which general SDK behavior should you rely on?
- Inspect the create operation’s response object and metadata.
- Delete and recreate the item to retrieve metadata.
- Use a backup restore.
- Query every partition after every create.
Correct Answer: 1. Inspect the create operation’s response object and metadata.
Explanation: Cosmos DB SDK operations return response information that can include the created resource and useful metadata such as request charge, status, and diagnostic details depending on the SDK and operation. Applications should use this response rather than issuing unnecessary follow-up queries solely to learn whether the create succeeded or how much it cost. Deleting and recreating an item is wasteful, while backup restore is unrelated. Cross-partition queries after each create would significantly increase latency and request-unit consumption. Understanding SDK response objects is important for efficient application code and observability.
Q8. Your application runs CPU-intensive work on the same threads that perform Cosmos DB asynchronous SDK calls. Throughput is lower than expected. What should you review?
- TTL settings.
- Client-side threading and parallelism behavior.
- Unique key policies.
- Backup mode.
Correct Answer: 2. Client-side threading and parallelism behavior.
Explanation: Cosmos DB performance depends not only on database configuration but also on how the client application schedules and executes work. Blocking or CPU-intensive processing on threads responsible for asynchronous database operations can reduce concurrency and overall throughput. Developers should review asynchronous programming patterns, client-side parallelism, thread-pool behavior, and whether the application is creating unnecessary bottlenecks. TTL, unique keys, and backup mode do not address client execution efficiency. SDK tuning should be combined with a long-lived client instance, appropriate connection mode, retry handling, and sufficient provisioned throughput.
Q9. You need to process changes from Cosmos DB but want the application framework to automatically balance work across multiple processor instances. What should you use?
- The change feed pull model only.
- A stored procedure.
- A SQL UDF.
- The change feed processor.
Correct Answer: 4. The change feed processor.
Explanation: The change feed processor provides a higher-level framework for consuming changes and automatically coordinating processing across multiple application instances. It uses lease information to distribute feed ranges, checkpoint progress, and rebalance work as processor instances are added or removed. The pull model gives developers more explicit control but requires more custom coordination. Stored procedures execute transactional server-side JavaScript, while UDFs are used in SQL queries. The change feed processor is usually the preferred choice when applications need scalable, managed distribution of change-feed work.
Q10. Your application uses a custom change feed processor and the lease container is unavailable. What capability is most directly affected?
- Coordination and checkpointing of change feed processing.
- Item TTL expiration.
- Composite-index creation.
- Global consistency configuration.
Correct Answer: 1. Coordination and checkpointing of change feed processing.
Explanation: The change feed processor relies on its lease container to track ownership of feed ranges, processor progress, and checkpoints. If the lease container is unavailable, processor instances cannot reliably coordinate work or persist their progress. This can interrupt scalable change processing even though the source container remains available. TTL, indexing, and account consistency do not depend on the lease container. The lease container should therefore be treated as an important operational dependency and provisioned with appropriate availability and throughput for the change feed workload.
Q11. Your workload contains a query that filters by two equality predicates and then sorts by a third property. You want to lower RU cost. What should you evaluate?
- Disabling all indexes.
- Increasing TTL.
- An appropriate composite index that matches the query pattern.
- Changing the backup mode.
Correct Answer: 3. An appropriate composite index that matches the query pattern.
Explanation: Composite indexes can improve queries that combine multiple predicates and ordering requirements. When a frequently executed query filters on multiple fields and orders by another, a composite index aligned with the property order and sort direction can reduce execution cost. Disabling indexes would generally make the situation worse, while TTL and backup mode have no effect on query planning. Because indexes add storage and write-maintenance overhead, they should be introduced for important repeated patterns and validated by comparing query metrics and request charges before and after the change.
Q12. You want to determine the exact RU cost of a point read during application testing. Where should you obtain the information?
- From the item’s partition-key string.
- From the SDK response request-charge metadata.
- From the TTL configuration.
- From the failover priority.
Correct Answer: 2. From the SDK response request-charge metadata.
Explanation: Cosmos DB SDK responses expose request-charge information that indicates how many request units were consumed by an operation. This applies to queries and point operations and is valuable when comparing designs or estimating capacity. The partition key influences routing efficiency, but the key string itself does not report RU cost. TTL and regional failover priorities serve unrelated purposes. Capturing request charges from representative application operations is one of the most practical ways to estimate throughput requirements and identify expensive access patterns before production deployment.
Q13. You need a data-processing workflow to archive documents to another service whenever records transition to a final state. You do not want the original write request to wait for the archive operation. Which pattern should you use?
- Process the change feed asynchronously and archive qualifying records.
- Perform the archive inside every point read.
- Disable indexing.
- Use integrated cache as permanent archive storage.
Correct Answer: 1. Process the change feed asynchronously and archive qualifying records.
Explanation: Change feed processing allows archival logic to run after source changes are committed, keeping the original transactional request focused and low latency. A processor can inspect changed documents, identify records that reached the final state, and copy them to the archive destination. The workflow should account for retries and idempotency so records are not archived incorrectly multiple times. Reads should not trigger archival behavior, and integrated cache is not durable archival storage. Asynchronous change-driven integration is a common Cosmos DB architecture pattern.
Q14. You need to ensure that a downstream reporting container reflects changes made to a source container, but temporary delays are acceptable. What consistency model does this architecture represent at the application level?
- Synchronous distributed transaction.
- Eventual consistency between the source and derived projection.
- Strong consistency across separate applications by default.
- NoSQL schema validation.
Correct Answer: 2. Eventual consistency between the source and derived projection.
Explanation: When a materialized projection is updated asynchronously from the change feed, there is a period after the source write during which the derived container may not yet contain the newest state. This is an application-level eventual-consistency pattern. It is common in scalable distributed systems because it separates transactional operations from downstream reporting or denormalization work. This architectural concept is distinct from the Cosmos DB account consistency level used for reads. Designers should make sure users and downstream systems understand the expected delay and that change processing is monitored for backlog.
Q15. You need to expose Cosmos DB data to Azure AI Search and keep the search index updated as source data changes. Which design is appropriate?
- Disable the Cosmos DB partition key.
- Use periodic backup as the search index.
- Use integrated cache as the search engine.
- Integrate Cosmos DB with Azure AI Search using a supported indexing approach.
Correct Answer: 4. Integrate Cosmos DB with Azure AI Search using a supported indexing approach.
Explanation: Azure AI Search provides specialized indexing and full-text search capabilities that complement Cosmos DB’s role as an operational database. A supported integration can populate and update a dedicated search index from Cosmos DB data. This enables capabilities such as search relevance and text-oriented lookup without forcing the transactional database to act as a full search engine. Partition keys, backup copies, and integrated cache do not replace a search index. The solution should account for update frequency, index schema, source changes, and acceptable synchronization delay.
Q16. You need a Spark pipeline that only analyzes Cosmos DB data and should avoid consuming transactional RU/s for large analytical scans. Which source should Spark use when available?
- The transactional store through point reads only.
- The analytical store.
- The account backup files.
- The lease container.
Correct Answer: 2. The analytical store.
Explanation: The analytical store provides a column-oriented representation designed for analytical workloads and helps separate large-scale analytics from the request-unit consumption of the transactional store. Spark-based analysis can use this representation when the architecture supports it, making it better suited for broad scans and analytical transformations. The transactional store remains the correct source when the workload requires operational reads and writes. Backup files and lease containers are not analytical sources. Choosing the correct store helps avoid unnecessary pressure on production transactional workloads.
Q17. An application must remain available for reads if its nearest Azure region fails. The Cosmos DB account already has multiple read regions. What else should the application configure?
- A suitable SDK region preference and failover behavior.
- TTL on every item.
- One constant partition key.
- A UDF for every query.
Correct Answer: 1. A suitable SDK region preference and failover behavior.
Explanation: Adding multiple Cosmos DB regions provides the service-side foundation for regional availability, but the application should also be configured to use those regions appropriately. SDK preferred-region settings help clients choose low-latency regions and fail over to another healthy replica when required. TTL, UDFs, and constant partition keys do not improve regional routing. Resilience testing should verify both account configuration and application behavior because a database may be regionally resilient while an application remains tied to one endpoint or deployment assumption.
Q18. Your organization requires the strongest possible read consistency so clients never observe stale committed data. Which level should you select if supported by the account’s regional configuration?
- Eventual.
- Strong.
- Consistent prefix.
- Session.
Correct Answer: 2. Strong.
Explanation: Strong consistency guarantees that reads return the most recent committed version of data, providing linearizable behavior from the application’s perspective. This is the strictest Cosmos DB consistency level and can have tradeoffs in latency, throughput, availability, and regional configuration. Session consistency is often sufficient for interactive applications, while eventual and consistent-prefix levels allow stale reads under defined semantics. Consistency should be chosen according to application correctness requirements rather than by automatically selecting the strongest level because stronger guarantees can affect performance and global distribution options.
Q19. Monitoring shows a container’s data is evenly distributed across partitions, but one partition still receives far more requests than the others. What does this indicate?
- A throughput-distribution hotspot caused by skewed access patterns.
- Backup corruption.
- A unique-key failure.
- TTL malfunction.
Correct Answer: 1. A throughput-distribution hotspot caused by skewed access patterns.
Explanation: Balanced data distribution does not guarantee balanced request distribution. If users disproportionately access one partition-key value, that partition can become hot even though storage is evenly spread. Monitoring both data distribution and throughput distribution is therefore essential. The solution may involve revisiting access patterns, partition-key design, caching, data duplication, or workload routing. Backup, unique keys, and TTL do not explain uneven request pressure. Production workloads should be monitored because actual traffic patterns can expose hotspots that were not obvious from data size alone.
Q20. You need to detect unusual spikes in HTTP 429 throttling and automatically notify an operations team. Which solution should you configure?
- A unique key.
- TTL.
- Azure Monitor metrics with an alert rule and action group.
- A stored procedure.
Correct Answer: 3. Azure Monitor metrics with an alert rule and action group.
Explanation: Azure Monitor can track Cosmos DB metrics related to throttling and other operational conditions. An alert rule can evaluate those metrics over a specified time window, and an action group can notify the operations team through supported channels or trigger automation. Unique keys enforce data integrity, TTL controls document expiration, and stored procedures execute server-side transactional logic. Proactive alerts are essential for identifying capacity issues, hot partitions, and unexpected traffic changes before sustained throttling significantly affects application performance.