Microsoft AZ-204: Azure API Management — Study Guide

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

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure API Management (APIM) provides a unified façade over diverse backend services, combining a high-performance gateway with a configurable policy engine, developer onboarding, and a full management plane. It enables consistent security, throttling, transformation, observability, and lifecycle controls across REST, SOAP, and GraphQL backends. APIM is both a runtime gateway for traffic and a configuration-driven system you manage via the Azure portal, ARM/Bicep/CLI, or CI/CD. Understanding the request pipeline, policy capabilities, versioning/revisions, subscription model, and tier characteristics is fundamental to building robust, secure APIs at scale.

Architecture, Tiers, and Core Components

The gateway is the data plane. It terminates client connections, applies policies in a deterministic order, routes to backends, and returns responses. It supports built-in caching, JWT validation, mutual TLS, and content transformation at line rate. Gateways can be Microsoft-hosted per region or self-hosted (containerized) to run closer to on-premises or edge workloads while remaining centrally managed. The gateway exposes tracing and metrics and integrates with Application Insights for distributed telemetry.

The developer portal is the consumer-facing experience for discovery, documentation, and subscription management. It renders OpenAPI/GraphQL documentation, provides interactive “try it” consoles, handles OAuth 2.0 flows in-browser, and supports custom branding and identity providers. Developers self-serve product subscriptions and rotate keys here.

The management plane is the configuration and governance surface. It stores APIs, operations, policies, products, users/groups, backends, certificates, and diagnostics. It is accessible via the Azure portal, ARM/Bicep/CLI/PowerShell, the Management REST API, and Git-based configuration sync. This plane orchestrates deployments, versioning, revisions, and RBAC.

APIM tiers determine scale, features, and network capabilities:

Consumption is serverless and billed per call. It auto-scales, is ideal for spiky/low-throughput scenarios, and supports most core policies. It does not include built-in response caching and lacks advanced networking and multi-region features.
Developer is for non-production. It offers nearly full feature functionality without an SLA and without production-scale throughput.
Basic and Standard are dedicated, single-region production tiers with predictable throughput, scale-out units, and built-in response caching. They are suitable for many enterprise workloads that do not require multi-region or advanced networking.
Premium adds multi-region deployment, advanced networking (including VNet integration), higher scale, availability zones in supported regions, and self-hosted gateway licensing. Choose Premium for global, mission-critical deployments and private networking.

Policies and the Request Pipeline

APIM policies are declarative statements that execute in a strict order across four sections: inbound, backend, outbound, and on-error.

Inbound policies run before the request is forwarded to the backend. Typical tasks include requiring or validating subscription keys, validating JWTs (enforcing issuer, audience, signature), checking client IPs, applying rate limits and quotas, normalizing headers, rewriting URIs, and transforming the payload. You can route conditionally to different backends and set variables for later stages.

The backend section configures and modifies the call to the upstream service. Use it to select a backend entity, attach client credentials (Basic auth, client certificates, or tokens acquired via managed identity for Azure AD–protected backends), set timeouts, enable retries, and apply circuit breaking. Mutual TLS to the backend is configured here by associating a client certificate the gateway will present.

Outbound policies run after receiving the backend response. They commonly perform response transformations (e.g., JSON to XML or vice versa), header rewriting, data shaping, masking internal details, and response caching. This is also the place to apply content negotiation conversions or to normalize status codes.

On-error policies execute if an exception occurs in any earlier section, including the backend call. Use this section to map backend errors to standardized API error shapes, set appropriate status codes, redact sensitive messages, add correlation IDs, or provide fallback responses.

Common policy patterns:

Rate limiting controls burst throughput and protects backends. rate-limit-by-key enforces a per-identity throttle using a key such as subscription key, JWT claim, or IP. For longer windows, combine with quota-by-key to cap daily or monthly usage.
IP filtering blocks or allows traffic by client IP or CIDR ranges using ip-filter, often positioned early in inbound to minimize cost and exposure.
JWT validation with validate-jwt enforces OpenID Connect parameters. Configure the OpenID configuration URL or issuer, define accepted audiences/scopes, select required claims, and tune clock skew and token lifetime checks. Deny anonymous access by requiring a valid token for all operations where anonymous calls are not allowed.
Transformation includes rewrite-uri, set-header, set-query-parameter, set-body, and find-and-replace. Use xml-to-json or json-to-xml to bridge mismatched client/backend formats without changing code.
Caching leverages cache-lookup and cache-store to cache whole responses based on keys that can include path, query, headers, and JWT claims. Use cache-lookup-value/cache-store-value for key/value caching within policies, such as caching tokens. Note that built-in response caching is not available in the Consumption tier.

Security, Identity, and Subscriptions

Front-end client-to-gateway security and back-end gateway-to-service security must both be addressed.

For front-end security, OAuth 2.0 with Azure AD is the dominant pattern. Clients acquire tokens from Azure AD and present them to the gateway. APIM enforces token requirements using validate-jwt referencing the Azure AD OpenID Connect metadata (the tenant’s well-known endpoint). Policies can enforce audience checks to ensure the token targets the correct API, scope claims to ensure callers have appropriate permissions, and optional claims such as app roles. To eliminate anonymous calls, validate-jwt should be applied to all operations. The developer portal can be configured with Azure AD to simplify token acquisition during testing.

For client certificates and mutual TLS, APIM can require inbound client certificates from callers, validating issuer/subject/expiry and optionally CRL/OCSP status using validate-client-certificate. This is suitable for B2B and high-assurance integrations. For gateway-to-backend mTLS, upload a client certificate to APIM, associate it with a backend entity or set-backend-service, and APIM will present it during TLS handshake to authenticate to the backend. This approach is often required by secured App Service or custom services enforcing certificate auth.

For Azure AD–protected backends, use authentication-managed-identity in the backend section to acquire an access token with the APIM system-assigned or user-assigned managed identity. The policy injects the Authorization header for the backend call. This avoids storing secrets and satisfies modern zero-trust requirements.

Subscriptions provide a coarse-grained access and monetization model. Products are bundles of APIs governed by terms, approval, and usage limits. Developers subscribe to products to obtain subscription keys (primary and secondary) used via Ocp-Apim-Subscription-Key header or a query parameter. Keys can be rotated without downtime thanks to dual keys. Subscription scope determines where keys apply: all APIs, a single API, or a specific product. Subscription-based access is complementary to OAuth 2.0; both can be required, enabling separate throttling/accounting while authentication relies on tokens. Products can enforce per-subscription quotas and rate limits independent of per-operation policies, providing layered protection and governance.

Backends, Resilience, Versioning, and Revisions

Backends in APIM are first-class, reusable entities that encapsulate a target service’s base URL, protocol, credentials, TLS settings, header templates, and proxy configuration. Associating APIs and operations with backends decouples routing from policies and centralizes connection details. Use set-backend-service by backend ID in policies to route requests without hard-coding URLs, simplifying environment promotion across dev, test, and prod.

Resilience is enforced with retries and circuit breaking. Retries with exponential backoff can mitigate transient failures; they should be scoped to idempotent operations and bounded by reasonable timeouts to prevent amplification. A circuit breaker policy opens when failure rate, consecutive failures, or latency exceed configured thresholds within a sampling window, short-circuiting requests for a defined break duration. During the open state, the policy can immediately return a fallback response or route to a standby backend. When half-open, a limited number of trial requests probes backend health before closing the circuit. This protects backends, improves client experience, and stabilizes systems under partial failure.

Load balancing and routing can be implemented at the policy layer. Conditional routing with choose can direct traffic by user segment, geography, request content, or health signals. Weighted routing can be achieved by policy expressions that pseudorandomly select a backend according to desired weights, enabling canary releases and gradual rollouts. Active-active backends across regions can be addressed by Premium-tier multi-region APIM deployment combined with conditional routing to the closest healthy region; alternatively, integrate with Azure Front Door for global layer 7 load balancing while APIM handles auth and transformation.

Versioning and revisions govern API lifecycle. Version sets define how multiple API versions are surfaced to clients using a versioning scheme of path, query string, or header. Use versions for breaking changes; each version is a separate API entity associated with the same version set. Non-breaking, iterative changes are implemented as revisions. A revision is a mutable snapshot of an API that can be invoked explicitly (via the revision suffix) for testing while an earlier revision remains the current production revision. After validation, promote the new revision to current without changing the version identifier. This separation enables safe, progressive delivery: revisions for non-breaking updates; versions for breaking changes, surfaced through clear discovery and documentation in the developer portal.

Finally, observe and govern. Enable tracing, set correlation IDs, and export diagnostics to Application Insights for end-to-end visibility. Manage the configuration via ARM/Bicep or the APIM DevOps Resource Kit to achieve repeatable deployments, and apply RBAC on the management plane to separate duties for API authors, publishers, and operators.

Practical Problem Scenario

Starbucks must expose a unified public API for mobile ordering that aggregates microservices across two Azure regions. The API must block anonymous access, throttle abusive clients, protect regional backends from cascading failures, and allow gradual rollout of a v2 order schema without breaking v1 clients.

Stand up an APIM Premium instance in two regions and enable multi-region deployment. Premium is selected for multi-region gateway presence, advanced networking, and enterprise scale. Regional gateways reduce latency for mobile clients and provide active-active resilience.
Import the backend services as APIM backend entities, including the App Service instances in both regions. Backend entities centralize base URLs, TLS, and credential settings, enabling clean routing policies and environment portability.
Secure client-to-gateway with Azure AD OAuth 2.0 and enforce tokens using validate-jwt in the inbound section. Azure AD provides centralized identity, conditional access, and strong token validation. validate-jwt ensures only authenticated callers with correct audiences/scopes can invoke the API.
Require product subscriptions and issue subscription keys per partner app. This adds a governance and metering layer independent of OAuth and allows per-partner quotas, easy key rotation, and portal-based self-service onboarding.
Configure rate-limit-by-key and quota-by-key in inbound, keyed by subscription key. Throttling protects backends from spikes and enables differentiated SLAs for partners. Using subscription keys as the discriminator aligns enforcement with business contracts.
Implement IP filtering to block known malicious ranges and allow Starbucks-owned corporate ranges for administration. ip-filter reduces attack surface early in the pipeline and saves downstream resources.
Configure backend mutual TLS for sensitive services by uploading client certificates to APIM and binding them to the relevant backend entities. mTLS provides strong service-to-service authentication where backends require certificates, satisfying internal security policies.
Add authentication-managed-identity in the backend section for Azure AD–protected services. APIM’s managed identity acquires access tokens for the backend, removing secrets and integrating with Azure RBAC and conditional access.
Implement a circuit-breaker with retry and fallback in the backend section. On repeated failures within a time window, open the circuit and route requests to the healthy regional backend; if both are down, return a standardized, cached fallback response. This protects degraded services and delivers predictable behavior under failure.
Use conditional routing to load balance reads to the nearest region and fail over on health signals. Policy expressions select the local region by inspecting a custom header or IP geolocation; health probes populate variables for routing decisions. This provides low latency and continuity during regional incidents.
Introduce a version set for the Orders API with path-based versioning (/v1, /v2). Create a new revision of v2 for testing, validate with select clients by invoking the revision-specific URL, then promote it to current. Version sets communicate breaking changes cleanly, while revisions enable safe, non-breaking iteration.
Enable response caching for read-heavy endpoints (menu/catalog) in the outbound section with cache-lookup and cache-store, varying by locale and device type. Caching offloads repeated fetches from backends and improves mobile performance; Premium supports these features at scale.

This design delivers authenticated, throttled, resilient, and evolvable APIs. APIM Premium provides the global, secure gateway; policies enforce identity, throttling, transformation, and resilience; backend entities and managed identities secure and decouple connections; version sets and revisions provide a disciplined lifecycle for continuous delivery without client disruption.

← Azure Authentication · All domains · Azure Event-Based and Message Solutions →

Practice these questions → · Timed practice on ExamRoll.io →