Microsoft AZ-801: Azure Arc y gestión de servidores híbridos — 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

Azure Arc incorpora servidores que no son de Azure (locales o en otras nubes) bajo el mismo plano de control que los recursos nativos de Azure. Los servidores habilitados para Arc se presentan como recursos de Azure de primera clase, lo que permite aplicar Azure Policy, gestionar extensiones, recopilar telemetría con Azure Monitor Agent, orquestar la aplicación de parches con Update Management Center y estandarizar con Azure Automanage. El dominio de los patrones de incorporación, los requisitos del agente y de la red, el control de acceso basado en roles (RBAC) y la gobernanza a escala es esencial para operar flotas híbridas de forma segura y coherente.

Servidores habilitados para Azure Arc: incorporación, prerrequisitos, redes, RBAC y acceso seguro

La incorporación (onboarding) conecta una máquina a Azure mediante la instalación del agente Azure Connected Machine (azcmagent), que registra un servidor en una suscripción, un grupo de recursos y una región seleccionados.

• La incorporación interactiva mediante script es la forma más rápida de empezar. Desde el portal de Azure, genere el script «Add servers» y ejecútelo localmente. El script descarga e instala el agente y, a continuación, utiliza el flujo de código de dispositivo (device code flow) para autenticar a su usuario en Azure Resource Manager y crear el recurso ConnectedMachine.
• La incorporación basada en una entidad de servicio (service principal) es el método recomendado para producción. Cree un registro de aplicación de Microsoft Entra y una credencial de privilegios mínimos con el rol Azure Connected Machine Onboarding asignado al grupo de recursos de destino. Pase el ID y el secreto de la entidad de servicio al script de incorporación para permitir el despliegue desatendido y a escala a través de sus herramientas existentes (Configuration Manager, Group Policy, Ansible o automatización personalizada).
• La habilitación a escala con Azure Policy se centra en la estandarización posterior a la incorporación. Azure Policy no puede instalar el agente de Arc en máquinas que no son de Azure, pero una vez que las máquinas están conectadas a Arc, asigne directivas para desplegar automáticamente las extensiones requeridas (Azure Monitor Agent, Dependency Agent, Custom Script) y las bases de referencia de configuración de invitado (guest configuration baselines) a miles de servidores, con detección y corrección de desviaciones (drift). Este es el enfoque de mínimo esfuerzo para incorporar servidores de Arc en servicios como Microsoft Sentinel o VM insights, según las pruebas.

Los sistemas operativos compatibles incluyen Windows Server 2012 R2, 2016, 2019 y 2022, y distribuciones comunes de Linux para empresas como Ubuntu LTS (18.04+), RHEL 7–9, SLES 12/15, Oracle Linux 7/8/9, CentOS 7 y Amazon Linux 2. Verifique siempre las versiones precisas y los requisitos del kernel en la documentación actual antes de un despliegue a gran escala.

Los prerrequisitos del agente son sencillos: TLS 1.2, HTTPS de salida (TCP 443), disco y memoria suficientes para la caché del agente y las extensiones, un reloj de máquina estable y privilegios de administrador/root para la instalación. Para los proxies, el agente admite el proxy del sistema en Windows (WinHTTP) y un proxy explícito en ambas plataformas. Configure azcmagent para usar un proxy con azcmagent config set proxy.url=https://user:pass@proxy:port o utilice netsh winhttp set proxy en Windows. Si su entorno utiliza inspección de TLS, importe la CA raíz de confianza del proxy en el almacén de la máquina para que el agente pueda validar los puntos de conexión de Azure.

Las listas de permitidos (allowlists) del firewall y de egreso deben permitir el tráfico de salida por el puerto 443 hacia Microsoft Entra ID (para autenticación), Azure Resource Manager y los servicios regionales de Arc. Si va a utilizar Update Management Center y Automanage, permita también el acceso a Windows Update/Microsoft Update y a los repositorios de su distribución de Linux, además de los puntos de conexión de entrega de contenido que distribuyen los paquetes. Arc no requiere la apertura de puertos de entrada en el firewall; todo el tráfico de control se origina desde el servidor hacia Azure.

El RBAC para servidores habilitados para Arc sigue el modelo de Azure. Utilice los roles integrados para separar responsabilidades:

• Azure Connected Machine Onboarding permite crear recursos ConnectedMachine a través de entidades de servicio, al tiempo que impide derechos de modificación más amplios.
• Azure Connected Machine Resource Administrator gestiona el recurso del servidor de Arc y sus extensiones sin conceder permisos a nivel de suscripción.
• Azure Connected Machine User Login y Azure Connected Machine Administrator Login controlan el acceso interactivo cuando se habilita el inicio de sesión basado en Azure AD a través de SSH (Linux) o RDP/WinRM (Windows). Organice las máquinas de Arc en grupos de recursos que reflejen el entorno (Prod/NoProd), la geografía, la unidad de negocio o el anillo de aplicación de parches (patch ring). Asigne el ámbito de las directivas, los bloqueos y las asignaciones de roles a nivel de grupo de recursos o de grupo de administración para simplificar la gobernanza.

El acceso seguro por SSH sin una IP pública es compatible a través del túnel justo a tiempo (just-in-time) de Arc. Instale la extensión AADSSHLoginForLinux para habilitar la autenticación basada en Entra ID y asignar usuarios/grupos a entidades de seguridad locales. Los usuarios autorizados con el rol de inicio de sesión apropiado pueden ejecutar az ssh arc --resource-group RG --name Server01 para establecer un túnel TLS efímero y de salida hacia el demonio SSH del servidor, sin necesidad de un puerto de entrada, VPN o bastión. Aplique Conditional Access y Privileged Identity Management para limitar en el tiempo los roles de inicio de sesión.

Gobernanza y configuración a escala: configuración de invitado de Azure Policy y Automanage

La configuración de invitado es la capacidad de auditoría y configuración dentro del invitado de Azure Policy para Arc. Las directivas integradas cubren bases de referencia comunes, como garantizar que el agente de Azure Monitor esté instalado, auditar las directivas de contraseñas, forzar el modo BitLocker o FIPS en Windows donde sea compatible, o requerir instalaciones de syslog específicas en Linux. Asigne estas directivas a escala a los ámbitos de Arc, y la plataforma implementa la extensión de configuración de invitado según sea necesario. Para directivas personalizadas, cree un paquete de configuración de invitado basado en DSC que exprese el estado deseado (por ejemplo, una configuración reforzada de SSHD o reglas del Firewall de Windows), publíquelo como una definición de directiva personalizada y luego asígnelo a su ámbito de Arc.

Las tareas de corrección transforman las auditorías en acciones. Las directivas con efectos DeployIfNotExists o Modify pueden crear o cambiar la configuración, y puede desencadenar una corrección bajo demanda para que las máquinas existentes cumplan con la normativa. Para desviaciones recurrentes, habilite la corrección automática para que el motor de directivas vuelva a aplicar el estado deseado. Realice un seguimiento de la postura de cumplimiento por directiva, por máquina y por ámbito en el panel de Cumplimiento y exporte la evidencia para los reguladores desde la misma interfaz de usuario.

Azure Automanage para servidores habilitados para Arc operacionaliza las «mejores prácticas para máquinas». Seleccione un perfil de configuración apropiado para desarrollo/pruebas o producción y la plataforma incorpora la máquina a un conjunto seleccionado de servicios: Azure Monitor (a través de AMA y un perfil de VM insights), Update Management Center con ventanas de mantenimiento definidas, Change Tracking and Inventory, habilitación del plan de Microsoft Defender for Cloud y bases de referencia de seguridad del sistema operativo principal. Automanage detecta continuamente la desviación del perfil elegido y la corrige donde es compatible, mientras proporciona visibilidad sobre cualquier elemento que requiera intervención manual en entornos que no son de Azure. Dado que Automanage utiliza Azure Policy internamente, puede implementar perfiles a escala y confiar en el mismo modelo de informes de cumplimiento.

Operaciones y monitorización: Update Management Center, AMA y DCR, y extensiones de Arc

Update Management Center (UMC) es el servicio moderno y ligero de aplicación de parches para máquinas de Azure y Arc. Evalúa continuamente las actualizaciones de seguridad y no seguridad que faltan, muestra el cumplimiento por gravedad y clasificación, y admite configuraciones de mantenimiento tanto puntuales como recurrentes. Defina ventanas de mantenimiento con duración máxima, comportamiento de reinicio (Nunca, Si es necesario o Siempre), scripts previos y posteriores, y segmentación dinámica mediante consultas y etiquetas de Azure para que las nuevas máquinas de Arc que coincidan con los criterios se incluyan automáticamente. Para Windows, UMC obtiene las actualizaciones de Windows Update/Microsoft Update o WSUS si está configurado; para Linux, de los repositorios de paquetes configurados. Utilice los informes de cumplimiento para rastrear el porcentaje de parches aplicados por ámbito, ver fallos con códigos de error granulares y exportar datos para auditoría. Dado que UMC no depende de Azure Automation ni del MMA heredado, es la ruta estratégica a seguir para la orquestación de parches.

El agente de Azure Monitor (AMA) es la canalización de telemetría unificada para los servidores habilitados para Arc. En lugar de codificar de forma rígida un área de trabajo en la máquina, se definen Reglas de recopilación de datos (DCR) que describen:

• Qué recopilar: registros de eventos de Windows, instalaciones y gravedades de syslog de Linux, contadores de rendimiento y señales de seguimiento de cambios.
• A dónde enviarlo: una o más áreas de trabajo de Log Analytics, métricas de Azure Monitor y, opcionalmente, Event Hubs.
• Cómo transformarlo: modelado de datos opcional antes de la ingesta. Asocie las DCR en el ámbito del recurso, grupo de recursos, suscripción o grupo de administración. Esto desacopla la configuración de la máquina y hace que sea trivial mover una máquina entre áreas de trabajo o recopilar diferentes datos en diferentes entornos. VM insights en Arc ahora usa AMA con el perfil DCR de VM insights para el rendimiento; para los mapas de dependencias y la topología de procesos, instale el Dependency Agent.

Las extensiones son el mecanismo de entrega para las capacidades dentro del invitado. Adminístrelas desde el panel de Extensiones del servidor de Arc, la CLI o mediante directivas:

• Microsoft Monitoring Agent (MMA) es heredado y está retirado para la mayoría de las soluciones; úselo solo si una dependencia aún no se ha migrado a AMA.
• Azure Monitor Agent (AMA) es el predeterminado actual para registros y métricas; combínelo con las DCR.
• Dependency Agent proporciona mapas de servicios y procesos, necesarios para el mapa de VM insights hasta que se complete su reemplazo total.
• Custom Script Extension (Windows/Linux) ejecuta scripts a escala para el arranque inicial (bootstrap) o acciones correctivas cuando la corrección de directivas no puede expresar el cambio deseado.
• AADSSHLoginForLinux y AADLoginForWindows habilitan el inicio de sesión con Entra ID. Otras extensiones comunes incluyen Defender for Endpoint y clientes de gestión de configuración. Use Azure Policy para garantizar que las extensiones requeridas estén presentes y en buen estado. Las actualizaciones, reversiones y el estado de las extensiones son visibles en el recurso y en el registro de actividad para la auditoría.

Inventario, cumplimiento e informes con Azure Resource Graph

Las consultas de Azure Resource Graph (ARG) devuelven el estado de inventario y cumplimiento casi en tiempo real en todos los servidores habilitados para Arc sin necesidad de agentes. Utilícelo para impulsar la sincronización de la CMDB, la higiene de las etiquetas y la selección del ámbito para las políticas y la aplicación de parches. Los patrones comunes incluyen:

• Inventario híbrido por SO y ubicación:

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, resourceGroup, location, osName = properties.osName, osVersion = properties.osVersion, status = properties.status

• Preparación para Sentinel/AMA:

Resources
| where type == "microsoft.hybridcompute/machines"
| extend hasAMA = todynamic(properties.extensions) has_any (x: x.name =~ "AzureMonitorWindowsAgent" or x.name =~ "AzureMonitorLinuxAgent")
| project name, hasAMA

• Informes basados en etiquetas y selección de anillos de parches:

Resources
| where type == "microsoft.hybridcompute/machines"
| project name, patchRing = tags.PatchRing, owner = tags.Owner
| summarize count() by patchRing

• Resumen de cumplimiento de políticas:

PolicyResources
| where type == "microsoft.policyinsights/policystates"
| summarize nonCompliant = countif(isCompliant == false) by resourceId

Estas consultas son la base de los ámbitos dinámicos en Update Management Center, las asignaciones de Automanage y los paneles de control. Estandarice un conjunto mínimo de etiquetas (Environment, PatchRing, BusinessUnit, Owner) durante la incorporación para que ARG siga siendo procesable.

Escenario de problema práctico

Contoso Ltd. tiene 600 máquinas virtuales locales de Windows Server y Linux alojadas en dos centros de datos, administradas con Configuration Manager y Ansible. La dirección requiere una monitorización estandarizada, aplicación de parches mensual con estrictas ventanas de mantenimiento los sábados, incorporación a Sentinel y acceso SSH seguro para los ingenieros sin exponer direcciones IP públicas. También quieren pruebas de cumplimiento para los auditores y un esfuerzo administrativo continuo mínimo.

1. Preparar el acceso con privilegios mínimos

• Cree una entidad de servicio con ámbito en los RGs que contendrán las máquinas de Arc y asígnele el rol Azure Connected Machine Onboarding. Esto permite la incorporación desatendida a través de las herramientas existentes sin conceder permisos amplios. Por qué: La incorporación basada en una entidad de servicio escala y cumple con el principio de privilegios mínimos.

2. Incorporar máquinas con automatización

• Utilice el script de incorporación de Arc generado con la entidad de servicio en Configuration Manager para Windows y en Ansible para Linux para instalar el azcmagent y registrar cada servidor en el RG apropiado (etiquetado con Environment y PatchRing). Por qué: Reutiliza las herramientas de despliegue existentes para un lanzamiento rápido y coherente, e integra etiquetas para la gobernanza posterior.

3. Establecer la salida de red y proxy

• Asegure la salida por el puerto 443 hacia Entra ID, Azure Resource Manager, los puntos de conexión regionales de Arc, Windows Update/Microsoft Update y los repositorios de las distribuciones. Configure los ajustes de proxy del azcmagent e importe la CA raíz de inspección TLS donde sea necesario. Por qué: Garantiza la salud del agente y las extensiones, la recuperación de actualizaciones y evita la deriva de la conectividad.

4. Aplicar líneas base con la configuración de invitado de Azure Policy

• Asigne políticas integradas para desplegar la extensión de Guest Configuration, el AMA y el Dependency Agent. Aplique un paquete de configuración de invitado personalizado para reforzar la configuración de SSH y RDP. Habilite la remediación automática para las configuraciones críticas. Por qué: Las políticas expresan el estado deseado a escala, proporcionan detección de desviaciones y reparan las desviaciones.

5. Estandarizar operaciones con Automanage

• Asigne el perfil de Automanage for Arc Production a los RGs de producción y el perfil Dev/Test a los de no producción. Revise cualquier elemento marcado como manual para entornos no-Azure. Por qué: Automanage aplica continuamente las mejores prácticas con un esfuerzo mínimo por parte del operador.

6. Configurar la monitorización y la incorporación a Sentinel

• Cree DCRs para recopilar SecurityEvent de Windows, los facilities de autenticación de Syslog y los contadores de rendimiento en un área de trabajo de Log Analytics central conectada a Microsoft Sentinel. Utilice Azure Policy para asociar las DCRs con todas las máquinas de Arc y para desplegar los paquetes de soluciones de Sentinel según sea necesario. Por qué: AMA + DCR desacoplan la recopilación de las máquinas y Azure Policy proporciona el método de incorporación de mínimo esfuerzo validado en los escenarios de examen.

7. Orquestar la aplicación de parches con Update Management Center

• Defina configuraciones de mantenimiento recurrentes mensuales por cada etiqueta PatchRing con una ventana de 4 horas los sábados, reinicio si es necesario y ganchos de notificación. Utilice ámbitos dinámicos basados en etiquetas para que las nuevas máquinas se incluyan automáticamente. Por qué: UMC proporciona una gobernanza de parches ligera, impulsada por etiquetas y con informes de cumplimiento auditables.

8. Habilitar SSH seguro sin IPs públicas

• Despliegue AADSSHLoginForLinux a través de Policy y conceda a los ingenieros el rol Azure Connected Machine User Login en los RGs de destino a través de Privileged Identity Management. Indique a los ingenieros que utilicen az ssh arc con activación justo a tiempo. Por qué: La tunelización de Arc elimina la necesidad de entrada pública o jump hosts, y Entra ID junto con PIM ofrece un acceso con privilegios mínimos y por tiempo limitado.

9. Generar informes y auditar con Resource Graph y Compliance

• Cree libros de trabajo de ARG para mostrar el inventario de Arc por entorno, la cobertura de AMA/Dependency Agent, las tendencias de cumplimiento de políticas y el cumplimiento de parches de UMC por PatchRing. Exporte las pruebas de cumplimiento mensualmente. Por qué: ARG y los planos de cumplimiento de Policy/UMC centralizan las pruebas y reducen la sobrecarga de auditoría.

Al combinar la incorporación basada en una entidad de servicio, el despliegue de extensiones y la configuración de invitado impulsados por Policy, los perfiles de Automanage, AMA con DCRs, la aplicación de parches con UMC, Arc SSH y los informes de Resource Graph, Contoso logra una gestión de servidores híbridos segura, coherente y auditable con una intervención manual mínima.

← Seguridad de Active Directory Domain Services · Todos los dominios · Cifrado →

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

Explorar Microsoft →