Microsoft AZ-104: Bases de datos de Azure y Servicios de datos — Guía de estudio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Administrator Associate AZ-104 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

Las bases de datos y los servicios de datos de Azure abarcan motores relacionales gestionados, NoSQL distribuido globalmente, caché en memoria, análisis a gran escala e integración/orquestación. Como administrador, debe comprender los modelos de compra, los niveles de servicio, la topología de red y seguridad, la semántica de copia de seguridad/recuperación ante desastres (DR) y cómo combinar servicios para obtener rendimiento, costo y resiliencia. Esta sección se centra en las opciones operativas y las características de la plataforma que configura en el día a día: modelos de aprovisionamiento (DTU vs. vCore), grupos elásticos, copia de seguridad y retención a largo plazo, georreplicación y conmutación por error, instancias administradas inyectadas en VNet, distribución y consistencia de Cosmos DB, réplicas de lectura/alta disponibilidad para bases de datos relacionales de código abierto, motores de Synapse y entornos de ejecución de Data Factory.

Bases de datos relacionales de Azure (SQL Database, Managed Instance, MySQL/PostgreSQL)

Azure SQL Database ofrece dos modelos de compra. El modelo DTU agrupa CPU, memoria e IOPS en Unidades de Transacción de Base de Datos (Database Transaction Units) con niveles Básico, Estándar y Premium; es sencillo pero opaco, bueno para cargas de trabajo estables y predecibles y para el dimensionamiento heredado. El modelo vCore expone la generación/cantidad de CPU y la memoria, combinado con controles de almacenamiento e IOPS. vCore permite la transparencia en el dimensionamiento, la Ventaja Híbrida de Azure y los descuentos por Capacidad Reservada. Dentro de vCore, los niveles de servicio se asignan a patrones de carga de trabajo y disponibilidad: Uso General utiliza almacenamiento remoto Premium SSD o Azure Premium Storage con una arquitectura de disponibilidad estándar; Crítico para la Empresa ubica el cómputo y el almacenamiento en SSD locales con múltiples réplicas, baja latencia y escalado horizontal de lectura integrado; Hiperescala desacopla el cómputo y el almacenamiento con servidores de páginas para un escalado casi instantáneo y bases de datos muy grandes. Para bases de datos únicas, el nivel de computación sin servidor (serverless) (vCore) escala elásticamente la CPU y puede pausarse automáticamente para reducir el costo en inactividad.

Los grupos elásticos comparten el cómputo entre múltiples bases de datos para absorber cargas de trabajo con ráfagas y desfasadas a un menor costo agregado. Los grupos están disponibles en variantes DTU (eDTU) y vCore. Se establecen límites mínimos/máximos por base de datos para contener a los “vecinos ruidosos” y un máximo para el grupo para controlar el gasto. La sobreasignación es aceptable cuando las ráfagas son cortas y no están correlacionadas. El dimensionamiento del grupo depende del consumo promedio sumado más un margen para la concurrencia; monitorear las métricas por base de datos y del grupo es fundamental para mantener los SLO.

Las copias de seguridad son automáticas. Azure SQL mantiene copias de seguridad completas, diferenciales y de registros de transacciones con restauración a un momento dado (PITR) a cualquier segundo dentro de la ventana de retención (generalmente de 7 a 35 días, dependiendo del nivel y la configuración de almacenamiento). La retención a largo plazo (LTR) conserva copias de seguridad completas semanales durante años en almacenamiento RA-GRS; puede restaurar una copia de seguridad LTR como una nueva base de datos en cualquier servidor dentro de la misma suscripción y conjunto de regiones, y la restauración entre regiones está disponible si el almacenamiento de copia de seguridad con redundancia geográfica está habilitado. Las restauraciones crean una nueva base de datos; no sobrescriben la existente.

Las opciones de georreplicación incluyen la georreplicación activa para bases de datos y grupos únicos (hasta cuatro secundarias legibles con replicación asíncrona) y grupos de conmutación por error automática a nivel del servidor lógico. Los grupos de conmutación por error agrupan múltiples bases de datos (o un servidor completo) con recuperación ante desastres geográfica (geo-DR), un punto de conexión de escucha de lectura y escritura, un punto de conexión de solo lectura para descargar las lecturas, conmutación por error automática basada en el estado y redirección basada en DNS. El nivel Crítico para la Empresa también proporciona escalado horizontal de lectura a través de una réplica local legible, lo que permite la descarga inmediata de la carga de trabajo de lectura sin la complejidad entre regiones.

Azure SQL Managed Instance (MI) ofrece una compatibilidad de casi el 100% con el motor de SQL Server, incluyendo SQL Agent, consultas entre bases de datos, CLR, servidores vinculados, Service Broker y copia de seguridad/restauración nativa de archivos .bak desde Azure Blob Storage. MI se inyecta en una VNet: se implementa en una subred dedicada y delegada con IP privadas y controles de NSG/UDR; planifique el tamaño de la subred y el espacio de direcciones por adelantado, ya que redimensionar las subredes más tarde es complejo. Las rutas de migración incluyen Azure Database Migration Service (transiciones en línea/fuera de línea), copia de seguridad/restauración nativa a URL en MI y replicación transaccional desde un SQL Server local a MI. Elija MI cuando requiera paridad en la superficie de exposición o características a nivel de instancia que las bases de datos únicas no exponen.

Azure Database for MySQL y Azure Database for PostgreSQL (Flexible Server) proporcionan motores OSS gestionados con control sobre las ventanas de mantenimiento, detener/iniciar para ahorrar costos, cómputo de uso general y ampliable (burstable), crecimiento automático del almacenamiento e integración con VNet. Flexible Server ofrece alta disponibilidad con replicación síncrona; puede elegir alta disponibilidad con redundancia de zona entre Zonas de Disponibilidad para un mayor aislamiento de fallos o alta disponibilidad en la misma zona para una menor latencia de escritura. Las réplicas de lectura están disponibles para el escalado horizontal de lecturas y pueden aprovisionarse dentro o entre regiones; utilizan replicación asíncrona y son ideales para análisis, informes o microservicios con uso intensivo de lectura. Promueva una réplica para la conmutación por error o la expansión regional cuando sea necesario, reconociendo el posible retraso en la replicación.

Datos distribuidos y almacenamiento en caché (Cosmos DB y Azure Cache for Redis)

Azure Cosmos DB es una base de datos multimodelo distribuida globalmente que ofrece API para Core (SQL), MongoDB, Cassandra, Gremlin (grafos) y Table. La elección de la API determina la compatibilidad del controlador de cliente y la semántica del modelo de datos; a nivel operativo, se gestiona el rendimiento (RU aprovisionadas o escalado automático) y las particiones, independientemente de la API. Los datos se particionan horizontalmente mediante una clave de partición que debe presentar una alta cardinalidad y una distribución de acceso uniforme para evitar particiones calientes; se deben evitar las claves monotónicamente crecientes y considerar claves de partición jerárquicas cuando existan patrones de acceso compuestos. Se admiten las consultas entre particiones, pero consumen más RU; cuando sea posible, coubique los datos relacionados por clave de partición.

Los niveles de coherencia son ajustables por cuenta, base de datos o solicitud: Strong (Fuerte) garantiza la linealizabilidad; Bounded Staleness (Obsolescencia limitada) limita la obsolescencia por tiempo o versión; Session (Sesión) (predeterminado) proporciona lecturas de sus propias escrituras para una sesión; Consistent Prefix (Prefijo coherente) garantiza el orden sin una coherencia total; Eventual (Eventual) maximiza la disponibilidad y el rendimiento. Para escrituras en múltiples regiones, elija una política de resolución de conflictos adecuada (LastWriterWins o personalizada mediante procedimientos almacenados) y defina las prioridades de conmutación por error. La distribución global permite agregar regiones con un clic; el servicio se encarga de la replicación, la conmutación por error y el enrutamiento optimizado para la latencia con SLA sobre rendimiento, latencia, disponibilidad y coherencia.

Azure Cache for Redis proporciona una latencia inferior al milisegundo, respaldada por Redis. Los niveles progresan en capacidad: Basic (nodo único, para desarrollo/pruebas), Standard (dos nodos replicados primario/réplica con SLA), Premium (tamaños mayores, clústeres, persistencia, inyección en VNet, georreplicación y módulos de Redis como Bloom), Enterprise y Enterprise Flash (basados en Redis Enterprise con clústeres avanzados, georreplicación activa para escrituras multiprimarias y cachés más grandes respaldadas por Flash). Las políticas de expulsión definen el comportamiento bajo presión de memoria: noeviction (errores en la escritura), allkeys-lru/lfu/random (considera todas las claves) y volatile-lru/lfu/ttl/random (considera solo las claves con TTL). Para el almacenamiento en caché de sesiones, utilice el nivel Premium o superior para obtener persistencia si no puede permitirse la pérdida de sesiones, habilite los TTL de las claves para limitar el crecimiento y considere la creación de clústeres para el rendimiento y la escala. Ubique la caché en la misma región y red virtual que los servidores de aplicaciones para minimizar la latencia; utilice Managed Identity o claves de acceso y aplique el aislamiento de red mediante Private Link o la inyección en VNet.

Análisis e integración (Synapse Analytics y Data Factory)

Azure Synapse Analytics unifica el almacenamiento de datos (data warehousing), el big data y la integración de datos. El grupo de SQL dedicado (anteriormente SQL DW) es un motor MPP con distribuciones hash/round-robin, tablas replicadas y almacenamiento en caché de conjuntos de resultados. Se puede escalar el cómputo hacia arriba o hacia abajo para cumplir con las ventanas de SLA y se puede pausar para pagar solo por el almacenamiento. El aislamiento de cargas de trabajo se puede lograr con grupos de cargas de trabajo y configuraciones de importancia para proteger las consultas críticas. El grupo de SQL sin servidor proporciona T-SQL bajo demanda sobre los datos en Azure Data Lake Storage Gen2 sin necesidad de aprovisionamiento; se paga por TB escaneado y se pueden externalizar los esquemas utilizando vistas para capas semánticas. Los grupos de Spark llevan Apache Spark a Synapse con escalado automático y clústeres bajo demanda, lo que permite el uso de notebooks, Delta Lake y machine learning con seguridad integrada y linaje de datos; se pueden compartir datos del lakehouse entre los motores de Spark y SQL.

Azure Data Factory (ADF) orquesta el movimiento y la transformación de datos. Las canalizaciones (Pipelines) coordinan actividades como Copy, Data Flow (flujos de mapeo basados en Spark) y cómputo externo (Databricks, Synapse, Functions). Los conjuntos de datos (Datasets) definen la forma y la ubicación de los datos, mientras que los servicios vinculados (linked services) encapsulan los detalles de conexión (autenticación, puntos de conexión) a los orígenes/destinos. Los entornos de ejecución de integración (Integration Runtimes o IR) proporcionan el plano de cómputo y de red: Azure IR para el movimiento y la transformación nativos de la nube, Self-hosted IR para orígenes en entornos locales o redes privadas a través de HTTPS saliente, y Azure-SSIS IR para la migración lift-and-shift de paquetes SSIS. Los desencadenadores (Triggers) (programación, ventana de saltos de tamaño constante, basados en eventos) permiten una orquestación repetible; se pueden habilitar la red virtual administrada y los puntos de conexión privados para la protección contra la exfiltración de datos y una conectividad conforme a normativas. La parametrización y la integración con Key Vault admiten patrones reutilizables y seguros para la promoción entre entornos (desarrollo/pruebas/producción).

Continuidad del negocio, características geográficas y grupos elásticos

Las estrategias de copia de seguridad y restauración difieren según el servicio, pero comparten temas clave: automatizar, probar las restauraciones regularmente y separar la PITR (errores operativos) de la LTR (cumplimiento). En Azure SQL, use la PITR para eliminaciones accidentales o implementaciones incorrectas; almacene copias completas semanales de LTR en RA-GRS para la retención regulatoria y las restauraciones de recuperación ante desastres entre regiones. Para MySQL/PostgreSQL Flexible Server, habilite las copias de seguridad automatizadas con almacenamiento con redundancia geográfica donde sea compatible, establezca la retención según la política y valide las restauraciones a un momento dado en servidores alternativos. Las cuentas de Cosmos DB con múltiples regiones habilitan la conmutación por error automática; combine esto con escrituras multirregión cuando el RPO deba ser cero y la aplicación pueda resolver conflictos de forma determinista.

La georreplicación y los grupos de conmutación por error automática en Azure SQL proporcionan DR y descarga de lectura. Use la georreplicación activa para una única base de datos o grupo cuando desee administrar explícitamente las secundarias; use grupos de conmutación por error automática para agrupar muchas bases de datos y obtener agentes de escucha basados en DNS además de la conmutación por error automática. Donde las lecturas de baja latencia importan pero el DR no es el objetivo, use el escalado horizontal de lectura de Business Critical o las réplicas con nombre de Hyperscale para mantener las cargas de análisis e informes fuera de la principal. Supervise el retraso de la replicación y las señales de estado de la conmutación por error, y pruebe simulacros de conmutación por error para validar el RTO/RPO.

Los grupos elásticos son palancas de optimización de costos para SaaS multiinquilino y flotas de bases de datos pequeñas. En los grupos basados en DTU, asigne eDTU con límites por base de datos; en los grupos de vCore, asigne vCores, memoria y rendimiento de E/S con un máximo de vCores por base de datos y gobernanza de E/S. Dimensione correctamente midiendo el uso del percentil 95 por base de datos y alineando la capacidad del grupo con los patrones de simultaneidad; aumente los límites por base de datos para inquilinos con SLO más altos y considere dividir los grupos por clase de carga de trabajo (p. ej., inquilinos pesados frente a ligeros). Use alertas sobre los límites del grupo y por base de datos para detectar la saturación de forma temprana. Cuando unas pocas bases de datos alcanzan constantemente los límites máximos, muévalas a un cómputo dedicado o a un grupo separado para mantener la previsibilidad.

Escenario de problema práctico

Starbucks necesita modernizar su plataforma global de lealtad para satisfacer el tráfico pico durante las promociones, reducir la sobrecarga operativa y soportar análisis sin interrumpir las operaciones de las tiendas en todo el mundo.

1. Particionar el almacén de datos operativos:

• Elija Azure Cosmos DB (Core SQL API) para las interacciones de clientes y los eventos de recompensas para lograr una distribución global con baja latencia. Configure escrituras multirregión en regiones cercanas a las principales poblaciones de clientes y establezca la consistencia de Sesión para equilibrar la lectura de sus propias escrituras con el rendimiento. Seleccione una clave de partición de alta cardinalidad como customerId o una clave jerárquica compuesta (customerId, eventMonth) para distribuir el rendimiento y soportar patrones de consulta comunes.

2. Implementar datos transaccionales de cuentas y catálogos:

• Implemente Azure SQL Managed Instance para saldos de cuentas, canjes y SKU/catálogo porque se necesita una compatibilidad de casi el 100% con SQL Server para los procedimientos almacenados y la lógica entre bases de datos existentes. Coloque la MI en una subred dedicada y delegada con NSG y tablas de enrutamiento según lo requiera la inyección en VNet, habilitando el acceso privado desde subredes de aplicaciones y ExpressRoute.

3. Proporcionar escalado de lectura global y DR para cargas de trabajo relacionales:

• Para nuevos microservicios que usan Azure SQL Database, utilice vCore Business Critical para baja latencia y escalado horizontal de lectura. Cree un grupo de conmutación por error automática a una región emparejada con puntos de conexión de escucha de solo lectura para lecturas localizadas y conmutación por error automática para cumplir los objetivos de DR.

4. Añadir gestión de sesiones de baja latencia:

• Implemente Azure Cache for Redis Premium con clústeres y persistencia de datos para tokens de sesión web y móvil. Establezca una política de expulsión allkeys-lfu para mantener en memoria las sesiones de acceso frecuente. Integre la caché en la misma VNet y región que la capa de aplicación para minimizar la latencia.

5. Orquestar el movimiento de datos y construir análisis:

• Use Azure Data Factory para copiar datos operativos (fuente de cambios de Cosmos DB y SQL MI) a Azure Data Lake Storage Gen2. Emplee una IR de VNet administrada con puntos de conexión privados para prevenir la exfiltración de datos. Parametrice las canalizaciones y use desencadenadores de ventana de saltos de tamaño constante para garantizar el procesamiento ordenado.

6. Habilitar análisis empresariales con control de costos elástico:

• En Azure Synapse Analytics, use un grupo de SQL sin servidor para la exploración ad hoc sobre datos parquet y un grupo de SQL dedicado para modelos de BI curados y de alta concurrencia con rendimiento predecible. Cree grupos de Spark para la ingeniería de características sobre el comportamiento de lealtad y escriba tablas Delta en el lago para la interoperabilidad entre Spark y SQL.

7. Gobernanza, copias de seguridad y retención:

• Configure las prioridades de conmutación por error automática de Cosmos DB y supervise los conflictos usando LastWriterWins con un campo de marca de tiempo. Para Azure SQL Database y MI, verifique las ventanas de PITR y habilite la LTR para cumplir con la retención de cumplimiento. Para las instancias de Flexible Server que soportan servicios OSS auxiliares (p. ej., telemetría de tiendas regionales en PostgreSQL), habilite la alta disponibilidad con redundancia de zona y configure réplicas de lectura para informes.

Por qué estos servicios: La distribución global y la consistencia ajustable de Cosmos DB abordan las interacciones sensibles a la latencia en todo el mundo; MI conserva características complejas de SQL Server mientras proporciona operaciones administradas; las bases de datos Business Critical suministran escalado de lectura local sin latencia entre regiones; Redis asegura el acceso a sesiones en menos de un milisegundo durante los picos de tráfico; ADF proporciona un movimiento seguro y gobernado desde redes privadas; Synapse mezcla análisis bajo demanda y aprovisionados para obtener conocimientos rentables y escalables. Esta composición cumple con los SLO de rendimiento durante las promociones, reduce el trabajo administrativo repetitivo a través de PaaS administrado e impone límites claros de RTO/RPO y cumplimiento.

← Azure App Service y Cómputo de PaaS · Todos los dominios · Azure Monitor →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Microsoft →