Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen AZ-104. Lisez de haut en bas ou sautez à une section.
Gérer automatiquement l'appartenance à un groupe de sécurité en fonction des attributs utilisateur (par exemple, le service).
Configurer un groupe de sécurité Microsoft Entra ID avec le type d'appartenance "Dynamic User" et définir une règle basée sur les attributs.
Pourquoi: Les règles basées sur les attributs éliminent l'administration manuelle continue des changements de cycle de vie des utilisateurs. Nécessite Entra ID P1/P2.
Appliquer une gouvernance cohérente (stratégies, RBAC) sur plusieurs abonnements à partir d'un point de gestion unique.
Créer un groupe d'administration, y placer les abonnements et attribuer des stratégies ou des rôles RBAC au niveau du groupe d'administration.
Pourquoi: Les stratégies et les attributions de rôles sont héritées par tous les abonnements enfants, ce qui permet une gouvernance centralisée et cohérente.
Empêcher le déploiement de ressources dans des régions Azure non autorisées sur l'ensemble d'un abonnement.
Attribuer la stratégie Azure intégrée "Emplacements autorisés" avec un effet `Deny` au niveau de l'abonnement.
Pourquoi: La stratégie assure une gouvernance préventive. RBAC contrôle les actions, pas les emplacements de déploiement. Les verrous de ressources empêchent la modification/suppression, pas les nouveaux déploiements.
Accorder des autorisations pour gérer les VM mais pas le réseau virtuel sous-jacent ni l'accès utilisateur.
Attribuer le rôle intégré "Contributeur de machine virtuelle" au niveau du groupe de ressources ou de la VM.
Pourquoi: Ce rôle fournit des autorisations spécifiques de gestion des VM (démarrer, arrêter, réinitialiser l'image) sans accorder de droits de Contributeur ou de Propriétaire étendus.
Exiger la MFA lorsque les utilisateurs accèdent à des applications cloud spécifiques (par exemple, le portail Azure) depuis l'extérieur du réseau d'entreprise.
Créer une stratégie d'accès conditionnel avec un "emplacement nommé" pour les IP d'entreprise comme condition d'exclusion, et exiger la MFA comme contrôle d'octroi.
Pourquoi: L'exclusion d'un emplacement approuvé est la clé pour contourner la MFA sur le réseau d'entreprise tout en l'appliquant partout ailleurs.
Empêcher la suppression de ressources critiques, même par des administrateurs avec des rôles Propriétaire.
Appliquer un verrou de ressource `CanNotDelete` ou `ReadOnly` sur la ressource ou son groupe de ressources.
Pourquoi: Les verrous de ressources s'appliquent à tous les utilisateurs, quel que soit leur rôle RBAC, offrant la protection la plus solide contre la suppression accidentelle.
Corriger automatiquement les ressources non conformes existantes identifiées par une stratégie Azure (par exemple, ajouter une balise manquante).
Pour les stratégies avec les effets `Modify` ou `DeployIfNotExists`, créer une tâche de correction pour l'attribution de stratégie.
Pourquoi: Les tâches de correction déclenchent l'action corrective de la stratégie sur toutes les ressources non conformes existantes, automatisant le processus de mise en conformité d'un environnement.
Rapporter les coûts Azure ventilés par service, projet ou unité commerciale.
Appliquer une balise cohérente (par exemple, "CostCenter") à toutes les ressources. Utiliser Azure Cost Management pour filtrer et regrouper les coûts par cette balise.
Pourquoi: Les balises sont le principal mécanisme d'allocation des coûts personnalisée et de reporting sur les différents groupes de ressources et abonnements.
Accorder aux administrateurs des rôles privilégiés uniquement lorsque nécessaire, pour une durée limitée et avec un flux de travail d'approbation.
Utiliser Microsoft Entra Privileged Identity Management (PIM). Rendre les utilisateurs éligibles aux rôles et configurer les exigences d'activation.
Pourquoi: PIM applique l'accès Just-In-Time (JIT), réduisant l'exposition des comptes privilégiés permanents et fournissant une piste d'audit complète.
Accorder aux partenaires externes l'accès aux ressources Azure en utilisant leurs propres informations d'identification d'entreprise.
Utiliser la collaboration Microsoft Entra B2B pour inviter des partenaires en tant qu'utilisateurs invités à votre tenant.
Pourquoi: B2B évite la création et la gestion de nouvelles informations d'identification dans votre tenant ; les partenaires utilisent leur fournisseur d'identité existant pour l'authentification.
Minimiser les coûts de stockage pour les données à long terme (par exemple, les archives de conformité) rarement consultées mais devant être conservées.
Utiliser une stratégie de gestion du cycle de vie des objets blob pour faire passer automatiquement les objets blob des niveaux Hot/Cool au niveau Archive.
Pourquoi: Le niveau Archive a le coût de stockage le plus bas. Les règles de cycle de vie automatisent le processus de hiérarchisation en fonction de l'âge de l'objet blob ou de la dernière heure d'accès.
Assurer l'accès en lecture aux données de stockage à partir d'une région secondaire lors d'une panne de la région principale.
Configurer le compte de stockage avec le stockage géo-redondant avec accès en lecture (RA-GRS) ou RA-GZRS.
Pourquoi: GRS/GZRS standard réplique les données mais n'autorise pas l'accès en lecture à la secondaire avant un basculement. Le préfixe "RA" est requis pour un accès en lecture continu.
Capacité à révoquer immédiatement un ensemble de jetons de signature d'accès partagé (SAS) pour un conteneur spécifique.
Créer des jetons SAS basés sur une stratégie d'accès stockée sur le conteneur. Pour révoquer, modifier ou supprimer la stratégie.
Pourquoi: La modification de la stratégie d'accès stockée invalide immédiatement tous les jetons SAS qui lui sont associés, fournissant un mécanisme de révocation centralisé.
Synchroniser un serveur de fichiers local avec un partage de fichiers Azure tout en minimisant l'utilisation de l'espace disque local.
Déployer Azure File Sync et activer la hiérarchisation cloud sur le point de terminaison du serveur.
Pourquoi: La hiérarchisation cloud ne conserve que les fichiers fréquemment consultés ("chauds") mis en cache localement, tandis que les fichiers moins utilisés sont hiérarchisés vers Azure, apparaissant comme des stubs sur le serveur local.
Restreindre l'accès réseau à un compte de stockage à des sous-réseaux VNet spécifiques et à des adresses IP publiques.
Activer le pare-feu du compte de stockage. Ajouter des règles de réseau virtuel pour les sous-réseaux et des règles d'adresse IP pour les IP publiques.
Pourquoi: Le pare-feu de stockage fournit un contrôle d'accès au niveau du réseau directement sur le point de terminaison public du compte de stockage, bloquant tout autre trafic.
Protéger les objets blob contre la suppression accidentelle en permettant la récupération pendant une période spécifiée.
Activer la suppression réversible des objets blob sur le compte de stockage et configurer la période de rétention (par exemple, 14 jours).
Pourquoi: La suppression réversible conserve les objets blob supprimés pendant la période configurée, permettant une restauration simple. C'est la première ligne de défense contre la perte accidentelle de données.
Satisfaire aux exigences de conformité pour stocker des données dans un état non effaçable, non modifiable (WORM) pendant une période fixe.
Configurer une stratégie de rétention basée sur le temps sur un conteneur d'objets blob et verrouiller la stratégie.
Pourquoi: Une stratégie de rétention basée sur le temps verrouillée rend les objets blob immuables, empêchant leur suppression ou modification par quiconque (y compris les administrateurs) jusqu'à l'expiration de la période de rétention.
Migrer un très grand jeu de données (par exemple, plus de 50 To) vers Azure Blob Storage lorsque la bande passante réseau est limitée.
Utiliser l'appliance physique Azure Data Box pour un transfert hors ligne.
Pourquoi: Pour les grands ensembles de données, l'expédition d'un appareil physique est nettement plus rapide que le transfert de données via une connexion réseau lente ou saturée.
Atteindre un SLA de 99,99 % pour les VM et protéger une application contre une défaillance d'un seul centre de données au sein d'une région.
Déployer plusieurs instances de VM sur différentes zones de disponibilité au sein de la même région.
Pourquoi: Les zones de disponibilité sont des centres de données physiquement séparés. Les groupes à haute disponibilité ne protègent que contre les pannes au niveau du rack au sein d'un seul centre de données (SLA de 99,95 %).
Déployer et tester une nouvelle version d'application avec le trafic de production en direct avant une publication complète, avec zéro temps d'arrêt.
Utiliser un emplacement de déploiement App Service. Déployer sur l'emplacement, tester, puis effectuer un échange. Utiliser éventuellement le routage du trafic pour les tests canary.
Pourquoi: Les emplacements offrent un environnement de préproduction complet. L'opération d'échange est une redirection de trafic quasi instantanée, garantissant zéro temps d'arrêt.
Exécuter une tâche de traitement par lots conteneurisée de courte durée, selon un calendrier, avec un coût minimal et sans gestion d'infrastructure.
Utiliser Azure Container Instances (ACI).
Pourquoi: ACI offre une facturation à la seconde et aucune surcharge de gestion de cluster, ce qui en fait l'option la plus rentable pour les charges de travail de conteneurs sporadiques ou de courte durée.
Mettre à l'échelle automatiquement une charge de travail avec des pics quotidiens prévisibles (par exemple, heures de bureau) tout en gérant les pics inattendus.
Configurer l'autoscaling des VM Scale Set avec des règles basées sur un calendrier et des règles basées sur des métriques.
Pourquoi: La combinaison d'une mise à l'échelle proactive (basée sur un calendrier) et réactive (basée sur des métriques) offre le meilleur équilibre entre performance (prête avant le pic) et efficacité des coûts (réduction de l'échelle en cas d'inactivité).
Stocker des images de conteneurs pour un cluster Azure Kubernetes Service (AKS) de manière sécurisée dans un registre privé avec analyse des vulnérabilités.
Utiliser Azure Container Registry (ACR) SKU Premium et l'intégrer avec AKS en utilisant une identité managée.
Pourquoi: ACR fournit un registre privé colocalisé dans Azure. Le SKU Premium inclut l'analyse des vulnérabilités. L'identité managée fournit une authentification sécurisée et sans identifiants d'AKS vers ACR.
Effectuer une mise à jour du système d'exploitation ou de l'application sur toutes les instances de VMSS sans provoquer de temps d'arrêt de l'application.
Mettre à jour le modèle VMSS (par exemple, nouvelle version d'image) et utiliser une stratégie de mise à niveau Rolling.
Pourquoi: La stratégie Rolling met à jour les instances par lots configurables, garantissant qu'un sous-ensemble d'instances est toujours disponible pour servir le trafic tout au long du processus de mise à jour.
Déployer une application multi-conteneurs (par exemple, application + sidecar de journalisation) qui doit partager le réseau et le stockage, sans orchestrateur complet.
Déployer les conteneurs dans un groupe de conteneurs Azure Container Instances (ACI) unique.
Pourquoi: Un groupe de conteneurs colocalise plusieurs conteneurs, partageant un réseau localhost et des volumes, parfait pour les modèles de sidecar sans la complexité de Kubernetes.
Augmenter la taille du disque du système d'exploitation ou des données d'une VM après son déploiement.
Désallouer la VM, redimensionner la ressource de disque dans Azure, démarrer la VM, puis étendre la partition dans le système d'exploitation invité.
Pourquoi: Le redimensionnement du disque Azure n'alloue que plus d'espace. Le système d'exploitation invité doit être instruit d'utiliser ce nouvel espace en étendant sa partition de système de fichiers.
Permettre à un App Service d'accéder de manière sécurisée aux secrets d'Azure Key Vault sans stocker les identifiants dans l'application.
Activer une identité managée attribuée par le système sur l'App Service et accorder à cette identité les autorisations `Get` et `List` sur les secrets de Key Vault.
Pourquoi: L'identité managée fournit un mécanisme d'authentification sans identifiants. L'application peut acquérir automatiquement un jeton d'accès pour Key Vault, éliminant ainsi la gestion des secrets.
Organiser un déploiement d'infrastructure en tant que code vaste et complexe en composants plus petits, réutilisables et maintenables.
Refactoriser le déploiement en modules Bicep, chaque module représentant une unité logique (par exemple, mise en réseau, calcul), et les orchestrer à partir d'un fichier Bicep principal.
Pourquoi: Les modules favorisent la réutilisation du code, améliorent la lisibilité et simplifient la gestion des déploiements d'infrastructure complexes.
Isoler les niveaux d'application (web, application, données) au sein d'un VNet, empêchant la communication directe entre les niveaux non adjacents.
Utiliser un sous-réseau séparé pour chaque niveau et appliquer des groupes de sécurité réseau (NSG) à chaque sous-réseau pour contrôler le flux de trafic.
Pourquoi: Les NSG permettent un filtrage granulaire et avec état basé sur les plages d'IP source/destination (sous-réseaux), les ports et les protocoles, permettant la micro-segmentation du réseau.
Connecter deux VNet dans différentes régions Azure en privé sur le réseau fédérateur de Microsoft.
Configurer le peering VNet global entre les deux VNet.
Pourquoi: Le peering global est plus simple, a une latence plus faible et une bande passante plus élevée qu'une connexion VPN de VNet à VNet. Le trafic reste sur le réseau privé Microsoft.
VNet-A est appairé à Hub-VNet, et Spoke-VNet est également appairé à Hub-VNet. Les VM de VNet-A ne peuvent pas atteindre les VM de Spoke-VNet.
La cause est que le peering VNet est non transitif. Pour activer la communication, appairer directement VNet-A et Spoke-VNet ou utiliser une NVA dans le Hub.
Pourquoi: Le peering ne crée pas de chaîne. Chaque VNet doit être directement connecté pour communiquer, sauf si le routage via une Network Virtual Appliance est configuré.
Établir un tunnel IPsec persistant et chiffré depuis un réseau local vers un VNet Azure sur l'internet public.
Déployer une passerelle VPN Azure dans le VNet et configurer une connexion Site-à-Site (S2S).
Pourquoi: C'est la solution standard, sécurisée et fiable pour la connectivité hybride entre un site local unique et un VNet Azure.
Un Azure Load Balancer continue d'envoyer du trafic à une VM de backend non saine, provoquant des timeouts d'application.
Configurer une sonde de santé sur l'équilibreur de charge qui vérifie avec précision la santé de l'application sur les VM de backend.
Pourquoi: L'équilibreur de charge dépend entièrement des sondes de santé pour détecter les instances non saines. Sans une sonde correctement configurée, il ne peut pas retirer les VM défaillantes de la rotation du trafic.
Router le trafic HTTP/S vers différents pools de serveurs backend en fonction du chemin d'URL (par exemple, /images/* vs /api/*).
Utiliser Azure Application Gateway avec des règles de routage basées sur le chemin.
Pourquoi: Application Gateway est un équilibreur de charge de couche 7 qui inspecte les requêtes HTTP et peut prendre des décisions de routage basées sur les chemins d'URL. Un Azure Load Balancer standard est de couche 4 et ne le peut pas.
Les VM d'un VNet avec un serveur DNS personnalisé ne peuvent pas résoudre les noms d'hôtes dans une zone DNS privée Azure.
Configurer le serveur DNS personnalisé pour transférer conditionnellement les requêtes pour la zone privée à l'IP du résolveur DNS fournie par Azure (168.63.129.16).
Pourquoi: Lorsqu'un serveur DNS personnalisé est utilisé, il contourne le DNS interne d'Azure. Le serveur personnalisé doit apprendre à résoudre les zones spécifiques à Azure en transférant les requêtes au DNS Azure.
Forcer tout le trafic destiné à Internet depuis les VNet spoke à être inspecté par un Azure Firewall central dans le VNet hub.
Appliquer une table de routage avec une route définie par l'utilisateur (UDR) aux sous-réseaux spoke. L'UDR est une route par défaut (0.0.0.0/0) pointant vers l'IP privée du pare-feu.
Pourquoi: Une UDR remplace la route système par défaut d'Azure vers Internet, vous permettant de contrôler et de centraliser le flux de trafic de sortie pour l'inspection de sécurité.
Fournir un accès RDP/SSH sécurisé aux VM qui n'ont pas d'adresses IP publiques, sans configurer de VPN.
Déployer Azure Bastion dans un sous-réseau dédié (AzureBastionSubnet) dans le VNet.
Pourquoi: Bastion fournit un service de boîte de saut géré, permettant un accès administratif sécurisé via le portail Azure sur TLS, éliminant l'exposition des IP publiques sur les VM.
S'assurer que le trafic entre une VM et un service PaaS (par exemple, Azure SQL) reste sur le réseau privé et que le service PaaS n'est pas accessible publiquement.
Créer un point de terminaison privé pour le service PaaS dans le VNet de la VM et désactiver l'accès réseau public sur le service PaaS.
Pourquoi: Un point de terminaison privé donne au service PaaS une IP privée au sein de votre VNet, tandis que la désactivation de l'accès public garantit qu'il n'est accessible que via cette IP privée.
Router les utilisateurs mondiaux vers le point de terminaison d'application régional le plus proche afin de garantir la latence la plus faible possible.
Utiliser Azure Traffic Manager avec la méthode de routage "Performance".
Pourquoi: La méthode de routage Performance utilise le DNS pour diriger les clients vers le point de terminaison présentant la latence réseau la plus faible depuis leur emplacement.
Envoyer une notification (e-mail, SMS, webhook) lorsqu'une métrique de ressource (par exemple, le pourcentage de CPU d'une VM) dépasse un seuil pendant une durée définie.
Créer une règle d'alerte de métrique dans Azure Monitor et la lier à un groupe d'actions qui définit l'action de notification.
Pourquoi: C'est le modèle standard. La règle d'alerte définit la condition (quoi/quand), et le groupe d'actions définit la notification résultante (qui/comment).
Déterminer si le trafic entre deux VM est bloqué par une règle de groupe de sécurité réseau (NSG) spécifique.
Utiliser l'outil Vérification du flux IP dans Azure Network Watcher.
Pourquoi: Vérification du flux IP simule un flux de paquets et indique explicitement quel NSG et quelle règle autorisent ou refusent le trafic, ce qui en fait l'outil définitif pour résoudre les conflits de NSG.
Configurer des sauvegardes planifiées et basées sur des stratégies pour les VM Azure avec cohérence applicative et rétention à long terme.
Créer un coffre Recovery Services, définir une stratégie de sauvegarde (planification, rétention) et activer la sauvegarde pour les VM cibles.
Pourquoi: Le coffre Recovery Services est l'entité de gestion centrale pour Azure Backup. Il stocke les données de sauvegarde de manière sécurisée et gère toutes les opérations de sauvegarde et de restauration.
Créer un tableau de bord centralisé pour surveiller les performances (CPU, mémoire, disque, réseau) des VM sur plusieurs abonnements.
Déployer un espace de travail Log Analytics central et activer VM Insights pour toutes les VM cibles, en les pointant vers cet espace de travail.
Pourquoi: VM Insights collecte et agrège les données de performance, fournissant des classeurs pré-construits et une vue consolidée des performances "à l'échelle" sur plusieurs abonnements.
Identifier de manière proactive les ressources Azure sous-utilisées et les opportunités d'économies (par exemple, le dimensionnement approprié des VM).
Examiner régulièrement les recommandations de coûts dans Azure Advisor.
Pourquoi: Azure Advisor analyse automatiquement l'utilisation des ressources et fournit des recommandations exploitables et personnalisées pour des économies de coûts sans nécessiter de configuration supplémentaire.
Répliquer des VM Azure d'une région primaire vers une région secondaire pour fournir une capacité de récupération d'urgence.
Utiliser Azure Site Recovery. Créer un coffre Recovery Services et activer la réplication pour les VM vers la région cible.
Pourquoi: ASR est le service Azure natif pour orchestrer la réplication de VM, les tests de basculement et le basculement/retour arrière entre les régions Azure.
Définir différentes périodes de rétention des données pour les journaux de sécurité par rapport aux journaux de performances au sein d'un seul espace de travail Log Analytics pour optimiser les coûts.
Définir une rétention par défaut au niveau de l'espace de travail, puis configurer une période de rétention plus longue au niveau de la table individuelle (par exemple, pour la table SecurityEvent).
Pourquoi: La rétention par table vous permet de répondre aux besoins de conformité à long terme pour des données spécifiques tout en minimisant les coûts de stockage pour les données moins critiques et à volume élevé.