6 — Virtual Machines

IaaS Azure → VM Windows ou Linux. Tu gères l'OS, MS gère la couche infra (hyperviseur, hardware, réseau physique).

A. Présentation

Familles de VM (sizes)

À retenir (pièges classiques)

• Billing PAYG : VM Stopped = tu paies toujours. Stopped (Deallocated) = tu paies seulement le storage des disks. Bouton "Stop" depuis le portail = deallocate. shutdown /s depuis l'OS = stopped (toujours payé).
• Tu ne peux pas changer : nom de la VM, VNet, region. Workaround = recréer la VM en attachant les disques existants.
• Ressources VM = NIC + OS Disk + Data Disks + (option) Public IP → toutes dans la même region.
• Quotas par sub (Subscription > Usage + quotas) limitent le nb de cores par famille → demander increase si besoin.

Move VMs (déplacement)

Move = la VM garde son resource ID (cross-RG/sub) ou en obtient un nouveau (cross-region). Penser à mettre à jour les références (RBAC, locks, scripts).

Generation 1 vs 2

Le choix Gen1/Gen2 dépend de l'image Marketplace. Migration Gen1 → Gen2 possible via outil MS pour Windows (et upgrade vers Trusted Launch dans la foulée).

Pricing models

Pour AZ-104 : Spot ≠ prod critique. RI/Savings = optimiser une charge connue.

Azure Hybrid Benefit (AHB) — détails

• Pour qui : tu as déjà une licence Windows Server ou SQL Server avec Software Assurance (SA) ou abonnement on-prem.
• Effet : Azure ne te facture que la VM compute "Linux equivalent" (sans license Windows incluse), tu réutilises ta licence existante.
• Activation : à la création (Azure Hybrid Benefit: Yes) ou après (VM > Configuration > Operating system: License type).
• Combinable avec Reserved Instances → cumul des remises (jusqu'à -85% vs PAYG total).
• Couvre aussi : AKS nodes Windows, Azure SQL DB / MI (License-included → BYOL).
• ⚠️ Tu déclares respecter les termes de la SA — Microsoft peut auditer.

Lifecycle states

B. Disks

Types de disques managés

Ultra Disk et Premium SSD v2 = uniquement disques de données (pas OS).

Rôles des disques

• OS Disk (C: Windows / / Linux) : créé avec la VM, contient l'OS.
• Data Disks : ajoutables/détachables à chaud (sauf reduce size). Limite par taille de VM.
• Temp Disk (D: Windows / /dev/sdb Linux) : non persistant, perdu au deallocate. Pour swap/cache uniquement, jamais des données critiques.

Snapshots & Images

• Snapshot : copie point-in-time d'un disk → restore rapide, recréer un disk identique.
• Capture image (depuis VM généralisée) → modèle pour créer N VMs identiques.

C. Networking

• 1+ NIC par VM (nb max selon size). Multi-NIC souvent pour appliances réseau.
• 1+ IP configuration par NIC :
  • Private IP : obligatoire (Dynamic ou Static)
  • Public IP : optionnelle (ressource séparée à attacher)
• ⚠️ Pour resize NIC ou attach NIC additionnelle → la VM doit être Stopped (Deallocated).
• Voir fiche 4 pour NSG/ASG, fiche 5 pour routing/peering.

D. Images

Sources

• Azure Marketplace : Microsoft + éditeurs tiers (Windows Server, Ubuntu, RedHat, etc.). Souvent BYOL ou licences incluses.
• Custom images : capturées depuis tes propres VMs.

Workflow custom image

1. Configurer la VM "golden" (apps, settings)
2. Généraliser :
   • Windows : sysprep /generalize /oobe /shutdown + supprimer dossier C:\Windows\Panther
   • Linux : waagent -deprovision+user
3. Capturer depuis le portail → choisir la cible :
   • Managed image : modèle simple, 1 region, pas de versioning
   • Azure Compute Gallery (recommandé) : versioning, multi-region replication, RBAC, partage cross-tenant

Une fois la VM généralisée, elle ne redémarre pas normalement → utilisable seulement comme template.

E. Configuration & Management

Outils pour configurer/automatiser

Hors AZ-104 mais à savoir : Azure Arc étend ces outils aux VMs hors Azure.

Azure Update Manager

Service natif de patching des VMs Azure (et Arc-enabled). Successeur d'Azure Automation Update Management.

• Périodic assessment : scan régulier (24h par défaut) → liste des updates manquants par VM.
• Patching :
  • On-demand : déclencher manuellement
  • Automatic VM guest patching : auto pour patches Critical/Security (peu de contrôle)
  • Maintenance configuration + Schedule : fenêtre de maintenance custom (jour/heure, récurrence) appliquée à des VMs/RG/MG
• Hotpatching (Windows Server Datacenter Azure Edition) : patches sans reboot.
• Pre/post-maintenance events : scripts à exécuter avant/après le patching.
• Pas de Log Analytics workspace requis (contrairement à l'ancien service).
• Couvre Windows + Linux + SQL Server (Azure VMs et Arc-enabled).

Pour AZ-104 : retenir Maintenance configuration = la nouvelle façon de planifier le patching à grande échelle.

F. VM Scale Sets (VMSS)

Groupe de VMs identiques scalable horizontalement (out/in) avec auto-update et HA.

Orchestration modes

Mode immuable : choisi à la création, non modifiable après. Pour migrer Uniform → Flexible : recréer.

Scaling

• Manual : tu fixes le nombre d'instances.
• Autoscale :
  • Metric-based : CPU, mémoire, queue length, custom metric (Log Analytics)
  • Schedule-based : à heure fixe / récurrent
  • Profiles ordre de priorité : dates spécifiques > jours récurrents > default
  • Multi-rules : si plusieurs scale-out triggers en même temps, la règle qui ajoute le plus de VMs gagne.

Upgrade Policy (Uniform uniquement)

• Manual : tu déclenches Reimage ou Upgrade instance par instance après modif du model
• Automatic : MS push les changements sur toutes les instances (downtime possible)
• Rolling : par batches avec health checks

Resize d'une instance individuelle dans VMSS Uniform = redémarrage de toutes les instances. À planifier.

G. High Availability

Comparatif

Availability Set (AS)

• Fault Domain (FD) : groupe physique (rack, alim, réseau). Default 2, max 3.
• Update Domain (UD) : groupes pour MAJ MS (1 UD à la fois). Default 5, max 20.
• VMs réparties round-robin sur FD/UD à la création.
• ❌ Settings FD/UD non modifiables après création de l'AS.
• ❌ VM existante ne peut pas être ajoutée à un AS post-création.
• ⚠️ Toutes les VMs d'un AS doivent être dans la même region + même RG.

💡 Noms exacts des champs ARM/Bicep/Terraform :

• platformFaultDomainCount (FD) — règle : si FD=1 alors UD=1 obligatoire (sinon erreur Azure). Pour FD=2/3 → UD libre.
• platformUpdateDomainCount (UD)

Exemple piège exam : "Au moins 2 VMs disponibles pendant la maintenance planifiée" → maintenance planifiée = update domain → besoin UD ≥ 3 (pour qu'au pire 1 UD en cours de maj, les 2 autres tournent). FD=2 minimum (pour la contrainte FD/UD).

Availability Zones (AZ)

• 3 zones physiques par région (datacenters distincts).
• Une VM = 1 seule zone (zonal). Une Public IP / Disk Standard SSD/Premium peut être zone-redundant (réplication entre zones).
• Plusieurs VMs sur 3 AZ ≠ AS : ce sont des mécanismes différents, on ne combine pas AS et AZ pour une même VM.

Une AZ peut contenir plusieurs datacenters. Pour ressources avec besoin de low latency entre VMs dans la même zone, utiliser un PPG en plus.

Proximity Placement Group (PPG)

• Force les ressources à être placées physiquement proches (même DC).
• Contient : VMs, VMSS, Availability Sets.
• Region scope (pas de cross-region).
• Use case : low-latency clusters (HPC, DB répliquée, app + DB).

H. VM Encryption

Customer-Managed Keys (CMK)

• Au lieu des clés platform-managed (PMK), tu fournis tes propres clés via Azure Key Vault.
• Implémentation : Disk Encryption Set (DES) qui pointe vers la key dans le KV.
• Le KV doit avoir Soft delete + Purge protection activés pour CMK.

Pour AZ-104 : retenir que SSE est obligatoire et transparent. ADE = legacy à éviter pour de nouvelles VMs. Pour control des clés → Encryption at Host + DES + CMK.

ADE + KEK — préparation du Key Vault

Même si ADE part en retraite 2028, l'exam pose encore des questions sur sa configuration. Pour utiliser un Key Encryption Key (KEK) stocké dans un KV existant pour ADE, 2 actions côté KV :

1. Générer une nouvelle clé crypto dans le KV qui servira de KEK (Keys > Generate/Import). ⚠️ Type = RSA obligatoire (pas EC), taille min 2048 (2048 / 3072 / 4096 supportés). HSM-backed possible (Premium KV ou Managed HSM).
2. Update access policy du KV pour accorder les permissions au resource provider Azure Disk Encryption (pas au RP Microsoft.Compute) — il a besoin de WrapKey / UnwrapKey pour wrapper les clés de chiffrement disk.

⚠️ Pièges typiques tutorialdojo (réponses incorrectes mais plausibles) :

• "Enable soft-delete + purge protection" → c'est best practice KV mais pas un requirement spécifique ADE+KEK.
• "Configure key rotation policy" → bonne pratique, pas un requirement.
• "Grant access to Microsoft.Compute resource provider" → mauvais RP, c'est Azure Disk Encryption qui a besoin de l'accès, pas Compute.

Trusted Launch

Sécurité boot pour VMs Gen2 uniquement → protège contre rootkits / bootkits.

3 composants (activés par défaut quand on choisit Trusted Launch) :

• Secure Boot : vérifie la signature des composants au boot (refuse code non signé)
• vTPM (virtual TPM 2.0) : module crypto virtuel pour stockage de keys, attestation
• Boot Integrity Monitoring (Guest attestation) : reporte l'état du boot dans Azure Monitor

À retenir :

• ✅ Recommandé MS pour toutes nouvelles VMs Gen2 (default depuis 2023 sur la plupart des images).
• Compatible avec la plupart des sizes modernes (vérifier la doc pour les exceptions).
• Upgrade possible : Gen1 → Gen2-Trusted Launch (Windows) ou Gen2 existante → Trusted Launch.
• Prérequis pour Confidential VMs (AMD SEV-SNP / Intel TDX).

I. Troubleshooting & Monitoring

Boot diagnostics

• Capture screenshot console + serial log au boot → utile si la VM ne démarre pas / écran bleu.
• 2 modes :
  • Managed (recommandé) : MS gère le storage, pas de config
  • Custom : storage account explicite (legacy)
• Activé par défaut pour les nouvelles VMs.
• Accès : VM > Boot diagnostics > Screenshot / Serial log.

Serial Console

• Accès clavier OS sans réseau (port série) → utile si SSH/RDP HS, mauvaise config réseau, etc.
• Prérequis : Boot diagnostics activé + un user local connu (Linux : root ou créé), Windows (SAC puis cmd).
• Accès : VM > Serial console.

VM Insights

• Solution de monitoring détaillé : performance (CPU/RAM/disk/net) + map (dépendances réseau entre VMs et services).
• Prérequis : Log Analytics workspace + Azure Monitor Agent (AMA, remplace l'ancien MMA) déployé sur la VM.
• Activable au scope sub/RG/VM via Azure Policy ou portail.
• Données envoyées dans Log Analytics → KQL queries possibles.

Pour AZ-104 : Boot diagnostics (screenshot+serial), Serial console (clavier), VM Insights (perf+map). Distinguer les 3.

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Migration SAP S/4HANA lift-and-shift (industriel manufacturier)

Contexte business : Un groupe industriel ferme son datacenter et déplace son ERP SAP (critique) vers Azure. L'éditeur SAP impose une latence très basse entre l'app et la base (< 0.7 ms) et une reprise en moins d'1h. Choix architectural : VMs série M (optimisées mémoire, certifiées HANA, jusqu'à 12 TB RAM) avec disques Premium SSD v2 / Ultra Disk pour la base. On regroupe physiquement app et base via un Proximity Placement Group (PPG) pour la latence. Architecture / pattern :

• Le PPG est ancré sur la 1re VM HANA → toutes les autres VMs SAP (app servers, ASCS) atterrissent dans ce même PPG, donc proches physiquement.
• Haute dispo : 2 zones (une primaire, une secondaire) avec réplication HANA System Replication entre les deux.
• DR : réplication ASR vers une autre région.
• Coûts : Reserved Instances 3 ans + Azure Hybrid Benefit (jusqu'à -65%).
• Sécurité : Encryption at Host + CMK. Trade-offs assumés :
• Gain : latence minimale et SLA SAP respecté.
• Perte : familles M et disques Ultra sont chers, et le PPG fige la topologie. Pièges à éviter :
• HANA sur Standard SSD → SAP refuse le SLA. Toujours Premium SSD v2 ou Ultra Disk.
• Créer le PPG après la 1re VM → impossible. Il faut le créer avant.
• Vouloir combiner Availability Set + zones → interdit. Pour la HA inter-zones de HANA, on utilise HSR, pas d'AS.
• ASR + Ultra Disk : compatibilité limitée → vérifier la support matrix avant de promettre du DR.

📐 Réf. — SAP on Azure (Well-Architected) + Reliability : colocaliser app/DB via PPG pour la latence, HA inter-zones via HANA System Replication, DR via ASR cross-region est l'architecture recommandée pour SAP sur Azure. Lien

Scenario 2 : Rendu 3D / encodage vidéo (studio media & post-production)

Contexte business : Un studio livre des vidéos 4K/8K en urgence. Gros pics de rendu le soir, machines inutiles le jour. Le calcul est le plus gros poste de coût. Choix architectural : un VMSS Flexible rempli de Spot VMs (peu chères, mais interruptibles), sur familles HPC (HB/HC) ou GPU (N-series) selon le logiciel. L'autoscale suit un planning (soir vs jour). Architecture / pattern :

• VMSS qui mélange des tailles : HBv3 pour le CPU, NVads_A10_v5 pour les passes GPU.
• Autoscale planifié : "en semaine 19h-8h, min 20 / max 200", sinon min 2.
• Une Custom Script Extension dans l'extensionProfile du VMSS installe l'agent de rendu sur chaque nouvelle instance automatiquement.
• Spot : prix max -1 (paie au plus jusqu'au tarif normal) + eviction Delete (on jette l'instance évincée, le job repart ailleurs).
• La VM "chef d'orchestre" (head node) reste en Reserved Instance, jamais en Spot. Trade-offs assumés :
• Gain : coût compute fortement réduit grâce au Spot.
• Perte : risque d'éviction → il faut une head node stable et de quoi rebondir. Pièges à éviter :
• Tout passer en Spot : la head node doit rester PAYG ou RI, sinon une éviction casse le pipeline.
• Eviction Deallocate sur une grosse flotte Spot → des disques OS orphelins s'accumulent et gonflent la facture en silence.
• Quota vCPU régional trop bas → autoscale bloqué bien avant le max voulu. Demander l'augmentation avant la prod.
• Familles H/N souvent en pénurie → prévoir une 2e région ou une famille alternative en secours.

📐 Réf. WAF — Cost optimization (use Spot/pre-purchase) : utiliser Spot VMs pour les charges interruptibles + Reserved Instances pour la base stable est la stratégie Well-Architected d'optimisation des coûts compute. Lien

Scenario 3 : Application bancaire interne hautement réglementée (banque retail)

Contexte business : Une appli Windows ancienne (.NET, IIS) traite des données clients. RGPD + secret bancaire, rien exposé sur Internet, DR obligatoire (reprise en 4h). Choix architectural : VMs Windows Gen2 Trusted Launch (Secure Boot + vTPM), chiffrement disque via Encryption at Host + CMK, réparties sur 3 zones derrière un Load Balancer Standard zone-redundant. DR par ASR et patching géré par Azure Update Manager. Architecture / pattern :

• 3 VMs (1 par zone) derrière un LB Standard zone-redundant — du multi-zone, donc pas d'Availability Set.
• OS Windows Server Azure Edition → hotpatching (patchs sans redémarrage).
• Clés de chiffrement (CMK) dans un Key Vault Premium adossé à un HSM.
• Boot diagnostics + Serial Console activés pour dépanner même sans réseau.
• ASR avec recovery plan qui orchestre le basculement (DB, app, DNS).
• Coûts : Hybrid Benefit + RI 3 ans. Trade-offs assumés :
• Gain : résilience zone + conformité forte.
• Perte : 3 VMs toujours allumées + Key Vault HSM = coût récurrent. Pièges à éviter :
• Croire que les zones remplacent le backup : elles protègent d'une panne datacenter, pas d'une corruption ou d'un ransomware. Toujours ajouter Azure Backup.
• Activer ADE en 2026 → legacy (retraite 15 sept 2028). Pour une nouvelle VM : Encryption at Host directement.
• Patcher sans pré/post events → le LB envoie du trafic vers une VM en cours de patch. Toujours scripter un drain.
• Public IP non zone-redundant sur le LB → point de panne unique. Forcer Standard SKU zone-redundant.

📐 Réf. WAF — Reliability (redundancy) & Security (data-at-rest) : multi-zone derrière un LB zone-redundant + Encryption at Host/CMK + Azure Backup couplé à la redondance zone suit les piliers Reliability et Security du Well-Architected Framework. Lien

DEMO — chemins portail

Créer / gérer une VM

1. Virtual machines > Create → image, size, admin creds, disk options, networking, monitoring
2. Option "Delete with VM" sur OS disk + NIC + Public IP → cocher pour cleanup auto
3. Resize : Size blade. Si la size cible n'apparaît pas → stopper la VM (parfois cluster physique limite).
4. Redeploy : Help > Redeploy + reapply → migre la VM sur un autre host (utile en cas de bug host).

Disk operations

1. Snapshot avant changement : VM > Disks > [disk] > Create snapshot
2. Resize OS disk : VM doit être Stopped (Deallocated). Resize uniquement vers le haut.
3. Add data disk : possible à chaud. Côté OS Windows : diskmgmt.msc pour initialiser/format.
4. Convert disk type : Disk > Size + performance > Disk SKU (la VM doit être stoppée).

Image custom + Compute Gallery

1. Préparer la VM "golden" → installer apps + config
2. Généraliser :
   • Windows : RDP → C:\Windows\System32\Sysprep\sysprep.exe → cocher OOBE + Generalize + Shutdown
   • (avant : supprimer C:\Windows\Panther)
3. Compute Gallery > Create (dans la même region/RG idéalement)
4. Depuis la VM généralisée : Capture → choisir Gallery, image definition, version
5. Créer une nouvelle VM depuis : VM > Create > See all images > My items > Shared with me

Custom Script Extension

1. Stocker le script (.ps1 / .sh) dans un Blob (ou Git)
2. VM > Extensions + applications > Add > Custom Script Extension
3. Pointer vers le script (URL Blob avec SAS si privé)
4. Le script s'exécute une seule fois au déploiement de l'extension

CSE dans VMSS via ARM template : pour installer du soft (ex composants web IIS) sur toutes les instances d'un VMSS au déploiement, on déclare l'extension dans la section extensionProfile du VMSS dans l'ARM/Bicep template. Au scaling out → chaque nouvelle instance exécute le script auto. Pas besoin d'Automation Account, juste : (1) écrire le script, (2) référencer son URL dans extensionProfile.

VMSS Flexible

1. Virtual machine scale sets > Create → Orchestration mode: Flexible
2. Choisir VNet/subnet, LB optionnel
3. Scaling : Manual (instance count) ou Custom autoscale
4. Les instances apparaissent dans le RG comme des VMs standard

Autoscale rules

1. VMSS > Scaling > Custom autoscale
2. Default profile : min/max/default + scale rules
3. Add scale-out rule : metric (ex CPU > 75%), aggregation, cooldown, increment
4. Add scale-in rule : symétrique (CPU < 25%)
5. Schedule profile (ex : weekday 9-18h min=4, weekend min=1)

AS + PPG

1. Proximity placement group > Create (region target)
2. Availability set > Create (même region) → choisir le PPG, FD=2 ou 3, UD=5+
3. Avant les VMs : créer AS + PPG d'abord
4. À la création de la VM : Availability options > Availability set → sélectionner

Encryption VM — vue d'ensemble (rappel des 4 couches)

┌────────────────────────────────────────────────────────┐
│ SSE (Storage Service Encryption)                        │
│   ✅ Always-on, AES-256 at-rest côté plateforme         │
│   PMK par défaut (CMK possible via DES)                 │
├────────────────────────────────────────────────────────┤
│ Encryption at Host (recommandé MS)                   │
│   Chiffre OS + Data + Temp + Caches AU NIVEAU HOST      │
│   Avant écriture sur stockage                           │
├────────────────────────────────────────────────────────┤
│ ADE (Azure Disk Encryption) — legacy                    │
│   BitLocker (Win) / dm-crypt (Linux) DANS la VM         │
│   BEK → Key Vault, KEK optionnelle (wrap BEK)           │
├────────────────────────────────────────────────────────┤
│ Confidential Disk Encryption                            │
│   AMD SEV-SNP / Intel TDX pour workloads sensibles      │
└────────────────────────────────────────────────────────┘

DEMO 1 — Encryption at Host + CMK (recommandé prod)

1. Activer la feature sur la sub (one-shot) :

   az feature register --namespace Microsoft.Compute --name EncryptionAtHost
   az provider register -n Microsoft.Compute
   

2. Préparer Key Vault : Key vaults > Create avec Soft-delete ACTIVÉ + Purge protection ACTIVÉE (obligatoires pour CMK).
3. Créer une clé RSA : KV > Keys > Generate/Import → type RSA, taille 2048+ (2048/3072/4096).
4. Créer un Disk Encryption Set (DES) : Disk Encryption Sets > Create → pointer vers le KV + la key. Le DES reçoit une System-assigned Managed Identity auto.
5. Donner accès au DES sur le KV : KV > Access policies (ou RBAC) → ajouter la MI du DES avec Get, WrapKey, UnwrapKey.
6. À la création de la VM : Disks blade → Encryption at host: On + Encryption type: Customer-managed key → sélectionner le DES.
7. Vérifier : VM > Disks > [disk] > Encryption → doit afficher la clé du DES.

DEMO 2 — ADE + KEK (legacy mais encore en exam)

1. KV avec Soft-delete + Purge protection ACTIVÉS + Azure Disk Encryption for volume encryption activé (KV > Properties).
2. Créer la KEK : KV > Keys > Generate/Import → type RSA, taille 2048+.
3. Update access policy du KV → ajouter le resource provider Azure Disk Encryption (PAS Microsoft.Compute) avec Get, WrapKey, UnwrapKey.
4. Activer ADE sur la VM (PowerShell) :

   Set-AzVMDiskEncryptionExtension `
     -ResourceGroupName myrg -VMName myvm `
     -DiskEncryptionKeyVaultUrl $kv.VaultUri `
     -DiskEncryptionKeyVaultId $kv.ResourceId `
     -KeyEncryptionKeyUrl $kek.Key.Kid `
     -KeyEncryptionKeyVaultId $kv.ResourceId `
     -VolumeType All
   

5. Vérifier état : Get-AzVMDiskEncryptionStatus -ResourceGroupName myrg -VMName myvm.

🚨 Pièges ADE+KEK : KEK = RSA obligatoire (pas EC). Soft-delete + Purge protection = prérequis (sans ça, refus). Le RP est Azure Disk Encryption, pas Compute.

Move VM

1. VM > Move > Move to another resource group/subscription
2. Cocher les ressources liées (NIC, Public IP, Disks)
3. Validation Azure → confirmer le nouveau RG/sub
4. Cross-region : passer par ASR (réplication) ou snapshot disks → recreate dans la region cible

Spot VM

1. Create VM > Azure Spot instance: Yes
2. Choisir Eviction type : Capacity only (Azure récupère la capacité) ou Capacity or Price (eviction aussi quand le prix dépasse ton max)
3. Eviction policy : Deallocate (garde les disks, redéploiement plus rapide) ou Delete (cleanup total)
4. Max price : -1 (paie jusqu'au tarif PAYG max) ou cap personnalisé

Trusted Launch (sur nouvelle VM)

1. Create VM > Security type: Trusted launch virtual machines
2. Secure Boot + vTPM cochés par défaut → laisser
3. Choisir une image Gen2 compatible (la plupart des images modernes le sont)

Update Manager

1. Azure Update Manager > Machines → liste tous les VMs Azure + Arc
2. One-time : sélectionner VMs → One-time update → choisir classifications + reboot setting
3. Schedule : Maintenance configurations > Create → type Guest, scope (sub/RG/VM), recurrence → puis Assign aux VMs
4. Periodic assessment : activable à grande échelle via Azure Policy

Boot diagnostics / Serial console

1. Activer Boot diag : VM > Boot diagnostics > Settings > Enable with managed storage account
2. Voir l'écran : VM > Boot diagnostics > Screenshot (pour diagnostiquer un freeze au boot)
3. Serial console : VM > Serial console → si Linux, login root ou user créé. Si Windows, cmd pour activer SAC.

VM Insights

1. Prérequis : Log Analytics workspace existant
2. VM > Insights > Enable → choisir le workspace
3. AMA déployé auto → données dispo après quelques minutes
4. Vue Map : visualiser les connexions réseau de la VM

Backup (rappel quick — détaillé dans une fiche dédiée)

• VM > Backup → créer un Recovery Services Vault, choisir policy → backup automatique
• Restore options : full VM / disk / file-level