Microsoft AZ-801: Hyper-V, virtualización y almacenamiento — Guía de estudio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Forma parte de la Microsoft Windows Server Hybrid Administrator Associate AZ-801 — 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

Hyper‑V y el almacenamiento definido por software de Windows Server forman una plataforma cohesiva para cargas de trabajo seguras, aisladas y de alta disponibilidad. Su dominio requiere comprender cómo las estructuras protegidas (guarded fabrics) protegen las VM de los inquilinos frente a los administradores de la estructura, cómo la Seguridad basada en virtualización (VBS) fortalece el SO con aislamiento anclado en hardware, cómo las redes de Hyper‑V imponen el aislamiento y cómo se comportan la replicación, los puntos de control y los clústeres bajo carga y en caso de fallo. Esta sección explica el modelo de seguridad para las VM blindadas y el fortalecimiento del host, profundiza en las construcciones de aislamiento de red, cubre la durabilidad a través de la Réplica de Hyper‑V y la mecánica de los puntos de control, y finaliza con Storage Spaces Direct (S2D), los Volúmenes compartidos de clúster (CSV) y el diseño de cuórum en los Clústeres de conmutación por error.

Virtualización segura y protección de cargas de trabajo

Las VM blindadas (Shielded VMs) protegen los activos del inquilino del acceso de la estructura. El Servicio de protección de host (HGS) opera como el ancla de confianza, ofreciendo dos servicios: atestación (valida la salud del host) y protección de claves (libera las claves para desbloquear el TPM virtual de la VM). HGS se despliega en un bosque o dominio dedicado y bloqueado para minimizar el riesgo de compromiso. Existen dos modos de atestación:

Atestación de confianza de TPM: la garantía más sólida. Los hosts de Hyper‑V requieren TPM 2.0, Arranque seguro (Secure Boot), aplicación de la directiva de integridad de código y arranque medido (measured boot). HGS verifica los registros del arranque medido y la identidad del host antes de liberar el protector de clave al vTPM de la VM.
Atestación de confianza de administrador (Active Directory): garantía más ligera. Los hosts demuestran la confianza mediante la pertenencia a un grupo de AD y metadatos de host publicados. No se evalúa la evidencia del arranque medido, por lo que es más fácil de inicializar pero menos resistente a la manipulación.

Los roles de estructura e inquilino están deliberadamente separados. Los administradores de la estructura gestionan hosts, clústeres, almacenamiento y redes, pero se les impide inspeccionar los discos de las VM blindadas, adjuntar depuradores o usar la consola/PowerShell Direct. Los administradores de inquilinos construyen la VM, son propietarios de las credenciales del SO y crean los datos de blindaje (un paquete sellado que contiene un archivo de respuesta de instalación desatendida, un certificado RDP y claves de guardián) para controlar dónde puede ejecutarse la VM. Las VM blindadas utilizan BitLocker dentro del invitado, anclado en un vTPM, y solo los hosts protegidos atestiguados por HGS reciben los secretos necesarios para arrancar.

La Seguridad basada en virtualización (VBS) eleva el límite de seguridad por encima del kernel al crear el Modo seguro virtual (VSM). Con VBS, el hipervisor impone Niveles de confianza virtual (VTL), aislando componentes sensibles en VTL1 junto con un kernel seguro. Las características incluyen:

Credential Guard: los secretos de LSASS residen en un proceso aislado (LSAISO) en VSM; el SO normal (VTL0) no puede leer la memoria directamente.
Integridad de código protegida por hipervisor (HVCI): solo se ejecuta el código del kernel que cumple con los requisitos modernos de firma e integridad; los ataques de DMA se mitigan con IOMMU. Los requisitos incluyen UEFI con Arranque seguro (Secure Boot), virtualización de CPU con SLAT (Intel EPT/AMD NPT) e IOMMU (Intel VT‑d/AMD‑Vi). Se configura a través de la Directiva de grupo: Turn On Virtualization Based Security, luego se habilita Credential Guard y HVCI; la configuración se bloquea con Arranque seguro para evitar la reversión. Junto con las VM de generación 2, el Arranque seguro y el vTPM, VBS/VSM proporciona un fortalecimiento robusto tanto para los hosts como para los invitados.

Aislamiento de red, replicación y puntos de control de Hyper-V

Los conmutadores virtuales de Hyper-V imponen el aislamiento de Capa 2/L3:

Los conmutadores externos se enlazan a una NIC física (o un equipo SET) para alcanzar la LAN. Utilice adaptadores separados para el tráfico de administración y de inquilino para evitar la superposición.
Los conmutadores internos conectan las VM solo al host; no hay enlace ascendente externo.
Los conmutadores privados conectan las VM solo entre sí; no existe conectividad ni con el host ni con la LAN. Las VLAN segmentan los dominios de L2. Asigne una VLAN de acceso por cada NIC de VM para un aislamiento simple o habilite el modo troncal (trunk) para llevar múltiples VLAN a un dispositivo invitado compatible con VLAN. Las ACL de puerto en un adaptador de red de VM añaden filtrado sin estado de 5 tuplas (IP de origen/destino, protocolo, puerto) con direcciones (entrada/salida/ambas) y acciones (permitir/denegar/medir). Las ACL de puerto son aplicadas por el host y son útiles para el aislamiento local y el control de egreso rudimentario, pero no sustituyen a un firewall completo.

Hyper-V Replica proporciona replicación asíncrona por VM sin necesidad de almacenamiento compartido. Un servidor es el primario (que envía los registros de cambios) y otro es la réplica (que recibe los deltas basados en AVHDX). Los intervalos de replicación son de 30 segundos, 5 minutos o 15 minutos. Opciones de autenticación:

Kerberos (HTTP 80): simple para servidores unidos a un dominio; el tráfico no está cifrado. Use IPsec si se requiere cifrado en tránsito.
Basada en certificados (HTTPS 443): cifrada con TLS, funciona a través de redes no confiables y grupos de trabajo. Planifique las aperturas del firewall correspondientemente, configure la autorización en la réplica y seleccione el almacenamiento de la réplica. Tipos de conmutación por error (failover):
Conmutación por error de prueba (Test Failover): arranca una VM de prueba aislada en la réplica sin afectar la protección.
Conmutación por error planeada (Planned Failover): traspaso orquestado; el primario se apaga, se envían los registros restantes, lo que resulta en un RPO de cero pérdida de datos cuando existe conectividad saludable. Admite la replicación inversa para restablecer la protección.
Conmutación por error no planeada (Unplanned Failover): se invoca cuando el primario no está disponible; el RPO es igual al último registro recibido. La replicación extendida puede reenviar los cambios desde la réplica a un sitio terciario, aumentando la redundancia.

Los puntos de control (checkpoints) capturan un estado en un momento dado para recuperación y desarrollo/pruebas (dev/test). Los puntos de control estándar guardan la memoria de la VM y el estado del dispositivo, permitiendo reversiones instantáneas pero pudiendo interrumpir la consistencia de la aplicación. Los puntos de control de producción utilizan VSS dentro del invitado (Windows) o un volcado del sistema de archivos (Linux) para crear una imagen consistente con la aplicación sin el estado de la memoria; son apropiados para flujos de trabajo de copia de seguridad y puntos de restauración de larga duración. El almacenamiento se implementa como discos de diferenciación AVHDX encadenados al VHDX base. Aplicar o eliminar un punto de control fusiona la cadena de diferenciación con su padre en línea; las fusiones grandes crean presión de E/S, por lo que se debe mantener un margen de rendimiento adecuado y evitar árboles profundos. Para controladores de dominio y aplicaciones distribuidas, los puntos de control de producción mitigan la reversión de USN y problemas relacionados; los puntos de control estándar se limitan mejor a trabajos de desarrollo/pruebas de corta duración.

Capacidades del host, virtualización anidada y seguridad de generación de VM

Las VM de Generación 2 arrancan a través de UEFI, soportando Secure Boot y vTPM. Secure Boot verifica los cargadores de arranque contra una base de datos de confianza (utilice la plantilla de Windows o la de Linux apropiada). vTPM lleva la semántica de TPM 2.0 al invitado, habilitando BitLocker, el aprovisionamiento de Windows Hello for Business y escenarios de VM blindadas (shielded VM). Cuando los invitados más antiguos requieren BIOS o dispositivos heredados, las VM de Generación 1 siguen disponibles pero carecen de Secure Boot y vTPM.

La virtualización anidada permite ejecutar Hyper-V dentro de una VM. Los requisitos incluyen una CPU compatible (Intel VT-x/EPT o AMD-V/NPT), Windows Server 2016 o posterior en el host y el invitado, y una VM configurada con:

Memoria estática (deshabilitar Memoria Dinámica).
Extensiones de virtualización expuestas (Set-VMProcessor -ExposeVirtualizationExtensions $true).
Suplantación de direcciones MAC (MAC address spoofing) para escenarios donde los hosts internos proporcionan NAT o redes en modo puente (bridged). Los casos de uso incluyen la ejecución de contenedores aislados de Hyper-V, la creación de clústeres de laboratorio, la prueba de conmutación por error y las canalizaciones de CI que necesitan hipervisores. Azure admite la virtualización anidada en series de VM específicas; asegúrese de que la selección del tamaño se alinee con la necesidad de extensiones de virtualización.

Almacenamiento definido por software, comportamiento de CSV y cuórum

Storage Spaces Direct agrega unidades conectadas localmente en un grupo para todo el clúster utilizando SMB3, RDMA y la pila de clústeres. Los requisitos del clúster incluyen la edición Windows Server Datacenter, nodos unidos a un dominio con NIC homogéneas, redes de alto ancho de banda y baja latencia (10/25/40 GbE; se recomienda RDMA a través de iWARP o RoCEv2) y hardware validado. Los dominios de error pueden representar nodos, chasis y racks; configurarlos mejora el comportamiento de la ubicación y reparación de datos y mitiga los fallos correlacionados. Los tipos de resiliencia incluyen:

Espejo bidireccional (mín. 2 dominios de error): orientado al rendimiento, tolera un fallo.
Espejo tridireccional (mín. 3 dominios de error): mayor durabilidad, tolera dos fallos.
Paridad dual y paridad acelerada por espejo: eficientes en capacidad con contrapartidas en la latencia de escritura; adecuados para cargas de trabajo de archivado o mixtas con caché de reescritura (write-back cache). Los niveles de caché vinculan medios más rápidos (NVMe/SSD) como caché de lectura/escritura a las unidades de capacidad (SSD/HDD). La caché de reescritura absorbe las escrituras aleatorias y las fusiona; el ajuste se realiza por volumen. Use ReFS para la asignación acelerada, la clonación de bloques y los flujos de integridad; se combina bien con la semántica de rendimiento y reparación de S2D. Un testigo (disco, recurso compartido de archivos o en la nube) es obligatorio para que un clúster S2D de dos nodos pueda soportar el fallo de un solo nodo.

Los Volúmenes compartidos de clúster (CSV) exponen un espacio de nombres coherente (C:\ClusterStorage...) a todos los nodos, permitiendo el acceso concurrente a volúmenes NTFS/ReFS a través de CSVFS. Las operaciones normales utilizan E/S directa, donde la coordinación de metadatos se produce a través de SMB, pero las lecturas/escrituras acceden directamente a las rutas de almacenamiento. La E/S redirigida se activa bajo ciertas condiciones: mantenimiento, fallo en la ruta de almacenamiento, operaciones de instantáneas/copias de seguridad o cuando un volumen está en pausa. Existen dos modos de redirección:

E/S redirigida a nivel de sistema de archivos: el tráfico atraviesa SMB hacia el nodo coordinador.
E/S redirigida a nivel de bloque: más eficiente para cargas de trabajo pesadas en bloques cuando es necesario. La caché de CSV es una caché de lectura en la memoria del host que beneficia a las cargas de trabajo con predominio de lecturas, como los discos primarios VHDX y las cadenas de diferenciación. Configure la caché a nivel de clúster habilitándola y estableciendo un tamaño de caché de bloque apropiado para la RAM disponible, dejando un margen para el host y las cargas de trabajo. Supervise las tasas de acierto de la caché y ajústela de forma conservadora para evitar agotar la memoria del sistema.

El cuórum del clúster de conmutación por error determina la vitalidad del clúster. Los modos incluyen:

Mayoría de nodos: número impar de nodos; sobrevive a floor((N‑1)/2) fallos.
Mayoría de nodos y disco: añade un disco testigo que participa en la votación; es una buena opción cuando hay almacenamiento compartido.
Mayoría de nodos y recurso compartido de archivos: utiliza un recurso compartido de archivos como testigo, alojado fuera del dominio de error del clúster.
Testigo en la nube (Cloud Witness): aprovecha una cuenta de Azure Storage para un testigo ligero y de alta disponibilidad, ideal para despliegues multi-sitio y en el borde (edge). Los clústeres modernos utilizan cuórum dinámico y testigo dinámico: los votos se ajustan en tiempo real para maximizar la tolerancia a fallos, y el testigo gana o pierde un voto automáticamente para evitar empates. Aplique pesos de nodo para excluir de la votación a los nodos poco fiables cuando sea necesario. Para clústeres de dos nodos, configure siempre un testigo (recurso compartido de archivos o en la nube) para permitir la supervivencia ante el fallo de un solo nodo.

Escenario de problema práctico

En Siemens, el equipo de OT/TI necesita modernizar un pequeño sitio de borde (edge) que aloja tres VM de Windows Server que ejecutan telemetría de fabricación. Deben aislar el tráfico entre las redes de OT y las corporativas, proteger las credenciales en los hosts y lograr una resiliencia a nivel de sitio sin almacenamiento compartido.

Construir un clúster de conmutación por error de Hyper‑V de dos nodos con Storage Spaces Direct

Por qué: S2D elimina la necesidad de una SAN, proporciona duplicación (mirroring) entre nodos para mayor durabilidad y se integra con Failover Clustering para la conmutación por error automática. Se añade un testigo de recurso compartido de archivos o en la nube para que el clúster de dos nodos pueda soportar el fallo de un nodo.

Habilitar VBS con Credential Guard y HVCI en ambos hosts

Por qué: VBS/VSM aísla las credenciales de LSASS y aplica la integridad del código del kernel, reduciendo el riesgo de movimiento lateral de malware en un entorno con dispositivos OT mixtos.

Usar VM de Generación 2 con Secure Boot y vTPM

Por qué: El arranque seguro UEFI (Secure Boot) resiste la manipulación de boot-kits; vTPM habilita BitLocker dentro del sistema operativo invitado para los datos en reposo. Esto se alinea con el requisito de Siemens de proteger las configuraciones de telemetría sensibles contra el robo en ubicaciones remotas.

Crear un conmutador externo de Hyper‑V para cada enlace ascendente físico y segmentar con VLAN y ACL de puerto

Por qué: Las VLAN separan el tráfico de OT y el corporativo en la misma estructura física, mientras que las ACL de puerto proporcionan filtros detallados y aplicados por el host para evitar el tráfico este-oeste entre niveles sin necesidad de desplegar dispositivos virtuales completos en el borde.

Configurar Hyper‑V Replica desde el sitio de borde a un servidor de réplica en un centro de datos central a través de HTTPS

Por qué: La autenticación basada en certificados cifra la replicación de extremo a extremo a través de enlaces WAN no confiables. La conmutación por error planificada es compatible con las ventanas de mantenimiento; la conmutación por error no planificada ofrece recuperación ante desastres (DR) cuando el sitio de borde está fuera de línea. La replicación inversa vuelve a proteger los datos después de una conmutación por recuperación (failback).

Estandarizar el uso exclusivo de puntos de control de producción

Por qué: Los puntos de control de producción generan puntos de restauración coherentes con la aplicación sin el estado de la memoria, lo que es apropiado para la pila de telemetría y más seguro a largo plazo que los puntos de control estándar que capturan la memoria volátil.

Habilitar la caché de CSV con un dimensionamiento conservador

Por qué: Los paneles de telemetría de lectura intensiva se benefician de los bloques primarios en caché, mejorando la capacidad de respuesta sin consumir una cantidad excesiva de RAM en los nodos de borde con recursos limitados.

Este diseño utiliza S2D para alta disponibilidad, VBS/vTPM/Secure Boot para una confianza reforzada, VLAN y ACL de puerto para un aislamiento determinista, y Hyper‑V Replica para la resiliencia del sitio, equilibrando la seguridad, el rendimiento y la operatividad en un entorno de borde con recursos limitados.

← Actualización y gestión de parches de Windows Server · Todos los dominios · Recuperación ante desastres y continuidad del negocio →

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