La pregunta central del AZ-305 en datos relacionales: ¿dónde cae el workload en el espectro IaaS → PaaS? SQL Server en VM, SQL Managed Instance o Azure SQL Database — y dentro de SQL Database, qué tier (General Purpose, Business Critical, Hyperscale) y qué modelo de compra.
Contenido
Cada pregunta refleja exactamente la lógica que usa el examen — desde IaaS hasta el tier exacto de SQL Database.
🗄️Á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"
| Opción | Modelo | Compatibilidad SQL Server | Cuándo elegirla |
|---|---|---|---|
| SQL Server en Azure VM | IaaS | 100% — es SQL Server | Necesitas acceso al SO, SQL Agent completo, CLR sin restricciones, versión específica, o features no soportadas en PaaS. Tú parcheas y haces backups (con extensiones de ayuda). |
| SQL Managed Instance | PaaS | ~99% — instancia completa: cross-DB queries, SQL Agent, Service Broker, CLR | Lift-and-shift de SQL Server con MÍNIMOS cambios sin gestionar SO. Se despliega EN tu VNet. Link feature para DR híbrido. |
| Azure SQL Database | PaaS | Base de datos individual — sin cross-DB nativo, sin SQL Agent | Apps nuevas cloud-native, SaaS multi-tenant, máxima abstracción: backups, HA, parches automáticos. |
Señales en el examen
"Cross-database queries", "SQL Agent jobs", "migrar la instancia con cambios mínimos" → Managed Instance. "Acceso al sistema operativo", "versión exacta de SQL Server" → SQL en VM. "Minimizar administración", "app nueva" → SQL Database.
vCore (recomendado)
DTU (legacy)
| Service tier (vCore) | Arquitectura | Cuándo |
|---|---|---|
| General Purpose | Compute separado de storage remoto (premium). HA por re-aprovisionamiento. SLA 99.99% | Default para la mayoría de workloads — mejor precio/rendimiento |
| Business Critical | 4 réplicas con Always On local, storage SSD local, 1 réplica de lectura gratis. SLA hasta 99.995% (con zonas) | Baja latencia de IO, alta tasa de transacciones, resiliencia máxima, read scale-out incluido |
| Hyperscale | Storage distribuido en page servers, hasta 128 TB, backups/restores casi instantáneos (snapshots), hasta 4 réplicas HA + named replicas | Bases de datos MUY grandes (>4 TB), crecimiento impredecible, restore rápido, read scale-out masivo |
Trampa de examen
"Base de datos de 30 TB" → solo Hyperscale (GP y BC topan en 4 TB). "Restore en minutos sin importar el tamaño" → Hyperscale (snapshots). "Réplica de lectura sin costo adicional" → Business Critical (incluye 1 réplica read-only).
Elastic Pool
Serverless (General Purpose)
Escalar lecturas
Escalar escrituras
| Mecanismo HA/DR | Scope | Failover | Cuándo |
|---|---|---|---|
| HA integrada (todos los tiers) | Intra-región | Automático (<30s) — transparente | Default. Sin configuración adicional. No protege contra desastre regional |
| Active geo-replication | SQL Database — hasta 4 secundarias en otras regiones | Manual — cliente inicia failover | Réplicas legibles en otras regiones; failover controlado por la app. No disponible en Managed Instance |
| Auto-failover groups | SQL Database o Managed Instance — grupo de DBs | Automático o manual — endpoint único invariante | Failover transparente: el endpoint se redirige sin cambiar connection string. La opción más común en el examen para HA multi-región |
Auto-failover groups — señal de examen
"La aplicación debe continuar funcionando automáticamente si la región primaria falla, sin cambiar la connection string" → auto-failover group. El grupo expone dos endpoints invariantes: .database.windows.net (primario) y -secondary.database.windows.net (secundario, solo lectura). Tras el failover, el endpoint primario apunta a la nueva región automáticamente.
| Servicio | Puntos de diseño |
|---|---|
| PostgreSQL Flexible Server | HA zone-redundant opcional (standby síncrono), read replicas, ventana de mantenimiento controlable, parar/arrancar para ahorrar. Para apps que ya usan Postgres. |
| MySQL Flexible Server | Mismo modelo flexible: HA zonal, réplicas de lectura, burstable tiers para dev/test. |
| Cosmos DB for PostgreSQL (Citus) | Postgres DISTRIBUIDO horizontalmente (sharding nativo) — multi-tenant SaaS y analítica en tiempo real a escala. |
| El escenario dice... | Diseña con... |
|---|---|
| Migrar instancia SQL Server con SQL Agent y cross-DB queries, sin gestionar SO | SQL Managed Instance |
| App requiere features de SO o versión exacta de SQL Server | SQL Server en Azure VM |
| SaaS con 500 DBs de clientes con picos en horarios distintos | SQL Database en Elastic Pool |
| DB de dev que solo se usa en horario laboral | SQL Database serverless con auto-pause |
| OLTP de 40 TB con restores rápidos | SQL Database Hyperscale |
| Latencia de IO mínima + réplica de lectura incluida | Business Critical |
| Reducir costo de licencias (tienen SA) | vCore + Azure Hybrid Benefit + reserved capacity |
| Descargar reportes de la DB transaccional | Read scale-out (ApplicationIntent=ReadOnly) |
| Failover automático multi-región sin cambiar connection string | Auto-failover group (SQL Database o MI) |
| Réplicas de lectura en múltiples regiones, failover manual | Active geo-replication (SQL Database) |
| App existente sobre PostgreSQL con HA zonal | PostgreSQL Flexible Server zone-redundant |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa migra a Azure una aplicación con 3 bases de datos SQL Server que dependen de cross-database queries y jobs de SQL Server Agent. Quieren eliminar la gestión de sistema operativo y parches, con los mínimos cambios en la aplicación. ¿Qué recomiendas?
Inicia sesión para llevar tu progreso.