AZ-305 Design data storage solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Elastic pools

  Why this is correct

  Elastic pools are ideal for managing multiple databases with unpredictable, variable usage because they let a set of databases share a single pool of eDTUs or vCores. Each database can burst up to its per-database maximum using resources released by idle databases, while you set a per-database minimum to guarantee performance. This pooling model significantly reduces cost compared to provisioning dedicated resources per database, and adding or removing databases is an automated, simple operation. It is precisely the right fit for a large fleet of small, spiky workloads.

• ✗

  Single databases with DTU-based tiers

  Why it's wrong here

  Deploying each database as a standalone database under the DTU-based purchasing model means every database is billed separately for a fixed service tier, and you must choose a tier large enough to handle its peak usage. Because you cannot share spare capacity across databases, most databases remain under-utilised while you pay for the capacity that rare spikes require, leading to substantial over-provisioning across 100 databases. The DTU model also offers only single-database resource guarantees, so it lacks the statistical multiplexing that would make the overall workload cost-effective. This approach is uneconomical for many small databases with intermittent bursts.

• ✗

  Managed Instance

  Why it's wrong here

  A managed instance is an isolated SQL Server engine hosted in Azure, and while it can host hundreds of databases, all of them share one fixed allocation of vCores and storage within that instance. There is no elastic pool for the contained databases—each database cannot dynamically borrow from a shared budget, and you must manually manage resource distribution. The instance is designed for lift-and-shift migrations needing near‑100% SQL Server compatibility, not for multi-tenant consolidation with variable loads. Because the entire instance's capacity is provisioned as a unit, you still pay for the whole instance even when many databases are idle, failing to deliver the per‑database elasticity required here.

• ✗

  Hyperscale single database

  Why it's wrong here

  Hyperscale is a service tier for a single database that separates compute and storage, allowing storage to automatically scale to many terabytes and adding read replicas for extreme throughput. While it excels at very large, high‑IO databases, it is vastly over‑provisioned for 100 small databases, and the per‑database cost is far higher than a pooled model. Hyperscale also uses the vCore purchasing model and does not support sharing resources across multiple databases, so it cannot handle variable loads in a cost‑effective, pooled way. This option addresses a completely different scale of problem and would dramatically inflate costs for this workload.

Go deeper

Related to this question