Microsoft AZ-400: Infrastructure en tant que code et gestion de la configuration — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — 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.

Vue d’ensemble

L’Infrastructure as Code (IaC) et la gestion de la configuration sur Azure vous permettent de définir, de provisionner et d’appliquer les paramètres de l’infrastructure et des applications de manière répétée et sécurisée. Azure prend en charge nativement ARM JSON et Bicep, et s’intègre bien avec Terraform et Ansible. L’état de la configuration peut être déclaré avec PowerShell Desired State Configuration (DSC), Azure Automation DSC, Chef et Puppet. Le déploiement des fonctionnalités applicatives et la gestion des clés sont centralisés avec Azure App Configuration et Key Vault. Les images immuables construites avec Packer réduisent la dérive. La gouvernance est appliquée en tant que policy-as-code avec Azure Policy et OPA/Gatekeeper pour Kubernetes.

IaC natif d’Azure : Modèles ARM et Bicep

Les modèles ARM sont des documents JSON déclaratifs que l’Azure Resource Manager utilise pour créer et mettre à jour des ressources. La structure de haut niveau inclut $schema, contentVersion, parameters, variables, resources et outputs. Les paramètres permettent de fournir des entrées spécifiques à l’environnement ; les variables aident à dériver des valeurs calculées ; les ressources déclarent l’état souhaité ; les sorties publient des résultats tels que les ID de ressource. Les modèles prennent en charge les expressions de modèle et les fonctions d’exécution (par ex., resourceId, reference, concat, uniqueString) afin que vous puissiez composer des noms et récupérer des propriétés.

Pour diviser les déploiements importants en unités maintenables, vous pouvez utiliser des modèles imbriqués ou liés. Un modèle imbriqué intègre le JSON dans la propriété template d’une ressource Microsoft.Resources/deployments. Un modèle lié référence un modèle distant via templateLink.uri, généralement stocké dans Azure Storage avec une SAS à durée limitée pour garantir l’intégrité. Utilisez les modèles imbriqués lorsque tout peut résider dans un seul artefact et que vous souhaitez un déploiement transactionnel entre les différentes parties. Utilisez les modèles liés pour les topologies très vastes ou lors de la réutilisation de modèles entre différents dépôts ou équipes. Définissez la portée de vos déploiements au groupe de ressources, à l’abonnement, au groupe d’administration ou au locataire (tenant) selon les besoins en configurant la portée du déploiement sur la ressource de déploiements.

ARM prend en charge deux modes de déploiement. Le mode Incrémentiel (par défaut) crée ou met à jour les ressources présentes dans le modèle sans rien supprimer qui n’y soit pas déclaré. Le mode Complet supprime les ressources à la portée cible qui ne sont pas spécifiées dans le modèle, ce qui est utile pour garantir une dérive minimale mais aussi plus risqué si le modèle ne fait pas autorité pour cette portée. Les opérations de validation (Validate) et de simulation (What-If) aident à prévisualiser les changements pour réduire les risques avant l’exécution.

Bicep est un langage spécifique au domaine (DSL) qui compile en JSON ARM et offre une ergonomie de création de premier ordre. Les déclarations de ressources utilisent des noms symboliques, appliquent des types et prennent en charge le mot-clé existing pour référencer des ressources préexistantes sans redéploiement. Les déclarations de paramètres, de variables, de sorties et de ressources sont concises, et les relations parent-enfant ainsi que les portées sont explicites. Les modules permettent la composition et la réutilisation ; chaque module est un fichier Bicep référencé avec le mot-clé module et peut être publié et consommé depuis des spécifications de modèle (template spec) ou des registres d’artefacts OCI. Les conditions sont exprimées en ligne avec if sur les ressources ou les modules, et les boucles utilisent des expressions for pour déclarer plusieurs instances avec une gestion claire des dépendances. La migration depuis ARM JSON est simple :

undefined

(ou

undefined

) convertit le JSON en Bicep ; vous refactorisez ensuite en modules et adoptez des noms symboliques. Bicep est sans perte par rapport à ARM et prend en charge toute la surface de la plateforme ;

undefined

génère du JSON ARM standard pour le déploiement.

IaC multiplateforme sur Azure avec Terraform

Terraform complète l’IaC natif d’Azure lorsque des flux de travail multi-cloud ou agnostiques au fournisseur sont nécessaires. Le fournisseur azurerm gère les ressources Azure Resource Manager et sa version doit être épinglée ; incluez

undefined

même s’il est vide pour activer les fonctionnalités du fournisseur. D’autres fournisseurs courants incluent azuread pour les objets AAD et random pour les valeurs utilitaires. Authentifiez-vous via un principal de service, une identité managée (Managed Identity) sur des agents hébergés, ou avec Azure CLI. Adoptez une stratégie de configuration de fournisseur claire pour chaque environnement, et centralisez les modules réutilisables avec des variables d’entrée et des sorties.

La gestion de l’état est essentielle. Utilisez le backend azurerm pour stocker l’état à distance dans Azure Storage : configurez

undefined

; authentifiez-vous avec une identité managée ou une SAS ; et activez la suppression réversible (soft delete) et le versioning sur le conteneur de blobs. Le backend utilise des baux de blob (blob leases) pour verrouiller l’état et empêcher les modifications concurrentes. L’accès au compte de stockage doit être contrôlé par RBAC et éventuellement restreint avec des points de terminaison privés (Private Endpoints). Maintenez les fichiers d’état isolés par environnement, et ne stockez jamais de secrets dans l’état par conception — utilisez Key Vault et des sources de données (data sources) pour la récupération des secrets si nécessaire.

Les espaces de travail (workspaces) fournissent une isolation logique de l’état au sein de la même configuration pour la gestion des branches d’environnement telles que dev, test et prod. Utilisez

undefined

et assurez-vous que la clé du backend encode l’espace de travail pour éviter les collisions (par ex.,

undefined

). Les espaces de travail sont excellents pour la parité des environnements avec de faibles deltas ; lorsque les topologies divergent de manière significative, utilisez des configurations ou des modules distincts pour éviter la dérive et la complexité conditionnelle. Intégrez avec Azure Pipelines en utilisant des connexions de service et les tâches Terraform CLI pour standardiser init/plan/apply à travers les étapes (stages) et pour conditionner les applications (applies) à des approbations et des vérifications de politique.

Gestion de la configuration à l’échelle : DSC, Azure Automation DSC, Ansible, Chef et Puppet

PowerShell Desired State Configuration (DSC) déclare l’état des systèmes Windows et multiplateformes via des ressources. Deux modes de livraison existent : le mode push envoie les MOF directement aux nœuds ; le mode pull fait que les nœuds récupèrent leurs MOF depuis un service d’extraction (pull service) à intervalles réguliers. Le Local Configuration Manager (LCM) applique la politique. Les paramètres clés du LCM incluent :

ConfigurationMode : ApplyOnly (configure une fois, pas de correction de dérive), ApplyAndMonitor (détecte la dérive, pas de correction), ApplyAndAutoCorrect (détecte et corrige la dérive).
ConfigurationModeFrequencyMins et RefreshFrequencyMins pour ajuster la fréquence d’application et d’extraction.
RebootNodeIfNeeded et ActionAfterReboot pour gérer les redémarrages.
Configurations partielles pour composer l’état d’un nœud à partir de plusieurs MOF qui ciblent indépendamment des fonctionnalités (par ex., le durcissement de l’OS de base et le rôle applicatif).

Azure Automation State Configuration (Azure Automation DSC) est un service d’extraction (pull service) géré. Vous rédigez des configurations en PowerShell, les importez dans un compte Automation, et lancez des tâches de compilation qui produisent des configurations de nœud (MOF). Les nœuds s’enregistrent avec Register-AzAutomationDscNode en utilisant une clé/un point de terminaison d’enregistrement et peuvent être groupés et se voir assigner des configurations avec des valeurs de paramètres par nœud. Les rapports de conformité affichent la dernière configuration appliquée et l’état de dérive ; les nœuds en mode ApplyAndAutoCorrect corrigeront automatiquement la dérive lors de leur prochain enregistrement (check-in). Les tâches de compilation sont des artefacts de build auditables, et le contrôle d’accès basé sur les rôles (RBAC) restreint la création de configurations et l’assignation aux nœuds.

Ansible est sans agent et bien adapté à la configuration de parcs Linux et à l’orchestration ad-hoc. Sur Azure, utilisez la collection azure.azcollection, qui fournit des modules pour le calcul, le réseau, Key Vault, et plus encore. L’inventaire dynamique avec le plugin azure_rm découvre les hôtes depuis vos abonnements ou des groupes de ressources et tags spécifiques ; l’acquisition des informations d’identification peut utiliser un principal de service, Azure CLI ou une identité managée. Intégrez avec Azure Pipelines en installant Ansible sur un agent Linux, en vous connectant via AzureCLI@2 ou une connexion de service Azure Resource Manager, et en exécutant des playbooks qui référencent l’inventaire dynamique, les groupes de variables et les fichiers sécurisés. Ansible excelle dans les tâches idempotentes et lisibles et peut compléter DSC pour les parcs majoritairement Windows en gérant les workflows et l’orchestration multiplateformes.

Chef et Puppet fournissent des modèles de politique en tant que code (policy-as-code) matures et des rapports de conformité. Sur les VM Azure, les extensions de VM Chef et Puppet amorcent (bootstrap) les agents au moment du provisionnement, garantissant une convergence précoce. Chef Infra utilise des cookbooks et des Policyfiles pour épingler les dépendances et assurer des exécutions reproductibles ; Chef InSpec exprime la conformité en tant que code (compliance-as-code) et envoie les rapports à Chef Automate pour la dérive et la posture de contrôle. Les manifestes et modules de Puppet encodent l’état désiré, avec Code Manager et les environnements fournissant des flux de promotion ; Puppet Enterprise offre des rapports centralisés, une classification basée sur les rôles et la remédiation. Les deux outils s’intègrent à Azure via des modules et des fournisseurs de ressources et peuvent coexister avec DSC natif d’Azure lorsque la migration ou des parcs mixtes l’exigent.

Configuration d’application, images immuables et politique en tant que code

Azure App Configuration centralise les paramètres d’application et les indicateurs de fonctionnalité. Les indicateurs de fonctionnalité permettent un déploiement progressif : vous définissez des indicateurs et, si nécessaire, y attachez des filtres tels qu’un déploiement basé sur un pourcentage ou un ciblage d’utilisateurs via les bibliothèques Feature Manager. Les étiquettes (labels) vous permettent de séparer les valeurs par environnement ou par anneau (ring). Les instantanés de configuration (configuration snapshots) capturent une vue immuable et ponctuelle d’un ensemble de clés et d’étiquettes, permettant des déploiements cohérents et reproductibles sur de nombreux services, sans conditions de concurrence (race conditions) dues à des modifications de clés simultanées. Les références Key Vault vous permettent de conserver les secrets dans Key Vault tout en ne stockant que les références dans App Configuration ; l’identité managée de l’application doit avoir l’autorisation get sur le secret, et les bibliothèques clientes résolvent et mettent en cache les secrets avec un rafraîchissement dynamique optionnel. Utilisez le RBAC et l’isolation réseau sur les deux services pour protéger l’accès.

L’infrastructure immuable élimine la dérive de configuration en reconstruisant à partir d’une image connue au lieu de modifier les hôtes. Le builder azure-arm (maintenant azure) de Packer crée des images à partir d’un OS de base, exécute des provisioners (shell, PowerShell, Ansible) et les publie dans une Shared Image Gallery avec des régions répliquées et un versionnement sémantique. Un pipeline d’image de référence (golden image) vérifie généralement la syntaxe (lint) des modèles Packer, construit l’image, exécute des analyses de vulnérabilité et de conformité (par ex., InSpec), effectue des tests d’intégration, la promeut dans la galerie, puis met à jour les VM Scale Sets ou les pools d’hôtes. Avec les VM Scale Sets, les mises à niveau par vagues (rolling) ou basées sur la santé, et les mises à niveau automatiques d’images d’OS, vous obtenez des déploiements sûrs et cohérents et un retour en arrière (rollback) facile en sélectionnant une version d’image antérieure.

La politique en tant que code (policy as code) applique des garde-fous. Les définitions Azure Policy sont des objets JSON avec une policyRule qui évalue les propriétés des ressources et a des effets tels que deny, audit, append, modify ou deployIfNotExists pour une remédiation automatique. Paramétrez les définitions pour les réutiliser ; regroupez-les dans des initiatives (définitions d’ensemble de politiques) pour des attributions cohérentes et un suivi centralisé de la conformité. Attribuez les politiques au niveau du groupe d’administration, de l’abonnement ou du groupe de ressources ; activez les tâches de remédiation pour les politiques modify et deployIfNotExists afin de mettre les ressources existantes en conformité. Stockez les artefacts de politique dans un contrôle de code source, examinez-les via des pull requests et déployez-les via Bicep, ARM ou Terraform pour une promotion cohérente entre les environnements.

Pour Kubernetes, OPA/Gatekeeper applique des contraintes au moment de l’admission. Les ConstraintTemplates définissent les politiques Rego et leurs schémas ; les Constraints instancient ces politiques pour un cluster. Les contrôles courants incluent la restriction des images aux registres de confiance, l’exigence d’étiquettes/annotations ou l’interdiction des pods privilégiés. Gatekeeper s’intègre avec les outils GitOps (Flux/Argo CD) et les tests CI via conftest. Azure Policy for Kubernetes s’appuie sur Gatekeeper pour fournir des vues d’attribution et de conformité natives à Azure sur les clusters AKS, unifiant la gouvernance du cloud et des clusters sous un seul tableau de bord de posture.

Scénario de problème pratique

Spotify doit standardiser son infrastructure Azure, réduire la dérive de configuration et accélérer les déploiements de fonctionnalités sécurisés pour ses microservices qui s’étendent sur Windows et Linux, AKS et des charges de travail basées sur des VM.

Modéliser les ressources cloud avec des modules Bicep par domaine (réseau, données, calcul) et les déployer via des abonnements rattachés à des groupes d’administration. Cela produit des déclarations typées et maintenables, un périmètre clair et une réutilisation sans la verbosité du JSON ARM.
Utiliser un petit nombre de spécifications de modèles ARM liés (template specs) pour les services de plateforme partagés consommés par plusieurs équipes. Les modèles liés hébergés en tant que template specs fournissent des artefacts versionnés et immuables et découplent la cadence de la plateforme de celle des équipes applicatives.
Choisir Terraform pour les dépendances de périphérie (edge) et de CDN cross-cloud, avec le backend azurerm stockant l’état distant dans Azure Storage par espace de travail (dev/test/prod) et des baux de blob pour le verrouillage. Cela préserve un modèle de pipeline unique tout en isolant l’état en toute sécurité et en permettant une promotion cohérente.
Centraliser la configuration des applications et les indicateurs de fonctionnalité dans Azure App Configuration. Les indicateurs de fonctionnalité avec des filtres de pourcentage et des étiquettes permettent des déploiements par anneaux (ring-based) ; les instantanés de configuration garantissent que chaque étape de déploiement consomme un ensemble de clés immuable et audité.
Stocker les secrets dans Azure Key Vault et y faire référence depuis App Configuration. La résolution des références à l’exécution avec une identité managée permet la rotation des clés sans redéploiement et supprime les secrets de la configuration de l’application et des pipelines.
Adopter des images immuables pour les charges de travail de VM en utilisant Packer pour construire des images de référence (golden images) publiées dans une Shared Image Gallery. Un pipeline exécute des scripts de durcissement et des analyses InSpec, tague les images et ne promeut que les versions validées. Les VM Scale Sets consomment les images de la galerie pour les mises à niveau blue/green et par vagues, éliminant ainsi la dérive.
Appliquer des garde-fous avec des initiatives Azure Policy qui interdisent l’exposition d’IP publiques sur des sous-réseaux privés, exigent des paramètres de diagnostic vers Log Analytics et déploient automatiquement des politiques de sauvegarde. Attribuer au niveau du groupe d’administration pour une couverture large et créer des tâches de remédiation pour que les ressources existantes convergent rapidement vers la posture souhaitée.
Protéger AKS avec OPA/Gatekeeper en appliquant des contraintes qui bloquent les images non conformes et les pods privilégiés. Les politiques sont stockées et versionnées dans Git, validées avec conftest en CI, et appliquées via GitOps pour garantir que l’état du cluster correspond à la politique à tout moment.
Gérer la configuration des serveurs Windows avec Azure Automation DSC. Les nœuds s’enregistrent avec

undefined

et utilisent ConfigurationMode=ApplyAndAutoCorrect pour détecter et corriger la dérive ; les tâches de compilation émettent des fichiers MOF par rôle, et les tableaux de bord de conformité font remonter la dérive pour investigation. 10. Gérer la configuration et l’orchestration Linux avec Ansible en utilisant l’inventaire dynamique azure_rm et les modules azure.azcollection. Azure Pipelines s’authentifie avec une identité managée, exécute les playbooks de manière idempotente et coordonne les mises à jour entre les services, en complément de DSC sur Windows. 11. Tirer parti des profils Chef InSpec pour la conformité en tant que code (compliance-as-code) multiplateforme sur les images et les hôtes en cours d’exécution, en alimentant Chef Automate pour le reporting. Cela intègre des contrôles auditables et testables dans le pipeline et en production, garantissant que les exigences réglementaires sont validées en continu.

Cette combinaison fournit une IaC (Infrastructure as Code) typée et modulaire (Bicep/Terraform), des hôtes immuables (Packer), une configuration d’application centralisée (App Configuration/Key Vault), une application continue de la configuration (Azure Automation DSC, Ansible) et une gouvernance forte (Azure Policy, Gatekeeper). Elle réduit la dérive, raccourcit les temps de restauration et de déploiement, et rend la conformité démontrable.

← Pipelines CI · Tous les domaines · Conteneurisation et Kubernetes →

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