Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen AZ-204. Lisez de haut en bas ou sautez à une section.
Besoin d'un plan App Service pour une application web de production avec des domaines personnalisés/SSL, l'autoscale et des emplacements de déploiement.
Utiliser le niveau de plan App Service Standard (S1) ou supérieur.
Pourquoi: Standard est le niveau minimum supportant toutes les fonctionnalités de production clés : domaines personnalisés avec SSL, autoscale et emplacements de déploiement. Le niveau Basique ne prend pas en charge l'autoscale et les emplacements.
Effectuer un déploiement sans interruption de service pour un App Service et conserver les paramètres de production (comme les chaînes de connexion) dans l'emplacement de production.
Utiliser des emplacements de déploiement. Marquer les paramètres spécifiques à la production comme "paramètres d'emplacement de déploiement" (persistants). Effectuer une opération d'échange pour déployer.
Pourquoi: L'opération d'échange préchauffe l'emplacement de staging avant de rediriger le trafic. Les paramètres persistants ne se déplacent pas avec le code pendant un échange, empêchant les paramètres de staging de passer en production.
Un App Service doit se connecter à une ressource sur site (par exemple, SQL Server) sans VPN ni ExpressRoute.
Utiliser les App Service Hybrid Connections. Installer le Hybrid Connection Manager (HCM) sur site.
Pourquoi: Les Hybrid Connections fournissent un tunnel TCP sécurisé vers les ressources sur site sans nécessiter de ports de pare-feu entrants, de VPN ou d'intégration VNet. Le HCM initialise la connexion sortante.
Une fonction Azure sur le plan Consumption subit de longs démarrages à froid, entraînant de la latence.
Migrer vers le plan Functions Premium et configurer un minimum d'une instance pré-chauffée.
Pourquoi: Le plan Premium élimine les démarrages à froid en maintenant un nombre spécifié d'instances toujours prêtes. Il est plus rentable qu'un plan Dedicated complet à cette fin.
Une fonction Azure sur le plan Consumption expire car son exécution prend plus de 10 minutes.
Migrer la fonction vers un plan Premium ou Dedicated (App Service).
Pourquoi: Le plan Consumption a un délai d'expiration maximum de 10 minutes. Les plans Premium et Dedicated supportent des temps d'exécution beaucoup plus longs (jusqu'à 60 minutes ou illimités).
Traiter un grand nombre d'éléments indépendants en parallèle et attendre que tous soient terminés avant de continuer.
Implémenter le modèle Fan-out/Fan-in de Durable Functions. L'orchestrateur appelle plusieurs fonctions d'activité de manière concurrente et utilise `Task.WhenAll` (ou équivalent) pour attendre l'achèvement.
Pourquoi: Ce modèle est conçu pour l'exécution parallèle, qui est beaucoup plus efficace que le traitement séquentiel (Function Chaining) pour les tâches indépendantes.
Un workflow de longue durée doit attendre un événement externe, tel qu'une approbation humaine, avec un délai d'attente.
Utiliser le modèle d'interaction humaine de Durable Functions. Combiner `waitForExternalEvent` avec un `createTimer`. Utiliser `Task.WhenAny` pour continuer lorsque l'événement arrive ou que le minuteur expire.
Pourquoi: Ce modèle permet aux orchestrations de se mettre en pause indéfiniment sans consommer de calcul, en attendant un déclencheur externe, tout en gérant les délais d'attente de manière élégante.
Une application conteneurisée doit évoluer vers zéro instance en l'absence de trafic pour minimiser les coûts.
Utiliser Azure Container Apps avec une règle de mise à l'échelle basée sur KEDA (par exemple, requêtes HTTP ou longueur de file d'attente).
Pourquoi: Container Apps avec les scalers KEDA peut réduire à zéro réplique lorsqu'il est inactif et augmenter à la demande, ce qui est idéal pour les charges de travail basées sur des événements ou intermittentes. La mise à l'échelle CPU/mémoire ne peut pas réduire à zéro.
Un microservice backend dans Azure Container Apps ne doit être accessible que par d'autres applications de conteneurs au sein du même environnement, et non depuis l'internet public.
Activer l'entrée sur l'application de conteneurs backend et définir la visibilité du trafic sur `internal`.
Pourquoi: L'entrée interne restreint l'accès à l'environnement Container Apps. D'autres applications dans l'environnement peuvent découvrir et appeler le service en utilisant son FQDN interne.
Besoin d'exécuter un seul conteneur pour une tâche simple, un test ou un travail par lots sans orchestration.
Utiliser Azure Container Instances (ACI).
Pourquoi: ACI est le moyen le plus rapide et le plus simple d'exécuter un seul conteneur sans gérer d'infrastructure sous-jacente. Utiliser Container Apps ou AKS pour orchestrer des applications multi-conteneurs.
Besoin de construire et de pousser une image Docker vers Azure Container Registry (ACR) à partir d'un Dockerfile local, mais Docker n'est pas installé localement.
Utiliser la commande `az acr build`.
Pourquoi: `az acr build` décharge le processus de construction vers les tâches ACR dans le cloud. Il envoie le contexte de construction à Azure, construit l'image et la stocke directement dans le registre.
Concevoir un conteneur Cosmos DB avec des requêtes fréquentes filtrant sur une propriété spécifique (par exemple, `region`).
Sélectionner la propriété la plus fréquemment interrogée et de haute cardinalité comme clé de partition (par exemple, `/region`).
Pourquoi: Les requêtes qui incluent la clé de partition dans la clause `WHERE` sont ciblées sur une seule partition logique, évitant les requêtes fan-out coûteuses entre partitions et minimisant la consommation d'unités de requête (RU).
Une application distribuée globalement exige que les lectures renvoient toujours l'écriture la plus récemment validée.
Configurer le niveau de cohérence du compte Cosmos DB sur Forte (Strong).
Pourquoi: La cohérence forte offre une garantie de linéarisabilité, assurant que les lectures sont toujours à jour. D'autres niveaux (Session, Bounded Staleness, Eventual) échangent la cohérence contre une latence plus faible et une disponibilité plus élevée.
Besoin de traiter tous les documents nouveaux ou mis à jour dans un conteneur Cosmos DB en temps réel pour mettre à jour une vue matérialisée.
Utiliser une fonction Azure avec un déclencheur Cosmos DB, qui exploite le processeur de flux de modifications.
Pourquoi: Le flux de modifications fournit un journal persistant des changements. Le déclencheur Cosmos DB avec le processeur de flux de modifications automatise la gestion de l'état et l'équilibrage de charge entre plusieurs instances de fonction.
Besoin d'effectuer une opération atomique sur plusieurs documents au sein de la même partition logique (par exemple, créer deux et mettre à jour un).
Utiliser l'API `TransactionalBatch` dans le SDK Cosmos DB. Toutes les opérations doivent cibler la même clé de partition.
Pourquoi: TransactionalBatch garantit que toutes les opérations du lot réussissent ou échouent en tant qu'unité atomique unique, empêchant les mises à jour partielles. C'est plus efficace qu'une procédure stockée pour les opérations de lot côté client.
Une charge de travail Cosmos DB est imprévisible, avec des pics et des creux de trafic significatifs.
Configurer le débit provisionné par autoscale sur la base de données ou le conteneur.
Pourquoi: L'autoscale ajuste automatiquement les RU/s en fonction de l'utilisation, assurant les performances pendant les pics et des économies pendant les creux. Il s'adapte entre 10 % et 100 % des RU/s maximaux configurés.
Les données sont consultées fréquemment au début, puis rarement, et enfin archivées pour une conservation à long terme.
Utiliser une combinaison de niveaux d'accès Chaud (Hot), Froid (Cool) et Archive. Automatiser les transitions avec une politique de gestion du cycle de vie.
Pourquoi: Aligner le niveau d'accès avec le modèle d'accès optimise les coûts. Chaud est pour l'accès fréquent, Froid pour l'accès peu fréquent, et Archive pour le stockage à long terme et à faible coût. Les politiques de cycle de vie automatisent cela.
Empêcher plusieurs processus de modifier le même blob simultanément.
Implémenter les baux de blob. Un processus acquiert un verrou d'écriture exclusif (bail) sur un blob avant de le modifier.
Pourquoi: Les baux offrent un contrôle de concurrence pessimiste. Une fois un bail acquis, aucun autre client ne peut écrire sur le blob tant que le bail n'est pas libéré ou n'expire pas.
Stocker les journaux d'audit dans le stockage Blob et s'assurer qu'ils ne peuvent pas être modifiés ou supprimés pendant une période de rétention fixe (par exemple, 7 ans).
Configurer une politique de rétention basée sur le temps sur le conteneur de blob. Pour les rétentions indéfinies, utiliser une conservation légale (legal hold).
Pourquoi: Les politiques de stockage immuable appliquent l'état WORM (Write-Once, Read-Many), essentiel pour la conformité. Une fois verrouillée, une politique basée sur le temps ne peut pas être raccourcie.
Besoin de catégoriser les blobs avec des attributs clé-valeur et de les interroger sur l'ensemble d'un compte de stockage sans lister tous les blobs.
Utiliser les balises d'index de blob (Blob Index Tags).
Pourquoi: Les balises d'index sont indexées par le service de stockage et peuvent être utilisées dans les requêtes de filtrage côté serveur (`Find Blobs by Tags`). Les métadonnées ne sont pas indexées et ne peuvent être filtrées côté client qu'après avoir été listées.
Authentifier les utilisateurs de manière sécurisée dans une application monopage (SPA) et acquérir des jetons pour une API backend.
Utiliser le flux de code d'autorisation avec PKCE (Proof Key for Code Exchange).
Pourquoi: C'est la meilleure pratique de sécurité actuelle pour les clients publics. Cela évite d'exposer les jetons dans l'URL (contrairement au flux implicite déprécié) et ne nécessite pas de secret client.
Un service d'arrière-plan ou un démon doit appeler une API protégée (comme Microsoft Graph) sans utilisateur connecté.
Utiliser le flux Client Credentials avec les permissions d'application.
Pourquoi: Ce flux authentifie l'application elle-même à l'aide d'un secret client ou d'un certificat. Les permissions d'application accordent l'accès à l'ensemble de l'organisation, sous réserve du consentement de l'administrateur.
Une API web de niveau intermédiaire doit appeler une API aval tout en préservant l'identité de l'utilisateur connecté d'origine.
Implémenter le flux On-Behalf-Of (OBO).
Pourquoi: L'API de niveau intermédiaire échange le jeton d'accès de l'utilisateur contre un nouveau jeton dont la portée est l'API aval. Cela délègue l'identité de l'utilisateur de manière sécurisée.
Une application utilisant MSAL doit acquérir des jetons efficacement, en minimisant les invites utilisateur.
Toujours appeler `AcquireTokenSilent()` en premier. En cas d'échec avec une `MsalUiRequiredException`, revenir à une méthode interactive comme `AcquireTokenInteractive()` ou un flux d'autorisation.
Pourquoi: `AcquireTokenSilent()` vérifie le cache pour un jeton valide ou utilise un jeton de rafraîchissement pour en obtenir un nouveau sans interaction utilisateur. C'est crucial pour une bonne expérience utilisateur.
Une ressource Azure (par exemple, App Service, fonction) doit accéder à une autre ressource Azure (par exemple, Key Vault, base de données SQL) sans stocker les informations d'identification dans le code ou la configuration.
Activer une identité managée (attribuée par le système ou par l'utilisateur) sur la ressource source et lui accorder des permissions RBAC sur la ressource cible.
Pourquoi: L'identité managée fournit une identité dans Microsoft Entra ID pour la ressource. Azure gère le cycle de vie des informations d'identification, éliminant le besoin pour les développeurs de gérer les secrets.
Plusieurs ressources Azure doivent partager la même identité et les mêmes permissions pour accéder à d'autres services.
Créer une seule identité managée attribuée par l'utilisateur et l'affecter à toutes les ressources requises.
Pourquoi: Une identité attribuée par l'utilisateur a un cycle de vie indépendant de toute ressource, ce qui la rend réutilisable. Une identité attribuée par le système est liée à une seule ressource et est supprimée avec la ressource.
Besoin d'accorder l'accès aux secrets Key Vault en utilisant des groupes Azure AD avec des permissions granulaires au niveau de chaque secret.
Utiliser le modèle de permissions Azure RBAC pour Key Vault. Attribuer des rôles comme `Utilisateur de secrets Key Vault` aux principaux.
Pourquoi: RBAC permet des attributions de rôles au niveau du coffre, ou de la portée de clé/secret/certificat individuelle, offrant plus de granularité que les politiques d'accès, qui s'appliquent à tous les objets d'un type dans le coffre.
Une application doit prendre en compte les modifications de configuration d'Azure App Configuration sans redémarrer.
Utiliser le fournisseur/SDK App Configuration et le configurer pour qu'il se rafraîchisse en surveillant une clé sentinelle.
Pourquoi: Le SDK peut vérifier périodiquement une clé sentinelle pour les changements. Lorsque vous mettez à jour les paramètres de l'application, vous mettez également à jour la clé sentinelle, ce qui déclenche le rafraîchissement de la configuration de tous les clients.
Besoin d'activer une nouvelle fonctionnalité pour un groupe spécifique d'utilisateurs (par exemple, les testeurs bêta) et un pourcentage du public général.
Utiliser un indicateur de fonctionnalité Azure App Configuration avec un filtre de ciblage.
Pourquoi: Le filtre de ciblage prend en charge les déploiements complexes, vous permettant de définir des audiences basées sur des utilisateurs et des groupes avec des pourcentages spécifiques, plus un pourcentage de déploiement par défaut pour tous les autres.
Besoin de générer un jeton sécurisé et de courte durée pour accorder à un client l'accès à un blob spécifique.
Créer une SAS de délégation d'utilisateur.
Pourquoi: Une SAS de délégation d'utilisateur est signée avec les informations d'identification Microsoft Entra ID, et non la clé du compte de stockage. C'est plus sécurisé car cela évite de distribuer la clé du compte et l'accès peut être révoqué via les politiques Entra ID.
Dépanner un problème de performance dans une application de microservices en visualisant les dépendances et en identifiant quel service aval est à l'origine d'une latence élevée.
Utiliser la fonctionnalité Carte d'application (Application Map) dans Application Insights.
Pourquoi: La Carte d'application découvre et affiche automatiquement une vue topologique de votre application distribuée, montrant les métriques de santé et de performance pour chaque composant et les appels entre eux.
Tracer une seule requête utilisateur lorsqu'elle transite par plusieurs microservices.
Utiliser la vue des détails de transaction de bout en bout dans Application Insights. Toutes les données de télémétrie sont corrélées par un `operation_Id` partagé.
Pourquoi: Les SDK Application Insights propagent automatiquement les en-têtes W3C Trace Context, permettant de corréler toutes les données de télémétrie pour une seule opération avec le même `operation_Id`, offrant une vue unifiée.
Diagnostiquer un problème de production : performances lentes intermittentes vs. une exception intermittente.
Pour les performances lentes, utiliser Application Insights Profiler. Pour les exceptions, utiliser Snapshot Debugger.
Pourquoi: Profiler capture les traces de temps au niveau des méthodes pour les requêtes lentes ("chemins chauds"). Snapshot Debugger capture la pile d'appels et les variables locales au moment où une exception est levée.
Réduire le volume de données et les coûts d'Application Insights provenant d'une application à fort trafic tout en conservant des données statistiquement valides.
Activer l'échantillonnage adaptatif dans la configuration du SDK de l'application.
Pourquoi: L'échantillonnage adaptatif ajuste automatiquement le taux d'échantillonnage pour rester dans un volume de données cible, échantillonnant plus agressivement pendant le trafic élevé et moins pendant le trafic faible, préservant ainsi les données de télémétrie importantes.
Surveiller en continu la disponibilité d'un point de terminaison d'application web depuis plusieurs emplacements géographiques.
Configurer un test de disponibilité standard (test ping d'URL) dans Application Insights.
Pourquoi: Les tests de disponibilité envoient des requêtes à votre point de terminaison depuis les centres de données Azure du monde entier, offrant une surveillance proactive de la disponibilité et de la réactivité et déclenchant des alertes en cas d'échec.
Créer une alerte qui se déclenche lorsqu'une métrique de performance (par exemple, le temps de réponse moyen) dépasse un seuil spécifique pendant une période définie.
Créer une règle d'alerte métrique Azure Monitor. Cibler la ressource et la métrique, configurer un seuil statique, un type d'agrégation et une période d'évaluation. Lier à un groupe d'actions.
Pourquoi: Les alertes métriques offrent une surveillance à faible latence et avec état des données métriques quasi en temps réel, ce qui est idéal pour les alertes basées sur la performance.
Contrôler l'utilisation de l'API en limitant la fréquence des appels (par exemple, 100 appels/min) par rapport au nombre total d'appels sur une période plus longue (par exemple, 10 000 appels/mois).
Utiliser la politique `rate-limit` pour la fréquence des appels. Utiliser la politique `quota` pour le volume total d'appels.
Pourquoi: `rate-limit` limite les pics à court terme et renvoie un HTTP 429. `quota` impose une limite d'utilisation sur une période plus longue (par exemple, une période de facturation) et renvoie un HTTP 403 lorsqu'elle est dépassée.
Mettre en cache les réponses API dans API Management pour réduire la charge du backend, avec la clé de cache variant selon un en-tête de requête.
Utiliser une politique `<cache-lookup vary-by-header="..." />` dans la section entrante et une politique `<cache-store duration="..." />` dans la section sortante.
Pourquoi: Cette combinaison de politiques en deux parties active la mise en cache des réponses. `cache-lookup` vérifie la présence d'un élément mis en cache, et `cache-store` enregistre la réponse. Les attributs `vary-by` garantissent des entrées de cache uniques pour différentes variations de requêtes.
Gérer les modifications d'une API. Un changement disruptif est requis vs. un changement non-disruptif doit être testé.
Utiliser les Versions pour les changements disruptifs (par exemple, /v1, /v2). Utiliser les Révisions pour les changements non-disruptifs et les déploiements progressifs et sécurisés.
Pourquoi: Le versioning permet à plusieurs versions d'API d'être actives simultanément. Les révisions vous permettent de modifier une API hors ligne, de la tester, puis de la rendre la révision "actuelle" sans interruption de service.
Notifier plusieurs services aval indépendants lorsqu'un événement se produit dans un service Azure (par exemple, blob créé, groupe de ressources créé).
Utiliser Azure Event Grid. Créer un topic système pour la ressource Azure et des abonnements aux événements pour chaque gestionnaire aval.
Pourquoi: Event Grid est un service pub/sub entièrement géré, basé sur le push, qui découple les éditeurs d'événements des abonnés, permettant des architectures réactives et événementielles.
Ingérer un flux de télémétrie ou de données d'événements à haut volume (millions d'événements par seconde) provenant de nombreux appareils.
Utiliser Azure Event Hubs.
Pourquoi: Event Hubs est une plateforme de streaming de données massivement évolutive conçue pour l'ingestion à haut débit. Elle utilise un modèle de consommateur partitionné pour le traitement parallèle.
S'assurer que les événements provenant de la même source (par exemple, un appareil IoT spécifique) sont traités dans l'ordre par le même consommateur.
Envoyer des événements à Event Hubs avec une clé de partition définie sur l'identifiant de la source (par exemple, ID d'appareil).
Pourquoi: Event Hubs achemine tous les messages avec la même clé de partition vers la même partition. Au sein d'une partition, l'ordre des messages est maintenu.
Traiter une séquence de messages liés dans un ordre strict Premier entré, premier sorti (FIFO).
Utiliser les sessions Azure Service Bus. Envoyer tous les messages liés avec le même `SessionId`.
Pourquoi: Les sessions fournissent un flux de messages concurrent et ordonné. Un récepteur conscient de la session verrouille la session, garantissant que les messages sont traités séquentiellement par un seul consommateur.
Un seul éditeur envoie des messages à un topic, mais plusieurs abonnés ne veulent qu'un sous-ensemble de ces messages basé sur les propriétés des messages.
Utiliser un topic Service Bus avec plusieurs abonnements. Appliquer des filtres SQL ou des filtres de corrélation à chaque abonnement.
Pourquoi: C'est le modèle de publication-abonnement canonique avec routage basé sur le contenu. Chaque abonnement reçoit une copie du message s'il correspond à sa règle de filtre.
Un message ne peut pas être traité avec succès après plusieurs tentatives et doit être mis de côté pour une inspection ultérieure.
Laisser le message échouer le traitement jusqu'à ce que son nombre maximal de livraisons soit dépassé. Il sera automatiquement déplacé vers la Dead-Letter Queue (DLQ).
Pourquoi: La DLQ est une sous-file d'attente intégrée pour les messages "poison". Cela empêche un message défaillant de bloquer la file d'attente principale et permet une analyse et un retraitement hors ligne.
Choisir un service de messagerie pour : commandes d'entreprise, événements réactifs ou télémétrie à haut volume.
Service Bus pour les commandes (ordres, transactions). Event Grid pour les événements réactifs (blob créé, ressource modifiée). Event Hubs pour la télémétrie (données IoT, parcours de clics).
Pourquoi: Service Bus offre des fonctionnalités riches comme l'ordonnancement, les transactions et la mise en file d'attente des messages non distribuables. Event Grid est pour le routage d'événements léger et basé sur le push. Event Hubs est pour le streaming de données à haut débit.