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.

• ✓

  Azure SQL Database elastic pool

  Why this is correct

  An Azure SQL Database elastic pool allocates a shared set of eDTUs or vCores across multiple databases, allowing each database to burst beyond its guaranteed minimum during demand spikes while keeping baseline usage low. You pay for the pool's aggregate compute and storage, not per-database sizing, which dramatically lowers cost when workloads have low average utilization but unpredictable peaks. Adding a new database to the pool requires no additional compute provisioning, and per-database settings like max/min eDTUs let you control resource sharing efficiently.

• ✗

  Azure SQL Database single database with reserved capacity

  Why it's wrong here

  With Azure SQL Database reserved capacity, you commit to a one- or three-year compute plan for a single database, but that database is still isolated and billed for its own DTUs or vCores. Each database must be provisioned for its individual peak, so intermittent spikes force you to overprovision per DB; the reservation discount only lowers the unit price, it does not let idle capacity in one database be used by another. As a result, many small databases end up with high aggregate provisioned throughput and wasted spend compared to a shared elastic pool.

• ✗

  Azure SQL Managed Instance

  Why it's wrong here

  Azure SQL Managed Instance is intended for lift-and-shift migrations that need near-complete SQL Server instance-level compatibility, but it runs on a dedicated set of vCores and storage that are billed as a single instance, not per database. This means all your small databases share a fixed resource allocation, and you pay for the compute and capacity of that instance even if each database only uses a tiny fraction of it. Unlike an elastic pool, there is no fine-grained per-database resource control, and adding a new database doesn't increase pool capacity cheaply; it simply uses more of the instance's already-provisioned resources.

• ✗

  SQL Server on Azure Virtual Machines

  Why it's wrong here

  Running SQL Server on Azure VMs places the entire database engine on a virtual machine where you must size the VM, manage SQL Server configuration, apply OS and SQL patches, and maintain high availability with manual or automated processes. Each VM has fixed vCPU and memory resources, so to support many small databases you either overprovision multiple VMs or manually hyper-converge them onto one instance with complex resource governance. There is no Azure-native elastic pooling or per-database scaling, and you pay continuous VM compute costs plus licensing (bring-your-own or included) regardless of how lightly the databases are used, making it far more expensive than an elastic pool.