DP-900 Practice Question: Identify considerations for relational data on Azure
A company has a suite of 20 e-commerce applications, each with its own SQL Server database. The databases vary in size from 5 GB to 100 GB and have unpredictable usage patterns with bursty peaks. The company wants to migrate to Azure SQL Database to benefit from built-in high availability and automatic backups. They need to minimize costs by only paying for the resources each database actually uses, and they want to avoid over-provisioning for peak loads. Which Azure SQL Database deployment option should they choose?
⚠ Common exam trap
A common mix-up: candidates confuse the Serverless compute tier (which auto-pauses for cost savings on a single database) with the Elastic Pool (which shares resources across multiple databases), leading them to choose Serverless for cost minimization without recognizing the need for resource pooling across 20 databases.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Azure SQL Database Elastic Pool
Azure SQL Database Elastic Pool is the correct choice because it allows multiple databases to share a fixed pool of resources (DTUs or vCores), enabling cost efficiency by pooling and reallocating resources across databases with unpredictable, bursty usage patterns. This avoids over-provisioning for peak loads while still providing built-in high availability and automatic backups, as each database in the pool benefits from these features without needing individual resource reservations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Azure SQL Database Elastic Pool
Why this is correct
Azure SQL Database Elastic Pool is the correct choice because it lets all 20 databases share a single pool of eDTUs or vCores, with adjustable per-database minimum and maximum limits. This avoids over-provisioning each app separately and smooths out intermittent usage spikes across tenants. You pay only for the pooled resources actually allocated, not for 20 individually sized databases, which is exactly what unpredictable e-commerce workloads need.
- ✗
Azure SQL Database (single database) with Serverless compute tier
Why it's wrong here
Azure SQL Database (single database) with Serverless compute tier is wrong for this scenario because serverless applies to a single database that scales its compute up/down and can pause when idle, but each of the 20 apps would still need its own separate serverless database. There is no cross-database pooling or shared resource budget, so you can't offset one app's idle time against another's peak load. The per-database billing and lack of aggregate efficiency make it less cost-effective than an elastic pool for many variable workloads.
When this WOULD be correct
A company has a single e-commerce application with a database that experiences long periods of idle time and short, unpredictable bursts of activity. They want to minimize costs by paying only for compute used during active periods and automatically pausing during idle times.
- ✗
Azure SQL Managed Instance
Why it's wrong here
Azure SQL Managed Instance is not the answer because, while it offers near-100% SQL Server compatibility and each instance can host multiple databases, those databases share a fixed instance-level allocation of vCores and storage — not a dynamically pooled, per-database elastic budget. You would either cram all 20 apps into one managed instance (losing performance isolation and creating management risk) or create multiple instances, paying for each instance's full reserved capacity regardless of actual usage. Elastic pools, by contrast, are specifically designed to share and rebalance resources across many databases with varying, unpredictable demand.
When this WOULD be correct
A company needs to migrate multiple on-premises SQL Server databases to Azure with minimal application changes, requiring instance-scoped features like SQL Agent jobs, cross-database queries, and linked servers. They have a predictable workload and are willing to pay for a fixed set of resources rather than pooling databases.
- ✗
Azure SQL Database Hyperscale
Why it's wrong here
Azure SQL Database Hyperscale is incorrect because it is an architectural tier built for one extremely large database — often terabytes in size — that needs massive storage auto-scaling and quick backups via page servers. It does not pool compute resources across multiple independent databases; each Hyperscale database is its own resource silo. Deploying 20 e-commerce apps this way would require 20 Hyperscale instances with no shared resource benefit, driving up cost without improving elastic utilization.
When this WOULD be correct
A company has a single, very large database (e.g., over 4 TB) with high transaction throughput and requires rapid scaling for unpredictable workloads. They need built-in high availability and automatic backups, and cost is less of a concern than performance and scalability.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The DP-900 exam frequently reuses these exact scenarios with slightly different constraints.
✓Azure SQL Database Elastic PoolCorrect answer▾
Why this is correct
Azure SQL Database Elastic Pool is the correct choice because it lets all 20 databases share a single pool of eDTUs or vCores, with adjustable per-database minimum and maximum limits. This avoids over-provisioning each app separately and smooths out intermittent usage spikes across tenants. You pay only for the pooled resources actually allocated, not for 20 individually sized databases, which is exactly what unpredictable e-commerce workloads need.
✗Azure SQL Database (single database) with Serverless compute tierWrong answer — click to see why▾
Why this is wrong here
The Serverless compute tier is designed for a single database with intermittent usage, but the question involves 20 databases with bursty peaks. An Elastic Pool shares resources across databases, which is more cost-effective for multiple databases with varying peak times than provisioning each database individually with Serverless.
★ When this WOULD be the correct answer
A company has a single e-commerce application with a database that experiences long periods of idle time and short, unpredictable bursts of activity. They want to minimize costs by paying only for compute used during active periods and automatically pausing during idle times.
Why candidates choose this
Candidates may think Serverless is the best fit for unpredictable usage patterns because it automatically scales and pauses, but they overlook that the question involves multiple databases where resource pooling is more economical.
✗Azure SQL Managed InstanceWrong answer — click to see why▾
Why this is wrong here
Azure SQL Managed Instance is designed for lift-and-shift migrations requiring full SQL Server instance-level features (e.g., SQL Agent, cross-database queries) and does not offer the cost-sharing, per-database resource pooling that Elastic Pools provide. It would require over-provisioning for peak loads and does not minimize costs for 20 separate databases with bursty, unpredictable usage.
★ When this WOULD be the correct answer
A company needs to migrate multiple on-premises SQL Server databases to Azure with minimal application changes, requiring instance-scoped features like SQL Agent jobs, cross-database queries, and linked servers. They have a predictable workload and are willing to pay for a fixed set of resources rather than pooling databases.
Why candidates choose this
Candidates may confuse Managed Instance as a 'pooled' option because it supports multiple databases, but they overlook that it charges for the entire instance's resources (vCores and storage) rather than per-database usage, making it cost-inefficient for bursty, variable workloads across many databases.
✗Azure SQL Database HyperscaleWrong answer — click to see why▾
Why this is wrong here
Hyperscale is designed for very large databases (up to 100 TB) and high transaction throughput, not for managing multiple smaller databases with bursty, unpredictable usage patterns. It does not provide the cost-sharing benefits of an elastic pool, leading to over-provisioning and higher costs.
★ When this WOULD be the correct answer
A company has a single, very large database (e.g., over 4 TB) with high transaction throughput and requires rapid scaling for unpredictable workloads. They need built-in high availability and automatic backups, and cost is less of a concern than performance and scalability.
Why candidates choose this
Candidates may associate 'bursty peaks' with Hyperscale's rapid scaling capabilities, but overlook that Hyperscale is for individual large databases, not for pooling multiple smaller databases to share resources and minimize costs.
Analysis generated from the official DP-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
About these practice questions
This DP-900 question is part of Courseiva's 820-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-900 exam.