Microsoft AZ-900: Architecture Azure et infrastructure mondiale — 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.

L’architecture mondiale d’Azure est conçue pour fournir des services cloud résilients, performants et conformes à grande échelle. La compréhension de la disposition physique des géographies, des régions et des zones de disponibilité, ainsi que de la hiérarchie logique des groupes d’administration, des abonnements, des groupes de ressources et des ressources, est fondamentale pour une conception et une gouvernance fiables. Le plan de contrôle fourni par Azure Resource Manager, combiné à des modèles déclaratifs, permet des déploiements cohérents et reproductibles qui s’alignent sur les politiques organisationnelles et les exigences de sécurité. Les décisions de conception dans ce domaine influencent directement les objectifs de disponibilité, les obligations de résidence des données et l’expérience utilisateur dans le monde entier. La sélection du bon modèle de redondance, le calcul des SLA composites et le choix de services de routage mondiaux tels que Azure Front Door, Traffic Manager et Azure CDN sont essentiels pour atteindre les objectifs de continuité d’activité, de conformité et de performance.

Géographies, Régions, Zones de disponibilité et Paires de régions

Les géographies Azure sont des ensembles définis de régions qui préservent la résidence des données et les limites de conformité. Les exemples incluent les États-Unis, l’Europe, le Royaume-Uni, l’Australie et le Canada, ainsi que des clouds souverains avec des modèles de conformité et de connectivité distincts. Les charges de travail qui doivent rester dans une juridiction donnée doivent être déployées dans des régions appartenant à la géographie cible pour garantir l’alignement réglementaire et la résidence des données. Une région est un ensemble de datacenters déployés à l’intérieur d’un périmètre défini par la latence et connectés par un réseau dédié à faible latence. Tous les services ou fonctionnalités ne sont pas disponibles dans chaque région, la capacité et la disponibilité des fonctionnalités doivent donc être validées tôt dans la planification. Les régions qui prennent en charge les Zones de disponibilité (Availability Zones) fournissent au moins trois zones de datacenters physiquement séparées avec une alimentation, un refroidissement et une mise en réseau indépendants. Les services redondants interzones (ZRS) et une architecture répartie sur plusieurs zones protègent contre les pannes au niveau du datacenter tout en maintenant un accès à faible latence au sein de la région. Chaque région Azure est associée à une autre région au sein de la même géographie pour former une paire de régions (par exemple, North Europe avec West Europe, East US avec West US). Les paires de régions permettent une récupération prioritaire lors de pannes étendues, des mises à jour de plateforme échelonnées et la réplication de données pour certains services. Les options géo-redondantes d’Azure Storage (GRS/GZRS) répliquent les données de manière asynchrone vers la région jumelée ; lorsque l’accès en lecture au secondaire est requis, utilisez RA-GRS ou RA-GZRS pour autoriser les lectures depuis le point de terminaison secondaire lors d’une panne ou d’un basculement planifié. Pour les charges de travail critiques nécessitant à la fois une haute disponibilité intra-régionale et une reprise après sinistre inter-régionale, combinez la redondance de zone avec la réplication par paire de régions. L’équilibre entre la latence, la résilience et la conformité mène à un modèle courant : déployer des charges de travail actives à travers les zones d’une région primaire et se protéger contre les sinistres régionaux en répliquant les données et en fournissant des chemins de basculement vers la région jumelée. Validez régulièrement les runbooks de basculement et le comportement du routage DNS ou frontal pour vous assurer que les objectifs de récupération sont atteints.

• Géographie
  • Portée : Frontière multi-régions
  • Avantage clé : Résidence des données et conformité
  • Utilisation typique : Alignement réglementaire (par ex., données de l’UE)
• Région
  • Portée : Zone métropolitaine unique
  • Avantage clé : Accès à faible latence aux services
  • Utilisation typique : Emplacement de déploiement principal
• Zone de disponibilité
  • Portée : Datacenters distincts au sein d’une région
  • Avantage clé : Isolation des pannes au niveau du datacenter
  • Utilisation typique : Haute disponibilité intra-régionale
• Paire de régions
  • Portée : Deux régions dans la même géographie
  • Avantage clé : Récupération et mises à jour coordonnées
  • Utilisation typique : Reprise après sinistre inter-régionale

Organisation et gouvernance des ressources : Groupes d’administration, Abonnements, Groupes de ressources et Ressources

La hiérarchie de gestion d’Azure permet de contrôler les stratégies, les accès et les coûts à grande échelle. Les groupes d’administration (Management groups) se situent au-dessus des abonnements et vous permettent d’appliquer Azure Policy et le contrôle d’accès en fonction du rôle (RBAC) de manière centralisée, avec un héritage en cascade vers les groupes d’administration et les abonnements enfants. C’est la structure appropriée pour segmenter par divisions d’entreprise, par niveaux d’environnement (production, non-production) ou par frontières réglementaires, tout en maintenant des garde-fous uniformes. Les abonnements (Subscriptions) constituent la limite administrative, de facturation et de quota. Ils sont bien adaptés pour isoler les coûts et les accès pour les unités commerciales, les environnements ou les applications. Utilisez une conception d’abonnement cohérente pour séparer la production de la non-production et pour appliquer des limites et des budgets. Pour les organisations ayant plusieurs divisions et une administration décentralisée, attribuez à chaque division un ou plusieurs abonnements et placez-les sous des groupes d’administration spécifiques à la division pour un héritage clair des stratégies et du RBAC. Les groupes de ressources (Resource groups) sont des conteneurs logiques pour les ressources qui partagent un même cycle de vie. Ils permettent des déploiements atomiques, un balisage (tagging) cohérent et des opérations de cycle de vie comme la suppression ou le verrouillage. Regroupez les ressources qui sont déployées, mises à jour et retirées ensemble, comme un niveau web et ses composants de surveillance. Utilisez des balises (tags) pour piloter la refacturation/imputation (chargeback/showback), la propriété, l’environnement et les attributs de conformité sur l’ensemble des ressources et des groupes. Les verrous (Locks) (ReadOnly, CanNotDelete) ajoutent une protection contre la suppression accidentelle au niveau de la ressource ou du groupe. Les ressources (Resources) sont les instances de service déployées (VMs, plans App Service, comptes de stockage). Les portées RBAC (groupe d’administration, abonnement, groupe de ressources, ressource) permettent d’accorder un accès selon le principe du moindre privilège précisément là où c’est nécessaire. Pour les déploiements multi-divisions, conservez un seul tenant Microsoft Entra ID, sauf s’il existe une forte exigence de conformité ou d’autonomie pour plusieurs tenants ; les abonnements et les groupes d’administration fournissent généralement une séparation suffisante avec beaucoup moins de surcharge administrative.

• Management Group
  • Objectif principal : Gouvernance à l’échelle de l’organisation
  • Contrôles appliqués : RBAC, Policy, Blueprints (via Policy + modèles)
  • Modèles courants : Segmentation par division/réglementation
• Subscription
  • Objectif principal : Limite de facturation et de quota
  • Contrôles appliqués : Budgets, RBAC, Policy
  • Modèles courants : Isolation par unité commerciale (BU) ou par environnement
• Resource Group
  • Objectif principal : Limite de cycle de vie
  • Contrôles appliqués : Verrous (Locks), Balises (Tags), RBAC
  • Modèles courants : Par application ou par unité de charge de travail
• Resource
  • Objectif principal : Instance de service
  • Contrôles appliqués : RBAC au niveau de l’instance, Balises (Tags)
  • Modèles courants : Composants de service individuels

Azure Resource Manager et les modèles

Azure Resource Manager (ARM) est le plan de contrôle pour le déploiement, la mise à jour et la suppression des ressources Azure via une API cohérente et un modèle basé sur les rôles. ARM fournit des opérations idempotentes, la gestion des dépendances, le balisage (tagging) et l’application des stratégies au moment du déploiement, permettant d’intégrer la gouvernance de la plateforme dans chaque changement. Les modèles ARM déclaratifs décrivent l’état souhaité de votre environnement en JSON et prennent en charge les paramètres, les variables, les conditions et les modèles liés modulaires. Ils permettent des déploiements reproductibles et versionnés à travers les environnements et les abonnements. Pour une expérience de création simplifiée, Bicep offre une syntaxe concise qui se transpile en modèles ARM tout en conservant le même moteur de déploiement et les mêmes avantages. Stockez les modèles dans un contrôle de code source, empaquetez-les en tant que spécifications de modèle (template specs) pour le partage, et intégrez-les dans des pipelines CI/CD pour garantir des changements d’infrastructure sans dérive et auditables. Les valeurs sensibles telles que les mots de passe administrateur ou les chaînes de connexion ne doivent jamais être intégrées dans les modèles. Utilisez des paramètres de type secureString/secureObject avec des références Key Vault pour qu’ARM récupère les secrets au moment du déploiement sans les exposer dans les journaux. Combinez les modèles avec des identités managées (managed identities) pour éliminer les informations d’identification codées en dur dans l’automatisation. Cette approche réduit les risques tout en préservant une automatisation complète pour les déploiements à grande échelle et multi-abonnements.

• Déploiements idempotents
  • Support ARM/Modèle : Oui
  • Résultat : Changements sûrs et reproductibles
• Application des stratégies au déploiement
  • Support ARM/Modèle : Oui
  • Résultat : Garde-fous intégrés aux pipelines
• Composition modulaire
  • Support ARM/Modèle : Modules liés / modules Bicep
  • Résultat : Réutilisabilité et standardisation
• Gestion des secrets
  • Support ARM/Modèle : Références Key Vault
  • Résultat : Aucun secret dans le code ou les journaux

Disponibilité, SLA, SLA composites et cycle de vie des services

Azure publie des contrats de niveau de service (SLA) avec garanties financières pour les services en disponibilité générale (GA). Pour les machines virtuelles, la disponibilité dépend de la topologie de déploiement : une seule VM avec un stockage SSD Premium bénéficie d’un SLA de 99,9 % ; deux VM ou plus dans un groupe à haute disponibilité ont un SLA de 99,95 % ; et deux VM ou plus déployées sur plusieurs zones de disponibilité atteignent un SLA de 99,99 %. Les services de plateforme (par exemple, Azure SQL Database ou App Service) ont leurs propres SLA, qui peuvent varier selon le niveau de service ou l’option de redondance. Alignez l’architecture sur le SLA cible en sélectionnant le modèle de redondance et les niveaux de service appropriés. Lorsqu’une solution dépend de plusieurs services, le SLA composite est le produit des SLA individuels si tous les composants sont nécessaires au fonctionnement de l’application. Par exemple, si une application web (99,95 %) dépend d’une base de données (99,99 %), la disponibilité composite est d’environ 0,9995 × 0,9999 = 99,94 %. L’augmentation de la redondance à n’importe quelle couche — comme le déploiement sur plusieurs zones, l’ajout de plusieurs instances derrière un équilibreur de charge ou l’utilisation de magasins de données géo-redondants — améliore la disponibilité effective. Inversement, l’ajout de dépendances en série diminue le SLA composite et doit être justifié par une valeur fonctionnelle claire. Le statut du cycle de vie d’un service affecte les garanties de fiabilité. Les fonctionnalités en préversion publique sont proposées pour recueillir des commentaires et peuvent être limitées à certaines régions ou présenter des lacunes fonctionnelles ; elles ne sont généralement pas assorties d’un SLA et ne sont pas recommandées pour les chemins critiques en production. Les fonctionnalités en disponibilité générale (GA) sont prêtes pour la production et couvertes par un SLA. Les feuilles de route et les calendriers de déploiement par région doivent être suivis pour éviter de dépendre par inadvertance de fonctionnalités en préversion dans les conceptions de production, en particulier dans les environnements sensibles à la conformité. Les objectifs de reprise après sinistre tels que le RPO et le RTO complètent les SLA et guident les choix de conception comme la réplication interzone ou interrégion, la fréquence des sauvegardes et l’orchestration du basculement. Validez régulièrement les procédures de basculement pour vous assurer que les performances de récupération mesurées correspondent aux objectifs métier et que les dépendances DNS, de certificats et d’identité sont également restaurées comme prévu.

• VM unique (SSD Premium)
  • SLA indicatif : 99,9 %
  • Remarques : À utiliser pour les charges de travail non critiques ou les applications tolérantes
• 2+ VM dans un groupe à haute disponibilité
  • SLA indicatif : 99,95 %
  • Remarques : Protège contre les pannes de rack/domaine d’erreur
• 2+ VM sur plusieurs zones de disponibilité
  • SLA indicatif : 99,99 %
  • Remarques : Protège contre les pannes au niveau du centre de données
• Fonctionnalité en préversion publique
  • SLA indicatif : Pas de SLA financier
  • Remarques : À évaluer ; à éviter sur les chemins critiques
• Fonctionnalité GA (dépendant du niveau de service)
  • SLA indicatif : Garanti par un SLA
  • Remarques : Vérifier les SLA spécifiques au niveau et à la région

Routage mondial et distribution de contenu : Azure Front Door, Traffic Manager et Azure CDN

L’expérience utilisateur mondiale dépend d’un routage intelligent, de la proximité du contenu et d’un basculement rapide. Azure Front Door est un proxy inverse mondial de couche 7 basé sur anycast, avec un pare-feu d’applications web (WAF), la terminaison TLS, le routage basé sur l’URL/le chemin, l’affinité de session et des sondes d’intégrité depuis la périphérie. Il accélère le contenu dynamique via le split-TCP et des optimisations de protocole, et fournit un basculement quasi instantané entre les origines. Front Door est idéal pour les applications web et les API multirégionales en mode actif-actif ou actif-passif, où vous avez besoin à la fois de performances et d’une sécurité centralisée en périphérie. Azure Traffic Manager est un service de distribution de trafic basé sur le DNS qui dirige les clients vers le meilleur point de terminaison en utilisant des stratégies telles que la priorité, le poids, la performance (latence), la géographie, le sous-réseau ou la multivalue. Comme il fonctionne au niveau du DNS, il prend en charge les points de terminaison non-HTTP (par exemple, les services TCP) et les scénarios hybrides, mais la vitesse de basculement est limitée par le TTL DNS et la mise en cache du client. Traffic Manager n’agit pas comme un proxy pour le trafic et n’accélère pas le contenu ; il se contente de répondre aux requêtes DNS avec le point de terminaison choisi. Azure CDN met en cache le contenu statique dans des points de présence en périphérie pour réduire la latence et décharger les origines. Il est bien adapté aux ressources statiques volumineuses comme les images, les vidéos, les scripts et les téléchargements. Bien que le CDN réduise les allers-retours pour le contenu pouvant être mis en cache, ce n’est pas un équilibreur de charge mondial tenant compte de l’intégrité pour les origines dynamiques ; combinez-le avec Front Door ou Traffic Manager pour le basculement multi-origine ou pour une logique de routage dynamique. De nombreuses architectures placent un CDN pour la mise en cache des ressources statiques et Front Door pour le trafic dynamique et la sécurité devant la même application.

• Azure Front Door (Std/Prm)
  • Couche/Mécanisme : Proxy anycast de couche 7
  • Cas d’usage principaux : Équilibrage de charge mondial, sécurité en périphérie, accélération
  • Méthodes de routage : Priorité, poids ; règles basées sur le chemin/l’hôte
  • Sondes d’intégrité : Sondes depuis les POP en périphérie
  • Vitesse de basculement : Secondes (quasi instantané)
  • Accélération dynamique : Oui
  • Mise en cache statique : Oui (basé sur des règles)
  • WAF disponible : Oui (intégré)
  • Modèle typique : Front Door devant des applications web/API multirégionales
• Azure Traffic Manager
  • Couche/Mécanisme : Stratégie basée sur le DNS
  • Cas d’usage principaux : Routage DNS interrégional ; points de terminaison non-HTTP
  • Méthodes de routage : Priorité, poids, performance, géographique, sous-réseau, multivalue
  • Sondes d’intégrité : Sondes de points de terminaison mondiales
  • Vitesse de basculement : Limité par le TTL (dizaines de secondes à quelques minutes)
  • Accélération dynamique : Non
  • Mise en cache statique : Non
  • WAF disponible : S/O
  • Modèle typique : Aiguillage DNS pour les services HTTP et non-HTTP
• Azure CDN
  • Couche/Mécanisme : Réseau de mise en cache en périphérie
  • Cas d’usage principaux : Déchargement du contenu statique et réduction de la latence
  • Méthodes de routage : S/O (règles de cache)
  • Sondes d’intégrité : S/O (basculement de groupe d’origines en option)
  • Vitesse de basculement : S/O (basé sur le cache)
  • Accélération dynamique : Non (au-delà du cache)
  • Mise en cache statique : Oui
  • WAF disponible : Via Front Door Premium ou un WAF distinct
  • Modèle typique : CDN pour les ressources + Front Door/Traffic Manager pour les origines

Problème pratique : Conception d’une plateforme web hautement disponible, conforme et performante à l’échelle mondiale pour IronPeak Manufacturing

Scénario : IronPeak Manufacturing opère en Europe et en Amérique du Nord et consolide ses portails clients et partenaires sur Azure. La plateforme doit atteindre une disponibilité de 99,99 % pour le niveau web, conserver les données des clients de l’UE au sein de l’UE, fournir un basculement rapide entre les régions et assurer des temps de chargement de page rapides dans le monde entier. L’équipe souhaite des déploiements entièrement automatisés, sans secrets en texte clair dans le code ou les journaux.

Défi : Atteindre une haute disponibilité intra-régionale et une reprise après sinistre inter-régionale avec une résidence des données dans l’UE, une accélération et un basculement mondiaux pour le trafic dynamique, et des déploiements reproductibles et sécurisés à travers les abonnements.

Approche recommandée :

1. Sélectionner la géographie Europe et déployer la charge de travail principale dans une région dotée d’Availability Zones (par exemple, West Europe) en utilisant deux instances ou plus de VM scale set ou d’App Service réparties entre les zones.
2. Activer la reprise après sinistre inter-régionale vers la région jumelée (North Europe) en utilisant la réplication native des services : utiliser RA-GZRS pour le stockage et la géo-réplication pour les bases de données lorsque disponible ; configurer des runbooks de basculement automatisé.
3. Placer l’application derrière Azure Front Door Standard/Premium pour la terminaison HTTPS globale, le WAF, les sondes de santé en périphérie, le basculement basé sur la priorité entre West Europe (primaire) et North Europe (secondaire), et les règles de routage basé sur le chemin.
4. Mettre en cache les ressources statiques (images, scripts, téléchargements) en utilisant Azure CDN intégré avec les mêmes origines pour réduire la latence et décharger le trafic ; valider les règles de cache et les TTL.
5. Définir des groupes d’administration pour les divisions UE et NA ; placer les abonnements de production et de non-production sous chacun d’eux, en appliquant Azure Policy pour la résidence des données, le balisage et les emplacements autorisés.
6. Mettre en œuvre des modèles ARM/Bicep stockés dans un contrôle de code source et publiés en tant que spécifications de modèle ; paramétrer les régions, les SKU et la mise à l’échelle ; référencer les secrets depuis Azure Key Vault en utilisant des identités managées pour les déploiements.
7. Définir des SLA et tester la disponibilité composite : deux instances réparties sur des zones derrière Front Door ciblent 99,99 % pour la couche applicative ; valider trimestriellement les exercices de basculement de bout en bout, le DNS, les certificats et les dépendances d’identité.
8. Instrumenter la plateforme avec Application Insights et Azure Monitor ; configurer les sondes de santé et les alertes d’Azure Front Door ; ajuster les politiques de mise à l’échelle automatique et de mise en cache en fonction de la télémétrie.

Justification Azure : Cette conception maintient les données de l’UE au sein de la géographie Europe tout en fournissant un isolement des pannes intra-régional via les Availability Zones et une reprise après sinistre inter-régionale vers la région jumelée. Azure Front Door assure une accélération mondiale et un basculement basé sur l’état de santé pour le trafic dynamique, tandis qu’Azure CDN décharge le contenu statique pour améliorer les performances. Les modèles ARM/Bicep avec des références à Key Vault permettent des déploiements reproductibles et sécurisés à travers les abonnements et les régions. Les topologies choisies s’alignent sur les SLA publiés pour atteindre l’objectif de 99,99 % pour le niveau web, et les stratégies au niveau des groupes d’administration et des abonnements assurent la gouvernance avec une surcharge opérationnelle minimale.

← Concepts du Cloud · Tous les domaines · Calcul et services d’application →

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

Parcourir Microsoft →