API Management vs Application Gateway: What AZ-305 Expects

For AZ-305 API integration scenarios, choose Azure API Management when the requirement is API lifecycle control: publishing APIs, enforcing policies, validating credentials, applying quotas or rate limits, transforming requests and responses, exposing a developer portal, and managing subscriptions. Choose Azure Application Gateway when the requirement is regional HTTP(S) edge control: URL or host-based routing, TLS termination, Web Application Firewall, and controlled entry into private web or API backends. In many real designs, the answer is not either/or: Application Gateway with WAF can front an internal API Management instance while API Management remains the API product and policy layer.

That distinction matters for the current AZ-305 blueprint because Microsoft lists Design infrastructure solutions at 30-35% and includes Recommend a solution for API integration under Design an application architecture (AZ-305 study guide). The English exam page also says the exam was updated on April 17, 2026 and measures infrastructure design along with identity, data, continuity, and monitoring design (AZ-305 exam page).

Decision Shortcut

• Need products, subscriptions, developer onboarding, API keys, JWT or certificate checks, quotas, rate limits, caching, transformations, analytics, or version-friendly API exposure: start with API Management.
• Need WAF, TLS termination, listener rules, path or host routing, and a regional entry point for HTTP(S) traffic: start with Application Gateway.
• Need external clients to reach only some APIs while the API gateway stays private: use Application Gateway in front of internal API Management.
• Need global edge acceleration or global HTTP(S) failover: compare Azure Front Door separately. Do not turn this article into a generic load-balancing choice.

A Small Placement Diagram

The diagram is intentionally small: AZ-305 usually tests where the responsibility belongs, not every subnet, DNS record, or certificate.

What API Management Owns

Azure API Management is made up of an API gateway, a management plane, and a developer portal (API Management key concepts). The API gateway acts as a facade to backend services, routes calls to backends, verifies API keys and other credentials, enforces quotas and rate limits, can transform requests and responses, can cache responses, and emits logs and metrics for troubleshooting (API Management key concepts).

That makes API Management the stronger AZ-305 answer when the scenario talks about API consumers, partner onboarding, subscription keys, API products, versioning, request transformation, developer self-service, usage analytics, or centralized API governance. Microsoft describes the management plane as the place to define or import API schemas, package APIs into products, set policies such as quotas or transformations, view analytics, and manage users (API Management key concepts).

Policies are the key exam clue. Microsoft says API Management policies run on API requests or responses and can address scenarios such as authentication, rate limiting, caching, and transformation. Policies execute inside the gateway between the API consumer and the managed API, and can change inbound requests or outbound responses (API Management policies). If an answer choice needs to validate a JWT, throttle a partner, convert XML to JSON, rewrite headers, or apply product-specific quotas, Application Gateway is not the API lifecycle tool.

The developer portal is another clue. Microsoft describes it as an automatically generated, customizable site where API consumers can read API documentation, call APIs from an interactive console, create an account, subscribe to get API keys, view their own usage analytics, download API definitions, and manage API keys (API Management key concepts). Application Gateway does not replace that.

What Application Gateway Owns

Azure Application Gateway is a web traffic load balancer for HTTP(S) applications. Microsoft says it makes routing decisions based on HTTP request attributes such as URL paths and host headers, operates at OSI layer 7, and provides SSL/TLS termination, autoscaling, zone redundancy, and WAF integration (Application Gateway overview).

For this article, do not read that as a generic load-balancing fact. Read it as an API edge boundary. If the scenario says, "Expose only /external/* from a private API platform," "inspect internet requests with WAF before they hit the API gateway," "terminate TLS at the regional entry point," or "route portal and API hostnames through listeners," Application Gateway becomes relevant.

Microsoft's API protection reference architecture shows exactly that kind of boundary. External clients connect to Application Gateway with WAF, Application Gateway routes traffic to API Management, and API Management connects to backend services. The same architecture uses URL patterns so external API calls can reach permitted APIs while other paths go to a sinkpool, and it can route portal traffic separately (Protect APIs with Application Gateway and API Management).

Application Gateway WAF is also source-backed, not just a buzzword. Microsoft says WAF on Application Gateway safeguards web applications against common exploits such as SQL injection and cross-site scripting, and WAF policies can be associated with an application gateway, listeners, or path-based routing rules (WAF on Application Gateway).

When AZ-305 Expects Both

The clean combined pattern is: Application Gateway handles the regional HTTP(S) perimeter; API Management handles API behavior and governance.

Microsoft's internal-VNet integration guide says API Management can be configured in an internal virtual network so it is reachable only inside the virtual network, while Application Gateway acts as a Layer 7 reverse proxy with WAF. Combining the two can let one API Management resource serve internal and external consumers, expose only a subset of APIs externally, and provide a way to turn public access on or off (API Management with internal VNet and Application Gateway).

That is the most AZ-305-friendly way to avoid a false choice. Choose both when the requirements include private API hosting plus public selective exposure, WAF, shared API governance, and separate internal/external paths. Choose only API Management when public API governance is enough and the scenario does not ask for WAF or regional listener routing. Choose only Application Gateway when the workload is a web/API endpoint that needs edge routing and WAF, but the API lifecycle features are handled elsewhere or not required.

Networking tier details matter, but avoid overfitting. Microsoft notes that API Management networking options vary by tier and include virtual network injection, virtual network integration, and inbound private endpoints (API Management virtual network concepts). For AZ-305, focus on whether the design isolates the API gateway, the backend APIs, or both.

Worked Example: Partner Inventory API

Scenario:

A retailer exposes an inventory API to partner marketplaces and internal warehouse apps. Requirements:

• Partners need documentation, subscription approval, keys, and throttling.
• Internal warehouse apps must use the same API contract.
• Only /partner/* should be reachable from the internet.
• Internet requests need WAF inspection.
• Backend services run in AKS and App Service inside a private network.
• The team wants to change backend versions without forcing partners to update clients immediately.

First decision: API product behavior belongs to API Management. Subscription approval, keys, throttling, API products, docs, analytics, and request or response policy are API Management signals.

Second decision: the public/private edge belongs to Application Gateway. The scenario is not just "publish an API." It says only one URL family should be externally reachable and that internet requests need WAF inspection. Application Gateway can sit in front of an internal API Management instance and route allowed paths while sending disallowed paths to a dead end.

Third decision: backend evolution stays behind the API facade. API Management can present a stable partner-facing API while routing, transforming, or versioning backend calls through policy and API configuration. Application Gateway should not be used as the substitute for API products, subscriptions, or developer onboarding.

A concise AZ-305 answer would be: deploy API Management as the API facade and governance layer for partner and internal consumers; place Application Gateway with WAF in front of API Management for external HTTPS entry and URL-based exposure; keep private backends behind API Management; publish partner docs and subscription flow through the API Management developer portal.

What Wrong Answers Usually Reveal

Choosing Application Gateway when the scenario asks for subscription keys, quotas, products, or a developer portal usually means you matched the word "gateway" instead of the responsibility. Application Gateway is useful at the HTTP(S) edge, but it is not an API management platform.

Choosing API Management when the scenario only asks for WAF, TLS termination, and host/path routing usually means you over-weighted "API" and under-weighted the perimeter requirement. If there is no API lifecycle or policy clue, Application Gateway may be sufficient.

Choosing only API Management for a private internal deployment that must selectively expose public APIs usually misses the edge boundary. Microsoft explicitly documents Application Gateway in front of internal API Management for this kind of public/private access split.

Choosing both for every API is also a mistake. Extra services add certificates, probes, DNS, cost, and failure points. Use the combination because requirements demand both layers.

Study This Without Memorizing A Matrix

Use four questions:

1. Is the requirement about API consumers: products, subscriptions, docs, keys, quotas, analytics, versioning, transformations, or developer onboarding?
2. Is the requirement about the HTTP(S) perimeter: WAF, TLS termination, listeners, URL routing, host routing, or private regional ingress?
3. Is the API gateway itself supposed to be private, with only selected APIs published externally?
4. Is the scenario really about global edge routing? If yes, compare Front Door separately instead of forcing Application Gateway into a global role.

CramHQ can help turn misses on this topic into a targeted learning loop: identify whether the wrong answer came from API lifecycle, policy enforcement, developer onboarding, WAF/edge routing, or private exposure; then use focused remediation, lessons, and nearby practice instead of rereading the whole infrastructure domain. CramHQ is independent exam-preparation software, not a Microsoft product and not a pass guarantee.

When you are ready to test the boundary, take the AZ-305 assessment. On each miss, write one sentence: "I chose the wrong service because I confused ____ with ____." That is the fastest way to separate API gateway behavior from application edge routing.

Quick Recap

Use API Management for API lifecycle, policies, products, subscriptions, developer portal, API keys, quotas, transformations, and analytics. Use Application Gateway for regional HTTP(S) entry, WAF, TLS termination, URL or host routing, and controlled access to private web or API backends. Use both when an internal API Management instance needs a WAF-protected regional front door that exposes only selected APIs externally. For AZ-305, the answer is the service boundary that matches the requirement, not the word "gateway."