Microsoft AZ-104: Azure Monitor, Sauvegarde et Site Recovery — Guide d'étude

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Administrator Associate AZ-104 — 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

L’excellence opérationnelle sur Azure requiert la collaboration de trois piliers : une télémétrie observable, des données récupérables et des plans de continuité résilients. Azure Monitor et sa fondation Log Analytics collectent des métriques et des journaux de haute fidélité, génèrent des alertes intelligentes et exposent les performances des applications. Azure Backup protège les données de la plateforme et IaaS avec une récupération basée sur des coffres et pilotée par des stratégies, incluant des capacités de restauration instantanée pour un temps d’arrêt minimal. Azure Site Recovery (ASR) réplique les charges de travail vers des sites alternatifs et orchestre le basculement et la restauration (failover et failback) pour respecter les RPO/RTO de l’entreprise. Des services complémentaires — Network Watcher pour les diagnostics réseau et Azure Service Health pour la connaissance de la plateforme — complètent une boîte à outils complète pour l’administrateur.

Azure Monitor et Log Analytics

Azure Monitor unifie les métriques et les journaux de la plateforme. Les métriques sont des séries temporelles numériques optimisées pour l’analyse en quasi-temps réel (haute cardinalité, multidimensionnelles, avec une granularité d’une minute pour la plupart des ressources). Utilisez Metrics Explorer pour la visualisation et les alertes de métrique en quasi-temps réel avec des seuils statiques ou dynamiques. Les journaux sont des enregistrements à schéma riche stockés dans un espace de travail Log Analytics, interrogés avec le Kusto Query Language (KQL) pour l’investigation, les tableaux de bord et les alertes planifiées (de journal).

Les paramètres de diagnostic sont le pont entre les ressources et les récepteurs de télémétrie. Sur chaque ressource Azure, configurez les paramètres de diagnostic pour choisir des catégories (métriques de plateforme, journaux de plateforme et journaux de ressources) et les acheminer vers une ou plusieurs destinations :

Espace de travail Log Analytics pour l’analyse et les alertes basées sur les journaux
Comptes de stockage pour la conservation à long terme et à faible coût, et pour la conformité
Event Hubs pour le streaming vers des SIEM ou des outils tiers

Concevez les espaces de travail Log Analytics de manière délibérée :

Portée et accès de l’espace de travail : Utilisez le RBAC au niveau de l’espace de travail et de la table pour vous aligner sur le moindre privilège et les frontières opérationnelles (par exemple, par environnement et par région). Les requêtes en contexte de ressource permettent aux équipes d’interroger les journaux limités aux ressources auxquelles elles ont accès, même si les journaux sont centralisés.
Collecte de données : Préférez l’agent Azure Monitor (AMA) avec les règles de collecte de données (DCRs) aux agents hérités. Les DCRs définissent ce qu’il faut collecter (compteurs de performance, journaux d’événements Windows/Linux, syslog, journaux de texte personnalisés), depuis quelles machines, et dans quelles tables, permettant des pipelines granulaires par portée.
Coût et rétention : Contrôlez les coûts avec la rétention par table, l’archivage et les journaux de base le cas échéant. Utilisez l’échantillonnage et le filtrage au moment de la collecte lorsque c’est possible.
Sources de données : Azure Activity Log, journaux de ressources via les paramètres de diagnostic, VM insights et Container insights, journaux de connexion et d’audit Azure AD (via les paramètres de diagnostic), journaux de flux Azure Firewall/NSG, journaux d’application personnalisés, et sur site via l’agent Azure Monitor.

La maîtrise de KQL est essentielle. Exemples :

Audit rapide :

undefined

Triage des performances :

undefined

Taux d’erreur :

undefined

Les groupes d’actions définissent qui et quoi répond aux alertes : e-mail/SMS/push/voix, webhooks sécurisés, connecteurs ITSM, Functions, Logic Apps et runbooks Automation. Réutilisez les groupes d’actions à travers les règles d’alerte et appliquez un routage d’incidents cohérent.

Azure Monitor prend en charge plusieurs types d’alertes :

Alertes de métrique : Évaluent les métriques de plateforme ou personnalisées à une cadence quasi-temps réel avec des seuils statiques ou des seuils dynamiques qui apprennent les lignes de base normales.
Alertes de journal (requête planifiée) : Exécutent une requête KQL sur les données de l’espace de travail à une fréquence configurée ; se déclenchent sur le nombre de résultats ou un agrégat numérique. Utiles pour les modèles complexes sur plusieurs ressources.
Alertes du journal d’activité : Se déclenchent sur des événements du plan de contrôle (par exemple, lorsqu’une VM est supprimée ou qu’une attribution de rôle change). Celles-ci ne nécessitent pas d’espace de travail.
Détection intelligente : Détection d’anomalies et pics de taux d’échec principalement pour les ressources Application Insights ; notifie automatiquement les propriétaires et peut s’intégrer avec des groupes d’actions.

Application Insights et Alertes

Application Insights instrumente le code et la plateforme pour fournir une télémétrie d’application de bout en bout. Utilisez des chaînes de connexion et des SDK de premier ordre (.NET, Java, Node.js, Python) ou OpenTelemetry pour un traçage neutre vis-à-vis du fournisseur. Pour les services PaaS (App Service, Functions, AKS), activez l’auto-instrumentation là où elle est disponible pour capturer les requêtes, les dépendances, les exceptions et les traces sans modification du code. Maintenez le contexte de traçage distribué pour corréler les sauts entre le client, l’API et le backend.

Types de télémétrie clés :

Requêtes : Opérations entrantes avec codes de réponse et durée
Dépendances : Appels sortants (HTTP, SQL, files d’attente) avec durée et succès
Exceptions et Traces : Erreurs et journaux de diagnostic avec leur gravité
Métriques : Compteurs personnalisés ou standards
Vues de page et timings du navigateur : Performances du front-end
Événements et mesures personnalisés : Signaux spécifiques au domaine

Appliquez l’échantillonnage adaptatif pour contrôler le volume d’ingestion sans perdre la fidélité du signal, et utilisez Live Metrics Stream pour un aperçu à faible latence pendant les incidents.

Les tests de disponibilité valident la joignabilité externe et le SLA :

Tests standards (ping d’URL) : Sondent des points de terminaison depuis plusieurs régions Azure, valident les codes de statut, les fenêtres d’expiration SSL, la correspondance de contenu et les seuils de temps de réponse.
Tests personnalisés : Utilisez TrackAvailability dans le code pour des workflows synthétiques ou des points de terminaison protégés. Les échecs peuvent produire automatiquement des alertes connectées à des groupes d’actions.

Augmentez les alertes avec la détection intelligente dans Application Insights pour :

Anomalies d’échec et dégradation des performances
Fuites de mémoire et anomalies de dépendance Ces fonctionnalités apprennent les modèles typiques et réduisent les faux positifs, complétant les alertes basées sur des seuils.

Azure Backup

Un coffre Recovery Services sert de point d’ancrage pour la gestion des sauvegardes, les stratégies et la récupération. Placez les coffres dans la même région que les ressources protégées (ou dans la région jumelée pour les scénarios de restauration inter-régions pris en charge par le service). Renforcez la sécurité des coffres avec la suppression réversible (soft delete), la protection contre la purge et l’autorisation multi-utilisateur pour les opérations critiques.

Les stratégies de sauvegarde définissent les planifications et la rétention :

Sauvegarde de machines virtuelles Azure (Azure VM) : Instantanés quotidiens avec rétention à court terme, rétention à long terme hebdomadaire/mensuelle/annuelle en option ; points de récupération cohérents avec les applications via VSS (Windows) ou des scripts pré/post (Linux) lorsque l’option est activée.
Sauvegarde Azure Files : Sauvegardes quotidiennes basées sur des instantanés de partage ; rétention selon les besoins de l’entreprise ; prend en charge la restauration vers le partage d’origine ou un autre partage avec une récupération au niveau de l’élément.
SQL Server dans les machines virtuelles Azure : Les sauvegardes complètes (quotidiennes/hebdomadaires), différentielles (quotidiennes) et des journaux de transactions (jusqu’à toutes les 15 minutes) permettent une restauration à un instant dans le temps (point-in-time). La protection automatique (Auto-protect) découvre les nouvelles bases de données.

La restauration instantanée (Instant Restore) accélère les récupérations de machines virtuelles en utilisant des instantanés stockés localement et conservés pendant une courte période avant le stockage en profondeur dans le coffre. Les administrateurs peuvent :

Restaurer une machine virtuelle entière (nouvelle ressource de calcul) pour minimiser le temps de récupération (time-to-recover)
Restaurer des disques et les rattacher à une machine virtuelle existante pour une réparation ciblée
Effectuer une récupération de fichiers et de dossiers en montant un point de récupération en tant que périphérique iSCSI temporaire sur n’importe quelle machine virtuelle de l’abonnement (si le rôle le permet), permettant des restaurations chirurgicales après des événements comme une attaque par rançongiciel (ransomware)

Les considérations relatives à la sauvegarde de machines virtuelles incluent l’exclusion de disques pour les données non critiques, la gestion du chiffrement (Azure Backup prend en charge les disques chiffrés) et les modèles de cohérence (cohérence en cas de crash ou cohérence applicative). La sauvegarde Azure Files s’appuie sur les instantanés de stockage, bénéficiant d’une rétention incrémentielle, économe en espace, et de la protection par suppression réversible (soft delete). La sauvegarde de SQL dans les machines virtuelles Azure utilise une extension sensible à la charge de travail (workload-aware), coordonnée par le coffre, pour produire des chaînes de sauvegarde conformes et restaurables à travers les groupes de disponibilité Always On et les instances autonomes.

Azure Site Recovery, Network Watcher et Service Health

ASR assure la réplication des charges de travail et la récupération orchestrée :

Sources de réplication : D’un environnement local VMware/Hyper-V/physique vers Azure ; de région Azure à région Azure. Le service Mobilité sur les machines protégées capture les modifications et les réplique vers un stockage de cache/cible. Activez la cohérence multidisque pour les applications à plusieurs niveaux partageant un ordre d’écriture.
Configuration de la cible : Pré-créez ou mappez les groupes de ressources, les réseaux virtuels/sous-réseaux, les options de disponibilité (zones/groupes), les types de disques managés et les conventions de nommage. Utilisez le mappage réseau et les mises à jour DNS pour garantir l’accessibilité après le basculement.
Options de basculement : Basculement de test (validation isolée sans impact sur la production), Basculement planifié (zéro perte de données avec arrêt de la source) et Basculement non planifié (au mieux pendant les pannes). Après le basculement, effectuez une Reprotection pour inverser la réplication ; effectuez une Restauration (Failback) lorsque le site principal est prêt via des serveurs de processus ou une réplication directe, selon la source.
Plans de récupération : Orchestrez les niveaux multi-VM avec des groupes, des étapes d’approbation manuelle et des runbooks ou des scripts Azure Automation (pour le préchauffage des applications, la reconfiguration de l’équilibreur de charge et les changements DNS). Intégrez le séquencement et les délais d’attente pour atteindre un RTO prévisible.

Les objectifs RPO/RTO guident la stratégie :

Le RPO (perte de données acceptable) est déterminé par le taux de changement, le débit réseau et la fréquence de réplication. Définissez des seuils de RPO pour déclencher des alertes d’intégrité en cas de dépassement.
Le RTO (temps de restauration du service) dépend du temps de démarrage, des étapes d’orchestration, des mises à jour DNS/connexion et des opérations du plan de données (attachement de disque). Ajustez les plans de récupération, pré-provisionnez la capacité et utilisez les basculements de test pour valider que les objectifs sont atteints.
La stratégie de réplication définit la cadence des instantanés cohérents avec les applications et les fenêtres de rétention des points de récupération pour équilibrer le coût de stockage, la flexibilité de la récupération et les performances.

Azure Network Watcher fournit aux administrateurs des diagnostics réseau précis :

Vérification du flux IP : Valide si un flux est autorisé ou refusé par les règles NSG effectives sur une carte réseau (NIC), en identifiant la règle spécifique qui influence la décision.
Tronçon suivant (Next hop) : Calcule la décision de routage pour une destination donnée (Internet, réseau virtuel, appliance virtuelle), révélant les routes définies par l’utilisateur (UDR) et les routes système effectives.
Dépannage de connexion : Exécute des sondes de bout en bout entre la source et la destination à travers les réseaux virtuels et les liens hybrides, signalant l’accessibilité, la latence et le tronçon où la défaillance se produit.
Capture de paquets : Capture les paquets sur la carte réseau (NIC) d’une VM avec des filtres (protocole/port/IP), stockés dans un compte de stockage ou localement, utile pour une inspection approfondie des problèmes intermittents. Nécessite l’extension Network Watcher sur la VM.

Azure Service Health complète la surveillance avec une connaissance de la plateforme :

Problèmes de service : Événements de panne et de dégradation en temps réel impactant les services et régions sélectionnés, avec des mises à jour sur la cause racine et les mesures d’atténuation.
Maintenance planifiée : Notifications des fenêtres de maintenance de la plateforme à venir qui peuvent affecter les charges de travail, avec les plannings et les actions requises.
Avis d’intégrité : Recommandations de bonnes pratiques et de sécurité qui peuvent nécessiter des changements de configuration. Créez des alertes Service Health ciblées sur des services/régions/abonnements et acheminez-les via des groupes d’actions afin que les équipes opérationnelles soient informées avant l’impact. Utilisez Resource Health pour connaître l’état de disponibilité par ressource (Disponible, Dégradé, Indisponible, Inconnu) afin de distinguer les problèmes de plateforme des problèmes de charge de travail.

Scénario de problème pratique

Adobe doit renforcer et opérationnaliser une nouvelle plateforme e-commerce à deux régions sur Azure, en respectant des objectifs stricts d’observabilité, de sauvegarde et de reprise après sinistre, tout en garantissant un dépannage réseau rapide et une connaissance de la plateforme.

Déployez un espace de travail Log Analytics central par région et attachez des règles de collecte de données (DCR) à toutes les VM et à tous les nœuds AKS pour collecter les performances, les journaux syslog/EventLog et les journaux spécifiques aux ressources via les paramètres de diagnostic. Pourquoi : Les espaces de travail régionaux préservent la résidence des données et les performances ; l’association AMA+DCR offre une collecte granulaire et évolutive ainsi qu’un contrôle des coûts.
Configurez les paramètres de diagnostic sur App Service, Key Vault, Azure Firewall, Application Gateway et Storage pour acheminer les journaux et les métriques vers l’espace de travail régional et vers un compte de stockage pour une rétention à long terme. Pourquoi : L’analyse centralisée permet la corrélation entre les ressources ; la rétention en stockage répond aux besoins de conformité et d’investigation (forensic).
Instrumentez les niveaux web et API avec Application Insights en utilisant OpenTelemetry et activez l’auto-instrumentation sur App Service. Créez des tests de disponibilité depuis au moins cinq régions Azure avec des vérifications de correspondance de contenu et d’expiration TLS. Pourquoi : Le traçage distribué approfondi et les tests synthétiques détectent les régressions impactant les utilisateurs avant qu’ils ne s’en aperçoivent.
Créez des alertes Azure Monitor :

Alertes de métriques dynamiques pour le CPU, la mémoire, les taux d’erreurs HTTP 5xx et l’intégrité du backend d’App Gateway
Alertes de requête planifiée pour les refus de pare-feu anormaux et les échecs de connexion en utilisant KQL
Alertes de journal d’activité pour les événements de suppression/d’attribution de rôle sur les ressources critiques
Connectez toutes les alertes à des groupes d’actions partagés (e-mail/SMS pour l’astreinte, webhook vers ITSM, Logic App pour ouvrir des incidents) Pourquoi : L’alerte multi-signaux réduit le temps moyen de détection (MTTD) avec un acheminement exploitable vers les personnes et les systèmes.

Protégez les données avec Azure Backup :

Activez la sauvegarde des VM avec des stratégies alignées sur des sauvegardes nocturnes et une rétention à long terme ; activez les instantanés cohérents avec les applications le cas échéant
Protégez les partages Azure Files hébergeant les ressources multimédias avec des sauvegardes quotidiennes et la suppression réversible (soft delete)
Protégez SQL Server dans les VM Azure avec des planifications de sauvegardes complètes/différentielles/de journaux pour prendre en charge la restauration à un instant dans le passé (point-in-time restore)
Validez la Restauration instantanée en effectuant une restauration au niveau fichier en pré-production (staging) Pourquoi : Les sauvegardes basées sur un coffre (vault) et les restaurations instantanées minimisent les temps d’arrêt et la perte de données pour les charges de travail IaaS et de fichiers.

Implémentez Azure Site Recovery pour la reprise après sinistre (DR) de région à région des niveaux web, API et SQL avec une stratégie de réplication visant un RPO faible et des points de restauration cohérents avec l’application toutes les heures. Élaborez un plan de récupération avec des niveaux (données d’abord, puis API, puis web), une automatisation pour mettre à jour le DNS et purger les caches CDN, et testez le basculement sur un VNet isolé trimestriellement. Pourquoi : La réplication et les plans de récupération ASR fournissent un RTO prévisible avec des runbooks orchestrés et auditables et des tests non perturbateurs.
Activez Network Watcher et utilisez le Dépannage de connexion pour valider les flux frontend-backend, le Tronçon suivant (Next hop) pour vérifier les UDR à travers le niveau NVA, et la Vérification du flux IP pour confirmer le renforcement des NSG. Configurez la capture de paquets à la demande sur les VM de l’API pour l’analyse des expirations de délai (timeouts) intermittentes. Pourquoi : Des diagnostics spécialisés isolent rapidement les problèmes de routage/NSG et fournissent des preuves au niveau des paquets si nécessaire.
Créez des alertes Azure Service Health pour les deux régions et les services concernés (App Service, SQL, Storage, Key Vault, Front Door). Acheminez-les vers les mêmes groupes d’actions et incluez les listes de distribution de la direction pour les avis de maintenance planifiée. Pourquoi : Une connaissance proactive des incidents de plateforme et de la maintenance prévient les pannes surprises et permet une communication coordonnée.

Cette approche intégrée garantit qu’Adobe atteint ses objectifs RPO/RTO, restaure rapidement après une attaque par rançongiciel ou une erreur d’opérateur, détecte et corrige les anomalies en quelques minutes, et peut dépanner de manière concluante les chemins réseau tout en restant informé des événements de la plateforme Azure.

← Bases de données Azure et Services de données · Tous les domaines · Sécurité Azure et Conformité →

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