Microsoft AZ-700: Surveillance et dépannage du réseau — Guide d'étude

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Network Engineer AZ-700 — 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.

Outils d’observabilité et sources de données

L’observabilité dans le réseau Azure est centrée sur Network Watcher, Azure Monitor (Log Analytics) et les paramètres de diagnostic qui diffusent la télémétrie des ressources vers un espace de travail central ou un compte de stockage. Network Watcher fournit la capture de paquets, la vérification du flux IP (IP flow verify), le tronçon suivant (next hop), le dépannage de connexion (connection troubleshoot) et Connection Monitor. Connection Monitor v2 prend en charge les tests multi-points de terminaison et multi-protocoles, et stocke les résultats dans un espace de travail Log Analytics pour une télémétrie interrogeable. Les journaux de flux NSG (NSG flow logs) sont activés via Network Watcher et écrivent des enregistrements JSON dans un compte de stockage. L’activation de Traffic Analytics (qui nécessite les journaux de flux et un espace de travail Log Analytics) enrichit ces journaux avec des informations sur les applications/la géolocalisation et des visualisations. Les paramètres de diagnostic sur Azure Firewall, Application Gateway/WAF, Front Door et les équilibreurs de charge (load balancers) doivent être acheminés vers le même espace de travail Log Analytics pour corréler les signaux. Les pièges courants incluent les règles de pare-feu du compte de stockage qui bloquent l’écriture des journaux de flux, l’oubli d’activer Network Watcher pour chaque région dans les anciens tenants, et des politiques de rétention incohérentes entre le stockage et Log Analytics. Les compromis entre coût et capacité sont clairs : écrire les journaux bruts dans un compte de stockage pour un archivage à faible coût, par opposition à leur ingestion dans Log Analytics pour les requêtes et les alertes (coût plus élevé mais valeur de diagnostic bien supérieure). Le contrôle d’accès basé sur les rôles (Role-Based Access Control) (Monitor Reader et Storage Blob Data Reader si nécessaire) doit être configuré pour que les pipelines de diagnostic puissent écrire et que les analystes puissent lire les journaux.

Capture de paquets, Connection Monitor et diagnostics approfondis

Pour le dépannage au niveau des paquets, la capture de paquets de Network Watcher (via le portail/CLI/PowerShell) crée des fichiers PCAP dans un compte de stockage ou dans un fichier local sur une VM. Configurez les filtres de capture de paquets (protocole, IP source/destination, ports) et les limites de taille/temps pour éviter un stockage excessif et un impact sur les performances. Pour les VM à haut débit avec la mise en réseau accélérée (accelerated networking), la visibilité des paquets côté hôte peut être limitée ; utilisez VNet TAP pour mettre en miroir le trafic vers une VM collectrice ou une NVA afin d’éviter de manquer les paquets déchargés (offloaded packets). Connection Monitor doit être utilisé pour les tests synthétiques actifs : définissez les points de terminaison source et destination (IP, FQDN, port), choisissez la fréquence des tests et activez la latence par tronçon (per-hop latency) et la capture de chemin pour un diagnostic multi-segments. Utilisez IP Flow Verify pour vérifier si un 5-tuple spécifique est autorisé ou refusé par les NSG/UDR, et Next-hop pour confirmer le routage effectif. Attention aux pièges : la capture de paquets sur les VM Windows peut nécessiter des autorisations élevées et être affectée par les déchargements de l’OS (OS offloads) ; la capture de paquets peut être intensive en termes de CPU/disque, il est donc préférable d’utiliser des filtres ciblés et des plages de temps définies (timeboxes). Pour une inspection continue des paquets à grande échelle, associez VNet TAP à une appliance d’analyse de paquets ou à un SIEM cloud capable d’ingérer des flux PCAP.

Journaux de flux NSG, Traffic Analytics et diagnostics de sécurité

Les journaux de flux NSG (version 2) fournissent des enregistrements de flux avec horodatage, 5-tuple, nombre d’octets/paquets et la décision (autorisé/refusé). Ils ne contiennent pas la charge utile (payload), les détails de session de la couche applicative ou le TLS déchiffré. Traffic Analytics enrichit les journaux de flux avec les principaux émetteurs (top talkers), les ASN et la géolocalisation, ce qui nécessite un espace de travail Log Analytics. Azure Firewall, Application Gateway/WAF et Azure Front Door émettent leurs propres diagnostics ; ceux-ci doivent être dirigés vers Log Analytics pour une interrogation unifiée. Pièges de conception importants : les règles NSG appliquées au niveau de la carte réseau (NIC) priment sur les règles au niveau du sous-réseau ; des règles par défaut existent (par ex., AzureLoadBalancer, règles internet) et ne peuvent pas être supprimées, seulement remplacées par des règles de priorité plus élevée. L’utilité des journaux de flux dépend de la stratégie de rétention et d’ingestion : une longue rétention dans Log Analytics est coûteuse, tandis qu’une rétention courte risque de faire perdre des preuves pour l’investigation numérique (forensic). Combinez les journaux de flux NSG avec les journaux de diagnostic du pare-feu et des règles d’alerte basées sur des requêtes Kusto pour détecter les mouvements latéraux ou l’exfiltration de données. Lors de la planification des actions correctives, envisagez d’ajouter des adresses IP publiques dédiées à Azure Firewall pour atténuer l’épuisement des ports SNAT et utilisez les DiagnosticSettings pour acheminer les données vers Event Hubs pour une intégration SIEM si les coûts de Log Analytics sont prohibitifs.

Modèles de dépannage, pièges de routage et compromis de conception

Lors du dépannage de la connectivité, suivez une approche par couches : vérifiez les NSG/UDR au niveau des ressources, contrôlez les routes effectives et le saut suivant (next hop), utilisez IP Flow Verify et Connection Troubleshoot, puis passez à la capture de paquets ou à VNet TAP si nécessaire. Les pièges de routage apparaissent souvent avec le tunneling forcé, les chevauchements de CIDR ou des UDR mal configurés qui envoient du trafic dans l’AzureFirewallSubnet sans routes de retour appropriées. Pour l’équilibrage de charge et la mise à l’échelle, choisissez entre Azure Standard Load Balancer, Application Gateway WAF et Front Door en fonction des besoins L4 ou L7 et de la gestion du trafic mondial ou régional. Considérez ces compromis entre les références (SKU) :

Azure Firewall Standard vs Premium : La version Premium ajoute l’inspection TLS, l’IDPS et le filtrage d’URL pour un coût plus élevé ; choisissez Premium lorsque l’inspection approfondie du trafic et le contrôle réglementaire sont requis.
Azure Front Door Standard vs Premium : La version Premium prend en charge les fonctionnalités WAF avancées et les intégrations private link ; la version Standard est moins coûteuse pour un CDN mondial classique + routage.
VNet TAP vs capture de paquets : Le TAP est plus coûteux mais nécessaire pour une capture sans perte à grande échelle et lorsque la mise en réseau accélérée (accelerated networking) décharge les paquets. Les compromis portent sur la performance, le coût et la résilience : les NVA peuvent être moins chères ou plus riches en fonctionnalités que Firewall Premium, mais ajoutent une surcharge de gestion et un risque de point de défaillance unique (single-point-of-failure) à moins d’être architecturées avec de la haute disponibilité (HA). Planifiez la capacité SNAT, réservez des adresses IP publiques supplémentaires et préparez des pipelines de diagnostic pour équilibrer les besoins d’observabilité et les coûts d’ingestion.

Problème pratique : Scénario de cas d’usage

Scénario : Contoso Electronics exploite une infrastructure Azure dans deux régions (EastUS, WestEurope) avec des VNet en étoile (hub-and-spoke), un Azure Firewall Standard dans le hub, plusieurs Application Gateway WAF dans les spokes et un espace de travail Log Analytics central pour la surveillance. Ils ont récemment déployé un ensemble de VM de production dans un spoke qui signalent des défaillances intermittentes pour atteindre un cluster SQL sur site (on-premises) via un circuit ExpressRoute.

Défi : Connectivité intermittente et latence élevée vers les ressources sur site sans preuve claire au niveau des paquets ; les journaux de flux NSG existants sont activés mais affichent des flux autorisés sans métriques de latence.

Approche recommandée :

Déployer Connection Monitor v2 depuis des VM représentatives vers le FQDN et l’IP du SQL sur site en utilisant le port TCP 1433, définir des tests toutes les 30 secondes et envoyer les résultats à l’espace de travail Log Analytics central pour capturer la latence par saut et la joignabilité.
Activer la capture de paquets Network Watcher sur une VM affectée avec des filtres pour l’IP source/destination du cluster SQL et le port 1433, stocker les PCAP dans un compte de stockage avec une stratégie de cycle de vie ; activer simultanément VNet TAP sur le sous-réseau du spoke pour mettre en miroir le trafic vers une VM de collecte dédiée si la mise en réseau accélérée (accelerated networking) est présente.
Configurer les paramètres de diagnostic pour Azure Firewall (Standard) afin d’envoyer les journaux d’application et de réseau au même espace de travail Log Analytics, et exécuter des requêtes de corrélation joignant les résultats de Connection Monitor, les journaux du pare-feu et les journaux de flux NSG pour détecter l’épuisement SNAT du pare-feu ou les rejets par politique.
Utiliser IP Flow Verify et Next Hop pour un 5-tuple en échec lors d’un incident ; si un épuisement SNAT ou un routage asymétrique est suspecté, ajouter une adresse IP publique supplémentaire à l’Azure Firewall ou déployer une NAT Gateway dans le spoke pour une sortie (egress) prévisible et mettre à jour les UDR pour router via le hub.

Justification : Connection Monitor fournit une joignabilité synthétique et horodatée ainsi que la latence par saut ; la capture de paquets et VNet TAP fournissent des données forensiques sans perte lorsque les déchargements de l’OS masquent le trafic. La corrélation des journaux du pare-feu et des NSG dans Log Analytics identifie les problèmes de politique, de SNAT ou de routage asymétrique ; l’ajout d’adresses IP publiques ou d’une NAT Gateway atténue l’épuisement des ports et stabilise le comportement de sortie (egress).

← Équilibrage de charge et gestion du trafic · Tous les domaines · Azure Virtual WAN et Hub-Spoke →

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