Microsoft AZ-900: Surveillance, automatisation et gestion — Guide d'étude
Fait partie du Microsoft Azure AZ-900 — 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.
L’excellence opérationnelle dans Azure repose sur des plateformes observables, une automatisation reproductible et une gouvernance unifiée sur les parcs cloud et hybrides. Azure Monitor fournit le socle de télémétrie pour les métriques, les journaux, les traces et les insights applicatifs de bout en bout. Les outils de gestion — allant du portail Azure au CLI et à PowerShell — permettent aux équipes d’agir sur ces insights à grande échelle. Les services d’automatisation, associés à Azure Arc et Azure Lighthouse, étendent le contrôle aux serveurs et aux clusters n’importe où et rationalisent les opérations inter-locataires pour les fournisseurs de services et l’informatique centrale.
Azure Monitor : métriques, journaux, alertes et Application Insights
Azure Monitor collecte deux principaux types de signaux : les métriques et les journaux. Les métriques sont des séries temporelles numériques légères, optimisées pour des scénarios quasi temps réel tels que les tableaux de bord et la mise à l’échelle automatique (autoscale), et sont généralement conservées pendant 93 jours. Les journaux sont des enregistrements riches au schéma flexible, stockés dans des espaces de travail Log Analytics et interrogés avec le langage de requête Kusto (KQL). Avec l’agent Azure Monitor et les règles de collecte de données (DCR), les données des machines virtuelles, des serveurs compatibles Arc et des diagnostics de la plateforme peuvent être acheminées vers un ou plusieurs espaces de travail à travers les régions pour une analyse centralisée et une conservation à long terme. La conservation des journaux standard est configurable — généralement de 30 à 730 jours — avec un archivage à faible coût et une réhydratation disponibles pour les investigations historiques. Application Insights, bâti sur Azure Monitor, instrumente les applications pour le suivi distribué, le suivi des dépendances, les tests de disponibilité et la détection automatique d’anomalies. Il prend en charge OpenTelemetry pour une ingestion neutre vis-à-vis du fournisseur, permettant aux développeurs de corréler les appels client, serveur et base de données en une seule carte de transaction. Live Metrics fournit une télémétrie serveur à la seconde, sans échantillonnage, tandis que l’échantillonnage adaptatif réduit les coûts d’ingestion sans perdre la traçabilité de bout en bout pour les défaillances critiques. Les alertes couvrent les étendues de ressource, d’abonnement et de locataire. Les alertes de métrique évaluent des seuils de séries temporelles avec une granularité d’une minute et peuvent s’ajuster automatiquement via des seuils dynamiques. Les alertes de journal exécutent des requêtes KQL planifiées pour détecter des modèles complexes sur plusieurs ressources et régions, tandis que les alertes de journal d’activité se déclenchent sur des événements du plan de contrôle tels que la création, la mise à jour ou la suppression. Les groupes d’actions découplent la détection de la réponse, déclenchant des notifications (e-mail, SMS, push, vocal) et des automatisations (webhook/webhook sécurisé, Logic Apps, Functions, runbooks Automation, connecteurs ITSM). Les règles de suppression et les règles de traitement des alertes aident à réduire le bruit en désactivant ou en routant les alertes pendant les fenêtres de maintenance planifiée. Les tableaux de bord (Dashboards) et les classeurs (Workbooks) présentent la télémétrie différemment. Les tableaux de bord Azure sont des canevas basés sur des vignettes et inter-services, idéaux pour des vues opérationnelles rapides et pour épingler des graphiques de métriques. Les classeurs sont analytiques, paramétrés et collaboratifs, mêlant métriques, journaux et visualisations avec une interactivité pilotée par des requêtes. Les classeurs excellent pour les guides opérationnels (runbooks), les analyses post-incident et les revues de service, où les opérateurs peuvent pivoter entre les dimensions et explorer les données brutes sans quitter le contexte.
Service Health et signaux de résilience des ressources
La disponibilité et la maintenance de la plateforme nécessitent une surveillance dédiée, au-delà des métriques des ressources. Azure Service Health fournit une visibilité personnalisée sur les problèmes de service, la maintenance planifiée et les avis d’intégrité affectant les régions et services spécifiques d’un abonnement. Il complète la page publique État d’Azure (Azure Status) en fournissant l’impact à l’échelle de l’abonnement, des chronologies et des analyses de cause racine lorsqu’elles sont disponibles. Des alertes d’intégrité peuvent être configurées pour notifier les équipes opérationnelles via des groupes d’actions dès qu’un incident de service régional impacte les charges de travail déployées. Resource Health se concentre sur l’état des ressources individuelles telles que les machines virtuelles, les services d’application ou les bases de données. Il distingue les perturbations causées par la plateforme des événements initiés par l’utilisateur, fournissant les états d’intégrité actuels et historiques. L’intégration des alertes Service Health et Resource Health à la gestion des incidents garantit que les équipes sont notifiées lorsque la plateforme est la cause racine, réduisant le temps passé à dépanner des composants applicatifs sains. La combinaison de ces signaux avec les alertes Azure Monitor offre une visibilité complète (full-stack) : la performance applicative, l’utilisation de l’infrastructure et la disponibilité de la plateforme dans une vue opérationnelle unique.
Outils de gestion pour le contrôle opérationnel
Les tâches opérationnelles couvrent le dépannage interactif, l’automatisation scriptée et le triage mobile. Le portail Azure offre une expérience complète, basée sur les rôles, pour configurer les services, visualiser les métriques et lancer Cloud Shell directement en contexte. L’application mobile Azure prend en charge les vérifications d’état en déplacement, l’acquittement des alertes et les actions rapides comme le redémarrage d’une VM. Pour la répétabilité et l’intégration avec la CI/CD, Azure CLI et Azure PowerShell fournissent une automatisation multiplateforme avec une authentification cohérente via Microsoft Entra ID et la prise en charge des flux interactifs et non interactifs. Cloud Shell fournit un terminal sécurisé basé sur un navigateur avec Bash et PowerShell, préchargé avec Azure CLI, les modules Az PowerShell et des outils courants comme Git et Terraform. Les sessions s’exécutent dans un conteneur maintenu par Microsoft ; un partage Azure Files assure la persistance des profils utilisateur et des scripts. Cela élimine la dérive des outils locaux et simplifie les opérations juste-à-temps exécutées depuis le portail, sans avoir à gérer d’environnements d’exécution. Pour l’automatisation de longue durée ou à haut débit, hébergez CLI/PowerShell dans des pipelines ou des exécuteurs conteneurisés et authentifiez-vous avec des identités managées ou des informations d’identification fédérées pour éviter la prolifération des secrets.
- Azure portal
- Interface : Interface utilisateur web
- Idéal pour : Configuration, visualisation, tâches ad hoc
- Points forts : Expérience utilisateur riche, couverture de service étendue, Cloud Shell intégré
- Limites : Manuel, moins adapté au scripting à grande échelle
- Azure mobile app
- Interface : iOS/Android
- Idéal pour : Triage et actions rapides
- Points forts : Acquittement des alertes, actions de base sur les ressources, accès en déplacement
- Limites : Profondeur de configuration limitée
- Cloud Shell
- Interface : Shell de navigateur
- Idéal pour : Commandes ad hoc sans configuration locale
- Points forts : Outils préinstallés, répertoire personnel persistant via Azure Files, contexte sécurisé
- Limites : Conteneur éphémère ; ne convient pas aux tâches batch de longue durée
- Azure CLI (az)
- Interface : Ligne de commande
- Idéal pour : Scripting multiplateforme et pipelines
- Points forts : Syntaxe cohérente, sortie JSON, extensibilité
- Limites : Courbe d’apprentissage pour les graphes de ressources complexes
- Azure PowerShell (Az)
- Interface : Modules PowerShell
- Idéal pour : Automatisation Windows/Linux/macOS ; opérations centrées sur les objets
- Points forts : Riche couverture de cmdlets, objets pouvant être traités par pipeline
- Limites : Empreinte plus lourde ; nécessite la gestion du cycle de vie des modules
Automatisation : runbooks, gestion des mises à jour et planification des VM optimisée pour les coûts
Azure Automation fournit un service de runbooks managés pour orchestrer les tâches opérationnelles. Les runbooks peuvent être créés en PowerShell, Python ou sous forme de workflows graphiques, déclenchés par des planifications, via des webhooks ou par des alertes via des groupes d’actions. Les comptes d’identification (« Run-as accounts ») ont évolué vers les identités managées, qui suppriment la gestion des certificats et des secrets tout en prenant en charge un accès granulaire selon le principe du moindre privilège. Les Hybrid Runbook Workers étendent l’automatisation aux réseaux privés ou aux emplacements en périphérie (« edge »), en exécutant des runbooks sur des ressources sur site ou isolées tout en restant gérés depuis Azure. La gouvernance des correctifs est gérée par Azure Update Manager, qui unifie les mises à jour du système d’exploitation pour Windows et Linux sur les VM Azure et les serveurs compatibles avec Arc. Les configurations de maintenance définissent les planifications, le comportement de redémarrage, les scripts pré/post-exécution et les étendues dynamiques à l’aide de balises ou de requêtes enregistrées. Les rapports de conformité mettent en évidence les mises à jour manquantes et le succès des déploiements, tandis que les intégrations avec Azure Policy appliquent les configurations de base. Update Manager remplace l’ancienne solution Update Management d’Azure Automation, offrant une mise à l’échelle, une granularité et une prise en charge native d’Arc améliorées. Pour minimiser les dépenses de calcul pour les charges de travail qui ne fonctionnent pas 24h/24 et 7j/7, Azure propose plusieurs options pour arrêter et démarrer les machines virtuelles selon une planification. La solution Start/Stop VMs v2 orchestre le ciblage basé sur des balises, les planifications par fuseau horaire pour les heures de bureau, la détection d’inactivité et des notifications facultatives, en utilisant Azure Automation et Azure Monitor en arrière-plan. Les VM individuelles prennent également en charge des stratégies d’arrêt automatique, et les Virtual Machine Scale Sets peuvent utiliser des règles de mise à l’échelle automatique basées sur des métriques. La combinaison de la mise à l’échelle basée sur les métriques avec l’arrêt/démarrage planifié génère des économies prévisibles sans sacrifier les niveaux de service pendant les périodes de forte demande.
Opérations hybrides et inter-locataires : Azure Arc, Azure Lighthouse et Kusto inter-espaces de travail
Azure Arc projette les ressources non-Azure — serveurs, clusters Kubernetes, instances SQL Server — dans Azure Resource Manager afin qu’elles puissent être étiquetées, se voir attribuer des stratégies, être surveillées et mises à jour comme des ressources natives. L’agent Azure Monitor et les règles de collecte de données (Data Collection Rules) poussent la télémétrie des machines compatibles avec Arc vers un ou plusieurs espaces de travail Log Analytics, permettant une observabilité centralisée quel que soit l’emplacement. Pour Kubernetes, Arc intègre GitOps avec Flux pour une gestion déclarative des clusters et prend en charge des extensions pour déployer des agents pour Defender for Cloud, le scraping Prometheus et l’application de stratégies. Azure Lighthouse permet une gestion sécurisée et à grande échelle des ressources à travers les locataires (tenants) Microsoft Entra ID, ce qui est idéal pour les fournisseurs de services ou les équipes de plateforme centralisées qui soutiennent plusieurs unités commerciales. Les délégations accordent un accès juste suffisant via Azure RBAC au niveau de l’abonnement, du groupe de ressources ou de la ressource, tandis que toutes les actions sont auditées dans le locataire du client. Les opérateurs peuvent interroger les journaux, déployer des stratégies et exécuter des automatisations sur plusieurs locataires à partir d’un contexte unique, réduisant ainsi les frictions de connexion et éliminant la prolifération des informations d’identification inter-locataires. Le langage de requête Kusto (Kusto Query Language) prend en charge les analyses inter-ressources et inter-régions en interrogeant plusieurs espaces de travail et ressources Application Insights en une seule instruction. Les modèles courants incluent l’union sur plusieurs espaces de travail et les jointures pour corréler les traces applicatives avec les journaux d’infrastructure. Exemple :
undefined
. Un autre exemple corrèle les requêtes et les exceptions sur deux applications :
undefined
. Avec le routage multi-destination basé sur les DCR, les journaux des ressources Arc et Azure peuvent être stockés dans des espaces de travail régionaux tout en restant interrogeables de manière agrégée, assurant à la fois la résidence des données et des analyses globales.
Problème pratique : GlobalRetail Co. construit un centre névralgique des opérations pour un parc hybride
Scénario : GlobalRetail Co. exploite des services de point de vente dans 1 200 magasins, avec des centres de données régionaux à Dublin et Singapour et une empreinte Azure croissante pour les charges de travail web et analytiques. La direction souhaite une vue opérationnelle unique, l’application automatisée des correctifs et un contrôle des coûts pour les VM de développement, tandis qu’un fournisseur de services managés (MSP) externe assure le support de nuit pour tous les environnements.
Défi : Unifier la surveillance et les alertes sur les serveurs Azure et sur site, mettre en œuvre des mises à jour d’OS automatisées avec des fenêtres de maintenance, réduire les coûts des VM en dehors des heures de bureau en dev/test, et permettre des opérations inter-locataires sécurisées pour le MSP sans partager d’informations d’identification permanentes.
Approche recommandée :
- Déployer Azure Arc sur tous les serveurs Windows et Linux sur site ; activer l’agent Azure Monitor via des règles de collecte de données (Data Collection Rules) pour envoyer les données de plateforme, syslog/Event et de performance vers des espaces de travail Log Analytics régionaux.
- Instrumenter les charges de travail web et API avec Application Insights en utilisant OpenTelemetry ; configurer des tests de disponibilité depuis plusieurs régions et activer l’échantillonnage adaptatif et la détection intelligente.
- Créer des alertes de métriques, de journaux et de journal d’activité Azure Monitor pour les signaux critiques ; centraliser les notifications avec des groupes d’actions qui déclenchent des e-mails, des messages Teams via webhook et une connexion à un connecteur ITSM pour ouvrir automatiquement des incidents.
- Publier des Workbooks d’opérations combinant les échecs/latences d’App Insights, les performances des VM (InsightsMetrics) et les journaux d’activité de la plateforme ; épingler les graphiques clés sur un tableau de bord Azure à l’échelle de l’organisation.
- Mettre en œuvre Azure Update Manager avec des configurations de maintenance par région et type de magasin ; utiliser des pre-scripts pour drainer le trafic et des post-scripts pour valider la santé du service ; imposer la conformité via des attributions Azure Policy.
- Déployer Start/Stop VMs v2 en ciblant les abonnements dev/test à l’aide des étiquettes
undefined
et
undefined
; définir des plannings d’heures de bureau par fuseau horaire local et activer l’arrêt sur inactivité pour les fenêtres de faible utilisation. 7. Intégrer le MSP via une délégation Azure Lighthouse au niveau du groupe d’administration avec un rôle personnalisé de moindre privilège ; exiger une élévation juste-à-temps avec PIM et restreindre l’accès aux runbooks de secours (break-glass) instrumentés avec la journalisation des activités. 8. Rédiger des requêtes KQL qui unifient les espaces de travail de Dublin et Singapour pour les taux d’utilisation du CPU, de la mémoire et d’erreurs du parc ; planifier des alertes de journal pour détecter les pics et les acheminer vers le groupe d’actions du MSP en dehors des heures de bureau. 9. Configurer des alertes Service Health et Resource Health pour les régions/services impactés ; créer une automatisation d’incident qui publie les avis et les liens de l’analyse des causes racines (RCA) dans le ticket d’incident.
Justification Azure : Azure Arc standardise la gouvernance et la télémétrie pour les serveurs non-Azure, permettant à Azure Monitor de consolider les métriques et les journaux à travers les régions. Application Insights fournit une visibilité de bout en bout des transactions afin que les équipes opérationnelles puissent distinguer les défaillances applicatives des problèmes d’infrastructure. Les groupes d’actions et l’intégration ITSM assurent une création d’incidents automatisée et rapide, tandis que les Workbooks et les tableaux de bord fournissent une vision opérationnelle partagée. Update Manager impose une hygiène de correctifs cohérente dans les fenêtres de maintenance, et Start/Stop VMs v2 réduit les dépenses de dev/test sans affecter la productivité. Azure Lighthouse accorde au MSP un accès sécurisé, auditable et de moindre privilège à travers les locataires, et le KQL inter-espaces de travail relie la télémétrie globale pour une détection proactive et un diagnostic rapide.
← Gouvernance et conformité · Tous les domaines · Support →
Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Réussissez votre examen →