What the DP-420 exam covers
- Design and implement data models223 questions
- Design and implement data distribution53 questions
- Integrate an Azure Cosmos DB solution54 questions
- Optimize an Azure Cosmos DB solution117 questions
- Maintain an Azure Cosmos DB solution178 questions
Free DP-420 practice test questions
A sample of 10 questions with answers and explanations. Sign up free to practice all 625.
-
A container stores telemetry keyed on deviceId. One device produces far more readings than the rest, and writes to it are throttled while the account is far below its provisioned total. What does this indicate?
- AThat device's logical partition has become hot and is capped at its own share of throughputCorrect
- BThe account's total provisioned throughput is exhausted by the write volume
- CThe container is missing an index on deviceId, so writes are scanning
- DThe item size for that device exceeds the per-document limit for writes
✓ Correct answer: AProvisioned RU/s are spread evenly across physical partitions, and every logical partition lives entirely inside one of them. A key that attracts a disproportionate share of traffic therefore competes for only that partition's slice rather than the account total, and once it exceeds it the requests are rejected with 429 even though the account as a whole is barely used. A single logical partition is also capped at 10,000 RU/s and 20 GB regardless of what the container is provisioned. The fix is a partition key that spreads traffic more evenly, such as a synthetic key combining deviceId with a time bucket, or a hierarchical key.
Why the other options are wrong- BThe account total is not exhausted; the question states the account is far below its provisioned throughput, which is what makes this a per-partition problem.
- CA missing index does not throttle writes - indexing affects query cost, and writes are indexed automatically under the default policy.
- DItem size is limited to 2 MB, and exceeding it produces a specific error rather than the throttling described here.
-
A single-page application calls the account directly from the browser and every request fails a preflight check. Which account setting resolves this?
- AConfigure allowed origins in the account's CORS settingsCorrect
- BAdd the browser's public address to the account's IP firewall
- CEnable a private endpoint so the origin is treated as trusted
- DGrant the signed-in user a control plane reader role assignment
✓ Correct answer: AA browser sends an OPTIONS preflight before a cross-origin request and refuses to proceed unless the response permits that origin. Cosmos DB has an account-level CORS configuration listing allowed origins for exactly this case, and until the application's origin appears there the browser blocks the call regardless of credentials. It is a browser concern only - server-side callers never send a preflight - so this is specific to the JavaScript SDK running in a page. It also does not authorise anything: the request still needs a valid credential once the browser permits it.
Why the other options are wrong- BAn IP firewall rule controls which addresses may reach the account; it does not satisfy the browser's cross-origin check.
- CA private endpoint gives the account a private address inside a virtual network and has no bearing on browser preflight behaviour.
- DA control plane role assignment governs management operations on the resource and does not affect cross-origin handling.
-
A Spark job reads the analytical store, computes a result, and must make that result available to the application. What is the supported path?
- AWrite the result back to the transactional store through the connectorCorrect
- BWrite it into the analytical store, which the application then reads
- CUpdate the analytical store in place, which propagates transactionally
- DExpose the Spark table directly, which the SDK can query as a container
✓ Correct answer: AThe analytical store is maintained by the service from the transactional store, and the flow is one-way: nothing written into it would reach the application, and it cannot be updated directly. A Spark job that has computed something the application needs writes it back to the transactional store through the connector, which performs ordinary item writes and therefore consumes provisioned request units like any other client. That is the point to plan for - the read side of the job is free of RU, the write-back is not, so throughput is sized for it.
Why the other options are wrong- BThe analytical store cannot be written to directly, and the application reads the transactional store rather than the analytical one.
- CNo in-place update of the analytical store exists, and nothing propagates from it back to the transactional store.
- DThe SDK queries containers rather than Spark tables; a Spark table is not addressable as a container.
-
A cost review finds an account provisioned at 100,000 RU/s using around 8,000 at peak. What should be examined before simply lowering it?
- AWhether a hot partition forced the over-provisioning to relieve throttlingCorrect
- BWhether the account's consistency level requires the higher provisioning
- CWhether storage volume mandates a proportional throughput floor
- DWhether the number of regions requires throughput to be multiplied
✓ Correct answer: AA figure an order of magnitude above measured consumption is rarely arbitrary; it is usually the residue of relieving throttling that a skewed partition key caused, since raising the container total is the only way to raise a hot partition's share. Lowering it without addressing the skew brings the throttling straight back. The check is the per-partition data - Normalized RU Consumption and the per-key log categories - to see whether consumption is even. If it is, the provisioning is genuinely excessive and can be reduced, ideally onto autoscale.
Why the other options are wrong- BConsistency level affects the request charge of individual reads rather than requiring a particular provisioned level.
- CStorage volume drives a minimum throughput only at very large scales and does not explain a twelve-fold gap here.
- DRegion count multiplies the billed total but does not require the per-region figure to be higher than the workload needs.
-
A query must return the first three elements of a tags array on each document. Which construct does that?
- AARRAY_SLICE over the property with a start and a countCorrect
- BTOP applied inside the projection to the array expression
- COFFSET and LIMIT within the SELECT clause for that property
- DA JOIN over the array with TOP applied to the flattened rows
✓ Correct answer: ATOP, OFFSET and LIMIT operate on the rows a query returns, so they cannot bound how many elements an array within each row contains. ARRAY_SLICE is the array function for that, taking the array, a starting index and optionally a count, and returning the requested portion in the projection. A JOIN with TOP would limit the total flattened rows across the whole result set rather than taking three per document, which is a different and usually unintended answer.
Why the other options are wrong- BTOP limits the rows the query returns and cannot be applied to an array expression inside a projection.
- COFFSET and LIMIT page the result set as a whole rather than trimming an array within each document.
- DA JOIN with TOP bounds the total flattened rows across all documents rather than taking three from each.
-
An alert must fire when a specific container, rather than the account, begins throttling. How is that scoped?
- ASplit or filter the metric by the database and collection dimensionsCorrect
- BCreate a separate account per container so alerts are naturally scoped
- CUse diagnostic logs, since metrics cannot be filtered below account level
- DAlert on the account and correlate manually with container activity
✓ Correct answer: ACosmos DB metrics are published with dimensions including the database name and collection name, so an alert rule can be filtered to one container and will evaluate only that container's values. That is what makes per-container alerting straightforward without restructuring anything. Splitting the same metric by those dimensions on a chart is also how a noisy account is attributed to the container responsible, which is usually the first step when an account-level alert fires.
Why the other options are wrong- BRestructuring into separate accounts to gain alert scoping is unnecessary when the metric is already dimensioned.
- CMetrics can be filtered by database and collection dimensions, so logs are not required for container-level alerting.
- DManual correlation is unnecessary when the metric supports filtering directly to the container.
-
A container stores chat messages keyed on conversation identifier. Busy conversations run for years. What should the design add?
- AA time component in the key, so a conversation spans several partitionsCorrect
- BA composite index on conversation and timestamp to bound partition size
- CA lower default TTL, which prevents the partition from growing
- DMore provisioned throughput, which raises the partition's storage limit
✓ Correct answer: AKeying on the conversation makes reads efficient, and it also means every message for a long-running conversation accumulates in one logical partition against the 20 GB ceiling. Adding a period - a month or a quarter - as a second level of a hierarchical key subdivides it while preserving prefix routing, so a query for one conversation is still confined to the partitions holding that prefix. Retention is a complementary answer where old messages genuinely expire, but a key that cannot grow unboundedly is the structural fix.
Why the other options are wrong- BAn index accelerates queries and has no bearing on how much data accumulates under one partition key value.
- CA TTL removes old messages but is a retention policy rather than a fix for a key that cannot bound its partition.
- DThroughput governs request rate; the per-logical-partition storage ceiling is unaffected by it.
-
An item's most common access is by a natural business key rather than a generated identifier. What follows from that?
- AStore the business key as the id, so the common access is a point readCorrect
- BAdd a secondary index on the business key, since id cannot be assigned
- CQuery on the business key, since only generated identifiers may be ids
- DStore the business key in the partition key so it can be looked up directly
✓ Correct answer: AThe id property is written by the application and only needs to be unique within a logical partition, so a business key that is already unique there can serve as the id directly. That turns the dominant access from a query costing at least a few request units into a point read costing one, and removes the indirection of looking a key up to find an identifier. The constraint is that an id cannot be changed afterwards, so the key must genuinely be stable.
Why the other options are wrong- BA secondary index is unnecessary here, and the premise is wrong because the id can be assigned by the application.
- CGenerated identifiers are a convention rather than a rule; any unique string may be used as an id.
- DThe partition key determines distribution, and placing the business key there does not by itself make a lookup a point read.
-
A write is made by a web tier and a subsequent read is issued by a separate worker process, and the read must see the write. What makes that work under Session consistency?
- APass the session token from the writer to the reader and supply it on the readCorrect
- BConfigure both processes with the same preferred region, which shares the session
- CUse the same account key in both processes, which associates their sessions
- DNothing further, since Session consistency is guaranteed across all clients
✓ Correct answer: ASession consistency guarantees read-your-writes within a session, and the session is represented by a token that each client instance maintains for itself. A different process has its own token and no knowledge of the write, so it can read a replica that has not received it. Capturing the token from the write response, passing it alongside the work item, and supplying it on the read extends the guarantee across the boundary.
Why the other options are wrong- BA shared preferred region affects routing rather than making two processes share a session.
- CThe account key is a credential and has no bearing on which session a client belongs to.
- DThe guarantee holds within a session rather than across every client of the account.
-
A document embeds an object that another part of the application also needs to update independently. What does that argue?
- ASeparate it, since embedded content cannot be written without rewriting the parentCorrect
- BKeep it embedded, since a patch can update an embedded path independently
- CKeep it embedded and rely on ETags to prevent the two writers colliding
- DSeparate it into a different container so the two writers never contend
✓ Correct answer: AEmbedded content belongs to its parent document, so writing it means writing the parent - two independent writers therefore contend on the same item, each paying for the whole document and each able to overwrite the other's work. A patch narrows the cost and an ETag detects the collision, but neither removes the contention. Separate documents sharing a partition key keep them independently writable and still readable together.
Why the other options are wrong- BA patch reduces the charge but the writers still contend on the same document.
- CAn ETag detects a collision rather than removing the contention that produces it.
- DA different container gives up the shared partition key, so the two can no longer be read or written together atomically.
Who this DP-420 practice exam is for
This practice set is for anyone preparing for the DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB exam - from first-time candidates building a foundation to experienced Microsoft practitioners doing a final review before test day. If you learn best by working through realistic questions and reading why each answer is right or wrong, it is built for you.
How to use this DP-420 practice exam
- Start with the free sample questions above to gauge your current baseline.
- Read the full explanation on every question, including why each wrong option is wrong.
- Track your weak domains and focus your study where you are losing the most marks.
- Once you are scoring consistently well, take a timed, full-length mock exam.
- Use your readiness score to decide when you are ready to book the real DP-420 exam.
Related Microsoft resources
- Microsoft practice examsAll Microsoft
- Certification pathWhere this fits
- Certification exam guides & tipsBlog
- Plans & pricingFree & paid
- How these questions are written and reviewedMethodology
- Report a problem with a questionCorrections
- DP-600 practice examRelated
- DP-700 practice examRelated
- DP-750 practice examRelated
DP-420 practice exam FAQ
How many questions are in the DP-420 practice exam on CertGrid?
CertGrid has 625 practice questions for DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB, covering 5 exam domains. The real DP-420 exam is 40-60 qs in 100 min. CertGrid's timed mock is a fixed 50 questions.
What is the passing score for DP-420?
The DP-420 exam passing score is 700 / 1000, and you have about 100 min to complete it. CertGrid scores your practice attempts the same way so you know when you are ready.
Are these official DP-420 exam questions?
No. CertGrid is an independent practice platform. We do not provide real or leaked exam questions. Our questions are original and designed to help you practice the concepts, scenarios, and difficulty style of the DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB exam.
Is there a free DP-420 practice test?
Yes. You can take a free DP-420: Designing and Implementing Cloud-Native Applications Using Microsoft Azure Cosmos DB practice test straight away: a fixed set of 20 practice questions for this exam, retryable as often as you like, with no credit card required. You get readiness scoring and a weak-domain breakdown on those questions. Paid plans unlock the full 625-question bank, timed mock exams and full-bank domain analytics.
What CertGrid is (and is not)
CertGrid is an independent IT certification practice platform for Azure, AWS, Google, Cisco, Security, Linux, Kubernetes, Terraform, and other certification tracks. It provides objective-mapped practice questions, readiness scoring, weak-domain drills, and explanations to help learners understand what to study next.
Independent & original. CertGrid is an independent practice platform and is not affiliated with or endorsed by Microsoft. Questions are original practice items designed to mirror certification concepts and exam style. CertGrid does not provide official exam questions or braindumps.