AZ-305
Deep Dive
The central AZ-305 question on relational data: where does the workload fall on the IaaS → PaaS spectrum? SQL Server on a VM, SQL Managed Instance, or Azure SQL Database — and within SQL Database, which tier (General Purpose, Business Critical, Hyperscale) and which purchasing model.
Contents
This mirrors exactly the logic the exam uses — from IaaS down to the exact SQL Database tier.
🗄️Árbol de decisión — SQL en VM · MI · SQL Database
Del IaaS al tier exacto de SQL Database
Pregunta 1 de 6
¿El workload requiere acceso al sistema operativo, una versión exacta de SQL Server, o features sin soporte en PaaS (CLR sin restricciones, agentes de terceros)?
💡 Señal: "acceso al SO", "versión SQL Server 2014 específica", "software instalado en el servidor SQL"
| Option | Model | SQL Server compatibility | When to choose it |
|---|---|---|---|
| SQL Server on Azure VM | IaaS | 100% — it is SQL Server | You need OS-level access, the full SQL Agent, unrestricted CLR, a specific version, or features not supported in PaaS. You patch and back up (with helper extensions). |
| SQL Managed Instance | PaaS | ~99% — full instance: cross-DB queries, SQL Agent, Service Broker, CLR | Lift-and-shift of SQL Server with MINIMAL changes and no OS management. Deploys INSIDE your VNet. Link feature for hybrid DR. |
| Azure SQL Database | PaaS | Single database — no native cross-DB, no SQL Agent | New cloud-native apps, multi-tenant SaaS, maximum abstraction: automatic backups, HA, patching. |
Signals on the exam
"Cross-database queries", "SQL Agent jobs", "migrate the instance with minimal changes" → Managed Instance. "OS-level access", "exact SQL Server version" → SQL on VM. "Minimize administration", "new app" → SQL Database.
vCore (recommended)
DTU (legacy)
| Service tier (vCore) | Architecture | When |
|---|---|---|
| General Purpose | Compute separated from remote (premium) storage. HA via re-provisioning. SLA 99.99% | Default for most workloads — best price/performance |
| Business Critical | 4 replicas with local Always On, local SSD storage, 1 free read replica. SLA up to 99.995% (with zones) | Low IO latency, high transaction rate, maximum resilience, read scale-out included |
| Hyperscale | Storage distributed across page servers, up to 128 TB, near-instant backups/restores (snapshots), up to 4 HA replicas + named replicas | VERY large databases (>4 TB), unpredictable growth, fast restore, massive read scale-out |
Exam trap
"30 TB database" → only Hyperscale (GP and BC cap at 4 TB). "Restore in minutes regardless of size" → Hyperscale (snapshots). "Read replica at no extra cost" → Business Critical (includes 1 read-only replica).
Elastic Pool
Serverless (General Purpose)
Scaling reads
Scaling writes
| HA/DR mechanism | Scope | Failover | When |
|---|---|---|---|
| Built-in HA (all tiers) | Intra-region | Automatic (<30s) — transparent | Default. No extra configuration. Does not protect against a regional disaster |
| Active geo-replication | SQL Database — up to 4 secondaries in other regions | Manual — client initiates failover | Readable replicas in other regions; app-controlled failover. Not available on Managed Instance |
| Auto-failover groups | SQL Database or Managed Instance — group of DBs | Automatic or manual — single invariant endpoint | Transparent failover: the endpoint redirects with no connection-string change. The most common exam answer for multi-region HA |
Auto-failover groups — exam signal
"The application must keep working automatically if the primary region fails, without changing the connection string" → auto-failover group. The group exposes two invariant endpoints: .database.windows.net (primary) and -secondary.database.windows.net (secondary, read-only). After failover, the primary endpoint automatically points to the new region.
| Service | Design points |
|---|---|
| PostgreSQL Flexible Server | Optional zone-redundant HA (synchronous standby), read replicas, configurable maintenance window, stop/start to save cost. For apps that already run on Postgres. |
| MySQL Flexible Server | Same flexible model: zonal HA, read replicas, burstable tiers for dev/test. |
| Cosmos DB for PostgreSQL (Citus) | DISTRIBUTED Postgres, horizontally sharded natively — multi-tenant SaaS and real-time analytics at scale. |
| The scenario says... | Design with... |
|---|---|
| Migrate a SQL Server instance with SQL Agent and cross-DB queries, without managing the OS | SQL Managed Instance |
| App requires OS-level features or an exact SQL Server version | SQL Server on Azure VM |
| SaaS with 500 customer DBs peaking at different times | SQL Database in an Elastic Pool |
| Dev DB used only during working hours | SQL Database serverless with auto-pause |
| 40 TB OLTP workload needing fast restores | SQL Database Hyperscale |
| Minimal IO latency + included read replica | Business Critical |
| Reduce licensing cost (have SA) | vCore + Azure Hybrid Benefit + reserved capacity |
| Offload reports from the transactional DB | Read scale-out (ApplicationIntent=ReadOnly) |
| Automatic multi-region failover without changing the connection string | Auto-failover group (SQL Database or MI) |
| Read replicas across multiple regions, manual failover | Active geo-replication (SQL Database) |
| Existing app on PostgreSQL with zonal HA | PostgreSQL Flexible Server zone-redundant |
Did you get this topic?
Test what you just learned
A company migrates to Azure an application with 3 SQL Server databases that depend on cross-database queries and SQL Server Agent jobs. They want to eliminate operating system and patch management, with minimal changes to the application. What do you recommend?
Put what you learned to the test with original AZ-305 exam questions.
Start AZ-305 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.