Microsoft AZ-801: Azure Arc et gestion des serveurs hybrides — Guide d'étude

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

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Azure Arc place les serveurs non-Azure (sur site ou dans d’autres clouds) sous le même plan de contrôle que les ressources Azure natives. Les serveurs avec Azure Arc apparaissent comme des ressources Azure de premier ordre, vous permettant d’appliquer Azure Policy, de gérer les extensions, de collecter la télémétrie avec Azure Monitor Agent, d’orchestrer les correctifs avec Update Management Center et de standardiser avec Azure Automanage. La maîtrise des modèles d’intégration, des prérequis de l’agent et du réseau, du contrôle d’accès basé sur les rôles (RBAC) et de la gouvernance à grande échelle est essentielle pour exploiter des parcs hybrides de manière sécurisée et cohérente.

Serveurs avec Azure Arc : intégration, prérequis, réseau, RBAC et accès sécurisé

L’intégration (onboarding) connecte une machine à Azure en installant l’agent Azure Connected Machine (azcmagent), qui enregistre un serveur dans un abonnement, un groupe de ressources et une région choisis.

• L’intégration interactive par script est le moyen le plus rapide de démarrer. Depuis le portail Azure, générez le script « Ajouter des serveurs » et exécutez-le localement. Le script télécharge et installe l’agent, puis utilise le flux de code d’appareil (device code flow) pour authentifier votre utilisateur auprès d’Azure Resource Manager et créer la ressource ConnectedMachine.
• L’intégration basée sur un principal de service est la méthode recommandée pour la production. Créez une inscription d’application Microsoft Entra et un identifiant à privilèges minimum avec le rôle Azure Connected Machine Onboarding limité au groupe de ressources cible. Transmettez l’ID et le secret du principal de service au script d’intégration pour permettre un déploiement sans assistance et à grande échelle via vos outils existants (Configuration Manager, Group Policy, Ansible ou une automatisation personnalisée).
• L’activation à grande échelle avec Azure Policy se concentre sur la standardisation post-intégration. Azure Policy ne peut pas installer l’agent Arc sur des machines non-Azure, mais une fois les machines connectées à Arc, assignez des stratégies pour déployer automatiquement les extensions requises (Azure Monitor Agent, Dependency Agent, Custom Script) et les bases de référence de configuration invité (guest configuration) à des milliers de serveurs, avec détection et correction de la dérive. C’est l’approche à effort minimal pour intégrer les serveurs Arc dans des services tels que Microsoft Sentinel ou VM insights, comme vérifié lors des tests.

Les systèmes d’exploitation pris en charge incluent Windows Server 2012 R2, 2016, 2019 et 2022, ainsi que les distributions Linux d’entreprise courantes telles que Ubuntu LTS (18.04+), RHEL 7–9, SLES 12/15, Oracle Linux 7/8/9, CentOS 7 et Amazon Linux 2. Vérifiez toujours les versions précises et les prérequis du noyau dans la documentation actuelle avant un déploiement à grande échelle.

Les prérequis de l’agent sont simples : TLS 1.2, HTTPS sortant (TCP 443), suffisamment d’espace disque et de mémoire pour le cache de l’agent et les extensions, une horloge machine stable et des privilèges administrateur/root pour l’installation. Pour les proxys, l’agent prend en charge le proxy système sur Windows (WinHTTP) et un proxy explicite sur les deux plateformes. Configurez azcmagent pour utiliser un proxy avec

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

ou utilisez

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

sur Windows. Si votre environnement utilise l’inspection TLS, importez l’autorité de certification racine (CA) de confiance du proxy dans le magasin de la machine afin que l’agent puisse valider les points de terminaison Azure.

Le pare-feu et les listes d’autorisation de sortie (egress) doivent autoriser le trafic sortant sur le port 443 vers Microsoft Entra ID (pour l’authentification), Azure Resource Manager et les services Arc régionaux. Si vous prévoyez d’utiliser Update Management Center et Automanage, autorisez également Windows Update/Microsoft Update et les dépôts de votre distribution Linux, ainsi que les points de terminaison de livraison de contenu (CDN) qui distribuent les paquets. Arc ne nécessite aucune ouverture de port entrant sur le pare-feu ; tout le trafic de contrôle provient du serveur vers Azure.

Le RBAC pour les serveurs avec Azure Arc suit le modèle d’Azure. Utilisez les rôles intégrés pour séparer les responsabilités :

• Azure Connected Machine Onboarding permet de créer des ressources ConnectedMachine via des principaux de service tout en empêchant des droits de modification plus larges.
• Azure Connected Machine Resource Administrator gère la ressource de serveur Arc et ses extensions sans accorder de permissions à l’échelle de l’abonnement.
• Azure Connected Machine User Login et Azure Connected Machine Administrator Login contrôlent l’accès interactif lors de l’activation de la connexion basée sur Azure AD via SSH (Linux) ou RDP/WinRM (Windows). Organisez les machines Arc dans des groupes de ressources qui reflètent l’environnement (Prod/NonProd), la géographie, l’unité commerciale ou le cercle de correctifs (patch ring). Appliquez la portée des stratégies, des verrous et des attributions de rôle au niveau du groupe de ressources ou du groupe d’administration pour simplifier la gouvernance.

L’accès SSH sécurisé sans adresse IP publique est pris en charge grâce au tunnel juste-à-temps (just-in-time) d’Arc. Installez l’extension AADSSHLoginForLinux pour activer l’authentification basée sur Entra ID et mapper les utilisateurs/groupes aux principaux locaux. Les utilisateurs autorisés disposant du rôle de connexion approprié peuvent exécuter

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

pour établir un tunnel TLS sortant et éphémère vers le démon SSH du serveur, sans nécessiter de port entrant, de VPN ou de bastion. Appliquez l’accès conditionnel (Conditional Access) et Privileged Identity Management pour limiter dans le temps les rôles de connexion.

Gouvernance et configuration à l’échelle : configuration invité d’Azure Policy et Automanage

La configuration invité est la capacité d’audit et de configuration intra-invité d’Azure Policy pour Arc. Les stratégies intégrées couvrent des bases de référence communes telles que s’assurer que l’agent Azure Monitor est installé, auditer les stratégies de mot de passe, imposer le mode BitLocker ou FIPS sur Windows lorsque cela est pris en charge, ou exiger des installations syslog spécifiques sur Linux. Assignez ces stratégies à l’échelle aux étendues Arc, et la plateforme déploie l’extension Guest Configuration selon les besoins. Pour les stratégies personnalisées, créez un package de configuration invité basé sur DSC qui exprime l’état souhaité (par exemple, une configuration SSHD renforcée ou des règles de pare-feu Windows), publiez-le en tant que définition de stratégie personnalisée, puis assignez-le à votre étendue Arc.

Les tâches de remédiation transforment les audits en actions. Les stratégies avec des effets DeployIfNotExists ou Modify peuvent créer ou modifier la configuration, et vous pouvez déclencher une remédiation à la demande pour mettre en conformité les machines existantes. Pour les dérives récurrentes, activez la remédiation automatique afin que le moteur de stratégie réapplique l’état souhaité. Suivez la posture de conformité par stratégie, par machine et par étendue dans le panneau Conformité (Compliance blade) et exportez les preuves pour les régulateurs depuis la même interface utilisateur.

Azure Automanage pour les serveurs avec Arc opérationnalise les « meilleures pratiques pour les machines ». Sélectionnez un profil de configuration approprié pour le Dev/Test ou la Production et la plateforme intègre la machine dans un ensemble de services sélectionnés : Azure Monitor (via l’AMA et un profil VM insights), Update Management Center avec des fenêtres de maintenance définies, Change Tracking and Inventory, l’activation du plan Microsoft Defender for Cloud et les bases de référence de sécurité du système d’exploitation principal. Automanage détecte en continu les dérives par rapport au profil choisi et y remédie lorsque cela est pris en charge, tout en offrant une visibilité sur les éléments nécessitant une intervention manuelle dans les environnements non-Azure. Comme Automanage utilise Azure Policy en arrière-plan, vous pouvez déployer des profils à l’échelle et vous fier au même modèle de rapport de conformité.

Opérations et supervision : Update Management Center, AMA et DCR, et extensions Arc

Update Management Center (UMC) est le service de correctifs moderne et léger en agent pour les machines Azure et Arc. Il évalue en continu les mises à jour de sécurité et non liées à la sécurité manquantes, présente la conformité par gravité et classification, et prend en charge les configurations de maintenance ponctuelles et récurrentes. Définissez des fenêtres de maintenance avec une durée maximale, un comportement de redémarrage (Jamais, Si nécessaire ou Toujours), des scripts pré et post-exécution, et un ciblage dynamique à l’aide de requêtes et de balises Azure afin que les nouvelles machines Arc correspondant aux critères soient automatiquement incluses. Pour Windows, UMC s’approvisionne auprès de Windows Update/Microsoft Update ou de WSUS s’il est configuré ; pour Linux, auprès des dépôts de paquets configurés. Utilisez les rapports de conformité pour suivre le pourcentage de correctifs appliqués par étendue, afficher les échecs avec des codes d’erreur granulaires et exporter les données pour l’audit. Comme UMC ne dépend pas d’Azure Automation et de l’ancien agent MMA, il représente la voie stratégique à suivre pour l’orchestration des correctifs.

L’agent Azure Monitor (AMA) est le pipeline de télémétrie unifié pour les serveurs avec Arc. Plutôt que de coder en dur un espace de travail sur la machine, vous définissez des règles de collecte de données (DCR) qui décrivent :

• Quoi collecter : les journaux d’événements Windows, les installations et les niveaux de gravité syslog de Linux, les compteurs de performance et les signaux de suivi des modifications.
• Où l’envoyer : un ou plusieurs espaces de travail Log Analytics, Azure Monitor Metrics, et éventuellement Event Hubs.
• Comment transformer : mise en forme facultative des données avant l’ingestion. Associez les DCR au niveau de la ressource, du groupe de ressources, de l’abonnement ou du groupe d’administration. Cela découple la configuration de la machine et rend trivial le déplacement d’une machine entre des espaces de travail ou la collecte de données différentes dans des environnements différents. VM insights sur Arc utilise désormais l’AMA avec le profil DCR de VM insights pour les performances ; pour les cartes de dépendances et la topologie des processus, installez le Dependency Agent.

Les extensions sont le mécanisme de livraison pour les capacités intra-invité. Gérez-les depuis le panneau Extensions du serveur Arc, la CLI ou via une stratégie (Policy) :

• Microsoft Monitoring Agent (MMA) est l’ancien agent et il est déprécié pour la plupart des solutions ; ne l’utilisez que si une dépendance n’a pas encore migré vers l’AMA.
• Azure Monitor Agent (AMA) est l’agent par défaut actuel pour les journaux et les métriques ; associez-le à des DCR.
• Dependency Agent fournit des cartes de services et de processus, nécessaires pour la carte de VM insights jusqu’à ce que son remplacement complet soit terminé.
• Custom Script Extension (Windows/Linux) exécute des scripts à l’échelle pour le démarrage (bootstrap) ou des actions correctives lorsque la remédiation par stratégie ne peut pas exprimer le changement souhaité.
• AADSSHLoginForLinux et AADLoginForWindows activent la connexion avec Entra ID. D’autres extensions courantes incluent Defender for Endpoint et les clients de gestion de la configuration. Utilisez Azure Policy pour vous assurer que les extensions requises sont présentes et saines. Les mises à jour, les restaurations (rollbacks) et l’état des extensions sont visibles dans la ressource et dans le journal d’activité (Activity log) pour l’audit.

Inventaire, conformité et reporting avec Azure Resource Graph

Les requêtes Azure Resource Graph (ARG) renvoient un état d’inventaire et de conformité quasi en temps réel pour tous les serveurs avec Arc, sans nécessiter d’agents. Utilisez-le pour piloter la synchronisation des CMDB, l’hygiène des étiquettes (tags) et la sélection des étendues pour les stratégies et l’application des correctifs. Les modèles courants incluent :

• Inventaire hybride par SE et emplacement :

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

• Préparation pour 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

• Reporting basé sur les étiquettes et ciblage des anneaux de correctifs :

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

• Synthèse de la conformité aux stratégies :

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

Ces requêtes sous-tendent les étendues dynamiques dans Update Management Center, les attributions Automanage et les tableaux de bord. Standardisez un ensemble minimal d’étiquettes (Environment, PatchRing, BusinessUnit, Owner) lors de l’intégration afin qu’ARG reste exploitable.

Scénario de problème pratique

Contoso Ltd. possède 600 machines virtuelles Windows Server et Linux sur site, hébergées dans deux datacenters et gérées par Configuration Manager et Ansible. La direction exige une surveillance standardisée, une application mensuelle des correctifs avec des fenêtres de maintenance strictes le samedi, l’intégration à Sentinel et un accès SSH sécurisé pour les ingénieurs sans exposer d’adresses IP publiques. Elle souhaite également des preuves de conformité pour les auditeurs et un effort d’administration continu minimal.

1. Préparer l’accès à privilège minimum

• Créez un principal de service dont la portée est limitée aux groupes de ressources (RG) qui contiendront les machines Arc et attribuez-lui le rôle Azure Connected Machine Onboarding. Cela permet une intégration sans surveillance via les outils existants sans accorder de droits étendus. Pourquoi : L’intégration basée sur un principal de service est évolutive et respecte le principe du moindre privilège.

2. Intégrer les machines avec l’automatisation

• Utilisez le script d’intégration Arc généré avec le principal de service dans Configuration Manager pour Windows et Ansible pour Linux afin d’installer azcmagent et d’enregistrer chaque serveur dans le groupe de ressources approprié (étiqueté avec Environment et PatchRing). Pourquoi : Réutilise les outils de déploiement existants pour un déploiement rapide et cohérent, et intègre des étiquettes pour la gouvernance en aval.

3. Établir la sortie réseau et proxy

• Assurez la sortie sur le port 443 vers Entra ID, Azure Resource Manager, les points de terminaison régionaux d’Arc, Windows Update/Microsoft Update et les dépôts de distribution. Configurez les paramètres de proxy d’azcmagent et importez l’autorité de certification racine d’inspection TLS si nécessaire. Pourquoi : Garantit la santé de l’agent et des extensions, la récupération des mises à jour et évite la dérive de connectivité.

4. Appliquer les bases de référence avec la configuration invité d’Azure Policy

• Attribuez des stratégies intégrées pour déployer l’extension Guest Configuration, l’AMA et le Dependency Agent. Appliquez un package de configuration invité personnalisé pour renforcer les paramètres SSH et RDP. Activez la remédiation automatique pour les paramètres critiques. Pourquoi : La stratégie exprime l’état souhaité à grande échelle, détecte les dérives et corrige les écarts.

5. Standardiser les opérations avec Automanage

• Attribuez le profil Automanage for Arc Production aux RG de production et le profil Dev/Test aux environnements hors production. Examinez tous les éléments marqués comme manuels pour les ressources non-Azure. Pourquoi : Automanage applique en continu les meilleures pratiques avec un effort minimal de la part de l’opérateur.

6. Configurer la surveillance et l’intégration à Sentinel

• Créez des règles de collecte de données (DCR) pour collecter les Windows SecurityEvent, les journaux d’authentification Syslog et les compteurs de performance dans un espace de travail Log Analytics central connecté à Microsoft Sentinel. Utilisez Azure Policy pour associer les DCR à toutes les machines Arc et pour déployer les packs de solutions Sentinel selon les besoins. Pourquoi : AMA + DCR découplent la collecte des machines, et Azure Policy fournit la méthode d’intégration à effort minimal validée dans les scénarios d’examen.

7. Orchestrer l’application des correctifs avec Update Management Center

• Définissez des configurations de maintenance mensuelles récurrentes par étiquette PatchRing avec une fenêtre de 4 heures le samedi, un redémarrage si nécessaire et des hooks de notification. Utilisez des étendues dynamiques basées sur les étiquettes pour que les nouvelles machines soient automatiquement incluses. Pourquoi : UMC offre une gouvernance des correctifs légère en agents, pilotée par les étiquettes, avec des rapports de conformité auditables.

8. Activer l’accès SSH sécurisé sans adresses IP publiques

• Déployez AADSSHLoginForLinux via Policy et accordez aux ingénieurs le rôle Azure Connected Machine User Login sur les RG cibles via Privileged Identity Management. Donnez pour instruction aux ingénieurs d’utiliser az ssh arc avec une activation juste-à-temps. Pourquoi : Le tunneling Arc élimine le besoin d’entrées publiques ou de serveurs de rebond, et Entra ID avec PIM fournit un accès à privilège minimum et limité dans le temps.

9. Générer des rapports et auditer avec Resource Graph et la Conformité

• Créez des workbooks ARG pour visualiser l’inventaire Arc par environnement, la couverture AMA/Dependency Agent, les tendances de conformité des stratégies et la conformité des correctifs UMC par PatchRing. Exportez mensuellement les preuves de conformité. Pourquoi : ARG et les plans de conformité de Policy/UMC centralisent les preuves et réduisent la charge de travail liée aux audits.

En combinant l’intégration basée sur un principal de service, le déploiement d’extensions et de configurations invité piloté par Policy, les profils Automanage, l’AMA avec les DCR, l’application de correctifs UMC, l’accès SSH Arc et le reporting Resource Graph, Contoso parvient à une gestion de serveurs hybrides sécurisée, cohérente et auditable avec une intervention manuelle minimale.

← Sécurité des services de domaine Active Directory · Tous les domaines · Chiffrement →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →