Microsoft AZ-204: Azure API Management — Studiegids

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

Onderdeel van de Microsoft Azure Developer Associate AZ-204 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Azure API Management (APIM) biedt een uniforme façade over diverse backend-services en combineert een high-performance gateway met een configureerbare policy-engine, onboarding van ontwikkelaars en een volledig beheervlak. Het maakt consistente beveiliging, throttling, transformatie, observeerbaarheid en lifecycle-beheer mogelijk voor REST-, SOAP- en GraphQL-backends. APIM is zowel een runtime-gateway voor verkeer als een configuratiegestuurd systeem dat u beheert via de Azure-portal, ARM/Bicep/CLI of CI/CD. Het begrijpen van de request-pipeline, de mogelijkheden van policies, versiebeheer/revisies, het abonnementsmodel en de kenmerken van de tiers is fundamenteel voor het bouwen van robuuste, veilige API’s op schaal.

Architectuur, Tiers en Kerncomponenten

De gateway is het datavlak. Deze beëindigt clientverbindingen, past policies toe in een deterministische volgorde, routeert naar backends en retourneert responses. Het ondersteunt ingebouwde caching, JWT-validatie, mutual TLS en contenttransformatie op lijnsnelheid. Gateways kunnen per regio door Microsoft worden gehost of zelf-gehost (gecontaineriseerd) zijn om dichter bij on-premises of edge-workloads te draaien, terwijl ze centraal beheerd blijven. De gateway stelt tracing en metrics beschikbaar en integreert met Application Insights voor gedistribueerde telemetrie.

Het ontwikkelaarsportaal is de interface voor de consument voor discovery, documentatie en abonnementsbeheer. Het rendert OpenAPI/GraphQL-documentatie, biedt interactieve ’try it’-consoles, handelt OAuth 2.0-flows af in de browser en ondersteunt aangepaste branding en identity providers. Ontwikkelaars beheren hier via selfservice productabonnementen en rouleren sleutels.

Het beheervlak is de interface voor configuratie en governance. Het slaat API’s, operations, policies, producten, gebruikers/groepen, backends, certificaten en diagnostische gegevens op. Het is toegankelijk via de Azure-portal, ARM/Bicep/CLI/PowerShell, de Management REST API en configuratiesynchronisatie op basis van Git. Dit vlak orkestreert implementaties, versiebeheer, revisies en RBAC.

De APIM-tiers bepalen de schaal, functies en netwerkmogelijkheden:

Consumption is serverless en wordt per aanroep gefactureerd. Het schaalt automatisch, is ideaal voor scenario’s met pieken of lage doorvoer en ondersteunt de meeste kern-policies. Het bevat geen ingebouwde response-caching en mist geavanceerde netwerk- en multi-region-functies.
Developer is voor niet-productie. Het biedt bijna volledige functionaliteit zonder SLA en zonder doorvoer op productieschaal.
Basic en Standard zijn dedicated, single-region productietiers met voorspelbare doorvoer, scale-out-eenheden en ingebouwde response-caching. Ze zijn geschikt voor veel enterprise-workloads die geen multi-region of geavanceerde netwerkmogelijkheden vereisen.
Premium voegt multi-region implementatie, geavanceerde netwerkmogelijkheden (inclusief VNet-integratie), hogere schaal, availability zones in ondersteunde regio’s en licenties voor self-hosted gateways toe. Kies Premium voor wereldwijde, missiekritieke implementaties en private networking.

Policies en de Request-Pipeline

APIM-policies zijn declaratieve statements die in een strikte volgorde worden uitgevoerd in vier secties: inbound, backend, outbound en on-error.

Inbound-policies worden uitgevoerd voordat de aanvraag wordt doorgestuurd naar de backend. Typische taken zijn het vereisen of valideren van abonnementssleutels, het valideren van JWT’s (afdwingen van issuer, audience, signature), het controleren van client-IP’s, het toepassen van rate limits en quota’s, het normaliseren van headers, het herschrijven van URI’s en het transformeren van de payload. U kunt conditioneel routeren naar verschillende backends en variabelen instellen voor latere stadia.

De backend-sectie configureert en wijzigt de aanroep naar de upstream-service. Gebruik deze om een backend-entiteit te selecteren, client-credentials toe te voegen (Basic auth, clientcertificaten of tokens verkregen via managed identity voor met Azure AD beveiligde backends), time-outs in te stellen, retries in te schakelen en circuit breaking toe te passen. Mutual TLS naar de backend wordt hier geconfigureerd door een clientcertificaat te koppelen dat de gateway zal presenteren.

Outbound-policies worden uitgevoerd na het ontvangen van de response van de backend. Ze voeren doorgaans responstransformaties uit (bijv. JSON naar XML of vice versa), herschrijven van headers, data shaping, het afschermen van interne details en response-caching. Dit is ook de plek om conversies voor content negotiation toe te passen of om statuscodes te normaliseren.

On-error-policies worden uitgevoerd als er een exceptie optreedt in een van de eerdere secties, inclusief de backend-aanroep. Gebruik deze sectie om backendfouten te mappen naar gestandaardiseerde API-foutstructuren, de juiste statuscodes in te stellen, gevoelige berichten te redigeren, correlatie-ID’s toe te voegen of terugvalreacties te bieden.

Veelvoorkomende policy-patronen:

Rate limiting beheert de burst-doorvoer en beschermt backends. rate-limit-by-key dwingt een per-identiteit throttle af met behulp van een sleutel zoals een abonnementssleutel, JWT-claim of IP-adres. Voor langere perioden, combineer dit met quota-by-key om het dagelijkse of maandelijkse gebruik te maximeren.
IP-filtering blokkeert of staat verkeer toe op basis van client-IP of CIDR-ranges met behulp van ip-filter, vaak vroeg in de inbound-sectie geplaatst om kosten en blootstelling te minimaliseren.
JWT-validatie met validate-jwt dwingt OpenID Connect-parameters af. Configureer de OpenID-configuratie-URL of issuer, definieer geaccepteerde audiences/scopes, selecteer vereiste claims en pas de controles voor klokafwijking en levensduur van het token aan. Weiger anonieme toegang door een geldig token te vereisen voor alle operaties waar anonieme aanroepen niet zijn toegestaan.
Transformatie omvat rewrite-uri, set-header, set-query-parameter, set-body en find-and-replace. Gebruik xml-to-json of json-to-xml om een brug te slaan tussen niet-overeenkomende client/backend-formaten zonder code te wijzigen.
Caching maakt gebruik van cache-lookup en cache-store om volledige responses te cachen op basis van sleutels die het pad, de query, headers en JWT-claims kunnen bevatten. Gebruik cache-lookup-value/cache-store-value voor key/value-caching binnen policies, zoals het cachen van tokens. Let op: ingebouwde response-caching is niet beschikbaar in de Consumption-tier.

Beveiliging, Identiteit en Abonnementen

Zowel de front-end beveiliging (client-naar-gateway) als de back-end beveiliging (gateway-naar-service) moeten worden aangepakt.

Voor front-end beveiliging is OAuth 2.0 met Azure AD het dominante patroon. Clients verkrijgen tokens van Azure AD en presenteren deze aan de gateway. APIM dwingt tokenvereisten af met validate-jwt, die verwijst naar de Azure AD OpenID Connect-metadata (het ‘well-known endpoint’ van de tenant). Policies kunnen ‘audience checks’ afdwingen om te garanderen dat het token voor de juiste API bedoeld is, ‘scope claims’ om te verzekeren dat aanroepers de juiste permissies hebben, en optionele claims zoals ‘app roles’. Om anonieme aanroepen te elimineren, moet validate-jwt worden toegepast op alle operations. Het developer portal kan worden geconfigureerd met Azure AD om het verkrijgen van tokens tijdens het testen te vereenvoudigen.

Voor clientcertificaten en mutual TLS (mTLS) kan APIM inkomende clientcertificaten van aanroepers vereisen. Hierbij worden de issuer/subject/vervaldatum en optioneel de CRL/OCSP-status gevalideerd met validate-client-certificate. Dit is geschikt voor B2B- en high-assurance-integraties. Voor gateway-naar-backend mTLS upload je een clientcertificaat naar APIM, koppel je het aan een backend-entiteit of set-backend-service, en APIM zal het presenteren tijdens de TLS-handshake om te authenticeren bij de backend. Deze aanpak is vaak vereist door beveiligde App Service- of custom services die certificaatauthenticatie afdwingen.

Voor backends die met Azure AD zijn beveiligd, gebruik je authentication-managed-identity in de backend-sectie om een access token te verkrijgen met de ‘system-assigned’ of ‘user-assigned’ managed identity van APIM. De policy injecteert de Authorization-header voor de backend-aanroep. Dit voorkomt het opslaan van secrets en voldoet aan de moderne zero-trust-vereisten.

Abonnementen (Subscriptions) bieden een grofmazig model voor toegang en monetisatie. Products zijn bundels van API’s die worden beheerd door voorwaarden, goedkeuring en gebruikslimieten. Ontwikkelaars abonneren zich op products om abonnementssleutels (subscription keys - primair en secundair) te verkrijgen, die worden gebruikt via de Ocp-Apim-Subscription-Key-header of een queryparameter. Sleutels kunnen zonder downtime worden geroteerd dankzij de dubbele sleutels. De scope van het abonnement bepaalt waar de sleutels van toepassing zijn: alle API’s, een enkele API of een specifiek product. Toegang op basis van abonnementen is complementair aan OAuth 2.0; beide kunnen vereist zijn, wat afzonderlijke throttling/accounting mogelijk maakt, terwijl de authenticatie afhankelijk is van tokens. Products kunnen quota’s en rate limits per abonnement afdwingen, onafhankelijk van policies per operation. Dit zorgt voor gelaagde bescherming en governance.

Backends, Veerkracht, Versiebeheer en Revisies

Backends in APIM zijn eersteklas, herbruikbare entiteiten die de basis-URL, het protocol, de credentials, TLS-instellingen, header-templates en proxyconfiguratie van een doelservice inkapselen. Door API’s en operaties te koppelen aan backends wordt routering losgekoppeld van beleidsregels en worden verbindingsdetails gecentraliseerd. Gebruik set-backend-service met een backend-ID in beleidsregels om verzoeken te routeren zonder URL’s hard te coderen, wat de promotie tussen dev-, test- en prod-omgevingen vereenvoudigt.

Veerkracht wordt afgedwongen met retries en circuit breaking. Retries met exponentiële backoff kunnen tijdelijke storingen verhelpen; ze moeten beperkt worden tot idempotente operaties en begrensd worden door redelijke timeouts om amplificatie te voorkomen. Een circuit breaker-beleid wordt geactiveerd (opent) wanneer het foutpercentage, het aantal opeenvolgende fouten of de latentie de geconfigureerde drempels binnen een sample-venster overschrijdt, waardoor verzoeken gedurende een vastgestelde onderbrekingsduur worden kortgesloten. In de open toestand kan het beleid onmiddellijk een fallback-respons retourneren of routeren naar een standby-backend. In de half-open toestand peilt een beperkt aantal proefverzoeken de gezondheid van de backend voordat het circuit wordt gesloten. Dit beschermt backends, verbetert de klantervaring en stabiliseert systemen bij gedeeltelijke storingen.

Load balancing en routering kunnen op de beleidslaag worden geïmplementeerd. Conditionele routering met choose kan verkeer sturen op basis van gebruikerssegment, geografie, inhoud van het verzoek of gezondheidssignalen. Gewogen routering kan worden bereikt met beleidsexpressies die pseudowillekeurig een backend selecteren op basis van de gewenste gewichten, wat canary releases en geleidelijke uitrol mogelijk maakt. Actief-actieve backends verspreid over regio’s kunnen worden aangepakt met een Premium-tier multi-region APIM-implementatie in combinatie met conditionele routering naar de dichtstbijzijnde gezonde regio; als alternatief kan men integreren met Azure Front Door voor globale layer 7 load balancing, terwijl APIM de authenticatie en transformatie afhandelt.

Versiebeheer en revisies sturen de levenscyclus van een API. Versiesets definiëren hoe meerdere API-versies aan clients worden aangeboden via een versieschema op basis van pad, query string of header. Gebruik versies voor breaking changes; elke versie is een afzonderlijke API-entiteit die aan dezelfde versieset is gekoppeld. Non-breaking, iteratieve wijzigingen worden geïmplementeerd als revisies. Een revisie is een muteerbare snapshot van een API die expliciet kan worden aangeroepen (via het revisie-achtervoegsel) voor testdoeleinden, terwijl een eerdere revisie de huidige productierevisie blijft. Na validatie promoveer je de nieuwe revisie naar de huidige versie zonder de versie-identifier te wijzigen. Deze scheiding maakt veilige, progressieve levering mogelijk: revisies voor non-breaking updates; versies voor breaking changes, die duidelijk vindbaar en gedocumenteerd zijn in de developer portal.

Tot slot, observeer en beheer. Schakel tracing in, stel correlatie-ID’s in en exporteer diagnostische gegevens naar Application Insights voor end-to-end zichtbaarheid. Beheer de configuratie via ARM/Bicep of de APIM DevOps Resource Kit om herhaalbare implementaties te realiseren, en pas RBAC toe op het beheervlak om taken te scheiden voor API-auteurs, -uitgevers en -operators.

Praktijkscenario

Starbucks moet een uniforme publieke API voor mobiele bestellingen beschikbaar stellen die microservices uit twee Azure-regio’s samenvoegt. De API moet anonieme toegang blokkeren, misbruik makende clients afremmen (throttling), regionale backends beschermen tegen cascaderende storingen en een geleidelijke uitrol van een v2-orderschema mogelijk maken zonder v1-clients te verstoren.

Zet een APIM Premium-instantie op in twee regio’s en schakel multi-region implementatie in. Premium wordt gekozen vanwege de multi-region gateway-aanwezigheid, geavanceerde netwerkmogelijkheden en enterprise-schaal. Regionale gateways verminderen de latentie voor mobiele clients en bieden actief-actieve veerkracht.
Importeer de backend-services als APIM backend-entiteiten, inclusief de App Service-instanties in beide regio’s. Backend-entiteiten centraliseren basis-URL’s, TLS- en credential-instellingen, wat schone routeringsbeleidsregels en portabiliteit van omgevingen mogelijk maakt.
Beveilig de client-naar-gateway-verbinding met Azure AD OAuth 2.0 en dwing het gebruik van tokens af met validate-jwt in de inbound-sectie. Azure AD biedt gecentraliseerde identiteit, Conditional Access en sterke tokenvalidatie. validate-jwt zorgt ervoor dat alleen geauthenticeerde bellers met de juiste audiences/scopes de API kunnen aanroepen.
Vereis productabonnementen en geef abonnementssleutels (subscription keys) uit per partner-app. Dit voegt een governance- en meetlaag toe die onafhankelijk is van OAuth en maakt quota per partner, eenvoudige sleutelrotatie en via de portal gebaseerde self-service onboarding mogelijk.
Configureer rate-limit-by-key en quota-by-key in de inbound-sectie, met de abonnementssleutel als key. Throttling beschermt backends tegen pieken en maakt gedifferentieerde SLA’s voor partners mogelijk. Het gebruik van abonnementssleutels als discriminator stemt de handhaving af op zakelijke contracten.
Implementeer IP-filtering om bekende kwaadaardige IP-reeksen te blokkeren en de eigen bedrijfsreeksen van Starbucks toe te staan voor administratie. ip-filter verkleint het aanvalsoppervlak vroeg in de pipeline en bespaart downstream resources.
Configureer wederzijdse TLS (mTLS) voor de backend voor gevoelige services door clientcertificaten te uploaden naar APIM en deze te koppelen aan de relevante backend-entiteiten. mTLS biedt sterke service-naar-service-authenticatie waar backends certificaten vereisen, en voldoet zo aan interne beveiligingsbeleidsregels.
Voeg authentication-managed-identity toe in de backend-sectie voor services die door Azure AD worden beschermd. De managed identity van APIM verkrijgt toegangstokens voor de backend, waardoor geheimen worden geëlimineerd en integratie met Azure RBAC en Conditional Access mogelijk wordt.
Implementeer een circuit-breaker met retry en fallback in de backend-sectie. Bij herhaalde fouten binnen een tijdvenster, open het circuit en routeer verzoeken naar de gezonde regionale backend; als beide uitvallen, retourneer dan een gestandaardiseerde, gecachte fallback-respons. Dit beschermt overbelaste services en zorgt voor voorspelbaar gedrag bij storingen.
Gebruik conditionele routering om leesoperaties te load-balancen naar de dichtstbijzijnde regio en voor failover op basis van gezondheidssignalen. Beleidsexpressies selecteren de lokale regio door een aangepaste header of IP-geolocatie te inspecteren; health probes vullen variabelen voor routeringsbeslissingen. Dit zorgt voor lage latentie en continuïteit tijdens regionale incidenten.
Introduceer een versieset voor de Orders API met op pad gebaseerd versiebeheer (/v1, /v2). Maak een nieuwe revisie van v2 voor testdoeleinden, valideer deze met geselecteerde clients door de revisie-specifieke URL aan te roepen en promoveer deze vervolgens naar de huidige versie. Versiesets communiceren breaking changes op een duidelijke manier, terwijl revisies veilige, non-breaking iteratie mogelijk maken.
Schakel response caching in voor lees-intensieve endpoints (menu/catalogus) in de outbound-sectie met cache-lookup en cache-store, variërend per locale en apparaattype. Caching ontlast backends van herhaalde ophaalacties en verbetert de mobiele prestaties; Premium ondersteunt deze functies op grote schaal.

Dit ontwerp levert geauthenticeerde, afgeremde, veerkrachtige en evolueerbare API’s. APIM Premium biedt de globale, veilige gateway; beleidsregels dwingen identiteit, throttling, transformatie en veerkracht af; backend-entiteiten en managed identities beveiligen en ontkoppelen verbindingen; versiesets en revisies zorgen voor een gedisciplineerde levenscyclus voor continuous delivery zonder verstoring voor clients.

← Azure Authenticatie · Alle domeinen · Azure Event-gebaseerde en Berichtenoplossingen →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →