15 — Labs : Chemins Portail (cheat-sheet examen)

Séquences de clics prêtes pour un lab pratique AZ-700. Format par tâche : chemin portail exact + ordre des étapes + le piège. Tout est dans le portail Azure (portal.azure.com).

Labs officiels du repo MicrosoftLearning (Instructions/Exercises + Instructions/Demos) : VNet & global peering · DNS settings · VPN Gateway (S2S) · Virtual WAN · ExpressRoute (gateway + circuit) · Load Balancer · Traffic Manager · App Gateway · Front Door · DDoS · Azure Firewall · Firewall Manager (secured hub) · Service Endpoints · Private Endpoint · Monitor LB (Azure Monitor). Demos en plus : Custom Routes (UDR), Route to shared services, Private Link Service, NSG, NAT Gateway.

⚠️ Réflexe transverse : Region cohérente sur toutes les ressources d'un lab + SKU qui match (Public IP Standard ↔ LB/VPN GW/NAT GW Standard) + subnet réservé au nom exact (GatewaySubnet, AzureFirewallSubnet, AzureBastionSubnet, RouteServerSubnet, sensibles à la casse).

1. VNet Peering (hub-spoke)

Home > Virtual networks > <VNet-A> > Peerings > + Add

1. This virtual network (sens A→B) : Peering link name A-to-B, Traffic to remote = Allow, Traffic forwarded from remote = Allow (si NVA cross-spoke), Gateway = Use this virtual network's gateway si A = hub.
2. Remote virtual network (sens B→A créé en même temps) : link name B-to-A, sélectionner VNet-B, options en miroir, Gateway = Use the remote virtual network's gateway si B = spoke.
3. Add → vérifier Status Connected des 2 côtés.

Hub-spoke complet (couple gateway transit) : sur peering Hub→Spoke = Allow gateway transit ON ; sur peering Spoke→Hub = Use remote gateways ON. Les 2 ON ensemble.

🚨 Pièges : le peering c'est 2 sens — si un seul créé → Initiated/Disconnected. · Use remote gateways = 1 seul peer max (1 spoke ne peut pas avoir 2 hubs). · Trafic relayé par NVA dropé à l'arrivée si Allow forwarded traffic OFF. · Pas d'overlap d'IP entre les VNets. · Address space modifié après coup → LocalNotInSync → Peering > Sync.

2. UDR / Route Table

Home > Route tables > + Create (RG, Region, Name rt-spoke) → Review + create.

1. Route table > Routes > + Add : Route name default-to-fw, Destination type IP Addresses, CIDR 0.0.0.0/0, Next hop type = Virtual appliance, Next hop address = IP privée de la NVA/Firewall (ex 10.0.0.4).
2. Subnets > Associate : VNet + le subnet à forcer.
3. NVA custom uniquement : Virtual machines > <nva> > Networking > <nic> > IP configurations > Enable IP forwarding = ON.

🚨 Pièges : NVA sans IP forwarding = paquets droppés (pas requis pour Azure Firewall managé). · Next hop type None = drop. · Forced tunneling = next hop Virtual network gateway (pas Virtual appliance). · À préfixe égal UDR > BGP > système, mais Service Endpoint et peering ne sont jamais overridables. · Vérif : Network Watcher > Next hop.

3. Private Endpoint (PaaS Storage/SQL)

Home > Storage accounts > <storage> > Networking > Private endpoint connections > + Private endpoint (ou Home > Private endpoints > + Create)

1. Basics : RG, Name pe-storage, Region.
2. Resource : Resource type Microsoft.Storage/storageAccounts, ressource, Target sub-resource = blob (ou file/queue/table/dfs). 1 PE = 1 sub-resource.
3. Virtual Network : VNet + subnet (assez d'IPs libres), IP dynamique ou statique.
4. DNS : Integrate with private DNS zone = Yes → Azure crée privatelink.blob.core.windows.net + le record A.
5. Review + create.

Approbation cross-tenant/permissions séparées : <Resource> > Networking > Private endpoint connections > <Pending> > Approve.

🚨 Pièges : sans Private DNS zone intégrée → le FQDN public ne résout pas vers l'IP privée. · Bonne zone par service (privatelink.database.windows.net pour SQL, .vaultcore.azure.net pour KeyVault). · PrivateEndpointNetworkPolicies = Disabled par défaut → NSG/UDR ignorés sur le subnet du PE (à activer pour les appliquer). · États : Pending → Approved/Rejected/Disconnected.

4. Service Endpoint + Service Endpoint Policy

Service Endpoint : Virtual networks > <vnet> > Subnets > <subnet> > Service endpoints → Service Microsoft.Storage → Save. Côté ressource : Storage accounts > <sa> > Networking > Firewalls and virtual networks → Enabled from selected networks → + Add existing virtual network → VNet+subnet → Save.

Service Endpoint Policy (restreindre) : Home > Service endpoint policies > + Create

1. Basics : Name sep-storage.
2. Policy definitions > + Add : Service Microsoft.Storage, Resource = scope (Single account / All in RG / All in subscription) → choisir la ressource.
3. Review + create → Associated subnets > + Edit subnet association → VNet+subnet.

🚨 Pièges : SEP exige que le subnet ait déjà le Service Endpoint Microsoft.Storage activé. · SEP = Storage uniquement (+ SQL Managed Instance), allow-policy (tout le reste refusé). · Service Endpoint = pas d'IP privée, garde l'IP publique via backbone (≠ Private Endpoint). · Pas d'accès on-prem via SE.

5. Private DNS Zone + DNS Private Resolver

Private DNS Zone : Home > Private DNS zones > + Create (Name priv.contoso.com) → Review + create. → Virtual network links > + Add : VNet, Enable auto registration = ON (1 seul VNet en auto-reg par zone). → Recordsets > + Record set : Name web, Type A, IP 10.1.1.10.

DNS Private Resolver : Home > DNS private resolvers > + Create (RG, Name, Region, Virtual network).

• Inbound endpoints > + Add (on-prem → Azure) : subnet dédié /28 délégué auto à Microsoft.Network/dnsResolvers, IP statique ex 10.2.99.4. → côté on-prem : Conditional Forwarder de privatelink.* vers cette IP.
• Outbound endpoints > + Add (Azure → on-prem) : autre subnet dédié /28.
• DNS forwarding ruleset : Home > DNS forwarding rulesets > + Create → sélectionner l'outbound endpoint → Rules > + Add : Domain corp.local. (point final), Destination IP = DNS on-prem. → Virtual network links > + Add : lier au VNet.

🚨 Pièges : ruleset même région que les VNets liés. · 2 subnets /28 distincts (in/out), pas d'autre ressource. · Conditional forwarder on-prem pointe l'Inbound endpoint, pas 168.63.129.16. · Azure ne supporte pas les conditional forwarders dans les VNets (juste le lien VNet↔zone). · Limites QCM : 5 in/5 out par resolver, 2 outbound par ruleset.

6. VPN S2S (ordre strict)

Ordre obligatoire : GatewaySubnet → VPN Gateway → Local Network Gateway → Connection.

1. Virtual networks > <vnet> > Subnets > + Subnet : nom exact GatewaySubnet (/27 recommandé).
2. Home > Virtual network gateways > + Create : Gateway type VPN, VPN type Route-based, SKU VpnGw2AZ, Generation2, VNet, Public IP Standard Zone-redundant. ⏱️ 30-45 min.
3. Home > Local network gateways > + Create : Endpoint type IP address = IP publique du device on-prem, Address space = CIDR on-prem (ex 192.168.1.0/24).
4. Virtual network gateway > Connections > + Add : type Site-to-site (IPSec), sélectionner la VPN GW + le LNG, Shared key (PSK) identique des 2 côtés, IKEv2.
5. Vérifier Connections > Overview > Status: Connected.

BGP : sur GW (Configuration > Configure BGP, ASN 65515), sur LNG (ASN on-prem différent), sur Connection (Enable BGP ON).

🚨 Pièges : VPN type (policy vs route) figé à la création → erreur = delete+recreate. · PSK identique sinon tunnel down (IKEDiagnosticLog). · LNG = IP publique on-prem, pas l'IP de la GW. · Active-Active/BGP pas en SKU Basic. · Coexistence ER+VPN → GatewaySubnet /25.

7. VPN P2S

Pas de LNG ni de Connection — tout sur la GW (route-based, VpnGw1AZ min).

VPN Gateway > Point-to-site configuration > Configure now

1. Address pool : ex 172.16.0.0/24 (pas d'overlap avec VNet ni on-prem).
2. Tunnel type : OpenVPN (SSL).
3. Authentication type :
   • Entra ID : Tenant https://login.microsoftonline.com/<tid>/, Audience c632b3df-fb67-4d84-bdcf-b95ad541b5c8, Issuer https://sts.windows.net/<tid>/ (slash final).
   • Azure certificate : coller la clé publique Base64 du root cert (sans headers BEGIN/END).
   • RADIUS : IP privée NPS + shared secret.
4. Save → Download VPN client → importer dans Azure VPN Client.

🚨 Pièges : Entra ID = OpenVPN uniquement (pas IKEv2/SSTP). · Toute modif de topologie/routes → re-télécharger le client. · Révocation cert = thumbprint individuel dans Revoked certificates. · SSTP en retrait (2026/2027). · Cert client (clé privée) dans le Personal store du user.

8. Azure Firewall + Firewall Policy

Ordre : (Parent) Policy → (Child) Policy → Firewall → UDR sur spokes.

1. Home > Firewall Policies > + Create : Name parent-policy, Tier Premium, Parent vide. DNS Proxy ON. Rules : Rule collection group → Rule collection (Type DNAT / Network / Application, priority, Action). Threat Intel = Alert and Deny.
2. Child policy : + Create avec Parent policy = parent-policy (même Tier).
3. Home > Firewalls > + Create : Name fw-hub, Tier match, Firewall management = Firewall policy (pas Classic), sélectionner la policy, Public IP Standard, VNet hub, subnet AzureFirewallSubnet (/26).
4. UDR : 0.0.0.0/0 → Virtual appliance → IP privée du firewall sur chaque subnet spoke.

DNAT : Firewall Policy > Rules > + Add RCG → collection Type DNAT : Source = ton IP, Destination = IP publique FW, Dest port 33890, Translated address 10.1.1.5, Translated port 3389.

🚨 Pièges : sans UDR, le trafic ne passe pas par le firewall. · Ordre éval = DNAT → Network → Application (un Network Deny tue une App Allow). · Parent toujours avant child (un Deny parent est définitif). · SKU parent=child obligatoire. · Forced tunneling → 2e subnet AzureFirewallManagementSubnet /26. · DNAT Source Any sur 3389/22 refusé.

9. Load Balancer

Home > Load balancers > + Create

1. Basics : SKU Standard, Type Public, Tier Regional, Name lb-web.
2. Frontend IP : + Add → Public IP Standard Zone-redundant.
3. Backend pools : + Add → config NIC ou IP → ajouter les VMs.
4. Inbound rules > Load balancing rule : + Add → frontend, backend pool, TCP port 80, Health probe (+ Create HTTP /health), Floating IP Disabled (cas standard).
5. (Option) Inbound NAT rules : port public 50001 → backend 3389 (RDP vers 1 VM).
6. (Option) Outbound rules : SNAT — mais préférer NAT Gateway en prod.

🚨 Pièges : Health probe obligatoire sinon pas de trafic. · SKU LB Standard ↔ Public IP Standard (pas de mix Basic). · Floating IP = Enabled pour SQL AG Listener (+ loopback sur VMs, sonder un port dédié pas 1433). · Internal LB pour ne pas exposer une DB. · Cross-Region LB : Tier Global, backend = LB régionaux (pas des VMs).

10. Application Gateway

Home > Application gateways > + Create

1. Basics : Name agw, Tier Standard V2 (ou WAF V2), Autoscaling 2-10, AZ 1/2/3.
2. Virtual network : subnet dédié /24 recommandé.
3. Frontends : Public IP Standard.
4. Backends : + Add a backend pool (vide pour l'instant).
5. Configuration > Routing rules > + Add :
   • Listener : port 443 HTTPS, certificat depuis Key Vault (via Managed Identity) ou PFX, type Basic ou Multi site (host header).
   • Backend targets > Path-based : default pool + règles /app/* → app-pool, /web/* → web-pool.
   • Backend settings : HTTP 80 (SSL offload) ou HTTPS 443 + Trusted root cert (end-to-end), custom probe /health match 200-399.
6. Review + create. (WAF : associer une Regional WAF policy.)

Rewrite & URL rewrite (<App Gateway> > Settings > Rewrites > + Rewrite set) → associer le set à une routing rule (ou à un path précis si path-based ; 1 rule = 1 rewrite set max, mais 1 set réutilisable sur plusieurs rules) → + Add condition (optionnel, AND logique) + + Add action (request/response header ou URL path/query) :

• Réécrire X-Forwarded-For (response/request header) avec la server variable add_x_forwarded_for_proxy → enlève le port, ne garde que l'IP.
• Préserver le host vers le backend : header X-Forwarded-Host = {http_req_host}. ⚠️ {http_req_host} inclut le port (contoso.com:443) alors que {var_host} / {host} ne l'incluent pas → si le backend casse sur host:port, utiliser {var_host}.
• URL rewrite : path /application → /app (option Re-evaluate path map = ON si on veut re-router vers un autre pool après réécriture).
• rewrite (interne) : l'URL backend change, pas la barre d'adresse client. redirect (301/302) : géré dans la routing rule (Redirection), l'URL change côté client.
• Server variables utiles : host, client_ip, client_port, server_port, uri_path, add_x_forwarded_for_proxy. Syntaxe : {var_<serverVariable>} · {http_req_<Header>} · {http_resp_<Header>}. (Rewrite = App Gateway v2 only.)

🚨 Pièges : subnet AGW /29 trop petit pour l'autoscale → /24. · v2 interne a quand même besoin d'une IP publique de management (ports 65200-65535). · v1 retiré (28 avr 2026) → v2. · Sonde sur / (renvoie 200 si DB down) → /health custom. · 1 WAF policy = 1 type de service. · Rewrite indisponible en v1 (v2 only). · {http_req_host} ≠ {var_host} sur le port (cause classique de backend cassé).

11. Front Door

Home > Front Door and CDN profiles > + Create > Custom create

1. Basics : Profile name afd-shop, Tier Standard (ou Premium pour WAF managé + Private Link).
2. Endpoint : + Add endpoint → shop-prod.
3. Origin group : + Add og-webapp, Health probe /health, session affinity Disabled.
4. Origins : + Add → Origin type App Services, host webapp-eastus.azurewebsites.net, Priority 1, Weight 1000 ; ajouter un 2e origin (autre région).
5. Route : + Add route → route-default, Patterns /*, HTTPS only (redirect HTTP→HTTPS), origin group.
6. Review + create.

Caching : Routes > route-default > Edit > Caching = Enabled (+ query string behavior + compression). 2 routes : /static/* cache ON, /api/* cache OFF. Rules engine / URL rewrite (<AFD profile> > Settings > Rule sets > + Add a rule set → + Add rule → puis associer le rule set à une ou plusieurs routes) : 1 rule = jusqu'à 10 conditions (request path, header, geo, query string, device…) AND + 5 actions :

• URL redirect : redirect 301 apex→www (Redirect type Moved (301), Destination host www.contoso.com, Destination path/query/protocol = HTTPS).
• URL rewrite : Source pattern /application → Destination /app, Preserve unmatched path = Yes/No. ⚠️ seul le path après le patterns to match de la route compte ; / = matche tout.
• Autres actions : Modify request/response header, Route configuration override (cache, origin group), Server variables ({url_path:seg#}, {http_req_arg_<key>}).
• rewrite = interne (path vers l'origin change, client ne voit rien) vs redirect = réponse 301/302/307/308 renvoyée au client. WAF global : Home > WAF policies > + Create → Policy for = Global WAF (Front Door), Tier Premium, Managed rules Microsoft_DefaultRuleSet 2.2 + BotManager 1.1, custom rules (GeoMatch, rate limit), associer au profil Front Door. Mode Detection → Prevention après tuning.

🚨 Pièges : DRS managed rules = Premium only (Standard = custom rules seulement). · Private Link origin = Premium + approbation côté backend. · Protéger l'origine : Service Tag AzureFrontDoor.Backend + header X-Azure-FDID (sinon bypass). · WAF Front Door (global) ≠ WAF App Gateway (régional) — 2 policies distinctes.

12. NAT Gateway

Home > Public IP addresses > + Create : SKU Standard, Static, Zone-redundant/zonal. Home > NAT gateways > + Create

1. Basics : Name natgw, Region = celle du VNet, Availability zone (No zone ou 1/2/3), Idle timeout.
2. Outbound IP : sélectionner la Public IP (ou un Public IP Prefix pour scale SNAT).
3. Subnet : attacher le(s) subnet(s).
4. Review + create. Vérif depuis une VM : curl ifconfig.me = IP du NAT GW.

🚨 Pièges : NAT GW gagne en outbound sur la Public IP de la VM. · Pas de ressources Basic SKU dans le subnet attaché. · Standard (v1) zonale = SPOF si la zone tombe → StandardV2 zone-redundant ou stacks zonaux. · Sortie uniquement (inbound = LB Standard).

13. Bastion

Home > Bastions > + Create

1. Name bastion-hub, Region, SKU Standard (host scaling/Entra/native client).
2. Virtual network + subnet AzureBastionSubnet (/26, nom exact).
3. Public IP Standard (auto, pour le service).
4. Review + create. Connexion : VM > Connect > Bastion.

NSG remote admin sur la NIC/subnet de la VM cible : Allow RDP/SSH source VirtualNetwork (Bastion passe) + Deny RDP/SSH source Internet.

🚨 Pièges : NSG restrictif sur la VM, pas sur AzureBastionSubnet (Bastion gère sa sécurité). · Upgrade Basic→Standard irréversible (choisir Standard d'emblée). · VMs cibles sans Public IP.

14. Network Watcher (diagnostic)

Home > Network Watcher

• Topology : Sub + RG + VNet → carte visuelle.
• IP flow verify : VM, direction, protocole, IP+port local/distant → Allow/Deny + règle NSG.
• Next hop : VM source + IP destination → next hop type + IP (debug UDR/firewall).
• Effective security rules : NIC → toutes les règles NSG (subnet + NIC + AVNM admin).
• Connection troubleshoot : source (VM/Bastion/App GW) → dest → test ponctuel TCP/ICMP + raison du blocage.
• VPN troubleshoot : VPN GW/Connection → Storage account requis → rapport IKE.
• Packet capture : VM (agent Network Watcher requis) → Storage/disque → .cap Wireshark.
• Connection monitor > + Create : sources (VM agent / machine Arc-enabled on-prem) + destinations + test config (protocole/port/fréquence/seuils) → monitoring continu.
• Flow logs > + Create : type Virtual network (NSG = legacy), target VNet, Storage account, Traffic Analytics ON + Log Analytics Workspace.

🚨 Pièges : Troubleshoot = ponctuel, Monitor = continu (SLA → Monitor). · Packet capture / Connection Monitor exigent l'agent. · On-prem comme source → Arc-enabled. · NSG Flow Logs déprécié (création bloquée, retraite 30 sept 2027) → VNet Flow Logs. · Traffic Analytics nécessite un Log Analytics Workspace.

15. Route Server

Home > Route Servers > + Create

1. Basics : Name rs-hub, Region, Virtual network + subnet RouteServerSubnet (/27, nom exact).
2. Public IP Standard, Branch-to-branch = Enabled si les NVAs doivent s'échanger des routes.
3. Review + create.
4. Peers > + Add : Name, ASN de la NVA (différent de 65515 = ASN fixe Route Server), Peer IP = IP privée de la NVA → la NVA établit du BGP avec les 2 IPs du Route Server.

🚨 Pièges : RouteServerSubnet pas de NSG ni UDR. · ASN Route Server 65515 fixe. · BGP only (pas OSPF/RIP). · Propagation auto des routes → pas d'UDR manuelles. · Limites : 16 BGP peers.

16. Activity Log alert (alerte sur modif/suppression d'un VNet)

Home > Monitor > Alerts > + Create > Alert rule (ou depuis la ressource : <VNet> > Alerts > + Create > Alert rule, scope pré-rempli).

1. Scope : sélectionner le VNet (ou le RG/Subscription) → Apply. Filtrable par subscription/resource type/location.
2. Condition : Signal type = Activity Log → choisir le signal, ex Create or Update Virtual Network (= Microsoft.Network/virtualNetworks/write) ou Delete Virtual Network (.../delete). Alert logic : Event level (All), Status (Started/Succeeded/Failed), Event initiated by (caller optionnel).
3. Actions : sélectionner ou + Create action group → onglet Notifications = Email/SMS message/Push/Voice → email de l'owner. (Actions = webhook/Function/Logic App, optionnel.)
4. Details : RG (l'alerte se crée par défaut dans le RG de la ressource cible), Severity, Alert rule name. Region = Global par défaut (les Activity logs sont globaux).
5. Review + create.

🚨 Pièges : Activity Log alert = events control-plane (qui a fait quoi), ≠ Metric alert (perf) ≠ Log search alert (KQL). · Pas de notif sans Action Group. · Scope souvent au niveau Subscription/RG (un write/delete remonte là). · write couvre create et update — filtrer sur Status si besoin.

17. WAF Policy autonome (sans App Gateway ni Front Door)

Home > Create a resource > rechercher "WAF" > Web Application Firewall (WAF) > Create (ou Home > Web Application Firewall policies (WAF) > + Create)

1. Basics : Policy for = Regional WAF (Application Gateway) OU Global WAF (Front Door) (+ Front door tier si FD). RG, Policy name, Policy state = Enabled, Policy mode = Detection (défaut).
2. Policy settings : mode Detection/Prevention, taille max requête/body, Block response status code + body.
3. Managed rules : version du ruleset (DRS côté FD, CRS/OWASP côté AppGw), rule groups, exclusions, disable rule individuelle.
4. Custom rules : + Add custom rule → Match (IP/SocketAddr, GeoMatch, RequestHeader, size, string) ou Rate limit ; priorité ; action Allow/Deny/Log.
5. Association : laisser vide → c'est le but du lab : la policy existe non associée.
6. Review + create.

🚨 Pièges : policy non associée = ne protège rien (créée mais inerte). · mode défaut = Detection (ne bloque pas, log seulement) → passer Prevention après tuning. · Regional (AppGw) et Global (FD) = 2 types distincts non interchangeables. · Association AppGw possible uniquement sur WAF_v2. · une fois une policy associée à un WAF, il doit toujours y en avoir une (on remplace, on ne dissocie pas).

Récap ordre des dépendances (à ne pas inverser)