El dominio de bases de datos del AZ-305 exige juicio basado en escenarios, no memorización. Azure SQL Database, SQL Managed Instance, Cosmos DB, PostgreSQL Flexible Server y Synapse Analytics tienen condiciones distintas en las que cada uno es la elección correcta — y el examen evalúa exactamente esas fronteras. Aquí desglosamos los criterios de selección clave a través de patrones encontrados en 36 preguntas reales de examen.
---
Elegir entre Azure SQL Database y Managed Instance
Los servicios de bases de datos relacionales de Azure se presentan en tres variantes: Azure SQL Database, SQL Managed Instance y SQL Server on Azure VM. Los tres están construidos sobre el motor SQL Server, pero difieren significativamente en cobertura de funciones y sobrecarga operativa.
Azure SQL Database es una oferta PaaS completamente administrada. En el nivel Serverless, el vCore escala hacia arriba y hacia abajo automáticamente, y la base de datos se pausa tras un período de inactividad, eliminando los costos de cómputo durante ese tiempo. Esto la hace ideal para cargas de trabajo intermitentes.
SQL Managed Instance proporciona una compatibilidad cercana al 100% con SQL Server. Las funciones a nivel de instancia que Azure SQL Database no soporta — SQL Server Agent, procedimientos almacenados CLR, consultas entre bases de datos y transacciones distribuidas (MSDTC) — están disponibles sin cambios de código, lo que la convierte en la primera opción para migraciones lift-and-shift.
Las diferencias entre niveles dentro de Azure SQL Database también importan. Solo el nivel General Purpose soporta Serverless, mientras que Business Critical ofrece I/O por debajo de 1ms usando SSDs locales. Hyperscale permite escalar cómputo y almacenamiento de manera independiente hasta 100 TB, lo que lo hace adecuado para cargas de trabajo OLTP a gran escala en decenas de terabytes y más.
Elastic Pool permite que múltiples bases de datos compartan un pool de vCore, reduciendo costos hasta un 50% en escenarios SaaS multi-tenant, al tiempo que garantiza aislamiento mediante límites mínimos y máximos por base de datos. El modelo de compra vCore es el único que soporta Azure Hybrid Benefit (hasta un 55% de ahorro) y Long-Term Retention (LTR, hasta 10 años de retención de respaldos).
!Azure SQL Database vs Managed Instance
Cosmos DB y NoSQL distribuido globalmente
Azure Cosmos DB es una base de datos NoSQL completamente administrada que garantiza latencia de un solo dígito en milisegundos en cualquier región del mundo. Dos palabras clave acompañan cada escenario de Cosmos DB en el examen: escrituras simultáneas en múltiples regiones y SLA de respuesta en milisegundos.
Con escrituras en múltiples regiones habilitadas, cada región tiene un punto de conexión de escritura independiente, por lo que las escrituras continúan incluso si alguna región falla (Active-active). En contraste, Azure SQL Database Active Geo-Replication mantiene las réplicas secundarias como solo lectura, lo que significa que no puede soportar escrituras en múltiples regiones.
El modo Provisioned Throughput preasigna el rendimiento en RU/s y garantiza contractualmente una latencia de lectura P99 de 10ms y de escritura de 15ms. Esta es la única opción cuando se necesita demostrar los SLA de latencia en documentación durante auditorías regulatorias.
Elige la API según tu modelo de datos. Los documentos JSON con consultas SQL requieren la API NoSQL (Core SQL); la compatibilidad con el driver de MongoDB implica la MongoDB API; el SQL distribuido sobre PostgreSQL usa la PostgreSQL API (basada en Citus); y la traversal de relaciones nodo/arista usa la Gremlin API. Para traversals de múltiples saltos como “amigos de amigos,” la Gremlin API es la respuesta correcta.
Synapse Link for Cosmos DB sincroniza automáticamente los datos de Cosmos DB a un almacén analítico orientado a columnas sin ETL, permitiendo el análisis en Synapse Analytics sin impacto en el rendimiento operativo.
---
PostgreSQL y MySQL Flexible Server
Azure Database for PostgreSQL Flexible Server y Azure Database for MySQL Flexible Server son versiones completamente administradas de sus respectivas bases de datos relacionales de código abierto. Las preguntas del examen AZ-305 en esta área se centran principalmente en configuraciones de alta disponibilidad y opciones de recuperación ante desastres.
Existen tres niveles de cómputo: Burstable, General Purpose y Business Critical. La alta disponibilidad con redundancia de zona solo se soporta en el nivel General Purpose y superiores. El nivel Burstable tiene el costo más bajo, pero como no soporta HA con Zone-redundant, debes elegir General Purpose o superior cuando el requisito indica que el servicio debe sobrevivir a un fallo de un solo centro de datos.
También es importante distinguir entre las opciones de recuperación ante desastres regionales. Zone-redundant HA proporciona redundancia entre zonas de disponibilidad dentro de la misma región, protegiéndose contra fallos a nivel de centro de datos. Geo-redundant Backup replica automáticamente los respaldos a otra región de Azure, permitiendo la recuperación cuando una región completa deja de funcionar. Si un RTO de pocas horas es aceptable y la recuperación manual es factible, el respaldo georredundante por sí solo puede cumplir los requisitos de recuperación ante desastres regionales de forma rentable, sin necesidad de Zone-redundant HA.
También recuerda que las réplicas de lectura implementadas en la misma región no pueden servir para recuperación ante desastres regional. Si el DR regional es el objetivo, las réplicas deben implementarse en una región diferente, o se debe usar el respaldo georredundante.
---
Cargas de trabajo analíticas: Synapse y almacenamiento de datos
Azure Synapse Analytics ofrece un almacén de datos (Dedicated SQL Pool), procesamiento de big data basado en Apache Spark e integración con Azure Data Lake Storage en una sola plataforma. Si necesitas transformar decenas de terabytes de datos de investigación con Spark y analizar datos estructurados y no estructurados juntos, Synapse Studio te da una única superficie de gestión.
Dedicated SQL Pool usa una arquitectura MPP para soportar almacenes de datos a escala de petabytes. La decisión entre Synapse y Databricks es sencilla: elige Synapse Analytics cuando necesites gestión unificada de SQL DW + Spark + Data Lake; elige Databricks cuando te enfoques en machine learning avanzado centrado en Spark.
---
Tabla comparativa de servicios
| Servicio | Caso de uso principal | Escalado | Latencia | Modelo de costos | |----------|-----------------------|----------|----------|------------------| | Azure SQL Database (Serverless) | Cargas intermitentes o impredecibles | vCore escala automáticamente 0.5–80 | Nivel general | Facturación por segundo; sin cargo de cómputo en inactividad | | Azure SQL Database (Hyperscale) | OLTP a gran escala 10+ TB | Cómputo y almacenamiento escalan independientemente hasta 100 TB | Nivel general | Arquitectura de servidor de páginas de almacenamiento | | SQL Managed Instance | Compatibilidad total con SQL Server para lift-and-shift | Escalado vertical a nivel de instancia | Sub-1ms en nivel Business Critical | Facturación por hora de instancia | | Cosmos DB (Provisioned) | Escrituras en múltiples regiones, SLA en ms, NoSQL | Escalado horizontal en RU/s | P99 por debajo de 10ms | RU/s preasignados | | PostgreSQL Flexible Server | Relacional de código abierto con Zone-redundant HA | Escalado vertical | RDBMS estándar | Facturación por hora según nivel | | Synapse Analytics | SQL DW + Spark + Data Lake unificados | Escalado horizontal en DWU | Procesamiento analítico por lotes | Facturación por hora de DWU |
---
Criterios de selección que confunden frecuentemente a los candidatos
La clave de las preguntas del examen es mapear los términos clave con precisión a los servicios. Aquí están los patrones más frecuentes organizados por escenario.
Escenario de migración de base de datos relacional
Escenario: Estás migrando un SQL Server on-premises y debes conservar SQL Agent, procedimientos almacenados CLR y consultas entre bases de datos exactamente como están.
La respuesta es SQL Managed Instance. Azure SQL Database no soporta estas funciones a nivel de instancia. SQL Server on Azure VM ofrece compatibilidad perfecta de funciones, pero como solución IaaS requiere que administres los parches del sistema operativo y los respaldos tú mismo, añadiendo una sobrecarga operativa significativa. Cuando necesitas gestión PaaS combinada con plena compatibilidad con SQL Server, SQL Managed Instance es la respuesta.
Escenario de reducción de costos
Escenario: Quieres reutilizar licencias de SQL Server existentes (con Software Assurance) en Azure, o necesitas retener respaldos por siete o más años.
Ambas condiciones requieren el modelo vCore. Azure Hybrid Benefit y Long-Term Retention (LTR) solo están disponibles bajo el modelo de compra vCore. Ninguna de las dos funciones está disponible con el modelo DTU.
Decisión Cosmos DB vs SQL Database
Escenario: Los datos deben escribirse simultáneamente desde múltiples regiones en todo el mundo, con tiempos de respuesta en milisegundos garantizados.
La respuesta es Cosmos DB con escrituras en múltiples regiones habilitadas. Azure SQL Database Active Geo-Replication mantiene las réplicas secundarias como solo lectura y no puede soportar escrituras en múltiples regiones.
Escenario: Necesitas SLAs garantizados contractualmente para la latencia de escritura y el rendimiento, con documentación que pueda presentarse durante auditorías regulatorias.
De nuevo, la respuesta es Cosmos DB Provisioned Throughput. Azure documenta oficialmente SLAs de cuatro dimensiones — disponibilidad, latencia de lectura, latencia de escritura y rendimiento — en sus acuerdos de servicio.
Decisión Elastic Pool vs Serverless
Escenario: Administras cientos de bases de dato