Microsoft AZ-104: Azure App Service et Calcul PaaS — 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.

Conteneurs et Kubernetes

Azure Container Instances (ACI) fournit des conteneurs à la demande, facturés à la seconde, sans avoir à gérer de machines virtuelles ou d’orchestrateurs. L’unité de déploiement est un groupe de conteneurs : un ou plusieurs conteneurs planifiés sur le même hôte, partageant une adresse IP, des ports, des volumes et un cycle de vie. Définissez le CPU/la mémoire par conteneur, exposez des ports et montez des volumes tels que des partages Azure Files, des secrets et des emptyDir. Les variables d’environnement peuvent être en clair ou sécurisées (exclues des journaux et des surfaces de métadonnées). Les stratégies de redémarrage contrôlent le cycle de vie : Always (par défaut pour les services à longue durée de vie), OnFailure (pour les tâches qui doivent retenter en cas de sortie non nulle), et Never (pour les tâches qui s’exécutent jusqu’à leur terme et dont vous souhaitez inspecter l’état de sortie sans redémarrage). La mise en réseau prend en charge les adresses IP publiques, les adresses IP privées avec injection dans un réseau virtuel (VNet) au sein d’un sous-réseau délégué, et les étiquettes de nom DNS pour les points de terminaison publics.

Azure Kubernetes Service (AKS) est un plan de contrôle Kubernetes managé avec des pools de nœuds provisionnés en tant que Virtual Machine Scale Sets. Les pools de nœuds différencient les charges de travail système (composants kube-system) des charges de travail utilisateur, prennent en charge plusieurs tailles de VM, et peuvent exécuter Linux et Windows (Windows nécessite au moins un pool système Linux). Les pools peuvent être marqués d’une teinte (taint) pour contrôler la planification (scheduling). Les mises à niveau sont orchestrées par pool, et maxPods, les zones de disponibilité et les disques de système d’exploitation éphémères sont configurés à la création du pool. L’autoscaler de cluster s’intègre à la planification Kubernetes pour modifier le nombre de nœuds dans des limites min/max lorsque des pods en attente ne peuvent pas être planifiés ou que des nœuds sont sous-utilisés ; il respecte les Pod Disruption Budgets et ne réduit la taille (scale down) que lorsque cela est sûr. L’Horizontal Pod Autoscaler complète ce mécanisme en mettant à l’échelle les réplicas au sein d’un Déploiement en fonction de métriques.

Bases de kubectl pour l’administration de cluster :

Se connecter avec

undefined

pour fusionner le kubeconfig et sélectionner le contexte.

Inspecter les ressources :

undefined

;

undefined

pour les détails et les événements.

Diagnostiquer et interagir :

undefined

pour stdout/stderr,

undefined

pour le dépannage interactif.

Appliquer l’état désiré :

undefined

; utiliser les espaces de noms (namespaces) pour délimiter les ressources ;

undefined

pour changer d’espace de noms.

Les plugins réseau (Azure CNI ou kubenet), l’identité (identité managée ou principal de service) et l’intégration RBAC/Entra ID déterminent l’allocation d’adresses IP aux pods, l’authentification du cluster et l’autorisation. Assurez-vous que l’identité du cluster dispose des autorisations nécessaires pour les équilibreurs de charge, les disques managés et les groupes de ressources des nœuds.

Intégration, Réseau et Sécurité

Logic Apps fournit un moteur de workflow managé avec des connecteurs vers des centaines de services SaaS et Azure. Un workflow se compose d’un déclencheur qui démarre l’exécution et d’actions qui effectuent les étapes. Les déclencheurs incluent les requêtes HTTP, la récurrence, les messages Service Bus, les événements Event Grid, les événements de stockage et de nombreux événements SaaS (par ex., lorsqu’un enregistrement est créé dans Dynamics 365). Les actions incluent des constructions de contrôle (conditions, boucles, switch), des opérations sur les données (composer, analyser JSON, variables) et des opérations de connecteur (envoyer un e-mail, mettre un message en file d’attente, appeler une API). L’intégration avec les services Azure est profonde :

Service Bus et Event Grid fournissent une messagerie et une gestion d’événements fiables pour les architectures découplées.
Des Functions peuvent être invoquées pour des étapes de code personnalisé (HTTP synchrone ou asynchrone via des files d’attente).
L’identité managée sécurise l’accès à Key Vault, Storage, SQL et d’autres ressources Azure sans secrets. Logic Apps Consommation (multi-locataire) facture par exécution d’action et par utilisation de connecteur ; Logic Apps Standard (mono-locataire) s’exécute sur le runtime Functions dans un plan App Service ou Premium, prend en charge le développement local, l’intégration VNet, les points de terminaison privés et un débit plus élevé. L’Integration Service Environment (ISE) en mode Consommation fournit une isolation VNet pour les connecteurs managés lorsque cela est nécessaire.

App Service Environment (ASE) implémente le niveau Isolé pour App Service. Déployé dans votre réseau virtuel, un ASE fournit des instances de calcul et de stockage dédiées et mono-locataires avec un contrôle total du réseau. Un ASE externe expose des points de terminaison d’entrée publics ; un ASE avec équilibreur de charge interne (ILB) publie uniquement une adresse IP virtuelle privée pour un accès strictement privé. Les applications dans un ASE utilisent les niveaux de tarification Isolé/Isolé v2. Vous payez à la fois des frais fixes pour l’environnement et des coûts par instance de worker. Un ASE est choisi lorsque les exigences de conformité, d’isolation réseau ou de mise à l’échelle dépassent les capacités d’App Service en mode multi-locataire. Avec ASE v3, le déploiement et la mise en réseau sont simplifiés, mais la proposition de valeur principale reste la même : un App Service dédié, adressable de manière privée, avec votre VNet comme périmètre.

La gouvernance des accès à travers ces services repose sur Azure RBAC pour les actions sur les ressources, les identités managées pour l’authentification de service à service, et l’Accès Conditionnel (Conditional Access) au niveau du plan d’identité. Pour le contrôle du trafic entrant sur App Service, combinez des Private Endpoints ou un ASE ILB avec des restrictions d’accès et des frontaux avec WAF activé (par ex., Application Gateway ou Azure Front Door) selon les besoins. Pour le contrôle du trafic sortant, utilisez l’intégration VNet avec des NSG, des tables de routage et des points de terminaison privés pour les services de données.

Opérations de déploiement et de mise à l’échelle

Les déploiements fiables sur App Service utilisent des slots de déploiement pour valider la santé et préchauffer les caches avant un échange (swap). Marquez la configuration qui diffère selon l’environnement comme des « paramètres de slot » afin qu’elle ne soit pas déplacée lors de l’échange (par exemple, les chaînes de connexion, les feature flags). Utilisez l’échange avec prévisualisation pour exécuter des sondes de santé ou des points de terminaison de préchauffage spécifiques à l’application ; si l’application n’est pas saine, annulez l’échange. Lors d’un déploiement canary, activez le routage du trafic pour diriger un faible pourcentage persistant (sticky) vers un slot de préproduction et augmentez-le progressivement. Les paramètres d’application spécifiques à un slot peuvent activer des fonctionnalités bêta en toute sécurité.

L’Autoscale pour les App Service Plans est configuré sur la ressource du plan à l’aide de profils (min/max/défaut basés sur le temps) et de règles (seuils de métriques avec pas de mise à l’échelle et période de refroidissement). Combinez le CPU avec des métriques personnalisées (par exemple, la longueur d’une file d’attente) pour une mise à l’échelle plus précise. Pour les Functions, le plan Consommation se met à l’échelle automatiquement ; surveillez la concurrence et configurez host.json pour les comportements par déclencheur (par exemple, les tailles de lot et le prefetch pour Service Bus). Le plan Premium met à l’échelle des instances préchauffées et des instances en rafale ; alignez le nombre minimal d’instances avec les objectifs de latence.

Dans les conteneurs, les stratégies de redémarrage d’ACI doivent refléter l’intention : les tâches batch utilisent Never ou OnFailure pour éviter les boucles infinies ; les services utilisent Always. Utilisez des variables d’environnement pour la configuration et Azure Key Vault pour les secrets, en les injectant via une Identité Managée et du code de démarrage ou en montant les secrets en tant que volumes lorsque c’est approprié. Dans AKS, activez l’autoscaler de cluster avec des limites min/max raisonnables par pool de nœuds et configurez des HPA pour les Deployments critiques. Prévoyez une marge de manœuvre (headroom) et définissez des Pod Disruption Budgets pour garantir la disponibilité lors des mises à niveau et des scale-in. Validez les mises à niveau dans un pool de nœuds canary avant de déployer largement les mises à niveau du cluster ou du pool.

Scénario de problème pratique

Fabrikam, Inc. exploite un portail client et des services de traitement en arrière-plan. Ils doivent moderniser vers le PaaS, imposer un accès réseau privé aux banques de données, prendre en charge les déploiements blue-green et exécuter un ETL conteneurisé nocturne sans gérer de machines virtuelles.

Héberger le portail sur App Service Premium avec des slots de déploiement

Créer un App Service Plan en Premium v3 pour des performances supérieures et plus de slots, et déployer la Web App avec un slot de préproduction (staging).
Configurer les paramètres de slot pour les valeurs spécifiques à l’environnement et activer l’échange avec prévisualisation et les vérifications de santé.
Raison : Le plan Premium offre l’autoscale, plus de slots, le support des Points de terminaison privés (Private Endpoint) et un SLA adapté au trafic de production. Les slots permettent des déploiements blue-green sécurisés et le routage canary.

Imposer une entrée privée et une sortie contrôlée

Activer un Point de terminaison privé (Private Endpoint) pour la Web App et définir des restrictions d’accès pour refuser le réseau public.
Configurer l’Intégration au réseau virtuel régional (Regional VNet Integration) vers un sous-réseau délégué pour l’accès sortant aux banques de données privées et sur site via ExpressRoute.
Raison : Le Point de terminaison privé associé aux restrictions garantit un accès exclusivement privé ; l’Intégration au réseau virtuel achemine la sortie à travers le périmètre du VNet pour une politique de pare-feu cohérente.

Mettre en œuvre le traitement en arrière-plan avec Azure Functions Premium

Déployer une Function App sur un plan Premium avec une identité managée affectée par le système, en utilisant des déclencheurs Service Bus et Stockage pour les charges de travail basées sur des files d’attente.
Définir un nombre minimal d’instances préchauffées pour éliminer les démarrages à froid et intégrer avec le même VNet.
Raison : Le plan Premium de Functions répond aux exigences de faible latence et d’intégration VNet tout en conservant la mise à l’échelle serverless pour les charges de travail en rafale.

Orchestrer les workflows inter-services avec Logic Apps Standard

Construire des workflows pour coordonner l’intégration des clients : déclencher sur un message Service Bus, appeler la Function App, écrire dans le Stockage et notifier via le connecteur Microsoft 365.
Utiliser une identité managée pour l’accès à Key Vault et au Stockage et déployer dans le même App Service Plan pour tirer parti de l’intégration VNet et des points de terminaison privés.
Raison : Logic Apps fournit une orchestration visuelle et résiliente ainsi que des connecteurs natifs ; le plan Standard offre l’intégration VNet et des performances en mode single-tenant.

Exécuter l’ETL nocturne dans Azure Container Instances

Définir un groupe de conteneurs avec le conteneur ETL, monter un partage Azure Files pour les données intermédiaires, définir des variables d’environnement sécurisées et utiliser restartPolicy: Never.
Attacher le groupe au sous-réseau délégué du VNet pour un accès privé aux bases de données.
Raison : ACI fournit une capacité de calcul à la seconde, orientée tâche, sans la surcharge d’un cluster, et s’intègre avec le VNet pour la localité des données et la sécurité.

Se préparer pour les microservices conteneurisés avec AKS

Créer un cluster AKS avec un petit pool de nœuds système Linux et un pool de nœuds utilisateur dimensionné pour la charge attendue, activer l’autoscaler de cluster (limites min/max) et intégrer avec Entra ID et Azure CNI pour des adresses IP au niveau du pod.
Utiliser kubectl pour déployer un microservice canary et définir un HPA basé sur le CPU et des métriques personnalisées.
Raison : AKS fournit une orchestration de niveau entreprise lorsque les services se multiplient ; l’autoscaler et le HPA alignent la capacité sur la demande et kubectl offre un contrôle opérationnel standard.

← Stockage Azure · Tous les domaines · Bases de données Azure et Services de données →

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