Microsoft AZ-104: Máquinas virtuales de Azure y Cómputo — 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.

Información general

Las Máquinas Virtuales de Azure (VM) proporcionan computación elástica para cargas de trabajo de Windows y Linux con un control detallado sobre el tamaño, el almacenamiento, la disponibilidad, las redes, la seguridad y la gestión del ciclo de vida. Los administradores deben comprender las familias de tamaño, las estructuras de disponibilidad, la automatización del escalado, la capacidad spot, las extensiones, los modelos de almacenamiento, los hosts dedicados, las copias de seguridad y los patrones de acceso seguro para cumplir con los objetivos de fiabilidad, rendimiento y costo.

Opciones de proceso y dimensionamiento

Las familias de tamaño de VM se dirigen a perfiles de carga de trabajo distintos. Las de propósito general (Dv, Ev, serie B con capacidad de ráfaga) equilibran las relaciones de vCPU a memoria para servidores web, bases de datos pequeñas y servidores de aplicaciones. Las optimizadas para proceso (Fsv2, HB/HBv2 para HPC vinculadas a la CPU) maximizan las vCPU por GB y están ajustadas para una alta velocidad de reloj, beneficiando a los niveles de API sin estado, los trabajadores de lotes y los servidores de juegos. Las optimizadas para memoria (Ev5, Mv2/Mv3) ofrecen más memoria por vCPU y admiten cachés en memoria, motores de análisis y grandes bases de datos. Las VM con GPU (NV, NVv4 para visualización; NC/ND para entrenamiento e inferencia de CUDA/AI) incluyen GPU de NVIDIA con particionamiento de vGPU en algunos SKU para mayor densidad y eficiencia de costos; la compatibilidad de controladores y frameworks debe validarse y fijarse mediante extensiones.

Las operaciones de actualización y cambio de tamaño están limitadas por la disponibilidad de hardware en el clúster de destino; cambiar el tamaño de una VM en un conjunto de disponibilidad puede fallar con errores de asignación si la capacidad está restringida. Desasignar todas las VM del conjunto y luego cambiar su tamaño suele tener éxito al permitir la ubicación en diferente hardware. Cuando se requieren IP internas estáticas, se asignan en la configuración de la NIC en Azure, no dentro del SO invitado.

Azure Dedicated Hosts ubican sus VM en servidores físicos de un solo inquilino para aislamiento a nivel de host, cumplimiento normativo y previsibilidad. Los grupos de hosts definen una colección de hosts en una región y pueden abarcar zonas de disponibilidad y dominios de error de host para distribuir el riesgo de fallo y mantenimiento del host. Los dominios de error de host dentro de un grupo de hosts aseguran que las VM se distribuyan entre racks físicos. Los beneficios de licenciamiento incluyen la posibilidad de traer licencias de Windows Server/SQL Server con Software Assurance o Azure Hybrid Benefit y la opción de licenciar por host (útil para SQL Enterprise/Windows Datacenter) en lugar de por VM, lo que potencialmente reduce los costos para una consolidación densa.

Disponibilidad, escalado y optimización de costos

Los conjuntos de disponibilidad protegen contra fallos de hardware y mantenimiento planificado dentro de un centro de datos. Las VM se distribuyen entre dominios de error (alimentación/rack distintos) y dominios de actualización (oleadas de mantenimiento). Los límites típicos son de hasta 3 dominios de error y 20 dominios de actualización; despliegue al menos dos instancias para obtener el SLA del 99.95%. Las zonas de disponibilidad proporcionan una mayor resiliencia al ubicar los recursos en edificios de centros de datos físicamente separados dentro de una región; desplegar dos o más VM entre zonas produce un SLA de VM del 99.99%. Las zonas requieren recursos compatibles con zonas, y el tráfico entre zonas utiliza un equilibrador de carga o una puerta de enlace de aplicaciones de SKU Estándar; planifique el egreso de datos dentro de una región.

Los Virtual Machine Scale Sets (VMSS) orquestan flotas de VM idénticas o heterogéneas con autoescalado y gestión de estado integrados. La orquestación uniforme utiliza un modelo de conjunto de escalado con un único perfil de VM y se integra de forma nativa con Azure Load Balancer o Application Gateway. La orquestación flexible admite diversos SKU de VM e individualidad de la instancia, se combina con conjuntos/zonas de disponibilidad y es adecuada para roles con estado o mixtos. Los modos de actualización determinan el comportamiento del despliegue: Manual (el administrador desencadena las actualizaciones), Automático (la plataforma actualiza todas las instancias cuando cambia el modelo) y Progresivo (lotes con sondeos de estado, pausa entre lotes y umbrales de fallo). Las políticas de autoescalado reaccionan a métricas (CPU, memoria a través de AMA, longitud de la cola, métricas personalizadas), programaciones o ambas; defina la capacidad mínima/máxima/deseada, los períodos de enfriamiento y las políticas de reducción horizontal (p. ej., la VM más nueva primero) para controlar la rotación. Para la gestión de entrada a escala, utilice los grupos de NAT de entrada del equilibrador de carga en el Standard Load Balancer público o interno. Los sondeos de estado deben apuntar al puerto y protocolo del servicio real; para SQL Always On con un equilibrador de carga interno, utilice un sondeo TCP en el puerto de escucha en lugar de HTTP.

Las Azure Spot VMs aprovechan la capacidad de Azure no utilizada con grandes descuentos y sin garantías de disponibilidad. La expulsión ocurre cuando se reclama la capacidad o el precio de mercado supera su precio máximo; puede establecer la política de expulsión en Desasignar (conservar el disco para un reinicio posterior cuando esté disponible) o Eliminar (eliminar la instancia en la expulsión). Se integran con VMSS y Standard Load Balancer para el escalado sin estado. Los casos de uso adecuados incluyen el procesamiento por lotes, los ejecutores de CI/CD, el renderizado, el fuzzing y las granjas web sin estado a gran escala que pueden tolerar interrupciones. Evite las Spot para producción de instancia única o para niveles con estado sin puntos de control. Los límites de precio evitan que pague más de su umbral; si la demanda aumenta, espere tasas de expulsión más altas.

Almacenamiento, copia de seguridad y gestión de imágenes

Cada VM tiene un disco de SO (disco administrado, con caché optimizada para el arranque) y discos de datos opcionales para el almacenamiento de aplicaciones. El disco temporal (D: en Windows, a menudo /dev/sdb en Linux) reside en el host y no es persistente; úselo solo para cachés efímeras o archivos de paginación/intercambio. Los discos administrados abstraen las cuentas de almacenamiento, proporcionan opciones de redundancia zonal/regional, simplifican el escalado y mejoran la distribución en conjuntos de disponibilidad. Los discos no administrados ubicados en las cuentas de almacenamiento del cliente son heredados y deben evitarse debido a los límites de escalado y de limitación de velocidad (throttling). Seleccione los SKU de disco según el rendimiento y el costo: Premium SSD y Premium SSD v2 para cargas de trabajo transaccionales de baja latencia, Ultra Disk para rendimiento/IOPS extremos con rendimiento ajustable, Standard SSD para uso general y Standard HDD para cargas de trabajo frías.

Desasociar un disco de datos de una VM antes de asociarlo a otra minimiza el tiempo de inactividad y preserva la consistencia de los datos. Las operaciones de cambio de tamaño en los discos suelen requerir la expansión de la partición/sistema de archivos dentro del sistema operativo invitado; los cambios grandes en el tamaño de la VM pueden requerir una desasignación.

Azure Backup protege las VM utilizando un almacén de Recovery Services. Habilite la copia de seguridad en la VM o a escala mediante la asignación de directivas. Las directivas de copia de seguridad definen programaciones (diarias/semanales), retención (a corto y largo plazo) y parámetros de Instant Restore (conservar instantáneas localmente para una recuperación rápida de archivos). Las copias de seguridad coherentes con la aplicación están disponibles a través de VSS para Windows o scripts de pre/post ejecución en Linux. Las restauraciones pueden tener como destino una VM completa (generalmente a una nueva VM), discos (para volver a asociarlos/recuperación rápida) o archivos (restauración a nivel de archivo en cualquier VM de la suscripción con montaje seguro). Las copias de seguridad funcionan para VM en ejecución y detenidas (incluidas las desasignadas). Asegúrese de la compatibilidad del cifrado: las claves administradas por la plataforma son compatibles por defecto, y Azure Disk Encryption requiere pasos adicionales para la copia de seguridad. Considere la restauración entre regiones si su almacén tiene habilitado el almacenamiento con redundancia geográfica y su postura de cumplimiento lo permite.

Para las imágenes maestras (golden images), use Azure Compute Gallery para versionar y replicar imágenes entre regiones; las cargas desde VHD generalizados locales (on-premises) se pueden realizar con herramientas como

undefined

y luego capturarlas en la galería para un aprovisionamiento consistente.

Redes, acceso y observabilidad

Cada VM requiere al menos una interfaz de red (NIC), que contiene una o más configuraciones IP. Una sola NIC puede tener una IP privada principal y direcciones IP privadas secundarias adicionales; asocie una IP pública a una configuración IP para exponer servicios. La mayoría de las cargas de trabajo solo necesitan una NIC por VM; los tamaños determinan los límites de NIC. Al implementar cinco VM que necesitan tanto IP públicas como privadas con una postura de seguridad idéntica, cree una NIC por VM y un único Network Security Group aplicado en la subred (o en la NIC) para aplicar reglas de entrada/salida uniformes. La asignación de IP privadas debe ser estática en la NIC en Azure para mantener la continuidad de la dirección; no configure IP estáticas dentro del sistema operativo invitado. Las IP públicas deben usar el SKU Standard para compatibilidad con zonas y conjuntos de escalado; combínelas con un Standard Load Balancer para producción.

Accelerated Networking utiliza SR-IOV para omitir la ruta de datos del host y reducir la latencia, la fluctuación (jitter) y la sobrecarga de la CPU. Es compatible con tamaños de VM e imágenes de SO seleccionados y requiere una vNIC compatible en el momento de la creación (o una detención/desasignación para habilitarlo). Úselo para servicios de alto rendimiento y baja latencia y para niveles de puerta de enlace con mucho tráfico.

Azure Bastion proporciona RDP/SSH seguro sobre TLS directamente desde el portal de Azure o un cliente nativo sin exponer direcciones IP públicas en las VM. Implemente un host de Bastion en la red virtual de destino en una subred dedicada llamada AzureBastionSubnet con un prefijo /26 o mayor y asocie una IP pública Standard al recurso de Bastion. Los SKU incluyen Basic y Standard; Standard agrega características como escalado manual (instancias), conexiones basadas en IP (a cualquier IP privada accesible, incluso a través de VNets emparejadas), compatibilidad con cliente nativo, integración de grabación de sesiones y enlaces compartibles. Use Bastion para satisfacer el acceso administrativo de confianza cero (zero-trust) evitando al mismo tiempo los puntos de conexión públicos por VM y las reglas NAT de entrada.

Las extensiones de VM automatizan la configuración y la telemetría. La Custom Script Extension ejecuta PowerShell o Bash durante o después del aprovisionamiento para arrancar software o inyectar archivos de configuración; diseñe scripts idempotentes y almacene los artefactos en un almacenamiento seguro con tokens SAS. La extensión PowerShell DSC aplica la Desired State Configuration para hacer converger los nodos de Windows a un estado declarado; utilice servidores de extracción (pull servers) o Azure Automation State Configuration para la gestión a escala. El Azure Monitor Agent (instalado a través de una extensión) transmite métricas y registros del sistema operativo invitado a los espacios de trabajo de Log Analytics bajo las Reglas de Recopilación de Datos; prefiera el AMA sobre el agente heredado Log Analytics/MMA para un enrutamiento de datos granular, multihoming y escalabilidad.

Constructos de disponibilidad en la práctica y SLAs

Elija conjuntos de disponibilidad cuando necesite redundancia dentro del centro de datos con backends de almacenamiento compartido y no requiera una ubicación zonal. Elija zonas de disponibilidad para servicios de misión crítica que exijan aislamiento de fallos a nivel de edificio y un SLA más alto. Para servicios de escalado horizontal (scale-out), combine VMSS con zonas para una distribución uniforme y recuperación automática; fije los sondeos de estado (health probes) a los puertos de la carga de trabajo y aproveche las actualizaciones graduales (rolling upgrades) para mitigar el riesgo. Comprenda que las VMs individuales, incluso con Premium SSD, ofrecen un SLA más bajo que las implementaciones de varias instancias. Para las capas sin estado (stateless) sensibles al costo, incorpore un grupo de Spot VM detrás de un Standard Load Balancer y establezca políticas conservadoras de expulsión (eviction) y de reducción de escala (scale-in) para proteger la capacidad base.

Escenario de problema práctico

Contoso Ltd. opera una aplicación web de varias capas con una API sin estado (stateless), una caché de Redis con estado (stateful) y un grupo de disponibilidad Always On de SQL Server. Deben mejorar la resiliencia ante interrupciones zonales, reducir los costos de cómputo para la capa de API, asegurar el acceso de administrador sin IPs públicas y estandarizar el monitoreo y las copias de seguridad.

Cree tres subredes en una topología hub-spoke: una subred de administración compartida (hub), una subred web/API (spoke) y una subred de datos (spoke). Implemente Azure Bastion Standard en la AzureBastionSubnet (/26) del hub con una IP pública Standard. Razón: Bastion permite RDP/SSH sobre TLS sin exponer IPs públicas en ninguna VM, y el SKU Standard admite conexiones basadas en IP a través de VNets emparejadas (peered), centralizando el acceso de administrador.
Implemente la capa de API como un VM Scale Set (Uniform) a través de las Zonas de Disponibilidad 1, 2 y 3 con un Standard Load Balancer. Habilite las redes aceleradas (accelerated networking) y establezca reglas de autoescalado para agregar instancias cuando el promedio de CPU > 65% durante 10 minutos y eliminarlas cuando < 35% con un período de enfriamiento (cooldown). Agregue un grupo secundario de Spot VM dentro del mismo conjunto de escalado utilizando la orquestación Flexible o un conjunto de escalado complementario, configurando un precio máximo y la política de expulsión Deallocate. Razón: VMSS más zonas ofrece un SLA del 99.99% y recuperación automática; la capacidad Spot reduce los costos para la carga de ráfaga (burst load) mientras que Deallocate preserva los discos para una reutilización rápida.
Implemente las VMs de caché de Redis en un conjunto de disponibilidad con 2+ instancias y Premium SSD. Fije los dominios de error (fault domains) a 2 y confíe en los 20 dominios de actualización (update domains) de la plataforma. Razón: La caché tiene estado (stateful) pero puede replicarse; los conjuntos de disponibilidad proporcionan aislamiento de rack y mantenimiento sin las penalizaciones de latencia entre zonas.
Implemente dos VMs de SQL Server por zona (Zonas 1 y 2) que participen en un grupo de disponibilidad Always On. Colóquelas en Azure Dedicated Hosts dentro de un grupo de hosts que abarque dos zonas y dos dominios de error de host. Configure un Standard Load Balancer interno con un sondeo TCP en el puerto de escucha (p. ej., 1433) para el listener del AG. Razón: Los Dedicated Hosts proporcionan aislamiento a nivel de host y eficiencia en el licenciamiento (licenciamiento de SQL por host), mientras que la ubicación zonal y el sondeo de estado TCP se alinean con los requisitos del listener de SQL.
Estandarice las imágenes a través de Azure Compute Gallery que contenga imágenes de SO reforzadas (hardened). Use la Custom Script Extension para instalar los prerrequisitos de la aplicación y la extensión DSC para forzar el estado de las características de Windows y las líneas base del registro. Razón: Las imágenes de la galería aseguran un aprovisionamiento consistente; las extensiones permiten una configuración repetible y el control de la deriva (drift control).
Configure el Azure Monitor Agent a través de Reglas de Recopilación de Datos (Data Collection Rules) para enviar métricas y registros de invitado a un área de trabajo de Log Analytics. Habilite el monitoreo de conexiones y los mapas de dependencia según sea necesario. Razón: AMA es el agente actual, admite enrutamiento granular y es necesario para las características de monitoreo modernas y el autoescalado de VMSS basado en métricas más allá de la CPU.
Proteja todas las VMs con Azure Backup en un almacén de Recovery Services utilizando dos políticas: una política de Nivel 1 (Tier-1) con copias de seguridad diarias y retención de 30 días para API/caché, y una política de Nivel 0 (Tier-0) con retención diaria más semanal/mensual para SQL con instantáneas consistentes con la aplicación. Pruebe las restauraciones realizando una recuperación a nivel de archivo en una VM de salto (jump VM) y una restauración completa de la VM en una red de ensayo (staging network). Razón: Las políticas separadas se ajustan a la criticidad de los datos y al RPO/RTO; la recuperación de archivos y la restauración de VM cubren escenarios de ransomware y desastres.
Asigne IPs privadas estáticas a las NICs de SQL y Redis a nivel de la NIC de Azure; mantenga las instancias de API dinámicas detrás del balanceador de carga. Aplique un único NSG en cada subred para hacer cumplir reglas uniformes. Habilite las redes aceleradas (accelerated networking) en las capas con mucho tráfico. Razón: La asignación estática a nivel de NIC preserva el direccionamiento para las capas con estado (stateful); los NSG a nivel de subred minimizan la proliferación de reglas; las redes aceleradas reducen la latencia y la sobrecarga de la CPU.

Este diseño cumple con los objetivos de disponibilidad, costo, seguridad y operaciones al combinar zonas y conjuntos de disponibilidad de manera apropiada, aprovechar Spot para la escala sin estado, aplicar un acceso administrativo de confianza cero (zero-trust) con Bastion y estandarizar la configuración, el monitoreo y las copias de seguridad en todas las capas.

← Suscripciones de Azure · Todos los dominios · Redes virtuales de Azure →

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