Microsoft AZ-900: Calcul et services d'application — Guide d'étude

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Azure propose une gamme d’options de calcul allant des plateformes d’applications entièrement gérées au contrôle granulaire des machines virtuelles. Le bon choix équilibre le contrôle, la scalabilité, la disponibilité et le coût par rapport à l’effort opérationnel. À une extrémité se trouvent les machines virtuelles et les groupes de machines virtuelles identiques (scale sets), idéaux lorsque le contrôle au niveau du système d’exploitation et des images personnalisées sont requis. À l’autre extrémité se trouvent App Service, les conteneurs et les options serverless qui accélèrent la livraison en faisant abstraction de l’infrastructure. La conception pour la résilience et l’élasticité est au cœur du calcul sur Azure. Les groupes à haute disponibilité (availability sets) et les zones de disponibilité (availability zones) protègent contre les pannes matérielles et de datacenter, tandis que les fonctionnalités d’équilibrage de charge et de mise à l’échelle automatique (autoscale) aident à maintenir les performances face à une demande variable. Associés à des techniques de déploiement modernes telles que les emplacements bleu/vert (blue/green slots), ces services permettent une gestion sécurisée des changements sans temps d’arrêt.

Azure Virtual Machines : images et disques

Azure Virtual Machines (VM) fournit une infrastructure en tant que service (IaaS) pour Windows et Linux. Choisissez les familles de VM en fonction du profil de la charge de travail : usage général (Dsv5) pour un équilibre CPU/mémoire, optimisées pour le calcul (Fsv2) pour les tâches gourmandes en CPU, optimisées pour la mémoire (Esv5) pour les bases de données en mémoire, optimisées pour le stockage (Lsv3) pour un débit IOPS élevé, et les séries GPU/HPC (NC, ND, HB/HX) pour le calcul spécialisé. Les VM sont provisionnées à partir d’images de la marketplace ou d’images personnalisées qui standardisent les bases du système d’exploitation et des logiciels dans les différents environnements. La gestion des images personnalisées est simplifiée avec Azure Compute Gallery, qui gère les versions et réplique les images entre les régions pour des déploiements cohérents et rapides. Capturez une image « golden » à partir d’une VM configurée ou créez des images avec des outils tels que Packer, puis distribuez-les via la galerie aux groupes de machines virtuelles identiques (scale sets) et aux VM individuelles. Pour les charges de travail sans état (stateless), les disques de système d’exploitation éphémères accélèrent considérablement les temps de provisionnement et de redémarrage et éliminent les coûts de stockage persistant du SE en conservant ce dernier dans le cache de l’hôte. Les disques managés (Managed disks) simplifient le cycle de vie et la disponibilité du stockage. Sélectionnez les types de disques en fonction des performances et des coûts : Disque Ultra (Ultra Disk) pour une latence inférieure à la milliseconde et un débit/IOPS élevé ; SSD Premium v2 et SSD Premium pour les charges de travail de production ; SSD Standard pour les charges de travail à usage général ; et HDD Standard pour les scénarios sensibles aux coûts et à faible IOPS. Attachez des disques de système d’exploitation et de données avec des tailles et des niveaux de performance configurables, utilisez des instantanés (snapshots) pour des sauvegardes à un instant T, et profitez du chiffrement de disque par défaut avec le chiffrement côté serveur ; les clés gérées par le client et le chiffrement basé sur l’hôte sont disponibles pour une conformité plus stricte.

Haute disponibilité et mise à l’échelle élastique pour les VM : groupes à haute disponibilité, zones, groupes de machines virtuelles identiques et équilibrage de charge

Les groupes à haute disponibilité (availability sets) protègent contre les pannes au niveau du rack en répartissant les VM sur des domaines de panne (fault domains) et de mise à jour (update domains) au sein d’un même datacenter. Le déploiement d’au moins deux VM dans un groupe à haute disponibilité permet d’atteindre un SLA de disponibilité plus élevé en garantissant qu’un événement de mise à jour ou une panne matérielle n’affecte pas toutes les instances simultanément. Pour une isolation des pannes plus robuste, les zones de disponibilité (availability zones) répartissent les ressources sur des datacenters distincts au sein d’une même région. Le placement d’au moins deux VM dans au moins deux zones fournit le SLA de disponibilité le plus élevé pour les VM, ce qui convient aux applications métier critiques. Les groupes de machines virtuelles identiques (VM Scale Sets ou VMSS) gèrent des groupes de VM identiques comme une ressource unique pour la mise à l’échelle et l’orchestration. Définissez un modèle (image, taille, configuration) et laissez les VMSS gérer la création d’instances, la distribution entre les zones et la mise à l’échelle automatique (autoscale) en fonction de métriques telles que le CPU, la mémoire (via des métriques personnalisées) ou la longueur de la file d’attente. Intégrez avec Azure Compute Gallery pour déployer les mises à jour d’images en toute sécurité à l’aide de sondes d’intégrité (health probes) et de modes d’orchestration flexibles, et combinez cela avec des stratégies de mise à jour automatique du système d’exploitation et des applications pour minimiser les interruptions. Azure Load Balancer assure une distribution de couche 4 entre les instances de VM avec des sondes d’intégrité pour acheminer le trafic uniquement vers les backends sains. Le Standard Load Balancer prend en charge la haute disponibilité, la redondance de zone, l’équilibrage de charge interzone, les règles NAT entrantes et les règles de connectivité sortante. Utilisez-le devant des VMSS ou des VM pour exposer les services de manière fiable. Pour les fonctionnalités de couche 7 HTTP(S) telles que l’affinité basée sur les cookies, la terminaison TLS et le WAF, Application Gateway est le service complémentaire, tandis que Front Door gère le routage anycast global et l’accélération. La sélection du bon niveau d’équilibrage de charge maintient la résilience du trafic tout en répondant aux besoins en matière de protocole et de fonctionnalités.

App Service pour le Web, les API et les conteneurs avec des emplacements de déploiement

Azure App Service héberge des applications web, des API REST et des applications conteneurisées sur une plateforme entièrement gérée qui s’occupe de l’application des correctifs, de l’équilibrage de charge et de la mise à l’échelle automatique (autoscale). Les développeurs déploient du code à l’aide de pipelines CI/CD, de GitHub Actions ou d’un déploiement ZIP/web, et peuvent exécuter des conteneurs directement via App Service for Containers sans gérer d’orchestrateur de conteneurs. Les diagnostics intégrés, les journaux d’application et l’intégration avec Application Insights simplifient les opérations. Les capacités sont déterminées par le plan App Service. Les niveaux Gratuit (Free) et Partagé (Shared) sont destinés à l’évaluation. Le niveau De base (Basic) introduit des ressources de calcul dédiées, des domaines personnalisés, la mise à l’échelle horizontale (scale-out) sur plusieurs instances et le SSL basé sur SNI, répondant aux besoins de production à faible coût lorsque une capacité dédiée et une mise à l’échelle simple sont requises. Les niveaux Standard et Premium ajoutent des règles de mise à l’échelle automatique (autoscale), des emplacements de déploiement (deployment slots) pour des publications sans temps d’arrêt, l’intégration VNet, un nombre d’instances accru et des fonctionnalités avancées adaptées à la plupart des charges de travail de production. Le niveau Isolé (ASE) fournit des environnements dédiés et isolés du réseau pour une conformité et une mise à l’échelle strictes. Les emplacements de déploiement (deployment slots) permettent des publications sécurisées en maintenant un déploiement secondaire « chaud » à côté de la production. Permutez (swap) le trafic après validation pour éviter les démarrages à froid (cold starts), et marquez la configuration comme « paramètre d’emplacement » (slot setting) pour épingler des secrets ou des chaînes de connexion à un emplacement. L’augmentation progressive du trafic pendant les permutations prend en charge les déploiements canary, et la permutation automatique en cas de succès des sondes d’intégrité accélère la livraison continue avec un risque minimal.

Conteneurs sur Azure : AKS vs Azure Container Instances

Les conteneurs accélèrent le packaging et la portabilité. Azure Kubernetes Service (AKS) offre un plan de contrôle Kubernetes managé pour les microservices et les charges de travail avec état (stateful) qui nécessitent des fonctionnalités réseau avancées, une mise à l’échelle automatique et des mises à jour progressives. C’est la solution idéale lorsque vous avez besoin de fonctionnalités d’orchestration matures, de contrôle par stratégies et d’intégrations avec l’écosystème. Azure Container Instances (ACI) exécute des conteneurs à la demande sans avoir à gérer de serveurs ou d’orchestrateurs. Démarrez des conteneurs en quelques secondes, payez à la seconde pour le CPU et la mémoire, et utilisez le bursting pour des tâches de courte durée, des travaux événementiels ou des pipelines de build. ACI s’intègre aux réseaux virtuels pour les charges de travail privées et peut être placé derrière des équilibreurs de charge ou des passerelles API lorsque plusieurs instances sont utilisées pour la résilience. Le choix dépend du modèle opérationnel et de la nature de la charge de travail. Utilisez AKS pour les applications multi-conteneurs de longue durée avec des maillages de services (service meshes), une mise à l’échelle automatique avancée et des volumes persistants. Utilisez ACI pour les tâches simples et éphémères, les pics de charge et le traitement en arrière-plan où la surcharge liée à l’orchestration serait contre-productive.

• Azure Kubernetes Service (AKS)
  • Orchestration : Plan de contrôle Kubernetes managé avec des nœuds de travail (worker nodes)
  • Cas d’usage typiques : Microservices de longue durée, applications avec état (stateful), plateformes d’entreprise
  • Temps de démarrage : Minutes pour provisionner les clusters ; secondes pour démarrer les pods
  • Modèle de mise à l’échelle : Cluster Autoscaler + Horizontal Pod Autoscaler ; planifiée et basée sur des métriques
  • Réseau : kubenet ou Azure CNI avec les Services Kubernetes et les Network Policies
  • Options d’entrée (Ingress) : Contrôleurs d’Ingress (NGINX), Application Gateway Ingress Controller, Gateway API
  • Stockage persistant : PV/PVC Kubernetes via Azure Disks/Files ; pilotes CSI
  • Gestion des nœuds : Gestion du dimensionnement/des mises à jour des nœuds de travail ; plan de contrôle managé par Azure
  • Modèle de tarification : Paiement pour les nœuds de travail ; SLA de disponibilité (Uptime SLA) payant en option pour le plan de contrôle
  • Caractéristiques du SLA : Haute disponibilité conçue via des pools de nœuds et des zones multiples ; SLA du plan de contrôle disponible avec l’Uptime SLA
  • Idéal pour : Microservices et plateformes de production
• Azure Container Instances (ACI)
  • Orchestration : Pas d’orchestrateur ; groupes de conteneurs
  • Cas d’usage typiques : Tâches de courte durée, pics de calcul (burst compute), tâches CI/CD, traitement d’événements
  • Temps de démarrage : Secondes
  • Modèle de mise à l’échelle : Par groupe de conteneurs ; mise à l’échelle en créant plus de groupes
  • Réseau : Intégration VNet prise en charge ; adresses IP privées possibles
  • Options d’entrée (Ingress) : Exposition directe des ports ou via un Load Balancer/Application Gateway en frontal
  • Stockage persistant : Couche d’écriture éphémère ; lier Azure Files pour la persistance
  • Gestion des nœuds : Aucune ; la plateforme gère les hôtes
  • Modèle de tarification : Facturation à la seconde pour le vCPU et la mémoire ; pas de coûts de VM
  • Caractéristiques du SLA : Niveau de service pour une instance unique ; concevoir la haute disponibilité en exécutant plusieurs instances
  • Idéal pour : Conteneurs sans serveur à la demande et travaux par lots (batch jobs)

Intégration sans serveur et bases d’Azure Virtual Desktop

Le calcul sans serveur (serverless) délègue la gestion de l’infrastructure et se met à l’échelle de manière transparente en fonction de la demande. Azure Functions exécute du code événementiel avec des déclencheurs (triggers) pour HTTP, des minuteurs, des files d’attente, Service Bus, Event Grid, et plus encore. Choisissez le plan Consommation pour une facturation par exécution et une mise à l’échelle automatique, le plan Premium pour l’intégration VNet, des performances prévisibles et l’absence de démarrages à froid (cold starts), ou le plan Dédié (plan App Service) pour réutiliser une capacité existante. Les liaisons d’entrée/sortie (bindings) connectent les Functions à des sources de données de manière déclarative, réduisant ainsi le code répétitif (boilerplate). Logic Apps orchestre des flux de travail (workflows) entre des systèmes SaaS et sur site (on-premises) à l’aide de centaines de connecteurs managés. Créez des workflows avec état (stateful) ou sans état (stateless), implémentez des tentatives et la gestion des erreurs, et déployez en mode multi-locataire (Consommation) ou mono-locataire (Standard) pour l’isolation et des fonctionnalités réseau avancées. Event Grid fournit une structure de publication/abonnement (pub/sub) à faible latence pour router des événements système et personnalisés à grande échelle, avec des capacités de filtrage et de mise en file d’attente de lettres mortes (dead-lettering), ce qui est idéal pour les architectures réactives où les producteurs et les consommateurs sont faiblement couplés. Azure Virtual Desktop (AVD) fournit des bureaux virtuels et des applications sécurisés et évolutifs depuis Azure. Déployez des pools d’hôtes (host pools) de Windows 11/10 Entreprise multi-session ou des hôtes de session Windows Server, publiez des groupes d’applications et présentez-les aux utilisateurs via des espaces de travail (workspaces). Les profils sont itinérants entre les hôtes grâce à FSLogix, avec des conteneurs de profil stockés sur Azure Files ou Azure NetApp Files, permettant des ouvertures de session rapides et une expérience utilisateur cohérente. Intégrez avec Microsoft Entra ID pour l’identité, l’accès conditionnel (Conditional Access) pour les stratégies d’accès, et tirez parti de la mise à l’échelle automatique (autoscale) pour adapter le nombre d’hôtes de session à la demande tout en maîtrisant les coûts.

Problème pratique : Traitement des commandes prêt pour les pics de charge pour Fabrikam Health à l’aide de VMs résilientes, d’une plateforme d’applications moderne et d’événements serverless

Scénario : Fabrikam Health exploite un portail de commande en ligne qui connaît des pics de charge durant les 5 derniers jours de chaque mois. L’équipe gère un service de traitement des commandes hérité qui doit rester sur Windows Server, ainsi qu’un front-end web/API moderne. L’entreprise exige une disponibilité de 99,99 % pour le traitement des commandes, du HTTPS de bout en bout sur un domaine personnalisé, des déploiements sans interruption de service pour le site web et une surcharge opérationnelle minimale. Des contraintes budgétaires excluent une orchestration complexe autogérée pour les tâches d’arrière-plan, mais les pics de fin de mois doivent être absorbés sans intervention manuelle.

Défi : Garantir une disponibilité de 99,99 % pour le processeur de commandes basé sur des VMs, mettre à l’échelle le front-end web/API de manière transparente pendant les pics, prendre en charge des mises en production sécurisées et gérer les tâches d’arrière-plan en rafale avec une gestion minimale de l’infrastructure.

Approche recommandée :

1. Créer une image Windows Server renforcée dans Azure Compute Gallery qui inclut le service de traitement des commandes et ses dépendances ; la versionner pour des déploiements reproductibles.
2. Déployer un VM Scale Set avec deux instances réparties sur deux zones de disponibilité, en utilisant des disques Premium SSD pour le système d’exploitation et les données, et placer un Standard Load Balancer en amont avec des sondes d’intégrité pour atteindre une résilience au niveau de la zone et distribuer le trafic.
3. Provisionner un plan App Service (Standard ou Premium) pour le web/API public, lier le domaine personnalisé et les certificats, activer deux instances ou plus avec une mise à l’échelle automatique basée sur le taux de requêtes HTTP ou le CPU, et créer un emplacement de déploiement de préproduction (staging) pour les mises en production bleu/vert.
4. Implémenter des flux de travail asynchrones avec Azure Functions déclenchées par des événements Event Grid (par exemple, order-created) et des déclencheurs de file d’attente pour les tâches en aval telles que la génération de factures et les notifications par e-mail ; utiliser le plan Premium pour l’intégration au VNet si les systèmes backend l’exigent.
5. Pour les exportations ad-hoc et gourmandes en calcul en fin de mois, exécuter des tâches conteneurisées sur Azure Container Instances derrière un point de terminaison privé, invoquées par des Functions ; ne payer que pour le temps d’exécution sans gérer de cluster.
6. Introduire Azure Virtual Desktop pour le personnel financier qui a besoin d’accéder à un client lourd hérité : créer un pool d’hôtes groupé avec Windows 11 Entreprise multisession, activer les profils FSLogix sur Azure Files et publier l’application aux utilisateurs via un espace de travail.

Justification Azure : Deux instances de VM réparties sur plusieurs zones de disponibilité et placées derrière un Standard Load Balancer atteignent l’objectif de disponibilité de 99,99 % pour le processeur de commandes tout en conservant le contrôle au niveau de l’OS. App Service fournit une plateforme gérée pour le portail avec une mise à l’échelle automatique et des emplacements de déploiement pour gérer les pics de charge et fournir des mises à jour sûres et sans interruption de service. Event Grid et Functions découplent le traitement en arrière-plan et se mettent à l’échelle de manière transparente, tandis qu’ACI fournit une capacité de calcul en rafale avec la plus faible surcharge opérationnelle. Azure Virtual Desktop centralise l’accès au client hérité de manière sécurisée et se met à l’échelle avec la demande, complétant l’architecture avec un minimum d’infrastructure à gérer.

← Architecture Azure et infrastructure mondiale · Tous les domaines · Réseau →

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

Parcourir Microsoft →