Microsoft AZ-204: Solutions de conteneurs Azure — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Developer Associate AZ-204 — 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

Azure fournit une gamme d’options de conteneurs allant de l’exécution de conteneurs uniques aux clusters orchestrés, en passant par une chaîne d’approvisionnement d’images sécurisée et de qualité professionnelle. Azure Container Instances (ACI) est le moyen le plus rapide d’exécuter des conteneurs Linux ou Windows sans gérer de serveurs. Azure Kubernetes Service (AKS) est un plan de contrôle Kubernetes managé qui met à l’échelle les microservices avec des fonctionnalités avancées de planification, de mise en réseau, de sécurité et des intégrations DevOps. Azure Container Registry (ACR) est le registre privé et géo-répliqué qui ancre vos flux de build, de tag, de push/pull et de distribution Helm. La maîtrise de la construction d’images Docker et de la gestion de leur cycle de vie est fondamentale pour des déploiements fiables sur n’importe laquelle de ces plateformes. Cette section établit une vue pratique, centrée sur le développeur, sur la manière dont les différentes pièces s’assemblent, y compris les déploiements pilotés par YAML, le packaging Helm, l’exposition des services et les modèles d’identité/sécurité.

Docker et Azure Container Registry (ACR)

La livraison fiable de conteneurs commence par de solides fondamentaux Docker. Chaque image est composée de couches formées par les instructions du Dockerfile ; la réutilisation des couches et les succès de cache (cache hits) sont essentiels pour des builds rapides.

• Instructions courantes du Dockerfile et conseils :
  • FROM définit l’image de base. Préférez les images minimales (par ex., distroless, alpine le cas échéant) pour réduire la surface d’attaque et la taille.
  • RUN exécute des commandes pour installer les dépendances. Combinez les commandes associées pour réduire le nombre de couches, mais évitez les lignes RUN monolithiques qui masquent les échecs.
  • COPY et ADD placent les artefacts de l’application. Utilisez .dockerignore pour éviter de surcharger les contextes ; ancrez COPY à des chemins explicites.
  • WORKDIR définit le répertoire de travail ; utilisez-le au lieu d’enchaîner des cd dans RUN.
  • EXPOSE documente les ports d’écoute prévus (ce n’est pas un pare-feu).
  • ENV et ARG configurent les variables d’environnement et de build ; favorisez le déterminisme au moment du build en fixant les valeurs par défaut de ARG ou en passant des valeurs explicites.
  • ENTRYPOINT définit l’exécutable principal ; utilisez CMD pour les arguments par défaut. Privilégiez la forme exec (tableau JSON) pour préserver la gestion des signaux pour un arrêt en douceur (graceful shutdown).
  • HEALTHCHECK permet l’évaluation de la vivacité (liveness) afin que les orchestrateurs puissent réagir.
• Les builds multi-étapes (multi-stage) séparent les étapes de build et d’exécution, en ne copiant que les artefacts nécessaires dans une image d’exécution propre, réduisant ainsi considérablement la taille et l’empreinte CVE. Par exemple, construisez avec un SDK, publiez les binaires, puis copiez-les dans une base d’exécution.
• Les couches d’image sont immuables et adressées par leur contenu. La réorganisation des instructions modifie la mise en cache. Placez les instructions qui changent fréquemment (par ex., la source de COPY) à la fin du Dockerfile pour maximiser les succès de cache.

Avec ACR, stockez et distribuez des images et des charts Helm de manière privée :

• Référentiels et tagging : Poussez les images sous la forme <registry>.azurecr.io/<repo>:<tag>. Préférez les tags sémantiques ou basés sur Git (par ex., 1.4.0, build SHA) et utilisez des digests immuables dans les déploiements de production pour la répétabilité.
• Push et pull :
  • Authentifiez-vous auprès d’ACR en utilisant az acr login -n <acr-name> ou docker login avec un jeton Azure AD. Évitez d’activer l’utilisateur administrateur d’ACR en production.
  • Tag et push : docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Tirez avec docker pull ou via des références d’image Kubernetes.
  • Importez des images en amont (upstream) dans ACR pour contrôler la chaîne d’approvisionnement : az acr import -n <acr> --source docker.io/library/nginx:1.25 --image base/nginx:1.25.
• ACR Tasks : Buildez, testez et patchez des images nativement dans Azure. Utilisez az acr build -r <acr> -t apps/app:1.0 . pour des builds à la demande ; automatisez les mises à jour avec az acr task create pour déclencher des builds à partir de commits Git ou de mises à jour d’images de base, permettant la remédiation des CVE sans changer le code de l’application.
• La géo-réplication (SKU Premium) offre une localité de tirage (pull) et une résilience multi-régions. Configurez des répliques dans des régions proches des clusters AKS pour réduire la latence de tirage et le trafic de sortie inter-régional.
• Contrôle d’accès :
  • Intégrez avec Azure AD et assignez des rôles intégrés comme AcrPull à l’identité kubelet d’AKS, et AcrPush aux pipelines de CI. Des permissions à portée de référentiel sont disponibles via des jetons (tokens) et des scope maps pour un contrôle affiné.
  • Restreignez l’accès réseau avec des points de terminaison privés (private endpoints), des points de terminaison de service (service endpoints) et des règles de pare-feu. Préférez les points de terminaison privés pour la production.
  • Attachez ACR à AKS avec az aks update --attach-acr <acr> pour simplifier l’assignation du rôle AcrPull.

Azure Container Instances (ACI)

ACI exécute des conteneurs à la demande sans gestion de cluster. L’unité principale est un groupe de conteneurs, un ensemble de conteneurs co-planifiés partageant le même noyau de système d’exploitation hôte, le même cycle de vie, la même adresse IP et les mêmes volumes. Utilisez les groupes de conteneurs pour implémenter le pattern sidecar (par ex., des log shippers, des proxies) ou pour combiner un processus principal avec un assistant (helper).

• Les groupes multi-conteneurs partagent un espace de noms réseau, permettant la communication inter-conteneurs via localhost. Ils partagent également les volumes montés (Azure Files, emptyDir) et le cycle de vie, ce qui les rend adaptés à des tâches ponctuelles cohésives qui nécessitent un couplage étroit.
• Les stratégies de redémarrage contrôlent la sémantique d’exécution :
  • Always redémarre les conteneurs lorsqu’ils se terminent. Idéal pour les services de longue durée.
  • OnFailure redémarre uniquement sur les codes de sortie non nuls. Adapté aux tâches batch qui doivent réessayer en cas d’échec.
  • Never exécute les conteneurs une seule fois et ne les redémarre jamais, idéal pour les tâches idempotentes.
• Les intégrations réseau incluent une adresse IP publique avec une étiquette DNS, des adresses IP privées dans un sous-réseau Azure VNet délégué, et une sortie sécurisée via NAT ou pare-feu. Une ACI injectée dans un VNet permet un accès privé aux services (bases de données, stockage) sans exposition publique.
• Considérations opérationnelles :
  • Injectez les secrets en utilisant des variables d’environnement sécurisées ou montez des Azure Files ; pour une posture plus robuste, récupérez les secrets à l’exécution via une identité managée depuis Key Vault.
  • Observez avec az container logs et az container attach ; exécutez des commandes interactives avec az container exec.
  • La facturation est à la seconde pour le vCPU et la mémoire en GiB. Les conteneurs démarrent rapidement et sont adaptés aux charges de travail en rafale (bursty workloads), aux tâches d’assistance CI, aux tests d’intégration et aux tâches déclenchées par une file d’attente où la surcharge de Kubernetes n’est pas nécessaire.

Azure Kubernetes Service (AKS)

AKS fournit un plan de contrôle managé avec des pools de nœuds, une mise à l’échelle automatique (autoscaling) et des options avancées de réseau/identité.

Les pools de nœuds structurent la capacité et le placement des charges de travail. Les pools de nœuds système exécutent les services principaux ; les pools de nœuds utilisateur exécutent les pods applicatifs. Utilisez plusieurs pools pour séparer les charges de travail selon les besoins en CPU/Mémoire/GPU, le système d’exploitation (Linux/Windows), la taille de la VM et la zone de disponibilité. Employez des taints/tolerations pour protéger les pools système, des étiquettes (labels) pour la sélection, et le cluster autoscaler pour ajouter/supprimer des nœuds en fonction des pods en attente. Prenez en compte le nombre maximal de pods (maxPods) par nœud et la densité de pods lors du dimensionnement.

L’ordonnancement des pods est piloté par les requêtes/limites de ressources, les classes de QoS (Guaranteed/Burstable/BestEffort) et les contraintes. Utilisez nodeSelector/l’affinité et l’anti-affinité pour pousser les pods vers les pools appropriés et distribuer les réplicas à travers les zones et les domaines de défaillance. Les contraintes de répartition topologique (Topology spread constraints) améliorent une distribution uniforme. Pour les services critiques, définissez des PodDisruptionBudgets et des PriorityClasses pour façonner les interruptions volontaires et le comportement de préemption. Les DaemonSets placent des agents par nœud (journalisation, surveillance), et les CronJobs planifient des conteneurs pour des tâches périodiques.

Les déploiements dans AKS sont déclaratifs. Les manifestes YAML définissent apiVersion, kind, metadata et spec pour les Deployments, StatefulSets, Jobs, Services et Ingress. Conservez les manifestes dans un système de gestion de versions, paramétrez-les avec des overlays Kustomize pour les différences entre environnements, et appliquez-les avec kubectl apply -f. Le Server-side apply et des étiquettes/annotations appropriées aident à la gestion de la propriété et à la détection de dérive. Pour empaqueter des applications réutilisables, Helm 3 regroupe des modèles (templates) et des valeurs. Hébergez les charts Helm en tant qu’artefacts OCI dans ACR et installez-les avec

undefined

. Utilisez des fichiers de valeurs par environnement, suivez les versions des charts, et effectuez une restauration (rollback) avec helm rollback pour une récupération rapide.

Commandes kubectl que vous utiliserez quotidiennement :

• Accéder au contexte du cluster :

undefined

fusionne le kubeconfig ; l’utilisation d’une machine jointe à Azure AD avec kubectl est suffisante — Docker n’est pas requis pour déployer des manifestes.

• Inspecter et opérer :

undefined

;

undefined

;

undefined

;

undefined

;

undefined

;

undefined

;

undefined

;

undefined

pour la maintenance ;

undefined

pour vérifier le RBAC.

• Appliquer/patcher :

undefined

;

undefined

.

Le réseau dans AKS expose les pods et les services avec des responsabilités claires :

• ClusterIP fournit des IP virtuelles et un DNS internes au cluster uniquement pour la découverte de services. C’est le type par défaut pour le trafic est-ouest entre les microservices.
• NodePort ouvre le même port sur chaque nœud ; il est préférable de l’utiliser derrière un Ingress ou un LB externe plutôt que de le consommer directement.
• LoadBalancer provisionne un frontend Azure Load Balancer qui cible les NodePorts. Marquez les services comme internes en ajoutant l’annotation

undefined

, ou assignez une IP publique statique pour un DNS stable.

• Les contrôleurs d’Ingress fournissent un routage de niveau 7 (L7), la terminaison TLS et des règles de chemin/hôte. Le contrôleur d’Ingress NGINX est une option par défaut polyvalente avec de riches annotations. L’Application Gateway Ingress Controller (AGIC) s’intègre avec Azure Application Gateway pour le WAF, l’autoscaling et les capacités L7 d’entreprise tout en conservant des manifestes natifs de Kubernetes. Utilisez cert-manager pour automatiser le TLS avec ACME, ou synchronisez les certificats Key Vault dans des secrets Kubernetes avec le CSI Secret Store.

L’identité et l’autorisation intègrent Azure AD sans secrets au sein du cluster :

• Les identités managées pour AKS se composent de l’identité du cluster/plan de contrôle et de l’identité kubelet. Accordez le rôle AcrPull à l’identité kubelet sur ACR (

undefined

) pour que les nœuds puissent extraire les images de manière sécurisée.

• L’identité de charge de travail (Workload identity) permet aux pods d’accéder aux ressources Azure en utilisant des informations d’identification fédérées Azure AD mappées à des comptes de service Kubernetes — sans informations d’identification au

← Azure Cosmos DB · Tous les domaines · Authentification →

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

Parcourir Microsoft →