Expert

Administration avancée

Architecture hub-spoke et DNS privé, conformité avancée, scale sets et haute disponibilité, déploiement par modèles et diagnostic.

▶

Module 9 — Hub-spoke, peering et DNS privé

Réseau 20 %

1. Architecture hub-spoke

Le hub centralise les services partagés (pare-feu, passerelle VPN/ExpressRoute, DNS, Bastion) ; les spokes hébergent les charges applicatives. L’appairage (peering) relie les VNet en privé via le backbone Microsoft, sans Internet, avec une faible latence. L’appairage est bilatéral : il faut créer les deux sens. L’option use-remote-gateways permet à un spoke d’utiliser la passerelle du hub.

Pourquoi c'est important : sans topologie hub-spoke, chaque VNet applicatif réclame sa propre passerelle et son pare-feu, donc des coûts dupliqués et des flux incontrôlés. Un appairage à sens unique ou un DNS privé non lié au VNet produit des pannes de connectivité silencieuses que l'examen adore piéger.

L'analogie qui aide : le hub est l'aéroport international avec douane, contrôle et tour de contrôle partagés, les spokes sont les aérodromes régionaux reliés par des couloirs privés, l'appairage est la piste à double sens qu'il faut construire des deux côtés, et la zone DNS privée est l'annuaire interne qui évite de crier les noms dans le hall.

# VNet hub + spoke puis appairage dans les deux sens
az network vnet create --resource-group RG-Net --name VNet-Hub --address-prefix 10.100.0.0/16 --subnet-name Subnet-Shared --subnet-prefix 10.100.1.0/24
az network vnet create --resource-group RG-Net --name VNet-Spoke --address-prefix 10.101.0.0/16 --subnet-name Subnet-App --subnet-prefix 10.101.1.0/24

az network vnet peering create --name Hub-To-Spoke --resource-group RG-Net --vnet-name VNet-Hub --remote-vnet VNet-Spoke --allow-vnet-access
az network vnet peering create --name Spoke-To-Hub --resource-group RG-Net --vnet-name VNet-Spoke --remote-vnet VNet-Hub --allow-vnet-access
az network vnet peering list --resource-group RG-Net --vnet-name VNet-Hub -o table

2. DNS privé lié au VNet

La zone DNS privée (ex. contoso.local) liée au VNet résout les noms en adresses privées pour toutes les ressources du réseau. Avec registration-enabled, les VM s’enregistrent automatiquement. Un enregistrement A associe chaque serveur à son adresse privée.

Démonstration pas à pas : les deux az network vnet create posent le hub 10.100.0.0/16 et le spoke 10.101.0.0/16 ; les deux az network vnet peering create établissent le lien dans chaque sens, sans quoi le retour ne passe pas ; az network private-dns zone create fabrique contoso.local, link vnet l'attache au hub, et add-record publie srv-app vers 10.101.1.4. Le flux réseau suit alors le backbone privé Microsoft, sans sortir sur Internet.

az network private-dns zone create --resource-group RG-Net --name contoso.local
az network private-dns link vnet create --resource-group RG-Net --zone-name contoso.local --name Link-Hub --virtual-network VNet-Hub --registration-enabled false
az network private-dns record-set a add-record --resource-group RG-Net --zone-name contoso.local --record-set-name srv-app --ipv4-address 10.101.1.4

Composant	Rôle	Point de vigilance
Peering	Liaison privée inter-VNet	Créer les deux sens
GatewaySubnet	Accueille la passerelle	Nom exact, /27 minimum
Zone DNS privée	Résolution interne	Lier au VNet
168.63.129.16	DNS et santé de plateforme	Ne jamais bloquer

Point d’examen : le peering n’est pas transitif par défaut : pour qu’un spoke atteigne un autre spoke via le hub, activer le transit de passerelle des deux côtés. Le DNS privé évite tout fichier hosts manuel.

Pièges classiques : créer l'appairage dans un seul sens ; croire au transit automatique entre spokes sans activer le transit de passerelle ; oublier de lier la zone DNS privée au VNet ; bloquer l'adresse 168.63.129.16 qui porte le DNS et les sondes de santé de la plateforme.

À vous de jouer : deux spokes ne se joignent pas via le hub et srv-app.contoso.local ne se résout pas. Que vérifiez-vous en premier ?

Voir la réponse

Vérifiez l'appairage dans les deux sens avec az network vnet peering list, activez le transit de passerelle des deux côtés pour la communication entre spokes, puis contrôlez la liaison de la zone contoso.local au VNet et l'enregistrement A vers 10.101.1.4.

▶

Module 10 — Stratégies, conformité et identités avancées

Gouvernance 10 %

1. Azure Policy en profondeur

Une définition décrit la règle et son effet : audit (signale), deny (bloque), append (ajoute), deployIfNotExists (déploie si absent). L’affectation lie la définition à une étendue ; les exemptions excluent temporairement une ressource. Les initiatives regroupent plusieurs définitions (ex. socle de sécurité). La remédiation corrige les ressources non conformes via une identité managée.

Pourquoi c'est important : sans stratégie, chaque équipe déploie des ressources hors norme : IP publiques interdites qui apparaissent, balises absentes, régions non autorisées. Policy applique le socle à grande échelle, et l'accès conditionnel couplé à PIM évite qu'un compte compromis conserve un rôle sensible en permanence.

L'analogie qui aide : Policy est le règlement de copropriété affiché à l'entrée avec ses sanctions graduées (audit pour avertir, deny pour interdire, deployIfNotExists pour réparer d'office), l'accès conditionnel est le vigile qui exige une pièce supplémentaire selon l'heure et le visiteur, et PIM est le coffre qui ne prête la clé du local technique que sur demande motivée et pour une heure.

# Affecter une initiative de sécurité à l'abonnement puis vérifier la conformité
az policy assignment create --name "socle-securite" --policy "ASC Default" --scope /subscriptions/xxx
az policy state summarize --scope /subscriptions/xxx -o table

2. Accès conditionnel et Privileged Identity Management

Une stratégie d’accès conditionnel combine des conditions (utilisateurs, applications, plateformes, localisations, risque) et des contrôles (exiger la MFA, un appareil conforme, accepter les conditions). PIM transforme les rôles sensibles en accès éligibles : activation justifiée, limitée dans le temps, avec approbation et révision d’accès.

Démonstration pas à pas : az policy assignment create attache l'initiative socle-sécurité à l'étendue de l'abonnement, donc chaque création est évaluée à ce niveau et héritée vers le bas ; az policy state summarize affiche l'état de conformité par ressource ; côté identité, la stratégie d'accès conditionnel croise les signaux puis impose la MFA ou l'appareil conforme, tandis que PIM convertit le rôle permanent en éligibilité activable avec justification et expiration automatique.

Effet Policy	Comportement	Cas typique
Audit	Signale sans bloquer	Pilote avant durcissement
Deny	Bloque la création	Interdire les IP publiques
DeployIfNotExists	Déploie si absent	Installer l’agent de supervision

Point d’examen : pour « empêcher » il faut deny ; audit seul ne bloque rien. Toujours prévoir deux comptes d’urgence cloud pour ne pas être exclu par une stratégie d’accès conditionnel erronée.

Pièges classiques : affecter une stratégie en audit en croyant bloquer les déploiements ; oublier l'exemption temporaire et bloquer une urgence ; activer un accès conditionnel strict sans comptes d'urgence et se verrouiller dehors ; laisser un rôle Propriétaire permanent au lieu d'une éligibilité PIM avec révision.

À vous de jouer : vous devez interdire les IP publiques tout en testant d'abord sans bloquer, et sécuriser le rôle Propriétaire. Quelle combinaison choisissez-vous ?

Voir la réponse

Démarrez en effet audit pour mesurer l'impact avec az policy state summarize, basculez en deny pour interdire réellement, et convertissez Propriétaire en rôle éligible PIM avec activation justifiée, approbation et comptes d'urgence conservés hors stratégie.

▶

Module 11 — Scale sets, disponibilité et galerie d’images

Compute 15 %

1. Groupes de machines virtuelles identiques

Le scale set maintient N instances identiques derrière un équilibreur de charge et ajuste leur nombre selon des règles de mise à l’échelle (CPU moyen, longueur de file). La mise à niveau automatique du système d’exploitation remplace progressivement les instances par la dernière image, par vagues avec sondes d’intégrité. Les zones de disponibilité répartissent les instances sur des datacenters distincts.

Pourquoi c'est important : un site qui sature à chaque pic sans mise à l'échelle automatique perd des ventes, une grappe concentrée dans un seul datacenter tombe avec lui. Le scale set zone-redondant absorbe la charge et la perte d'un datacenter sans intervention nocturne.

L'analogie qui aide : le scale set est une équipe d'hôtes identiques derrière un maître de salle (l'équilibreur) qui ouvre ou ferme des tables selon la file d'attente, les zones sont les trois cuisines séparées qui évitent la fermeture totale, et la galerie d'images est le moule officiel qui garantit des assiettes strictement identiques.

# Scale set 2 instances avec mise à l'échelle automatique sur le CPU
az vmss create --resource-group RG-Compute --name ScaleSet-Web --image Ubuntu2204 --vm-sku Standard_B2s --instance-count 2 --load-balancer NatLB --upgrade-policy-mode Automatic
az monitor autoscale create --resource-group RG-Compute --resource ScaleSet-Web --resource-type Microsoft.Compute/virtualMachineScaleSets --min-count 2 --max-count 6 --count 2
az monitor autoscale rule create --resource-group RG-Compute --autoscale-name ScaleSet-Web --condition "Percentage CPU > 70 avg 5m" --scale out 2

2. Galerie de calcul et images

La galerie Azure Compute Gallery versionne les images généralisées et les réplique entre régions pour des déploiements rapides et homogènes. Le cycle est : préparer la VM source, la généraliser (sysprep sous Windows, waagent -deprovision sous Linux), la désallouer, puis créer la version d’image.

Démonstration pas à pas : az vmss create lance deux instances B2s derrière un équilibreur avec mise à niveau automatique ; az monitor autoscale create cadre la fourchette entre deux et six instances ; az monitor autoscale rule create ajoute deux instances quand le CPU dépasse 70 pour cent sur cinq minutes ; côté images, az sig create puis image-definition et image-version diffusent la version 1.0.0 vers francecentral et westeurope depuis une image source généralisée et désallouée.

# Galerie + définition + version d'image (diffusion multi-régions)
az sig create --resource-group RG-Compute --gallery-name Galerie-Entreprise
az sig image-definition create --resource-group RG-Compute --gallery-name Galerie-Entreprise --gallery-image-definition Image-Web --publisher Horizon5 --offer Web --sku 22_04 --os-type Linux
az sig image-version create --resource-group RG-Compute --gallery-name Galerie-Entreprise --gallery-image-definition Image-Web --gallery-image-version 1.0.0 --target-regions francecentral=1 westeurope=1 --managed-image /subscriptions/xxx/resourceGroups/RG-Compute/providers/Microsoft.Compute/images/Image-Web

Mécanisme	Protège contre	Portée
Availability set	Panne rack + maintenance	Datacenter
Zone de disponibilité	Perte d’un datacenter	Région
Scale set + LB	Charge + panne d’instance	Région (zones)
Site Recovery	Perte d’une région	Multi-régions

Point d’examen : associer chaque mécanisme à sa panne : set = rack/maintenance, zone = datacenter, Site Recovery = région. La mise à l’échelle automatique exige des sondes d’intégrité fiables pour éviter les oscillations.

Pièges classiques : confondre availability set (rack et maintenance) avec zone (datacenter) ; créer une image sans généraliser ni désallouer ; régler une mise à l'échelle sans sondes d'intégrité et provoquer des oscillations ; croire qu'un scale set protège d'une perte de région sans Site Recovery.

À vous de jouer : le trafic double à midi et un datacenter tombe l'après-midi. Que configurez-vous pour absorber les deux sans intervention manuelle ?

Voir la réponse

Un scale set zone-redondant de deux à six instances avec règle à 70 pour cent de CPU sur cinq minutes et sondes d'intégrité, déployé depuis une version de galerie répliquée : la charge déclenche le scale-out et la zone survivante absorbe la perte du datacenter.

▶

Module 12 — Déploiement par modèles et diagnostic avancé

Transverse

1. Déploiements déclaratifs (ARM/Bicep)

Le déploiement par modèle décrit l’état désiré en JSON (ARM) ou Bicep (syntaxe simplifiée) : idempotence, paramétrage par environnement, historique et restauration. az deployment group create applique le modèle à un groupe de ressources ; le mode Incremental ajoute sans supprimer, le mode Complete supprime ce qui n’est plus déclaré.

Pourquoi c'est important : cliquer dans le portail ne se rejoue pas, ne se relit pas et dérive d'un environnement à l'autre. Le modèle versionné garantit que le développement, la recette et la production sortent du même moule, avec un historique qui permet de revenir en arrière après un déploiement fautif.

L'analogie qui aide : le modèle ARM ou Bicep est le plan d'architecte côté et versionné, Incremental ajoute des meubles sans vider la pièce, Complete vide d'abord la pièce pour la meubler exactement comme le plan, et run-command est la trappe du concierge qui passe un outil sans ouvrir la porte principale SSH.

# Déploiement d'un modèle avec paramètres, puis vérification
az deployment group create --resource-group RG-App --template-file azuredeploy.json --parameters appName=app-horizon5 sku=B1 --mode Incremental
az deployment group list --resource-group RG-App -o table
az deployment group show --resource-group RG-App --name azuredeploy --query properties.provisioningState

2. Diagnostic sans ouvrir de port

az vm run-command exécute un script via l’agent Azure, sans SSH ni RDP : idéal quand le NSG bloque l’accès ou que la VM semble figée. Azure Bastion fournit un rebond RDP/SSH via le portail en TLS, sans IP publique sur les VM. La capture réseau (Network Watcher) et les journaux de flux NSG expliquent les refus de trafic.

Démonstration pas à pas : az deployment group create applique azuredeploy.json en Incremental avec appName et sku en paramètres, donc rejouer la commande converge sans détruire ; az deployment group show lit provisioningState pour valider ; en cas de VM injoignable, az vm run-command invoke exécute df -h via l'agent sans ouvrir le port 22, az network nic show contrôle la carte, et la configuration du flow-log NSG vers sthorizon5app enregistre les refus en JSON pour trancher entre règle NSG, route ou DNS.

# Diagnostic : état de l'agent, disque, carte réseau
az vm run-command invoke --resource-group RG-Compute --name VM-Web01 --command-id RunShellScript --scripts "df -h"
az network nic show --resource-group RG-Net --name NIC-VM-Web01
az network watcher flow-log configure --resource-group RG-Net --nsg NSG-Web --storage-account sthorizon5app --enabled true --format JSON --log-version 2

Symptôme	Vérifier en premier	Commande
VM injoignable	État d’alimentation + NSG	az vm show / règles NSG
Échec de déploiement	Détail de l’opération	az deployment group show
Accès refusé (RBAC)	Attributions + étendue	az role assignment list
Nom non résolu	Lien zone privée au VNet	private-dns link vnet show

Point d’examen : face à un scénario de panne, suivre l’ordre : alimentation, réseau (NSG, routes), résolution DNS, identité et accès, puis journaux. Run-command et Bastion sont les deux réponses favorites quand SSH/RDP direct est impossible.

Pièges classiques : lancer un déploiement en mode Complete en croyant ajouter sans supprimer ; ouvrir SSH en panique au lieu d'utiliser run-command ou Bastion ; conclure à un problème RBAC alors que le NSG ou le DNS privé bloque avant ; négliger l'historique de déploiement pour revenir en arrière.

À vous de jouer : la VM ne répond plus en SSH après un changement de NSG et le dernier déploiement a échoué. Quel ordre de diagnostic suivez-vous ?

Voir la réponse

Vérifiez l'état d'alimentation avec az vm show, contournez SSH par az vm run-command invoke et Bastion, contrôlez les règles NSG et les journaux de flux, puis relisez l'échec avec az deployment group show avant de redéployer en Incremental.

Passer l’examen blanc Réviser les fiches mémo