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

  Why this is correct

  Azure SQL Database is correct because its elastic pool model lets multiple databases share a fixed pool of eDTUs or vCores, so databases can burst above their individual allocation as long as the pool's total capacity is not exceeded. This supports cost optimization for varying workloads across separate databases while still delivering automated backups, point-in-time restore, and active geo-replication. As a fully managed service, Azure SQL Database handles patching, backups, and high availability without manual infrastructure management.

• ✗

  Azure SQL Managed Instance

  Why it's wrong here

  Azure SQL Managed Instance lacks the native resource pooling and multi-tenant scaling model required to optimise cost across varying workloads in separate databases; it provisions a fixed set of resources per instance rather than sharing a pool of resources that each database can draw from elastically. This option is tempting because it offers automated backups with point-in-time restore and geo-replication for disaster recovery, and it would be the correct choice if the company needed near‑full SQL Server compatibility with instance‑level features rather than a pooled, multi‑database architecture.

• ✗

  Azure Database for MySQL

  Why it's wrong here

  Azure Database for MySQL is fully managed and offers automated backups, point-in-time restore, and geo-redundant backup options, but it lacks the elastic pool abstraction that Azure SQL Database provides. Each MySQL server is provisioned with a fixed compute and storage tier, and all databases on that server contend for the same static resources; scaling requires resizing the entire server or moving to a higher tier, rather than dynamically sharing a pool of capacity. MySQL's own engine does not expose a native multi-database resource pool, so this option cannot meet the stated cost-sharing requirement.

• ✗

  Azure Database for PostgreSQL

  Why it's wrong here

  Azure Database for PostgreSQL (Flexible Server) is fully managed and includes automatic backups, point-in-time restore, and zone-redundant high availability, but it does not support elastic pools for sharing resources among multiple databases. Compute and storage are allocated at the server level, so you can only scale the whole server or add read replicas; you cannot carve a shared pool and let individual databases draw more capacity on demand. PostgreSQL also uses per-backend memory structures like shared_buffers and work_mem, which cannot be partitioned into a multi-tenant elastic pool at the PaaS layer, making this option unsuitable for the pooling requirement.

Go deeper

Related to this question