Study Azure AZ-305 Relational Data: key concepts, common traps, and exam decision cues.
Relational-data questions on AZ-305 are not asking whether SQL exists in Azure. They are asking how much compatibility, control, scale, and operational simplicity the workload needs. The best answer is usually the least operationally heavy managed option that still satisfies the requirement.
| Requirement | Strongest first fit | Why |
|---|---|---|
| managed relational OLTP with minimal ops | Azure SQL Database | simplest strong default for many app workloads |
| near-full SQL Server instance compatibility | SQL Managed Instance | stronger lift-and-modernize fit |
| OS-level or full SQL Server control | SQL Server on Azure VMs | use only when lower-level control is truly required |
| managed PostgreSQL or MySQL pattern | Azure Database for PostgreSQL or MySQL | managed open-source relational path |
The exam often turns on whether the workload genuinely needs:
If those first two are not explicit requirements, the stronger answer is usually not the VM-heavy option.
| Design concern | Strongest first reasoning move |
|---|---|
| relational scaling | decide whether the app needs service-tier scale, compute changes, or instance-level compatibility first |
| data protection | classify backup, geo-protection, and low-downtime continuity separately |
| cost control | avoid overbuying compatibility you do not need |
| Trap | Better rule |
|---|---|
| choosing SQL on VMs because it feels most flexible | flexibility is not free; use it only when control requirements justify the ops burden |
| choosing Managed Instance for every SQL workload | it is for stronger compatibility needs, not all managed SQL scenarios |
| treating protection and scaling as the same question | durability, backup, HA, and scale are related but distinct design decisions |