3.1 - Déployer des VM, images et modèles (ARM, Bicep)
L'objectif 3.1 de l'AZ-104 couvre le déploiement des ressources de calcul et l'infrastructure en tant que code. Pour capturer une image réutilisable, tu généralises d'abord la VM afin d'en retirer les identifiants spécifiques : exécute sysprep sous Windows, ou la commande waagent -deprovision sous Linux. Pour la disponibilité, un groupe à haute disponibilité répartit les VM sur des domaines de panne et de mise à jour dans un même datacenter, tandis qu'un déploiement sur plusieurs zones de disponibilité survit à la panne d'un datacenter entier et offre la meilleure résilience en région unique. Les modèles ARM sont des documents JSON avec des sections de haut niveau comme parameters, variables, resources et outputs, plus une propriété schema qui déclare la version du langage ; l'élément resources contient les ressources réelles, une boucle copy déploie plusieurs instances en itérant un compteur, et les fonctions reference et de référence Key Vault récupèrent des secrets au déploiement sans les coder en dur. Un modèle qui crée un groupe de ressources puis y place des ressources doit s'exécuter à la portée de l'abonnement. Bicep est le langage plus clair et concis qui se compile en ARM, gère les modules pour réutiliser un déploiement autonome défini dans un fichier .bicep séparé, et publie ces modules dans un Azure Container Registry pour les partager. Attends-toi à des mises en situation qui demandent quelle étape d'image, option de disponibilité ou construction de modèle convient.
Généraliser avant de capturer une image = sysprep (Windows) ou waagent -deprovision (Linux). Survivre à la panne d'un datacenter = zones de disponibilité. Répéter une ressource dans un modèle = boucle copy. Bicep se compile en ARM et gère des modules réutilisables.
Questions d'entraînement
1. Vous devez redeployer exactement la meme infrastructure de facon repetee, declarative et idempotente sur Azure. Quelle approche convient le mieux ?
- Un modele Bicep ou ARM (bonne réponse)
- Une suite de commandes Azure CLI ecrites a la main qu'un administrateur execute manuellement a chaque fois
- Un wiki de captures d'ecran du portail
- Un script shell unique par ressource
Les modeles Bicep et ARM sont de l'infrastructure as code declarative : on decrit l'etat voulu et Resource Manager rend les deploiements repetables et idempotents. Les executions CLI manuelles, les captures et les scripts uniques sont imperatifs et sujets aux erreurs.
2. Au sein d'un availability set, que represente un fault domain (domaine de panne) ?
- Un groupe de VM partageant une source d'alimentation et un commutateur reseau communs (bonne réponse)
- Un regroupement logique servant uniquement a planifier et echelonner le deploiement de la maintenance planifiee et des mises a jour de l'OS hote par lots
- Une region Azure separee
- Un type de disque manage
Un fault domain est un ensemble de VM partageant une alimentation et un commutateur reseau communs ; repartir les VM entre fault domains protege d'une panne materielle ou d'alimentation unique. L'echelonnement des mises a jour releve des update domains.
3. Au sein d'un availability set, quel est le role des update domains (domaines de mise a jour) ?
- Ils copient chaque disque de VM vers une region secondaire appariee pour que les donnees survivent a la perte complete de la region principale lors d'un sinistre
- Ils garantissent que la maintenance planifiee de l'hote ne redemarre qu'un groupe de VM a la fois (bonne réponse)
- Ils filtrent le trafic reseau entrant
- Ils definissent le niveau de disque de la VM
Les update domains regroupent les VM afin que, lors de la maintenance planifiee de l'hote, un seul update domain soit redemarre a la fois, gardant le reste du set en service. La georeplication n'a aucun rapport, le filtrage est un role de NSG et les niveaux de disque sont distincts.
4. Vous placez des VM dans un seul availability set a l'interieur d'un centre de donnees. Contre quelle defaillance ce choix ne protege-t-il PAS ?
- Une baie de serveurs unique perdant son alimentation partagee, precisement le type de panne materielle localisee que la repartition sur des fault domains vise a isoler
- La panne du centre de donnees entier (bonne réponse)
- Un hote redemarre pour des mises a jour planifiees
- Un commutateur reseau unique defaillant
Un availability set repartit les VM sur des fault et update domains dans un seul centre, protegeant des pannes de baie, de switch et de maintenance, mais pas de la perte du centre entier. Les availability zones sont necessaires pour une resilience au niveau du centre.
5. Que sont les availability zones (zones de disponibilite) au sein d'une region Azure ?
- Des centres de donnees physiquement separes, chacun avec alimentation, refroidissement et reseau independants (bonne réponse)
- Des baies logiques dans un meme centre qui partagent la meme alimentation et le meme refroidissement mais utilisent des commutateurs differents
- Des copies de donnees dans une seconde region
- Differentes familles de tailles de VM
Les availability zones sont des centres de donnees physiquement separes dans une region, chacun avec sa propre alimentation, son refroidissement et son reseau ; repartir les VM entre zones survit a la panne d'un centre entier. Ce ne sont ni des baies dans un batiment ni une seconde region.
6. Vous voulez la plus haute disponibilite dans une region pour un groupe de VM afin qu'elles survivent a la panne d'un centre entier. Que devez-vous utiliser ?
- Un availability set, qui ne repartit les VM que sur des fault et update domains mais les garde toutes dans un seul et meme centre de donnees physique
- Des VM reparties sur deux availability zones ou plus (bonne réponse)
- Une seule grande VM
- Un groupe de placement de proximite
Repartir les VM sur deux availability zones ou plus les place dans des centres physiquement separes, survivant a la panne d'un centre. Un availability set ne protege que dans un centre, une seule grosse VM est un point unique de defaillance et un groupe de proximite reduit la latence.