Microsoft AZ-104: Machines virtuelles Azure et Services de calcul — Guide d'étude

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Administrator Associate AZ-104 — 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.

Stockage, sauvegarde et gestion des images

Chaque VM possède un disque de système d’exploitation (disque managé, avec une mise en cache optimisée pour le démarrage) et des disques de données optionnels pour le stockage des applications. Le disque temporaire (D: sous Windows, souvent /dev/sdb sous Linux) réside sur l’hôte et n’est pas persistant ; ne l’utilisez que pour les caches éphémères ou le fichier d’échange (pagefile/swap). Les disques managés (Managed Disks) font abstraction des comptes de stockage, offrent des options de redondance zonale/régionale, simplifient la mise à l’échelle et améliorent la répartition dans les groupes à haute disponibilité (availability sets). Les disques non managés (Unmanaged Disks) placés dans les comptes de stockage du client sont obsolètes et doivent être évités en raison des limites de mise à l’échelle et de limitation des performances (throttling). Sélectionnez les références (SKU) de disque en fonction des performances et du coût : Premium SSD et Premium SSD v2 pour les charges de travail transactionnelles à faible latence, Ultra Disk pour un débit/IOPS extrême avec des performances ajustables, Standard SSD pour un usage général, et Standard HDD pour les charges de travail froides.

Détacher un disque de données d’une VM avant de l’attacher à une autre minimise les temps d’arrêt et préserve la cohérence des données. Les opérations de redimensionnement sur les disques nécessitent généralement une extension de la partition/du système de fichiers au sein du système d’exploitation invité ; des changements importants de la taille de la VM peuvent nécessiter une désallocation.

Azure Backup protège les VM à l’aide d’un coffre Recovery Services. Activez la sauvegarde sur la VM ou à grande échelle via l’attribution de stratégies (policy). Les stratégies de sauvegarde définissent les planifications (quotidiennes/hebdomadaires), la rétention (à court et long terme) et les paramètres de restauration instantanée (Instant Restore) (conserver les instantanés localement pour une récupération rapide des fichiers). Des sauvegardes cohérentes avec les applications sont disponibles via VSS pour Windows ou des scripts pré/post-exécution sur Linux. Les restaurations peuvent cibler une VM entière (généralement vers une nouvelle VM), des disques (pour un rattachement/une récupération rapide) ou des fichiers (restauration au niveau fichier vers n’importe quelle VM de l’abonnement avec un montage sécurisé). Les sauvegardes fonctionnent pour les VM en cours d’exécution et arrêtées (y compris désallouées). Assurez la compatibilité du chiffrement : les clés gérées par la plateforme sont prises en charge par défaut, et Azure Disk Encryption nécessite des étapes supplémentaires pour la sauvegarde. Envisagez la restauration inter-régions si votre coffre a le stockage géo-redondant activé et si votre posture de conformité le permet.

Pour les images de référence (golden images), utilisez Azure Compute Gallery pour versionner et répliquer les images entre les régions ; les téléversements de VHD généralisés sur site peuvent être effectués avec des outils tels que Add-AzVhd, puis capturés dans la galerie pour un provisionnement cohérent.

Réseautage, accès et observabilité

Chaque VM nécessite au moins une interface réseau (NIC), qui contient une ou plusieurs configurations IP. Une seule NIC peut détenir une adresse IP privée principale et des adresses IP privées secondaires supplémentaires ; associez une adresse IP publique à une configuration IP pour exposer des services. La plupart des charges de travail ne nécessitent qu’une seule NIC par VM ; les tailles de VM déterminent les limites de NIC. Lors du déploiement de cinq VM qui nécessitent chacune des adresses IP publiques et privées avec une posture de sécurité identique, créez une NIC par VM et un seul groupe de sécurité réseau (Network Security Group) appliqué au niveau du sous-réseau (ou de la NIC) pour appliquer des règles entrantes/sortantes uniformes. L’attribution d’adresses IP privées doit être statique au niveau de la NIC dans Azure pour maintenir la continuité de l’adresse ; ne configurez pas d’adresses IP statiques à l’intérieur du système d’exploitation invité. Les adresses IP publiques doivent utiliser la référence (SKU) Standard pour la prise en charge des zones et des groupes de machines virtuelles identiques (scale sets) ; associez-les à un Standard Load Balancer pour la production.

Le réseau accéléré (Accelerated Networking) utilise SR-IOV pour contourner le chemin de données de l’hôte et réduire la latence, la gigue et la charge CPU. Il est pris en charge sur certaines tailles de VM et images de système d’exploitation et nécessite une vNIC compatible au moment de la création (ou un arrêt/désallocation pour l’activer). Utilisez-le pour les services à haut débit et faible latence et pour les niveaux de passerelle très sollicités.

Azure Bastion fournit un accès RDP/SSH sécurisé sur TLS directement depuis le portail Azure ou un client natif sans exposer d’adresses IP publiques sur les VM. Déployez un hôte Bastion dans le réseau virtuel cible, dans un sous-réseau dédié nommé AzureBastionSubnet avec un préfixe /26 ou plus grand, et associez une adresse IP publique Standard à la ressource Bastion. Les références (SKU) incluent Basic et Standard ; la référence Standard ajoute des fonctionnalités telles que la mise à l’échelle manuelle (instances), les connexions basées sur IP (vers n’importe quelle IP privée joignable, y compris à travers des réseaux virtuels appairés), la prise en charge du client natif, l’intégration de l’enregistrement de session et les liens partageables. Utilisez Bastion pour satisfaire un accès administratif de type zero-trust tout en évitant les points de terminaison publics par VM et les règles NAT entrantes.

Les extensions de VM automatisent la configuration et la télémétrie. L’extension de script personnalisé (Custom Script Extension) exécute PowerShell ou Bash pendant ou après le provisionnement pour amorcer des logiciels ou injecter des fichiers de configuration ; concevez des scripts idempotents et stockez les artefacts dans un stockage sécurisé avec des jetons SAS. L’extension PowerShell DSC applique la configuration d’état souhaité (Desired State Configuration) pour faire converger les nœuds Windows vers un état déclaré ; utilisez des serveurs pull ou Azure Automation State Configuration pour une gestion à grande échelle. L’agent Azure Monitor (installé via une extension) envoie les métriques et les journaux du système d’exploitation invité vers les espaces de travail Log Analytics sous des règles de collecte de données (Data Collection Rules) ; préférez l’AMA à l’ancien agent Log Analytics/MMA pour un routage granulaire des données, le multihoming et la mise à l’échelle.

Mécanismes de disponibilité en pratique et SLAs

Choisissez les groupes à haute disponibilité (availability sets) lorsque vous avez besoin d’une redondance intra-datacenter avec des backends de stockage partagés et que vous n’exigez pas de placement zonal. Optez pour les zones de disponibilité (availability zones) pour les services critiques qui exigent une isolation des pannes au niveau du bâtiment et un SLA plus élevé. Pour les services à montée en charge horizontale (scale-out), combinez les VMSS avec les zones pour une distribution uniforme et une réparation automatique ; épinglez les sondes d’intégrité (health probes) aux ports des charges de travail et tirez parti des mises à niveau propagées (rolling upgrades) pour atténuer les risques. Comprenez que les VMs uniques, même avec des disques Premium SSD, offrent un SLA inférieur à celui des déploiements multi-instances. Pour les couches sans état sensibles aux coûts, intégrez un pool de VMs Spot derrière un Standard Load Balancer et définissez des stratégies d’éviction et de scale-in prudentes pour protéger la capacité de base.

Scénario de problème pratique

Contoso Ltd. exploite une application web multi-niveaux avec une API sans état (stateless), un cache Redis avec état (stateful) et un groupe de disponibilité SQL Server Always On. Ils doivent améliorer la résilience aux pannes de zone, réduire les coûts de calcul pour la couche API, sécuriser l’accès administratif sans adresses IP publiques, et standardiser la surveillance et les sauvegardes.

1. Créez trois sous-réseaux dans une topologie hub-spoke : un sous-réseau de gestion partagé (hub), un sous-réseau web/API (spoke) et un sous-réseau de données (spoke). Déployez Azure Bastion Standard dans l’AzureBastionSubnet (/26) du hub avec une adresse IP publique Standard. Raison : Bastion permet les connexions RDP/SSH sur TLS sans exposer d’adresses IP publiques sur les VMs, et la référence (SKU) Standard prend en charge les connexions basées sur IP à travers les réseaux virtuels appairés (peered VNets), centralisant ainsi l’accès administratif.

2. Déployez la couche API en tant que VM Scale Set (Uniform) à travers les zones de disponibilité 1, 2 et 3 avec un Standard Load Balancer. Activez les performances réseau accélérées (accelerated networking) et définissez des règles de mise à l’échelle automatique pour ajouter des instances lorsque l’utilisation moyenne du processeur est > 65 % pendant 10 minutes et en supprimer lorsqu’elle est < 35 % avec un temps de recharge (cooldown). Ajoutez un pool de VMs Spot secondaire au sein du même groupe identique en utilisant l’orchestration Flexible ou un groupe identique compagnon, en configurant le prix maximum et la stratégie d’éviction Deallocate (Désallouer). Raison : Les VMSS combinés aux zones offrent un SLA de 99,99 % et une réparation automatique ; la capacité Spot réduit les coûts pour les pics de charge tandis que la stratégie Deallocate préserve les disques pour une réutilisation rapide.

3. Déployez les VMs du cache Redis dans un groupe à haute disponibilité (availability set) avec au moins 2 instances et des disques Premium SSD. Épinglez les domaines d’erreur (fault domains) à 2 et fiez-vous aux 20 domaines de mise à jour (update domains) de la plateforme. Raison : Le cache est avec état mais peut se répliquer ; les groupes à haute disponibilité fournissent une isolation au niveau du rack et de la maintenance sans les pénalités de latence inter-zones.

4. Déployez deux VMs SQL Server par zone (zones 1 et 2) participant à un groupe de disponibilité Always On. Placez-les sur des Azure Dedicated Hosts au sein d’un groupe d’hôtes s’étendant sur deux zones et deux domaines d’erreur d’hôte. Configurez un Standard Load Balancer interne avec une sonde TCP sur le port d’écoute (par ex., 1433) pour l’écouteur du groupe de disponibilité (AG listener). Raison : Les Dedicated Hosts fournissent une isolation au niveau de l’hôte et une efficacité de licence (licences SQL par hôte), tandis que le placement zonal et les sondes d’intégrité TCP s’alignent sur les exigences de l’écouteur SQL.

5. Standardisez les images via Azure Compute Gallery contenant des images de système d’exploitation renforcées (hardened). Utilisez l’extension de script personnalisé (Custom Script Extension) pour installer les prérequis de l’application et l’extension DSC pour appliquer l’état des fonctionnalités Windows et les bases de référence du registre. Raison : Les images de la galerie garantissent un provisionnement cohérent ; les extensions permettent une configuration reproductible et un contrôle de la dérive.

6. Configurez l’Azure Monitor Agent via des règles de collecte de données (Data Collection Rules) pour envoyer les métriques et les journaux des invités (guest) à un espace de travail Log Analytics. Activez la surveillance des connexions et les cartographies de dépendances selon les besoins. Raison : L’AMA est l’agent actuel, il prend en charge le routage granulaire et est requis pour les fonctionnalités de surveillance modernes et la mise à l’échelle automatique des VMSS basée sur des métriques autres que le processeur.

7. Protégez toutes les VMs avec Azure Backup dans un coffre Recovery Services en utilisant deux stratégies : une stratégie de niveau 1 (Tier-1) avec des sauvegardes quotidiennes et une rétention de 30 jours pour l’API/cache, et une stratégie de niveau 0 (Tier-0) avec une rétention quotidienne plus hebdomadaire/mensuelle pour SQL avec des instantanés cohérents avec l’application (application-consistent snapshots). Testez les restaurations en effectuant une récupération au niveau fichier vers une VM de rebond (jump VM) et une restauration complète de VM vers un réseau de préproduction (staging). Raison : Des stratégies distinctes correspondent à la criticité des données et aux RPO/RTO ; la récupération de fichiers et la restauration de VM couvrent les scénarios de ransomware et de sinistre.

8. Attribuez des adresses IP privées statiques aux cartes réseau (NICs) de SQL et Redis au niveau de la carte réseau Azure ; conservez les instances d’API en mode dynamique derrière le répartiteur de charge. Appliquez un seul NSG à chaque sous-réseau pour imposer des règles uniformes. Activez les performances réseau accélérées sur les couches à fort trafic. Raison : L’attribution statique au niveau de la carte réseau préserve l’adressage pour les couches avec état ; les NSG au niveau du sous-réseau minimisent la prolifération des règles ; les performances réseau accélérées réduisent la latence et la charge du processeur.

Cette conception répond aux objectifs de disponibilité, de coût, de sécurité et d’exploitation en combinant de manière appropriée les zones et les groupes à haute disponibilité, en tirant parti des VMs Spot pour la mise à l’échelle sans état, en appliquant un accès administratif zero-trust avec Bastion, et en standardisant la configuration, la surveillance et la sauvegarde à travers les différentes couches.

← Abonnements Azure · Tous les domaines · Réseaux virtuels Azure →

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

Parcourir Microsoft →