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 single databases

  Why it's wrong here

  Each database in the single database deployment model receives its own dedicated compute and storage resources, whether measured in DTUs or vCores. Because those resources are reserved for that database alone, you must size each database for its unique peak workload, leaving idle capacity most of the time. With 50 small databases that have sporadic usage, this over-provisioning multiplies cost significantly, and there is no resource-sharing mechanism to absorb bursty traffic across databases.

• ✓

  Azure SQL Database elastic pool

  Why this is correct

  Azure SQL Database elastic pools distribute a shared pool of eDTUs or vCores across many databases, allowing each database to burst beyond its guaranteed minimum without a dedicated allocation. This statistical multiplexing is ideal for 50 small databases with variable, low average utilization because you pay only for the pooled resources actually needed, not the sum of individual peak demands. By configuring per-database min and max limits, you protect individual tenants while maximizing overall cost efficiency.

• ✗

  Azure SQL Managed Instance

  Why it's wrong here

  Azure SQL Managed Instance replicates a full SQL Server instance, allocating compute, storage, and memory to the instance itself, not to individual databases. You therefore pay for the complete instance capacity regardless of how few databases are active, and you cannot subdivide that capacity into elastic pools across separate managed instances. For 50 small databases that don't need instance-scoped features like SQL Agent, Service Broker, or cross-database queries, this is a costly over-provisioning choice with no resource-sharing benefit.

• ✗

  SQL Server on Azure Virtual Machines

  Why it's wrong here

  Hosting SQL Server on Azure VMs places all responsibility for SQL Server licensing, patching, backups, and high availability on your team, and you must reserve a VM sku large enough for the combined peak load of all 50 databases. Because there is no built-in database-level resource governance, a single busy database can degrade performance for all others, and you can't pool resources dynamically the way an elastic pool does. The resulting idle capacity, manual administrative effort, and lack of automated scaling make this an unnecessarily expensive and complex option for this scenario.