You read an AZ-305 scenario, and both options in the answer choices are gateways. Decide from the job the requirement assigns. API lifecycle jobs, such as products, subscriptions, API keys, quotas, policies, and a developer portal, point to Azure API Management. HTTP edge jobs, such as web application firewall (WAF) inspection, TLS termination, and URL or host routing, point to Azure Application Gateway. When the scenario needs both jobs, Microsoft's documented pattern is an Application Gateway with WAF in front of an internal API Management instance.
The exam measures this decision directly. The current study guide lists "Recommend a solution for API integration" as a task under Design an application architecture, in the Design infrastructure solutions domain, which is 30-35% of the exam (skills measured as of April 17, 2026) (AZ-305 study guide). The English version of the exam was updated on April 17, 2026, so recheck the study guide before you book (AZ-305 exam page).
The cues that pick the service
The scenario's wording does the work. Match each requirement to a job, and the job names the service.
- If the scenario lists products, subscriptions, developer onboarding, API keys, JWT or certificate checks, quotas, rate limits, caching, or transformations, it is API Management.
- If it lists WAF, TLS termination, listener rules, path or host routing, or a regional entry point for HTTP(S) traffic, it is Application Gateway.
- If external clients must reach only some APIs while the API platform itself stays private, it is Application Gateway in front of an internal API Management instance.
- If the scenario needs global edge routing or quick global failover, the comparison moves to Azure Front Door. The Application Gateway overview points there when global routing of web traffic is the goal.
What API Management owns
Microsoft describes API Management as an API gateway, a management plane, and a developer portal, all Azure-hosted and fully managed by default (API Management key concepts).
All requests from a client first reach the gateway, which accepts the calls and routes them to the appropriate backends. The gateway acts as a facade to those backends. It verifies API keys and other credentials such as JWTs and certificates presented with requests, enforces usage quotas and rate limits, optionally transforms requests and responses as policy specifies, caches responses when configured, and emits logs, metrics, and traces for monitoring and troubleshooting.
Policies are the key exam clue. API Management provides more than 75 policies out of the box to address scenarios such as authentication, rate limiting, caching, and transformation of requests or responses (how policies work). Policies are runtime rules executed inside the gateway. They apply between the API consumer and the managed API, and a policy can change both the inbound request and the outbound response. The source's example list includes transforming from XML to JSON and rate limiting to restrict the calls from a developer. If an answer choice must validate a JWT, throttle a partner, or transform a payload, that is policy work.
The management plane handles the configuration work. You use it to define or import API schemas from a range of sources, package APIs into products, set policies such as quotas or transformations, get insights from analytics, and manage users such as app developers. If the scenario wants partner onboarding, self-service, or usage reporting, that is the management plane doing the work.
The developer portal is the onboarding cue. It is an automatically generated, fully customizable website with the documentation of your APIs. Consumers use it to read API documentation, call an API via the interactive console, create an account and subscribe to get API keys, access analytics on their own usage, download API definitions, and manage API keys. None of that is part of Application Gateway's documented role.
What Application Gateway owns
Application Gateway operates at the application layer, OSI layer 7, and makes routing decisions on HTTP request attributes such as URL paths and host headers. Traditional load balancers route on IP address and port. It provides SSL/TLS termination, autoscaling, and zone redundancy, and it integrates with Web Application Firewall (Application Gateway overview).
The scope is regional. Microsoft's API protection reference architecture says to deploy one Application Gateway per region because Application Gateway is a regional service (Protect APIs with Application Gateway and API Management). When a scenario needs global routing or quick global failover, the overview points to Azure Front Door instead.
In an API scenario, those details define the perimeter. If the scenario says to expose only /external/* from a private API platform, inspect internet requests with WAF before they reach the API gateway, terminate TLS at the regional entry point, or route portal and API hostnames through different listeners, the work belongs to Application Gateway.
The reference architecture shows the boundary in place. External clients connect through the internet to Application Gateway, which includes a WAF. Application Gateway routes the traffic to API Management, and API Management connects to the backend services. The architecture uses URL patterns so external API calls reach the permitted APIs. Calls that are not permitted go to a sinkpool, a back-end pool with no target, and a routing rule sends portal traffic to the developer portal.
WAF on Application Gateway actively safeguards web applications against common exploits and vulnerabilities such as SQL injection and cross-site scripting. The WAF features exist in a WAF policy, and you can associate a policy with an application gateway, with individual listeners, or with path-based routing rules, which lets you define separate policies for each site (WAF on Application Gateway).
The combined pattern when the scenario needs both
Application Gateway handles the regional HTTP(S) perimeter, and API Management handles API behavior and governance. That split is the pattern Microsoft documents for a private API platform with selective public exposure.
You configure API Management in a virtual network in internal mode, which makes it accessible only within the virtual network. In front of it, Application Gateway acts as a Layer-7 load balancer and reverse proxy that provides WAF. By combining the two, one API Management resource serves both internal and external consumers, a subset of the APIs is available to external consumers, and you get a turnkey way to switch public access on and off (integrate API Management with an internal virtual network and Application Gateway).
The diagram shows the combined placement. Notice which service each requirement lands on. AZ-305 tests where the responsibility belongs, not every subnet, DNS record, or certificate.
Choose the combination when the requirements include private API hosting, selective public exposure, WAF, and shared API governance. Choose API Management alone when public API governance is enough and the scenario does not ask for WAF or regional listener routing. Choose Application Gateway alone when the workload needs edge routing and WAF and the API lifecycle is handled elsewhere or is out of scope.
The networking options vary by tier. The networking guide lists virtual network injection for the classic Developer and Premium tiers, virtual network integration for the Standard v2 and Premium v2 tiers, and inbound private endpoints across the Developer, Basic, Standard, Standard v2, Premium, and Premium v2 tiers (virtual network concepts). For the exam, the question is whether the design isolates the API gateway, the backend APIs, or both.
The decision in one table
| API Management | Application Gateway | |
|---|---|---|
| What it is | An API gateway with a management plane and a developer portal | A layer 7 load balancer for HTTP(S) traffic |
| The job it takes | API lifecycle. Products, subscriptions, keys, quotas, policies, portal | HTTP edge. WAF, TLS termination, URL and host routing |
| Where it sits | In front of the backend APIs, public or in an internal virtual network | In front of other services, one gateway per region |
| The scenario cue | "Partners need docs, keys, and throttling" | "Internet requests need WAF inspection" |
| Verdict | Pick it when the scenario assigns API lifecycle work | Pick it when the scenario assigns HTTP edge work |
Worked scenario: the partner inventory API
A retailer exposes an inventory API to partner marketplaces and internal warehouse apps. The 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 their clients.
Three decisions, each driven by a different requirement.
First, the API product behavior belongs to API Management. Subscription approval, keys, throttling, products, documentation, and analytics are all API lifecycle requirements.
Second, the public and private edge belongs to Application Gateway. Two requirements drive it. Only one URL family may be reachable from the internet, and internet requests need WAF inspection. Application Gateway sits in front of the internal API Management instance, routes the allowed paths to it, and sends the disallowed paths to a sinkpool.
Third, backend evolution stays behind the API facade. API Management presents a stable partner-facing API while it routes and transforms the backend calls. The partner product, the subscriptions, and the onboarding flow all map to API Management's documented components. Application Gateway's documented role is edge routing and protection.
The answer assembles into four parts. Deploy API Management as the API facade and governance layer for the partner and internal consumers. Place Application Gateway with WAF in front of API Management for external HTTPS entry and URL-based exposure. Keep the private backends behind API Management. Publish the partner documentation and subscription flow through the developer portal.
What the wrong answer reveals
- Picking 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 routes and protects HTTP traffic. The products, subscriptions, and portal live in API Management.
- Picking API Management when the scenario only asks for WAF, TLS termination, and host or path routing usually means you weighted the word "API" heavier than the perimeter requirement. With no API lifecycle requirement in the stem, Application Gateway alone is sufficient.
- Picking API Management alone for a private deployment that must selectively expose APIs publicly misses the edge boundary. Microsoft documents Application Gateway in front of internal API Management for exactly this public and private split.
- Picking both for every API is also a mistake. Each extra service adds certificates, DNS, health probes, cost, and failure points. Use the combination when the requirements demand both layers.
Four questions that decide the API integration answer
Run these on every API integration scenario before you commit to an answer.
- Does the scenario assign API lifecycle work, such as products, subscriptions, documentation, keys, quotas, analytics, or transformations?
- Does it assign HTTP edge work, such as WAF, TLS termination, listeners, or URL and host routing?
- Is the API platform itself private, with only selected APIs exposed to the internet?
- Is the scale global edge routing? If yes, the comparison moves to Front Door.
If you keep getting the same kind of question wrong, start with the free AZ-305 assessment. It is free, needs no card, and returns a Readiness Report with your top gaps (free AZ-305 assessment). For each wrong answer, write one sentence naming the two responsibilities you confused. "I confused API lifecycle work with HTTP edge work." Fix that boundary, then work the nearby scenarios again. The AZ-305 Pass Plan is the core of the product: a ranked list of targeted repair tasks, each aimed at a gap you keep showing on API integration questions. As you work more scenarios, CramHQ finds new gaps, prices each one in exam points, and orders the plan so your costliest gap gets the top task. The practice tests and the timed final simulation sit beside the list to check your readiness as you work through it. The paid path costs US$34.99 for 12 months of access, and your first repair task is free (AZ-305 course).