Microsoft AZ-140: Resiliencia, recuperación y migración — Guía de estudio

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Virtual Desktop Specialty AZ-140 — 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

La planificación de la resiliencia, la recuperación y la migración de Azure Virtual Desktop (AVD) se centra en mantener la productividad del usuario ante fallos regionales, proteger los datos (perfiles, imágenes, aplicaciones), orquestar la conmutación por error de las dependencias y ofrecer una transición predecible desde los servicios de escritorio remoto (RDS) heredados. Los diseños eficaces separan el plano de control sin estado de AVD de los planos de datos con estado, utilizan automatización repetible para las reconstrucciones, definen objetivos de recuperación claros para cada componente y validan el rendimiento en el mundo real con el descubrimiento y el modelado de capacidad.

Arquitectura regional, acceso de usuarios y conmutación por error

Planos de control y de datos: Los servicios de bróker, acceso web, diagnóstico y gestión de AVD son globalmente resilientes. Los hosts de sesión, los grupos de hosts, las imágenes y el almacenamiento son específicos de una región y deben diseñarse para la conmutación por error.
Estrategia ante fallos regionales:
- Cree un grupo de hosts en una región secundaria por cada cohorte de usuarios con la misma familia de tamaños de VM y linaje de imágenes. Replique las imágenes en la región secundaria utilizando Azure Compute Gallery.
- Publique grupos de aplicaciones idénticos (RemoteApp y/o Desktop) en ambas regiones y asigne usuarios a ambos, estableciendo el grupo principal como el predeterminado y el secundario como el destino de DR (recuperación ante desastres).
- Mantenga los hosts de DR en una postura de espera en frío o en caliente. Para los hosts agrupados, escale horizontalmente a cero o apáguelos, y luego confíe en los planes de escalado y en Start VM on Connect para minimizar el coste en estado estacionario.
Acceso de usuarios durante las fallas:
- El servicio AVD enruta las solicitudes de conexión a los hosts de sesión en buen estado. Cuando se pone el grupo de hosts principal en modo de drenaje o no está disponible, las nuevas conexiones se dirigen al grupo secundario si los usuarios tienen asignaciones allí.
- Eduque a los usuarios sobre que las sesiones abiertas en la región fallida se desconectarán; la reconexión se realizará a la región disponible.
Paridad de imágenes y MSIX app attach:
- Utilice Azure Image Builder y Azure Compute Gallery (SIG) con replicación regional para las imágenes.
- Almacene los paquetes de MSIX app attach en ubicaciones de almacenamiento resilientes que sean accesibles desde ambas regiones y replique el contenido en la región secundaria (p. ej., replicación entre regiones de ANF o replicación de cuentas de almacenamiento).
Dependencias de red e identidad:
- Asegúrese de que el DNS y la identidad (Active Directory o Azure AD DS) sean accesibles desde ambas regiones. Para Azure AD DS, configure los ajustes de DNS de la VNet con las IP del dominio administrado en cada VNet regional que requiera la unión al dominio y la resolución de nombres.
- Valide el comportamiento de RDP Shortpath entre regiones; recurra a la conexión inversa si el UDP está impedido.

Ejemplo para replicar una versión de imagen en dos regiones:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Objetivos de recuperación y roles de protección de datos

Defina un RTO/RPO distinto por componente:

Grupos de hosts y hosts de sesión:
- Agrupados: Trate los hosts de sesión como efímeros. El RTO es de minutos (redespliegue automatizado), el RPO es N/A (sin estado en el host). No dependa de las copias de seguridad de las VM para la recuperación; redespliegue desde la imagen y autoescale.
- Personales: Si el estado del usuario reside en el disco del SO, protéjalo con Azure Backup o Azure Site Recovery (ASR). Prefiera descargar el estado del usuario a perfiles de FSLogix para simplificar la DR.
Imágenes:
- RPO cercano a cero para la disponibilidad de imágenes utilizando la replicación de Compute Gallery; RTO de minutos para desplegar nuevos hosts. Mantenga las canalizaciones de imágenes maestras versionadas y reproducibles.
Perfiles y cachés de Office (FSLogix):
- RPO: de minutos a horas dependiendo de los programas de replicación y copia de seguridad; RTO: minutos para montar en la región secundaria si Cloud Cache está configurado, de lo contrario, el tiempo para restaurar el volumen/recurso compartido y redirigir las sesiones.
Aplicaciones:
- Para aplicaciones en la imagen, alinéese con el RTO/RPO de la imagen. Para MSIX app attach, alinéese con la replicación del almacenamiento de paquetes y el tiempo de nuevo registro.

Azure Backup y ASR:

Azure Backup:
- Haga una copia de seguridad de los recursos compartidos de Azure Files que alojan los contenedores de perfiles de FSLogix y ODFC. Utilice instantáneas frecuentes para cumplir los objetivos de RPO; restaure VHD/VHDX individuales o un recurso compartido completo. Comunique que las instantáneas son coherentes con los bloqueos mientras los usuarios están conectados; para restauraciones de precisión, realice una copia/renombrado fuera de banda del contenedor de un usuario e indique al usuario que vuelva a iniciar sesión.
- Haga una copia de seguridad de los discos del SO de los escritorios personales cuando sea necesario. Los hosts agrupados generalmente no requieren copias de seguridad de VM.
Azure Site Recovery:
- Utilice ASR para los componentes de infraestructura con estado que son críticos para AVD (p. ej., servidores de gestión, servidores de licencias si aplica, servidores LOB) y para los grupos de hosts personales cuando se requiere preservar el estado de la VM.
- Evite ASR para los hosts de AVD agrupados; el redespliegue desde la imagen/planes de escalado es más rápido y económico.

Resiliencia del almacenamiento de perfiles, Cloud Cache, copia de seguridad y restauración

Opciones de almacenamiento para FSLogix:
- Azure NetApp Files (ANF): El mayor número de IOPS/latencia más baja a escala; admite la replicación entre regiones para DR. Ideal para entornos muy grandes o con alta concurrencia y demandas de E/S de perfiles.
- Azure Files Premium: Recursos compartidos de archivos PaaS respaldados por SSD con ZRS para resiliencia dentro de la región; excelente equilibrio entre rendimiento y administración. Para DR entre regiones, combine con Cloud Cache y copia de seguridad/restauración a nivel de recurso compartido o diseñe recursos compartidos de doble región.
- Storage Spaces Direct (S2D) en IaaS: Úselo solo cuando PaaS no sea viable. Requiere un mínimo de tres VM sin Cloud Witness para el cuórum. La sobrecarga operativa es mayor que las alternativas PaaS.
Cloud Cache:
- Configure múltiples proveedores (p. ej., dos puntos de conexión de Azure Files o ANF en diferentes zonas/regiones). Durante una interrupción regional, FSLogix continúa funcionando con los proveedores supervivientes con consistencia eventual para las escrituras en caché.
- Configuración de ejemplo:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

Patrones de copia de seguridad y restauración:
- Implemente instantáneas de Azure Backup cada hora o cada pocas horas para los recursos compartidos de perfiles. Para un perfil de usuario corrupto, aísle el VHDX actual, restaure la instantánea anterior en una ubicación alternativa y copie o vuelva a adjuntar el contenedor del usuario.
- Para ANF, utilice instantáneas y replicación entre regiones; restaure a nivel de volumen o un solo archivo a través del directorio de instantáneas.
Pruebas:
- Incluya la validación de montaje/adjunto, simulaciones de corrupción y reversión a nivel de usuario en los simulacros de DR.

Failover de tráfico, DNS y dependencias

Dependencias de la aplicación:
- Muchas aplicaciones de AVD dependen de API HTTP/S, interfaces web o bases de datos. Diseñe estas con balanceo de carga global y despliegues regionales para que el failover de las dependencias no deje a los usuarios varados en sesiones que, por lo demás, están en buen estado.
Azure Front Door y Traffic Manager:
- Use Azure Front Door para el balanceo de carga global de capa 7 para HTTP/S, WAF y enrutamiento basado en rutas de las dependencias de aplicaciones utilizadas por los usuarios de AVD. Combínelo con backends con redundancia de zona en cada región.
- Use Azure Traffic Manager para el balanceo de carga basado en DNS para endpoints que no son HTTP, que son de cara al público y que admiten sondeos de estado.
DNS privado y resolución de nombres:
- Centralice los reenviadores condicionales usando Azure DNS Private Resolver para enrutar consultas entre entornos on-premises, VNets de Azure y dominios administrados. Publique registros con TTL bajo para los endpoints que puedan necesitar un failover rápido.
- Para los endpoints de almacenamiento que no pueden realizar un failover nativo sin interrupciones, considere el uso de endpoints con doble nombre abstraídos detrás de un DNS interno para cambiar entre los recursos compartidos primarios y de DR durante un incidente.
QoS de red y acceso:
- Priorice el tráfico de AVD en tiempo real (UDP/TCP) a través de las WAN; ajuste la QoS en los routers de sucursal para garantizar que las clases de tráfico de AVD tengan suficiente ancho de banda para reducir los errores de conexión y la latencia.
- Valide la accesibilidad de Shortpath y los pinholes del firewall; asegúrese de que la planificación del ancho de banda de egreso coincida con la concurrencia y la combinación de cargas de trabajo.

Migración desde RDS, descubrimiento, densidad y capacidad

Evaluación de RDS:
- Haga un inventario de los Connection Brokers, RD Gateways, RD Web, RD Session Hosts, RD Licensing y servidores de archivos/almacenes de perfiles. Documente las GPO, la configuración de FSLogix y los métodos de entrega de aplicaciones.
- Asigne los roles a las construcciones de AVD: host pools, workspaces, grupos de aplicaciones, almacenamiento de perfiles y el brokering administrado por AVD; elimine la necesidad de RD Gateway y Broker en Azure.
Azure Migrate y descubrimiento:
- Use el appliance de Azure Migrate para descubrir las VM de RDS existentes, las bases de referencia de rendimiento y las dependencias. Identifique las relaciones de aplicación a servidor para la ubicación de los session hosts de AVD y la gravedad de los datos (data gravity).
Análisis de densidad de usuarios:
- Construya modelos de densidad por carga de trabajo (usuarios de tareas/conocimiento/avanzados). Derive las sesiones por VM utilizando las bases de referencia de CPU ready, presión de memoria e IO de perfiles. Valide con pruebas piloto de rendimiento en los SKU de VM candidatos (p. ej., Dv5/Esv5/Dasv5, habilitados para GPU para gráficos).
- Use el Azure Virtual Desktop Experience Estimator para seleccionar las regiones con la latencia más baja de usuario a host.
Modelado de capacidad:
- Convierta la densidad en recuentos de hosts por pool con un búfer N+1 y una sobrecarga para mantenimiento. Defina los umbrales de escalado horizontal y los hosts mínimos/máximos en los planes de escalado. Considere las reservas de capacidad para obtener un costo predecible y núcleos garantizados en regiones con mucha actividad.
- Asegúrese de que las cuotas de suscripción y regionales (vCPU, núcleos por familia, IP, NIC, discos) se aumenten con antelación; envíe las solicitudes de aumento de cuota con tiempo.

Transición, coexistencia, cuotas y runbooks

Planificación de la transición:
- Ejecutar en coexistencia paralela: mantener RDS operativo mientras AVD incorpora a los pilotos. Publicar las mismas aplicaciones en ambos sistemas, pero dirigir a los usuarios por cohortes.
- Cohortes piloto: comenzar con TI y los primeros adoptantes (early adopters), expandir a departamentos representativos y luego realizar un despliegue general. Usar los comentarios para ajustar las imágenes, la configuración de FSLogix y el escalado.
- Reversión (Rollback): mantener las rutas de acceso a RDS hasta que se cumplan los criterios de aceptación. Mantener los perfiles de usuario retrocompatibles o proporcionar una ruta de restablecimiento de perfil por cohorte.
Preparación operativa:
- Claves de registro: al incorporar máquinas virtuales existentes a los host pools, generar una clave de registro y unirlas a través del agente de AVD; automatizar mediante Azure Image Builder y scripts de post-aprovisionamiento.
- Higiene de los workspaces y grupos de aplicaciones: publicar grupos de aplicaciones con privilegios mínimos; separar Desktop y RemoteApp; mantener los grupos de aplicaciones de DR asignados pero con menor énfasis visual si es necesario.
Runbooks y automatización:
- Crear runbooks de continuidad del negocio y recuperación ante desastres (BCDR) que cubran:
  - La declaración del incidente y la puesta de los pools primarios en modo de drenaje (drain mode).
  - El escalado de los pools de DR y la verificación de la paridad de imágenes.
  - El cambio del almacenamiento de perfiles a través de Cloud Cache o el re direccionamiento de DNS.
  - La validación de las dependencias de aplicaciones críticas a través de Front Door/Traffic Manager.
  - La comunicación a los usuarios y al service desk.
  - La reversión (rollback) cuando se restaure la región primaria.
- Implementar los runbooks usando Azure Automation o Functions con controles de acceso basados en roles y aprobaciones de cambios.
Costos y reservas:
- Usar Savings Plans y Capacity Reservations para las cargas de trabajo base estables; mantener la capacidad de ráfaga (burst) en modo de pago por uso con autoescalado. Programar el apagado de los pools de no producción fuera del horario laboral.

Escenario de problema práctico

Adobe debe garantizar que los equipos creativos y de soporte puedan trabajar de forma continua durante una interrupción regional mientras migran de una granja RDS local (on-premises) a Azure Virtual Desktop, con cientos de terabytes de perfiles móviles y cargas de trabajo de gráficos exigentes.

Descubrir y establecer una línea base

Usar Azure Migrate para inventariar los hosts de RDS, los recursos compartidos de perfiles y las dependencias de LOB, y para capturar los patrones de CPU/memoria/IO para las cohortes de gráficos y de soporte.
Por qué: Las líneas base empíricas impulsan objetivos precisos de densidad de usuarios y la selección de SKU de VM, minimizando el sobreaprovisionamiento.

Diseñar la arquitectura regional

Crear host pools primarios en West US 2 con NVadsA v5 habilitadas para GPU para los creativos y Dv5 para soporte; desplegar pools secundarios en Central US.
Replicar imágenes a través de Azure Compute Gallery; almacenar paquetes MSIX en ANF con replicación entre regiones.
Por qué: Asegura la paridad de computación y aplicaciones entre regiones con un rendimiento predecible.

Reforzar la identidad y el DNS

Configurar el DNS de la VNet con las IP de Azure AD DS donde los session hosts se unirán al dominio; desplegar Azure DNS Private Resolver para reenviar consultas entre el entorno local (on-premises) y Azure.
Por qué: La resolución de nombres fiable entre regiones permite el inicio de sesión y el acceso a aplicaciones durante la conmutación por error (failover).

Implementar perfiles resilientes

Usar Azure NetApp Files para FSLogix con instantáneas (snapshots) y replicación entre regiones; habilitar FSLogix Cloud Cache apuntando a los volúmenes de ANF primarios y de DR.
Por qué: ANF ofrece los IOPS/latencia que los creativos requieren; Cloud Cache y CRR proporcionan continuidad si una región falla.

Orquestar la conmutación por error de dependencias

Exponer las API web de LOB con Azure Front Door y configurar backends desplegados regionalmente; usar Traffic Manager para cualquier punto de conexión público que no sea HTTP.
Por qué: Mantiene los puntos de conexión de las aplicaciones accesibles desde cualquier región de AVD sin necesidad de reconfiguración.

Establecer objetivos de recuperación y protección

Establecer un RTO de minutos para los hosts agrupados (pooled) (reconstrucción), horas para los escritorios personales (si los hay, protegidos por Azure Backup/ASR) y un RPO de 15 minutos para los perfiles a través de instantáneas de ANF; hacer copia de seguridad de los recursos compartidos de Azure Files de la cohorte de soporte si se utilizan.
Por qué: Los objetivos específicos por componente alinean el costo con el impacto en el negocio.

Pilotar y coexistir

Incorporar a 100 usuarios de soporte y 50 creativos a AVD; mantener RDS publicado en paralelo. Validar la densidad, la estabilidad de los perfiles y el rendimiento de las aplicaciones. Iterar las políticas de escalado y la configuración de FSLogix.
Por qué: Los pilotos controlados mitigan el riesgo en las elecciones de imagen, almacenamiento y autoescalado.

Transición y simulacro de DR

Generar claves de registro de AVD para expandir los pools; asignar los grupos de aplicaciones de DR a todos los usuarios. Ejecutar un simulacro de DR: drenar el primario, escalar el de DR, validar la continuidad de Cloud Cache y conmutar por error las dependencias de aplicaciones a través de Front Door.
Por qué: Demuestra la conmutación por error de extremo a extremo, incluyendo perfiles y dependencias, antes de la migración completa.

Cuotas, reservas y automatización

Pre-incrementar las cuotas regionales de vCPU y GPU; comprar Capacity Reservations para la línea base de GPU y CPU; implementar runbooks de Azure Automation para el drenaje, escalado, cambio de almacenamiento y comunicaciones.
Por qué: Garantiza la capacidad durante incidentes y elimina los pasos manuales en eventos estresantes.

Migración completa y plan de reversión

Migrar las cohortes restantes en oleadas durante dos semanas; mantener el acceso a RDS como una ruta de reversión (rollback) con puertas de decisión claras por oleada.
Por qué: La transición gradual reduce el riesgo y preserva una alternativa de repliegue inmediata si surgen problemas inesperados.

← Supervisión · Todos los dominios

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