Microsoft AZ-204: Gestion des API Azure — Guide d'étude

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

Vue d’ensemble

Azure API Management (APIM) fournit une façade unifiée sur des services backend divers, combinant une passerelle haute performance avec un moteur de stratégies configurable, l’intégration des développeurs et un plan de gestion complet. Il permet d’appliquer des contrôles cohérents de sécurité, de limitation de débit (throttling), de transformation, d’observabilité et de cycle de vie sur des backends REST, SOAP et GraphQL. APIM est à la fois une passerelle d’exécution pour le trafic et un système piloté par la configuration que vous gérez via le portail Azure, ARM/Bicep/CLI ou CI/CD. Comprendre le pipeline de requêtes, les capacités des stratégies, le versioning/révisions, le modèle d’abonnement et les caractéristiques des niveaux de service est fondamental pour construire des API robustes et sécurisées à grande échelle.

Architecture, Niveaux de service et Composants principaux

La passerelle est le plan de données (data plane). Elle termine les connexions des clients, applique les stratégies dans un ordre déterministe, route vers les backends et renvoie les réponses. Elle prend en charge la mise en cache intégrée, la validation JWT, le TLS mutuel et la transformation de contenu à la vitesse du réseau (line rate). Les passerelles peuvent être hébergées par Microsoft par région ou auto-hébergées (conteneurisées) pour s’exécuter plus près des charges de travail sur site (on-premises) ou en périphérie (edge) tout en restant gérées de manière centralisée. La passerelle expose le traçage et les métriques, et s’intègre avec Application Insights pour la télémétrie distribuée.

Le portail des développeurs est l’expérience destinée aux consommateurs pour la découverte, la documentation et la gestion des abonnements. Il affiche la documentation OpenAPI/GraphQL, fournit des consoles interactives « try it », gère les flux OAuth 2.0 dans le navigateur, et prend en charge la personnalisation de l’image de marque (branding) et les fournisseurs d’identité. Les développeurs y gèrent en libre-service leurs abonnements aux produits et renouvellent leurs clés.

Le plan de gestion est la surface de configuration et de gouvernance. Il stocke les API, les opérations, les stratégies, les produits, les utilisateurs/groupes, les backends, les certificats et les diagnostics. Il est accessible via le portail Azure, ARM/Bicep/CLI/PowerShell, l’API REST de gestion et la synchronisation de configuration basée sur Git. Ce plan orchestre les déploiements, le versioning, les révisions et le RBAC.

Les niveaux de service (tiers) d’APIM déterminent la mise à l’échelle, les fonctionnalités et les capacités réseau :

Consommation (Consumption) est serverless et facturé à l’appel. Il se met à l’échelle automatiquement, est idéal pour les scénarios à trafic en pics ou à faible débit, et prend en charge la plupart des stratégies de base. Il n’inclut pas de mise en cache de réponse intégrée et ne dispose pas des fonctionnalités réseau avancées ni multi-régions.
Développeur (Developer) est destiné à la non-production. Il offre une fonctionnalité quasi complète sans SLA et sans le débit à l’échelle de la production.
De base (Basic) et Standard sont des niveaux de production dédiés, mono-région, avec un débit prévisible, des unités de mise à l’échelle (scale-out) et une mise en cache de réponse intégrée. Ils sont adaptés à de nombreuses charges de travail d’entreprise qui ne nécessitent pas de déploiement multi-région ou de fonctionnalités réseau avancées.
Premium ajoute le déploiement multi-région, des fonctionnalités réseau avancées (y compris l’intégration VNet), une mise à l’échelle supérieure, les zones de disponibilité dans les régions prises en charge, et la licence pour les passerelles auto-hébergées. Choisissez Premium pour les déploiements mondiaux, critiques et les réseaux privés.

Stratégies et Pipeline de requêtes

Les stratégies APIM sont des déclarations qui s’exécutent dans un ordre strict au sein de quatre sections : inbound (entrante), backend, outbound (sortante) et on-error (en cas d’erreur).

Les stratégies inbound s’exécutent avant que la requête ne soit transmise au backend. Les tâches typiques incluent l’exigence ou la validation des clés d’abonnement, la validation des JWT (en forçant l’émetteur, l’audience, la signature), la vérification des IP clientes, l’application de limites de débit et de quotas, la normalisation des en-têtes, la réécriture des URI et la transformation du corps de la requête (payload). Vous pouvez router conditionnellement vers différents backends et définir des variables pour les étapes ultérieures.

La section backend configure et modifie l’appel au service en amont. Utilisez-la pour sélectionner une entité backend, joindre des informations d’identification du client (authentification de base, certificats clients ou jetons acquis via une identité managée pour les backends protégés par Azure AD), définir des délais d’attente (timeouts), activer les nouvelles tentatives (retries) et appliquer le patron de conception disjoncteur (circuit breaking). Le TLS mutuel vers le backend est configuré ici en associant un certificat client que la passerelle présentera.

Les stratégies outbound s’exécutent après la réception de la réponse du backend. Elles effectuent couramment des transformations de réponse (par ex., JSON vers XML ou vice versa), la réécriture d’en-têtes, le formatage des données (data shaping), le masquage de détails internes et la mise en cache de la réponse. C’est aussi l’endroit où appliquer des conversions de négociation de contenu ou normaliser les codes de statut.

Les stratégies on-error s’exécutent si une exception se produit dans n’importe quelle section précédente, y compris l’appel au backend. Utilisez cette section pour mapper les erreurs du backend à des formats d’erreur d’API standardisés, définir des codes de statut appropriés, expurger les messages sensibles, ajouter des ID de corrélation ou fournir des réponses de secours (fallback).

Patrons de stratégies courants :

La limitation de débit (rate limiting) contrôle le débit en rafale et protège les backends. rate-limit-by-key applique une limitation par identité en utilisant une clé telle que la clé d’abonnement, une revendication (claim) JWT ou l’adresse IP. Pour des fenêtres de temps plus longues, combinez-la avec quota-by-key pour plafonner l’utilisation journalière ou mensuelle.
Le filtrage IP bloque ou autorise le trafic par IP cliente ou plages CIDR en utilisant ip-filter, souvent positionné au début de la section inbound pour minimiser les coûts et l’exposition.
La validation JWT avec validate-jwt applique les paramètres OpenID Connect. Configurez l’URL de configuration OpenID ou l’émetteur, définissez les audiences/scopes acceptés, sélectionnez les revendications (claims) requises, et ajustez la tolérance d’horloge (clock skew) et les vérifications de durée de vie du jeton. Refusez l’accès anonyme en exigeant un jeton valide pour toutes les opérations où les appels anonymes ne sont pas autorisés.
La transformation inclut rewrite-uri, set-header, set-query-parameter, set-body et find-and-replace. Utilisez xml-to-json ou json-to-xml pour faire le pont entre des formats client/backend incompatibles sans modifier le code.
La mise en cache s’appuie sur cache-lookup et cache-store pour mettre en cache des réponses complètes en se basant sur des clés qui peuvent inclure le chemin, la requête, les en-têtes et les revendications JWT. Utilisez cache-lookup-value/cache-store-value pour la mise en cache clé/valeur au sein des stratégies, comme pour la mise en cache de jetons. Notez que la mise en cache de réponse intégrée n’est pas disponible dans le niveau Consommation.

Sécurité, identité et abonnements

La sécurité front-end du client vers la passerelle et la sécurité back-end de la passerelle vers le service doivent toutes deux être prises en compte.

Pour la sécurité front-end, OAuth 2.0 avec Azure AD est le modèle dominant. Les clients acquièrent des jetons auprès d’Azure AD et les présentent à la passerelle. APIM applique les exigences relatives aux jetons en utilisant validate-jwt qui référence les métadonnées OpenID Connect d’Azure AD (le point de terminaison well-known du locataire). Les stratégies peuvent imposer des vérifications d’audience (audience checks) pour s’assurer que le jeton cible la bonne API, des revendications de portée (scope claims) pour garantir que les appelants disposent des autorisations appropriées, et des revendications facultatives telles que les rôles d’application (app roles). Pour éliminer les appels anonymes, validate-jwt doit être appliqué à toutes les opérations. Le portail des développeurs peut être configuré avec Azure AD pour simplifier l’acquisition de jetons pendant les tests.

Pour les certificats clients et le TLS mutuel (mTLS), APIM peut exiger des certificats clients entrants de la part des appelants, en validant l’émetteur/sujet/l’expiration et éventuellement le statut CRL/OCSP à l’aide de validate-client-certificate. Ceci est adapté aux intégrations B2B et à haute assurance. Pour le mTLS de la passerelle vers le backend, téléchargez un certificat client dans APIM, associez-le à une entité backend ou à set-backend-service, et APIM le présentera lors de la poignée de main TLS pour s’authentifier auprès du backend. Cette approche est souvent requise par les services App Service sécurisés ou les services personnalisés qui imposent une authentification par certificat.

Pour les backends protégés par Azure AD, utilisez authentication-managed-identity dans la section backend pour acquérir un jeton d’accès avec l’identité managée assignée par le système ou par l’utilisateur d’APIM. La stratégie injecte l’en-tête Authorization pour l’appel backend. Cela évite de stocker des secrets et répond aux exigences modernes du zero-trust (confiance nulle).

Les abonnements fournissent un modèle d’accès et de monétisation à granularité grossière. Les produits sont des ensembles d’API régis par des conditions, une approbation et des limites d’utilisation. Les développeurs s’abonnent aux produits pour obtenir des clés d’abonnement (principale et secondaire) utilisées via l’en-tête Ocp-Apim-Subscription-Key ou un paramètre de requête. Les clés peuvent être renouvelées sans interruption de service grâce aux doubles clés. La portée de l’abonnement détermine où les clés s’appliquent : toutes les API, une seule API ou un produit spécifique. L’accès basé sur l’abonnement est complémentaire à OAuth 2.0 ; les deux peuvent être requis, permettant une limitation (throttling) et une comptabilisation distinctes tandis que l’authentification repose sur les jetons. Les produits peuvent appliquer des quotas et des limites de débit par abonnement, indépendamment des stratégies par opération, offrant une protection et une gouvernance à plusieurs niveaux.

Back-ends, Résilience, Gestion des versions et Révisions

Dans APIM, les back-ends sont des entités réutilisables de première classe qui encapsulent l’URL de base d’un service cible, le protocole, les informations d’identification, les paramètres TLS, les modèles d’en-tête et la configuration du proxy. Associer des API et des opérations à des back-ends découple le routage des stratégies et centralise les détails de connexion. Utilisez set-backend-service par ID de back-end dans les stratégies pour router les requêtes sans coder en dur les URL, ce qui simplifie la promotion d’environnement entre dev, test et prod.

La résilience est assurée par des tentatives de réessai et des disjoncteurs. Les tentatives de réessai avec backoff exponentiel peuvent atténuer les défaillances transitoires ; elles doivent être limitées aux opérations idempotentes et encadrées par des délais d’attente raisonnables pour éviter l’amplification. Une stratégie de disjoncteur s’ouvre lorsque le taux d’échec, les échecs consécutifs ou la latence dépassent les seuils configurés dans une fenêtre d’échantillonnage, court-circuitant les requêtes pour une durée de coupure définie. Pendant l’état ouvert, la stratégie peut retourner immédiatement une réponse de repli ou router vers un back-end de secours. En état semi-ouvert, un nombre limité de requêtes d’essai sonde la santé du back-end avant de fermer le circuit. Cela protège les back-ends, améliore l’expérience client et stabilise les systèmes en cas de défaillance partielle.

L’équilibrage de charge et le routage peuvent être implémentés au niveau de la couche des stratégies. Le routage conditionnel avec choose peut diriger le trafic par segment d’utilisateur, géographie, contenu de la requête ou signaux de santé. Le routage pondéré peut être réalisé par des expressions de stratégie qui sélectionnent de manière pseudo-aléatoire un back-end selon les poids souhaités, permettant les canary releases et les déploiements progressifs. Les back-ends actif-actif entre régions peuvent être gérés par un déploiement APIM multi-régions de niveau Premium combiné à un routage conditionnel vers la région saine la plus proche ; alternativement, intégrez avec Azure Front Door pour un équilibrage de charge global de couche 7 pendant qu’APIM gère l’authentification et la transformation.

La gestion des versions et les révisions gouvernent le cycle de vie des API. Les ensembles de versions définissent comment plusieurs versions d’API sont présentées aux clients à l’aide d’un schéma de versioning par chemin, chaîne de requête ou en-tête. Utilisez les versions pour les changements cassants ; chaque version est une entité API distincte associée au même ensemble de versions. Les changements itératifs non cassants sont implémentés en tant que révisions. Une révision est un snapshot modifiable d’une API qui peut être invoquée explicitement (via le suffixe de révision) pour les tests pendant qu’une révision antérieure reste la révision de production actuelle. Après validation, promouvez la nouvelle révision comme version actuelle sans changer l’identifiant de version. Cette séparation permet une livraison progressive et sûre : les révisions pour les mises à jour non cassantes ; les versions pour les changements cassants, présentées via une découverte et une documentation claires dans le portail des développeurs.

Enfin, observez et gouvernez. Activez le traçage, définissez des ID de corrélation et exportez les diagnostics vers Application Insights pour une visibilité de bout en bout. Gérez la configuration via ARM/Bicep ou le APIM DevOps Resource Kit pour obtenir des déploiements reproductibles, et appliquez le RBAC sur le plan de gestion pour séparer les responsabilités des auteurs, des éditeurs et des opérateurs d’API.

Scénario de problème pratique

Starbucks doit exposer une API publique unifiée pour la commande mobile qui agrège des microservices répartis sur deux régions Azure. L’API doit bloquer l’accès anonyme, limiter les clients abusifs, protéger les back-ends régionaux des défaillances en cascade et permettre un déploiement progressif d’un schéma de commande v2 sans casser les clients v1.

Mettez en place une instance APIM Premium dans deux régions et activez le déploiement multi-régions. Le niveau Premium est choisi pour la présence de passerelles multi-régions, les fonctionnalités réseau avancées et la mise à l’échelle d’entreprise. Les passerelles régionales réduisent la latence pour les clients mobiles et fournissent une résilience actif-actif.
Importez les services back-end en tant qu’entités back-end APIM, y compris les instances App Service dans les deux régions. Les entités back-end centralisent les URL de base, les paramètres TLS et les informations d’identification, permettant des stratégies de routage claires et la portabilité des environnements.
Sécurisez la communication client-passerelle avec Azure AD OAuth 2.0 et appliquez la validation des jetons en utilisant validate-jwt dans la section inbound. Azure AD fournit une identité centralisée, un accès conditionnel et une validation forte des jetons. validate-jwt garantit que seuls les appelants authentifiés avec les audiences/scopes corrects peuvent invoquer l’API.
Exigez des abonnements aux produits et délivrez des clés d’abonnement par application partenaire. Cela ajoute une couche de gouvernance et de mesure indépendante d’OAuth et permet des quotas par partenaire, une rotation facile des clés et une intégration en libre-service via le portail.
Configurez rate-limit-by-key et quota-by-key dans la section inbound, en utilisant la clé d’abonnement comme identifiant. La limitation de débit protège les back-ends des pics de charge et permet des SLA différenciés pour les partenaires. L’utilisation des clés d’abonnement comme discriminateur aligne l’application des règles sur les contrats commerciaux.
Implémentez le filtrage IP pour bloquer les plages d’adresses malveillantes connues et autoriser les plages d’adresses de l’entreprise Starbucks pour l’administration. ip-filter réduit la surface d’attaque tôt dans le pipeline et économise les ressources en aval.
Configurez le TLS mutuel (mTLS) du back-end pour les services sensibles en téléchargeant des certificats clients dans APIM et en les liant aux entités back-end pertinentes. Le mTLS fournit une authentification forte de service à service lorsque les back-ends exigent des certificats, satisfaisant ainsi les politiques de sécurité internes.
Ajoutez authentication-managed-identity dans la section back-end pour les services protégés par Azure AD. L’identité managée d’APIM acquiert des jetons d’accès pour le back-end, ce qui supprime les secrets et s’intègre avec Azure RBAC et l’accès conditionnel.
Implémentez un disjoncteur avec tentatives de réessai et solution de repli dans la section back-end. En cas d’échecs répétés dans une fenêtre de temps, ouvrez le circuit et routez les requêtes vers le back-end régional sain ; si les deux sont en panne, retournez une réponse de repli standardisée et mise en cache. Cela protège les services dégradés et assure un comportement prévisible en cas de défaillance.
Utilisez le routage conditionnel pour équilibrer la charge des lectures vers la région la plus proche et basculer en fonction des signaux de santé. Les expressions de stratégie sélectionnent la région locale en inspectant un en-tête personnalisé ou la géolocalisation IP ; les sondes de santé remplissent des variables pour les décisions de routage. Cela assure une faible latence et une continuité de service pendant les incidents régionaux.
Introduisez un ensemble de versions pour l’API des commandes avec un versioning basé sur le chemin (/v1, /v2). Créez une nouvelle révision de la v2 pour les tests, validez-la avec des clients sélectionnés en invoquant l’URL spécifique à la révision, puis promouvez-la comme version actuelle. Les ensembles de versions communiquent clairement les changements cassants, tandis que les révisions permettent une itération sûre et non cassante.
Activez la mise en cache des réponses pour les points de terminaison à forte lecture (menu/catalogue) dans la section outbound avec cache-lookup et cache-store, en variant selon la locale et le type d’appareil. La mise en cache décharge les back-ends des requêtes répétées et améliore les performances mobiles ; le niveau Premium prend en charge ces fonctionnalités à grande échelle.

Cette conception fournit des API authentifiées, limitées en débit, résilientes et évolutives. APIM Premium fournit la passerelle globale et sécurisée ; les stratégies appliquent l’identité, la limitation de débit,

← Authentification · Tous les domaines · Solutions basées sur les événements et la messagerie Azure →

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