Microsoft AZ-204: Azure API Management — Lernleitfaden

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

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Azure API Management (APIM) bietet eine einheitliche Fassade für verschiedene Backend-Dienste und kombiniert ein hochleistungsfähiges Gateway mit einer konfigurierbaren Richtlinien-Engine, Entwickler-Onboarding und einer vollständigen Verwaltungsebene. Es ermöglicht konsistente Sicherheits-, Drosselungs-, Transformations-, Beobachtbarkeits- und Lebenszykluskontrollen über REST-, SOAP- und GraphQL-Backends hinweg. APIM ist sowohl ein Laufzeit-Gateway für den Datenverkehr als auch ein konfigurationsgesteuertes System, das Sie über das Azure-Portal, ARM/Bicep/CLI oder CI/CD verwalten. Das Verständnis der Anforderungspipeline, der Richtlinienfunktionen, der Versionierung/Revisionen, des Abonnementmodells und der Merkmale der Tarife ist grundlegend für die Erstellung robuster, sicherer APIs im großen Maßstab.

Architektur, Tarife und Kernkomponenten

Das Gateway ist die Datenebene. Es beendet Client-Verbindungen, wendet Richtlinien in einer deterministischen Reihenfolge an, leitet an Backends weiter und gibt Antworten zurück. Es unterstützt integriertes Caching, JWT-Validierung, Mutual TLS und Inhaltsumwandlung mit Leitungsgeschwindigkeit. Gateways können pro Region von Microsoft gehostet oder selbst gehostet (containerisiert) werden, um näher an On-Premises- oder Edge-Workloads ausgeführt zu werden, während sie zentral verwaltet bleiben. Das Gateway stellt Tracing und Metriken bereit und integriert sich mit Application Insights für verteilte Telemetrie.

Das Entwicklerportal ist die nach außen gerichtete Oberfläche für Erkundung, Dokumentation und Abonnementverwaltung. Es rendert OpenAPI/GraphQL-Dokumentation, bietet interaktive „Ausprobieren“-Konsolen, wickelt OAuth 2.0-Flows im Browser ab und unterstützt benutzerdefiniertes Branding und Identitätsanbieter. Entwickler verwalten hier selbstständig Produktabonnements und rotieren Schlüssel.

Die Verwaltungsebene ist die Konfigurations- und Governance-Oberfläche. Sie speichert APIs, Operationen, Richtlinien, Produkte, Benutzer/Gruppen, Backends, Zertifikate und Diagnosedaten. Sie ist über das Azure-Portal, ARM/Bicep/CLI/PowerShell, die Management REST API und Git-basierte Konfigurationssynchronisierung zugänglich. Diese Ebene orchestriert Bereitstellungen, Versionierung, Revisionen und RBAC.

Die APIM-Tarife bestimmen Skalierung, Funktionen und Netzwerkfähigkeiten:

Consumption ist serverless und wird pro Aufruf abgerechnet. Er skaliert automatisch, ist ideal für Szenarien mit Lastspitzen oder geringem Durchsatz und unterstützt die meisten Kernrichtlinien. Er enthält kein integriertes Antwort-Caching und es fehlen erweiterte Netzwerk- und Multi-Region-Funktionen.
Developer ist für Nicht-Produktionsumgebungen. Er bietet nahezu den vollen Funktionsumfang ohne SLA und ohne den Durchsatz einer Produktionsumgebung.
Basic und Standard sind dedizierte Produktions-Tarife für eine einzelne Region mit vorhersagbarem Durchsatz, Scale-Out-Einheiten und integriertem Antwort-Caching. Sie eignen sich für viele Unternehmens-Workloads, die keine Multi-Region- oder erweiterten Netzwerkfunktionen erfordern.
Premium fügt Multi-Region-Bereitstellung, erweiterte Netzwerkfunktionen (einschließlich VNet-Integration), höhere Skalierung, Verfügbarkeitszonen in unterstützten Regionen und die Lizenzierung für selbst gehostete Gateways hinzu. Wählen Sie Premium für globale, geschäftskritische Bereitstellungen und privates Networking.

Richtlinien und die Anforderungspipeline

APIM-Richtlinien sind deklarative Anweisungen, die in einer strikten Reihenfolge in vier Abschnitten ausgeführt werden: inbound, backend, outbound und on-error.

Inbound-Richtlinien werden ausgeführt, bevor die Anforderung an das Backend weitergeleitet wird. Typische Aufgaben sind das Anfordern oder Validieren von Abonnementschlüsseln, das Validieren von JWTs (Erzwingen von Aussteller, Zielgruppe, Signatur), das Überprüfen von Client-IPs, das Anwenden von Ratenbegrenzungen und Kontingenten, das Normalisieren von Headern, das Umschreiben von URIs und das Transformieren des Payloads. Sie können bedingt an verschiedene Backends weiterleiten und Variablen für spätere Phasen setzen.

Der Backend-Abschnitt konfiguriert und modifiziert den Aufruf an den Upstream-Dienst. Verwenden Sie ihn, um eine Backend-Entität auszuwählen, Client-Anmeldeinformationen anzuhängen (Basic Auth, Client-Zertifikate oder Tokens, die über eine verwaltete Identität für durch Azure AD geschützte Backends bezogen wurden), Timeouts festzulegen, Wiederholungsversuche zu aktivieren und Circuit Breaking anzuwenden. Mutual TLS zum Backend wird hier konfiguriert, indem ein Client-Zertifikat zugeordnet wird, das das Gateway vorweisen wird.

Outbound-Richtlinien werden nach dem Empfang der Backend-Antwort ausgeführt. Sie führen üblicherweise Antworttransformationen (z. B. JSON zu XML oder umgekehrt), das Umschreiben von Headern, Data Shaping, das Maskieren interner Details und das Caching von Antworten durch. Dies ist auch der Ort, um Konvertierungen für die Inhaltsaushandlung (Content Negotiation) anzuwenden oder Statuscodes zu normalisieren.

On-error-Richtlinien werden ausgeführt, wenn in einem der vorherigen Abschnitte, einschließlich des Backend-Aufrufs, eine Ausnahme auftritt. Verwenden Sie diesen Abschnitt, um Backend-Fehler auf standardisierte API-Fehlerformate abzubilden, geeignete Statuscodes zu setzen, sensible Nachrichten zu schwärzen, Korrelations-IDs hinzuzufügen oder Fallback-Antworten bereitzustellen.

Gängige Richtlinienmuster:

Ratenbegrenzung (Rate Limiting) steuert den Burst-Durchsatz und schützt Backends. rate-limit-by-key erzwingt eine Drosselung pro Identität unter Verwendung eines Schlüssels wie Abonnementschlüssel, JWT-Claim oder IP-Adresse. Für längere Zeitfenster kombinieren Sie dies mit quota-by-key, um die tägliche oder monatliche Nutzung zu begrenzen.
IP-Filterung blockiert oder erlaubt Datenverkehr nach Client-IP oder CIDR-Bereichen mithilfe von ip-filter, oft früh im Inbound-Abschnitt positioniert, um Kosten und Angriffsfläche zu minimieren.
JWT-Validierung mit validate-jwt erzwingt OpenID Connect-Parameter. Konfigurieren Sie die OpenID-Konfigurations-URL oder den Aussteller, definieren Sie akzeptierte Zielgruppen/Scopes, wählen Sie erforderliche Claims aus und passen Sie die Uhrenabweichung (Clock Skew) und die Überprüfung der Token-Lebensdauer an. Verweigern Sie anonymen Zugriff, indem Sie ein gültiges Token für alle Operationen fordern, bei denen anonyme Aufrufe nicht erlaubt sind.
Transformation umfasst rewrite-uri, set-header, set-query-parameter, set-body und find-and-replace. Verwenden Sie xml-to-json oder json-to-xml, um nicht übereinstimmende Client-/Backend-Formate ohne Codeänderungen zu überbrücken.
Caching nutzt cache-lookup und cache-store, um ganze Antworten basierend auf Schlüsseln zu cachen, die Pfad, Abfrage, Header und JWT-Claims enthalten können. Verwenden Sie cache-lookup-value/cache-store-value für Key/Value-Caching innerhalb von Richtlinien, beispielsweise zum Cachen von Tokens. Beachten Sie, dass das integrierte Antwort-Caching im Consumption-Tarif nicht verfügbar ist.

Sicherheit, Identität und Abonnements

Sowohl die Sicherheit zwischen Front-End-Client und Gateway als auch die Sicherheit zwischen Back-End-Gateway und Service muss berücksichtigt werden.

Für die Front-End-Sicherheit ist OAuth 2.0 mit Azure AD das vorherrschende Muster. Clients beziehen Tokens von Azure AD und legen sie dem Gateway vor. APIM erzwingt Token-Anforderungen mithilfe von validate-jwt, das auf die OpenID Connect-Metadaten von Azure AD (den well-known-Endpunkt des Mandanten) verweist. Richtlinien können Audience-Prüfungen erzwingen, um sicherzustellen, dass das Token auf die richtige API abzielt, Scope-Claims, um sicherzustellen, dass Aufrufer über die entsprechenden Berechtigungen verfügen, und optionale Claims wie App-Rollen. Um anonyme Aufrufe zu unterbinden, sollte validate-jwt auf alle Operationen angewendet werden. Das Entwicklerportal kann mit Azure AD konfiguriert werden, um den Erwerb von Tokens während des Testens zu vereinfachen.

Für Client-Zertifikate und Mutual TLS kann APIM eingehende Client-Zertifikate von Aufrufern verlangen und dabei Aussteller/Subjekt/Ablaufdatum und optional den CRL/OCSP-Status mithilfe von validate-client-certificate validieren. Dies eignet sich für B2B- und hochsichere Integrationen. Für Gateway-zu-Backend-mTLS laden Sie ein Client-Zertifikat in APIM hoch, verknüpfen es mit einer Backend-Entität oder set-backend-service, und APIM wird es während des TLS-Handshakes zur Authentifizierung am Backend vorlegen. Dieser Ansatz wird oft von gesicherten App Service- oder benutzerdefinierten Diensten gefordert, die eine Zertifikatsauthentifizierung erzwingen.

Für durch Azure AD geschützte Backends verwenden Sie authentication-managed-identity im Backend-Abschnitt, um ein Zugriffstoken mit der system- oder benutzerseitig zugewiesenen verwalteten Identität von APIM zu beziehen. Die Richtlinie fügt den Authorization-Header für den Backend-Aufruf ein. Dies vermeidet die Speicherung von Geheimnissen und erfüllt moderne Zero-Trust-Anforderungen.

Abonnements bieten ein grobkörniges Zugriffs- und Monetarisierungsmodell. Produkte sind Bündel von APIs, die durch Bedingungen, Genehmigungen und Nutzungsgrenzen geregelt werden. Entwickler abonnieren Produkte, um Abonnementschlüssel (primär und sekundär) zu erhalten, die über den Ocp-Apim-Subscription-Key-Header oder einen Abfrageparameter verwendet werden. Dank der dualen Schlüssel können diese ohne Ausfallzeit rotiert werden. Der Geltungsbereich des Abonnements (Subscription Scope) bestimmt, wo die Schlüssel gelten: für alle APIs, eine einzelne API oder ein bestimmtes Produkt. Der abonnementbasierte Zugriff ist komplementär zu OAuth 2.0; beide können erforderlich sein, was eine getrennte Drosselung/Abrechnung ermöglicht, während die Authentifizierung auf Tokens beruht. Produkte können pro Abonnement Kontingente und Ratenbegrenzungen unabhängig von Richtlinien auf Operationsebene durchsetzen, was einen mehrschichtigen Schutz und eine mehrschichtige Governance bietet.

Backends, Resilienz, Versionierung und Revisionen

Backends in APIM sind erstklassige, wiederverwendbare Entitäten, die die Basis-URL, das Protokoll, die Anmeldeinformationen, die TLS-Einstellungen, die Header-Vorlagen und die Proxy-Konfiguration eines Zieldienstes kapseln. Die Verknüpfung von APIs und Operationen mit Backends entkoppelt das Routing von den Richtlinien und zentralisiert die Verbindungsdetails. Verwenden Sie set-backend-service nach Backend-ID in Richtlinien, um Anfragen ohne hartcodierte URLs weiterzuleiten, was die Überführung zwischen den Umgebungen Dev, Test und Prod vereinfacht.

Resilienz wird durch Wiederholungsversuche (Retries) und Circuit Breaking durchgesetzt. Wiederholungsversuche mit exponentiellem Backoff können transiente Fehler abmildern; sie sollten auf idempotente Operationen beschränkt und durch angemessene Timeouts begrenzt sein, um eine Verstärkung zu verhindern. Eine Circuit-Breaker-Richtlinie öffnet sich, wenn die Fehlerrate, aufeinanderfolgende Fehler oder die Latenz konfigurierte Schwellenwerte innerhalb eines Stichprobenfensters überschreiten, und schaltet Anfragen für eine definierte Unterbrechungsdauer kurz. Während des offenen Zustands kann die Richtlinie sofort eine Fallback-Antwort zurückgeben oder an ein Standby-Backend weiterleiten. Im halb-offenen Zustand prüft eine begrenzte Anzahl von Testanfragen die Backend-Integrität, bevor der Kreis wieder geschlossen wird. Dies schützt Backends, verbessert die Client-Erfahrung und stabilisiert Systeme bei Teilausfällen.

Lastenausgleich und Routing können auf der Richtlinienebene implementiert werden. Bedingtes Routing mit choose kann den Datenverkehr nach Benutzersegment, Geografie, Anfrageinhalt oder Integritätssignalen (Health Signals) steuern. Gewichtetes Routing kann durch Richtlinienausdrücke erreicht werden, die pseudozufällig ein Backend entsprechend den gewünschten Gewichtungen auswählen, was Canary Releases und schrittweise Rollouts ermöglicht. Aktiv-Aktiv-Backends über Regionen hinweg können durch eine Multi-Region-Bereitstellung von APIM im Premium-Tarif in Kombination mit bedingtem Routing zur nächstgelegenen fehlerfreien Region realisiert werden; alternativ kann die Integration mit Azure Front Door für globales Layer-7-Load-Balancing erfolgen, während APIM die Authentifizierung und Transformation übernimmt.

Versionierung und Revisionen steuern den API-Lebenszyklus. Versionssätze (Version Sets) definieren, wie mehrere API-Versionen für Clients über ein Versionierungsschema nach Pfad, Abfragezeichenfolge (Query String) oder Header bereitgestellt werden. Verwenden Sie Versionen für Breaking Changes; jede Version ist eine separate API-Entität, die mit demselben Versionssatz verknüpft ist. Nicht-breaking, iterative Änderungen werden als Revisionen implementiert. Eine Revision ist ein veränderbarer Snapshot einer API, der explizit (über das Revisions-Suffix) zum Testen aufgerufen werden kann, während eine frühere Revision die aktuelle Produktionsrevision bleibt. Nach der Validierung wird die neue Revision zur aktuellen Revision befördert, ohne den Versionsbezeichner zu ändern. Diese Trennung ermöglicht eine sichere, progressive Bereitstellung: Revisionen für nicht-breaking Updates; Versionen für Breaking Changes, die durch klare Erkennung und Dokumentation im Entwicklerportal sichtbar gemacht werden.

Schließlich: Überwachen und Steuern (Observe and Govern). Aktivieren Sie Tracing, setzen Sie Korrelations-IDs und exportieren Sie Diagnosedaten nach Application Insights für eine durchgängige Sichtbarkeit (End-to-End Visibility). Verwalten Sie die Konfiguration über ARM/Bicep oder das APIM DevOps Resource Kit, um wiederholbare Bereitstellungen zu erreichen, und wenden Sie RBAC auf der Verwaltungsebene an, um die Aufgaben für API-Autoren, Publisher und Betreiber zu trennen.

Praktisches Problemszenario

Starbucks muss eine einheitliche öffentliche API für mobile Bestellungen bereitstellen, die Microservices aus zwei Azure-Regionen aggregiert. Die API muss anonymen Zugriff blockieren, missbräuchliche Clients drosseln, regionale Backends vor kaskadierenden Ausfällen schützen und die schrittweise Einführung eines v2-Bestellschemas ermöglichen, ohne v1-Clients zu beeinträchtigen.

Stellen Sie eine APIM Premium-Instanz in zwei Regionen bereit und aktivieren Sie die Multi-Region-Bereitstellung. Der Premium-Tarif wird wegen der Gateway-Präsenz in mehreren Regionen, der erweiterten Netzwerkfunktionen und der Skalierbarkeit für Unternehmen gewählt. Regionale Gateways reduzieren die Latenz für mobile Clients und bieten Aktiv-Aktiv-Resilienz.
Importieren Sie die Backend-Dienste als APIM-Backend-Entitäten, einschließlich der App Service-Instanzen in beiden Regionen. Backend-Entitäten zentralisieren Basis-URLs, TLS- und Anmeldeinformationseinstellungen und ermöglichen so saubere Routing-Richtlinien und Portabilität zwischen Umgebungen.
Sichern Sie die Client-zu-Gateway-Verbindung mit Azure AD OAuth 2.0 und erzwingen Sie die Token-Validierung mit validate-jwt im Inbound-Abschnitt. Azure AD bietet zentralisierte Identität, bedingten Zugriff (Conditional Access) und eine starke Token-Validierung. validate-jwt stellt sicher, dass nur authentifizierte Aufrufer mit den korrekten Audiences/Scopes die API aufrufen können.
Fordern Sie Produktabonnements an und geben Sie Abonnement-Schlüssel (Subscription Keys) pro Partner-App aus. Dies fügt eine Governance- und Messungsebene hinzu, die unabhängig von OAuth ist, und ermöglicht partner-spezifische Kontingente, einfache Schlüsselrotation und ein portalbasiertes Self-Service-Onboarding.
Konfigurieren Sie rate-limit-by-key und quota-by-key im Inbound-Abschnitt, geschlüsselt nach dem Subscription Key. Die Drosselung schützt Backends vor Lastspitzen und ermöglicht differenzierte SLAs für Partner. Die Verwendung von Subscription Keys als Unterscheidungsmerkmal richtet die Durchsetzung an den Geschäftsverträgen aus.
Implementieren Sie IP-Filterung, um bekannte bösartige Bereiche zu blockieren und Starbucks-eigene Unternehmensbereiche für die Verwaltung zuzulassen. ip-filter reduziert die Angriffsfläche früh in der Pipeline und schont nachgelagerte Ressourcen.
Konfigurieren Sie gegenseitiges TLS (mTLS) für sensible Dienste, indem Sie Client-Zertifikate in APIM hochladen und sie an die relevanten Backend-Entitäten binden. mTLS bietet eine starke Dienst-zu-Dienst-Authentifizierung, wenn Backends Zertifikate erfordern, und erfüllt so interne Sicherheitsrichtlinien.
Fügen Sie authentication-managed-identity im Backend-Abschnitt für durch Azure AD geschützte Dienste hinzu. Die verwaltete Identität (Managed Identity) von APIM ruft Zugriffstoken für das Backend ab, wodurch Geheimnisse (Secrets) vermieden und die Integration mit Azure RBAC und bedingtem Zugriff (Conditional Access) ermöglicht wird.
Implementieren Sie einen Circuit Breaker mit Wiederholungsversuch (Retry) und Fallback im Backend-Abschnitt. Bei wiederholten Fehlern innerhalb eines Zeitfensters öffnen Sie den Kreis und leiten Anfragen an das fehlerfreie regionale Backend weiter; wenn beide ausgefallen sind, geben Sie eine standardisierte, zwischengespeicherte Fallback-Antwort zurück. Dies schützt beeinträchtigte Dienste und sorgt für ein vorhersagbares Verhalten bei Ausfällen.
Verwenden Sie bedingtes Routing, um Lesezugriffe auf die nächstgelegene Region zu verteilen und bei Integritätssignalen (Health Signals) ein Failover durchzuführen. Richtlinienausdrücke wählen die lokale Region aus, indem sie einen benutzerdefinierten Header oder die IP-Geolokalisierung prüfen; Health Probes füllen Variablen für Routing-Entscheidungen. Dies sorgt für niedrige Latenz und Kontinuität bei regionalen Vorfällen.
Führen Sie einen Versionssatz (Version Set) für die Orders-API mit pfadbasierter Versionierung (/v1, /v2) ein. Erstellen Sie eine neue Revision von v2 zum Testen, validieren Sie diese mit ausgewählten Clients durch Aufruf der revisionsspezifischen URL und befördern Sie sie dann zur aktuellen Revision. Versionssätze kommunizieren Breaking Changes sauber, während Revisionen eine sichere, nicht-breaking Iteration ermöglichen.
Aktivieren Sie das Response Caching für leselastige Endpunkte (Menü/Katalog) im Outbound-Abschnitt mit cache-lookup und cache-store, variierend nach Locale und Gerätetyp. Caching entlastet die Backends von wiederholten Abrufen und verbessert die mobile Performance; der Premium-Tarif unterstützt diese Funktionen in großem Maßstab.

Dieses Design liefert authentifizierte, gedrosselte, resiliente und erweiterbare APIs. APIM Premium stellt das globale, sichere Gateway bereit; Richtlinien erzwingen Identität, Drosselung, Transformation und Resilienz; Backend-Entitäten und verwaltete Identitäten (Managed Identities) sichern und entkoppeln Verbindungen; Versionssätze und Revisionen bieten einen disziplinierten Lebenszyklus für Continuous Delivery ohne Unterbrechung für die Clients.

← Azure-Authentifizierung · Alle Domänen · Azure: Ereignis- und nachrichtenbasierte Lösungen →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →