Microsoft Azure Network Engineer Associate
Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen AZ-700. Lisez de haut en bas ou sautez à une section.
Connecter des ressources entre des réseaux virtuels (VNets) dans différentes souscriptions ou régions de manière privée.
Configurer le peering de VNet entre les réseaux virtuels.
Pourquoi: Maintient le trafic sur le backbone Microsoft. Le peering de VNet n'est pas transitif ; un peering direct est requis pour la communication (A->B, B->C != A->C).
Concevoir des espaces d'adressage VNet pour une connectivité future.
Attribuer des blocs CIDR uniques et non chevauchants à chaque VNet.
Pourquoi: Le peering de VNet nécessite des espaces d'adressage non chevauchants. Planifier la croissance pour éviter de devoir ré-architecturer.
Calculer la taille de sous-réseau requise pour un nombre spécifique d'hôtes.
Utiliser la notation CIDR qui fournit le nombre d'hôtes requis + 5 adresses IP réservées pour Azure.
Pourquoi: Azure réserve les quatre premières et la dernière adresse IP dans chaque sous-réseau. Un /24 (256 IP) ne fournit que 251 IP utilisables.
Déployer des services comme Azure Firewall, Gateway ou Bastion.
Créer des sous-réseaux dédiés avec des noms spécifiques (par exemple, AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) et des tailles minimales (/26, /27, /26 respectivement).
Pourquoi: Ces services nécessitent des sous-réseaux dédiés, nommés spécifiquement, pour injecter leurs ressources. Le dimensionnement est critique pour la fonctionnalité et la mise à l'échelle future.
Activer la résolution de noms entre les réseaux locaux et les zones DNS privées Azure.
Déployer Azure DNS Private Resolver. Utiliser un point de terminaison entrant pour les requêtes du réseau local vers Azure et un point de terminaison sortant avec des règles de transfert pour les requêtes d'Azure vers le réseau local.
Pourquoi: Fournit une solution PaaS gérée pour le DNS hybride sans nécessiter de machines virtuelles DNS personnalisées. Le DNS local transmet les requêtes à l'IP du point de terminaison entrant.
Un VNet peeré ne peut pas résoudre les enregistrements dans une zone DNS privée.
Créer un lien de réseau virtuel de la zone DNS privée vers le VNet peeré.
Pourquoi: L'accès à la zone DNS privée n'est pas transitif via le peering. Chaque VNet nécessitant une résolution doit avoir un lien explicite.
Fournir une IP publique sortante statique et prévisible pour les machines virtuelles dans un sous-réseau pour l'autorisation d'accès (allow-listing).
Associer une Azure NAT Gateway avec une IP publique ou un préfixe d'IP publique au sous-réseau.
Pourquoi: NAT Gateway annule toutes les autres méthodes de connectivité sortante pour un sous-réseau, garantissant que tout le trafic utilise ses IP publiques statiques.
Assurer qu'une IP publique pour une ressource comme un Load Balancer reste constante.
Utiliser une adresse IP publique de SKU Standard avec allocation statique.
Pourquoi: Les IP statiques de SKU Standard sont redondantes de zone par défaut et persistent même lorsque la ressource associée est arrêtée ou supprimée.
Concevoir un sous-réseau pour un cluster AKS utilisant le réseau Azure CNI.
Calculer les besoins en IP comme (nombre de nœuds * nombre maximal de pods par nœud) + nombre de nœuds. Allouer un sous-réseau pouvant accueillir ce compte.
Pourquoi: Avec Azure CNI, chaque pod obtient une IP directement du sous-réseau, nécessitant une allocation significative d'adresses IP.
Acheminer tout le trafic destiné à Internet depuis un VNet spoke via un Azure Firewall dans le VNet hub.
Créer une table de routage définie par l'utilisateur (UDR) avec une route pour 0.0.0.0/0, un type de saut suivant "Appliance virtuelle", et l'IP privée de l'Azure Firewall.
Pourquoi: Cela annule la route système par défaut vers Internet, forçant tout le trafic à passer par le pare-feu pour inspection.
Inspecter le trafic entre deux VNets spokes à l'aide d'un Azure Firewall dans le hub.
Dans chaque spoke, créer des UDR pour les autres espaces d'adressage des spokes pointant vers le pare-feu. Dans le pare-feu, créer des règles de réseau pour autoriser le trafic.
Pourquoi: Le routage doit être configuré sur les deux spokes pour envoyer le trafic au pare-feu, qui par défaut refuse le trafic inter-VNet.
Déployer un cluster d'Appliance Virtuelle Réseau (NVA) résilient pour l'inspection ou le routage du trafic.
Utiliser Azure Route Server. Les NVA se peerent avec Route Server via BGP et annoncent des routes. Route Server utilise ECMP pour la répartition de charge.
Pourquoi: Route Server simplifie le routage dynamique avec les NVA, éliminant la gestion complexe des UDR et offrant un basculement automatisé.
Une NVA abandonne le trafic qu'elle devrait router.
Activer le "transfert IP" sur l'interface réseau (NIC) de la NVA.
Pourquoi: Ce paramètre au niveau d'Azure est requis pour permettre à la NIC de recevoir et de transférer le trafic non destiné à sa propre adresse IP.
Distribuer le trafic HTTP/S globalement vers le backend à la latence la plus faible avec WAF et déchargement SSL.
Utiliser Azure Front Door.
Pourquoi: Front Door utilise le routage anycast pour des performances optimales et intègre WAF, le routage d'URL et le déchargement SSL en périphérie.
Distribuer le trafic vers des points de terminaison globaux basés sur DNS avec basculement piloté par des sondes de santé.
Utiliser Azure Traffic Manager.
Pourquoi: Traffic Manager est un équilibreur de charge basé sur DNS. Utiliser le routage "Performance" pour la latence la plus faible ou "Priorité" pour un basculement actif/passif.
Fournir un équilibrage de charge HTTP/S régional de couche 7 avec WAF, terminaison SSL et routage basé sur l'URL/hôte.
Déployer Azure Application Gateway v2.
Pourquoi: Application Gateway est un équilibreur de charge L7 régional. Utiliser des règles basées sur le chemin pour le routage d'URL et des écouteurs multi-sites pour le routage basé sur l'hôte.
Équilibrer la charge du trafic non-HTTP/S (TCP/UDP) au sein d'une région.
Utiliser Azure Load Balancer (SKU Standard).
Pourquoi: Azure Load Balancer est un équilibreur de charge L4 régional. Il préserve l'IP source du client et convient à tous les protocoles TCP/UDP.
Terminer le SSL au niveau d'Application Gateway mais re-chiffrer le trafic vers le backend.
Configurer un écouteur HTTPS. Dans les paramètres HTTP du backend, définir le protocole sur HTTPS et télécharger le certificat racine de confiance des serveurs backend.
Pourquoi: Garantit que le trafic est chiffré en transit jusqu'au backend, même avec des certificats auto-signés sur les serveurs backend.
Équilibrer la charge du trafic vers un écouteur de groupe de disponibilité SQL Server Always On.
Utiliser un Load Balancer Standard interne avec le paramètre "IP flottante (Direct Server Return)" activé sur la règle d'équilibrage de charge.
Pourquoi: L'IP flottante est requise pour que l'écouteur de groupe de disponibilité SQL fonctionne correctement, car elle permet au nœud secondaire de répondre directement aux clients après un basculement.
Équilibrer la charge du trafic vers un cluster de NVA qui doivent traiter tous les protocoles et ports.
Utiliser un Load Balancer Standard interne avec une règle d'équilibrage de charge "Ports HA".
Pourquoi: La règle Ports HA transfère tout le trafic TCP et UDP sur tous les ports, simplifiant la configuration pour les NVA qui doivent inspecter tous les flux de trafic.
Configurer le basculement automatique entre une origine d'application web primaire et secondaire.
Placer les deux origines dans le même groupe d'origines Front Door. Attribuer une priorité de 1 à l'origine primaire et une priorité inférieure (par exemple, 2) à l'origine secondaire.
Pourquoi: Front Door envoie toujours le trafic à l'origine saine ayant la priorité la plus élevée. Lorsque l'origine primaire échoue aux sondes de santé, le trafic bascule automatiquement vers la priorité suivante.
Fournir un accès RDP/SSH sécurisé aux machines virtuelles Azure sans exposer les ports de gestion à Internet.
Déployer Azure Bastion (SKU Standard pour les fonctionnalités avancées).
Pourquoi: Bastion agit comme une boîte de saut gérée, offrant un accès via le portail Azure sur TLS. Il élimine le besoin d'IP publiques sur les machines virtuelles pour la gestion.
Accéder à un service PaaS Azure (par exemple, SQL, Stockage) en utilisant une adresse IP privée depuis votre VNet.
Créer un Private Endpoint pour la ressource PaaS. Intégrer avec une zone DNS privée pour une résolution de noms automatique.
Pourquoi: Private Endpoint projette le service PaaS dans votre VNet avec une IP privée, permettant une connectivité véritablement privée. La désactivation de l'accès au réseau public sur le service PaaS renforce cela.
Accéder aux services PaaS Azure depuis un VNet via le backbone Azure sans utiliser d'IP publiques, mais sans gérer d'IP privée dédiée.
Activer un Service Endpoint pour le service spécifique (par exemple, Microsoft.Storage) sur le sous-réseau source.
Pourquoi: Les Service Endpoints fournissent une route directe vers les services PaaS depuis un VNet, mais n'utilisent pas d'IP privée dans le VNet. C'est plus simple mais moins flexible que les Private Endpoints.
Exposer un service exécuté dans votre VNet à des consommateurs dans d'autres VNets (potentiellement d'autres tenants) de manière privée.
Placer le service derrière un Load Balancer Standard et créer un Private Link Service pointant vers celui-ci.
Pourquoi: Private Link Service est le composant côté fournisseur. Les consommateurs créent des Private Endpoints dans leurs VNets pour se connecter à votre service de manière privée.
Simplifier les règles de groupe de sécurité réseau (NSG) pour une application multi-niveaux où les machines virtuelles peuvent évoluer ou changer d'IP.
Créer des groupes de sécurité d'application (ASGs) pour chaque niveau (par exemple, Web, App, DB). Définir des règles NSG en utilisant les ASGs comme source/destination.
Pourquoi: Les ASGs agissent comme des balises d'objet réseau pour les machines virtuelles, vous permettant de créer des règles basées sur la structure de l'application plutôt que sur des adresses IP fragiles.
Le trafic est bloqué de manière inattendue lorsque des NSG sont appliqués à la fois à une NIC et à son sous-réseau.
Rappeler l'ordre d'évaluation des règles NSG. Entrant : règles de NIC d'abord, puis règles de sous-réseau. Sortant : règles de sous-réseau d'abord, puis règles de NIC.
Pourquoi: Un refus à n'importe quel niveau bloquera le trafic. Les deux NSG doivent autoriser le flux de trafic pour qu'il réussisse.
Bloquer automatiquement le trafic vers/depuis des adresses IP et des domaines malveillants connus.
Activer le filtrage basé sur la Threat intelligence d'Azure Firewall en mode "Alerter et refuser".
Pourquoi: Cela utilise le flux de Threat intelligence de Microsoft pour fournir une protection gérée et à jour contre les menaces connues avec une configuration nulle.
Inspecter le trafic HTTPS chiffré pour détecter des menaces comme les logiciels malveillants.
Utiliser Azure Firewall Premium. Activer l'inspection TLS dans la politique et déployer un certificat CA intermédiaire auquel les clients doivent faire confiance.
Pourquoi: C'est une fonctionnalité premium qui effectue un déchiffrement de type "man-in-the-middle" pour inspecter le trafic, ce qui est essentiel pour une posture de sécurité de confiance zéro.
Autoriser l'accès sortant à des services Microsoft complexes comme Windows Update sans maintenir des listes d'IP.
Dans Azure Firewall, créer une règle d'application utilisant des balises FQDN (par exemple, "WindowsUpdate", "AzureBackup").
Pourquoi: Microsoft gère les FQDN associés à ces balises, simplifiant la gestion des règles de pare-feu pour les services dynamiques.
Protéger les applications exposées au public contre les attaques DDoS volumétriques et obtenir un accès à un support de réponse rapide.
Activer la protection réseau DDoS (anciennement Standard) sur le VNet.
Pourquoi: Fournit un réglage adaptatif, la télémétrie d'attaque, des rapports d'atténuation et l'accès à l'équipe de réponse rapide DDoS, ce que la protection de base gratuite ne possède pas.
Diagnostiquer une défaillance de connectivité et identifier le saut exact où le trafic est abandonné.
Utiliser Network Watcher > Dépannage de connexion.
Pourquoi: Il effectue une vérification de bout en bout, montrant le chemin complet saut par saut et identifiant les défaillances dues aux NSG, UDR ou autres problèmes réseau.
Vérifier rapidement si une règle NSG autorise ou refuse le trafic vers/depuis une machine virtuelle.
Utiliser Network Watcher > Vérification du flux IP.
Pourquoi: C'est l'outil le plus direct pour tester un 5-tuple spécifique par rapport aux règles NSG et voir quelle règle est responsable du résultat.
Enregistrer tout le trafic réseau autorisé et refusé pour la conformité et l'analyse.
Activer les journaux de flux NSG et les ingérer dans Traffic Analytics (via un espace de travail Log Analytics).
Pourquoi: Les journaux de flux NSG fournissent des données de trafic brutes. Traffic Analytics enrichit et visualise ces données pour identifier les schémas de trafic, les principaux communicateurs et les menaces de sécurité.
Connecter un réseau local à Azure avec une connexion privée et dédiée offrant une latence prévisible et une bande passante élevée.
Provisionner un circuit Azure ExpressRoute.
Pourquoi: ExpressRoute contourne complètement l'internet public, offrant une connexion plus fiable, plus rapide et à latence plus faible qu'un VPN Site-à-Site.
Choisir le peering ExpressRoute correct pour accéder aux ressources Azure.
Utiliser le peering privé Azure pour se connecter aux VNets. Utiliser le peering Microsoft pour accéder aux services PaaS publics et à Microsoft 365.
Pourquoi: Les deux types de peering donnent accès à différents ensembles de ressources. Le peering Microsoft nécessite des IP publiques, du NAT et des filtres de route.
Autoriser les VNets spokes à accéder aux réseaux locaux via une passerelle VPN ou ExpressRoute centrale dans le VNet hub.
Sur le peering hub-vers-spoke, activer "Autoriser le transit de passerelle". Sur le peering spoke-vers-hub, activer "Utiliser les passerelles distantes".
Pourquoi: Cette configuration en deux parties permet aux spokes d'utiliser la passerelle du hub, centralisant la connectivité hybride.
Configurer un VPN Site-à-Site comme sauvegarde pour une connexion ExpressRoute.
Déployer une passerelle ExpressRoute et une passerelle VPN. Par défaut, les chemins ExpressRoute sont préférés aux chemins VPN pour les mêmes préfixes.
Pourquoi: Azure préfère automatiquement ExpressRoute en raison d'un poids de route par défaut plus élevé. Si le circuit ExpressRoute échoue, BGP retirera les routes et le trafic basculera vers le VPN.
Influencer le trafic pour préférer un circuit ExpressRoute à un autre pour une redondance active/passive.
Utiliser le préfixage de chemin AS BGP. Ajouter votre propre ASN plusieurs fois aux annonces de route sur le circuit de sauvegarde pour que son chemin semble plus long.
Pourquoi: BGP préfère le chemin AS le plus court. Cela fait du circuit primaire le chemin préféré, avec un basculement automatique vers le circuit de sauvegarde si le chemin primaire est retiré.
Connecter deux sites locaux via le réseau dorsal de Microsoft en utilisant leurs circuits ExpressRoute existants.
Activer ExpressRoute Global Reach.
Pourquoi: Global Reach relie deux circuits ExpressRoute ensemble, permettant un WAN privé sur le réseau Microsoft sans que le trafic n'ait à faire de "hairpin" dans un VNet Azure.
Simplifier la gestion d'un réseau global connectant de nombreux bureaux distants et VNets.
Déployer Azure Virtual WAN.
Pourquoi: Virtual WAN fournit un service hub-and-spoke géré avec une connectivité transitive, un routage et une intégration automatisés de type "any-to-any" avec les services de sécurité (hub sécurisé).
Dans Virtual WAN, inspecter de manière centralisée tout le trafic inter-VNet, inter-succursales et destiné à Internet.
Déployer un hub virtuel sécurisé (avec Azure Firewall). Configurer l'intention de routage pour envoyer le trafic privé et Internet via le pare-feu.
Pourquoi: L'intention de routage simplifie l'ingénierie du trafic dans vWAN, programmant automatiquement les routes pour forcer le trafic à passer par le fournisseur de sécurité sans UDR manuelles.
Fournir une connexion VPN résiliente à Azure.
Déployer une passerelle VPN dans une configuration active-active. Cela nécessite deux IP publiques et un périphérique sur site capable d'établir deux tunnels.
Pourquoi: Fournit une redondance au niveau de l'instance au sein de la région Azure. Pour la redondance inter-zone, utiliser les SKU redondantes de zone (AZ).
Choisir un protocole VPN Point-à-Site pour une large compatibilité client sans logiciel supplémentaire.
Utiliser IKEv2. Pour une compatibilité maximale incluant les anciens appareils, utiliser OpenVPN.
Pourquoi: IKEv2 est nativement pris en charge sur les versions modernes de Windows, macOS et iOS. SSTP est uniquement pour Windows. OpenVPN nécessite un client mais est largement pris en charge.
Rediriger tout le trafic destiné à Internet depuis les machines virtuelles Azure vers une appliance de sécurité locale.
Depuis le réseau local, annoncer une route par défaut (0.0.0.0/0) via BGP sur la connexion ExpressRoute ou VPN.
Pourquoi: Cette annonce BGP annule la route Internet par défaut d'Azure, forçant le trafic à revenir vers le réseau local pour inspection.
