AZ-305 Practice Question 39: Partner API Exposure
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 4 · question 9 of 10
A logistics company wants to expose 40 internal REST APIs to about 200 partner developers. The design must provide:
- one hostname and one consistent URL scheme in front of backends that are spread across App Service, Azure Functions, and virtual machines, all of which must stay unreachable from the internet, - a per-partner credential and enforced call quotas and rate limits, - validation of Microsoft Entra ID-issued JWTs, and response transformation for two legacy XML backends, - a self-service site where partner developers read the documentation, obtain keys, and try calls.
Which service should you place in front of the backends?
Show answer and explanation
Answer:
API Management is made up of a gateway, a management plane, and a developer portal, and each requirement maps onto one of them. The gateway acts as a facade to the backend services, verifies API keys and other credentials such as JWTs and certificates, enforces usage quotas and rate limits, and optionally transforms requests and responses through policies, including XML-to-JSON conversion. Products and subscriptions give each partner its own key and its own limits, and the developer portal lets consumers read documentation, subscribe for keys, and call APIs from an interactive console. Tiers with virtual network integration or injection keep the backends private.
Option A is a global edge service. Front Door accelerates and protects HTTP traffic, but it has no concept of subscriptions, API keys, per-consumer quotas, or a developer portal, and its rules engine does not perform XML transformation or JWT validation policies.
Option B is a regional layer 7 load balancer. Path-based routing would put the 40 APIs behind one address, and everything else on the list (keys, quotas, JWT validation, transformation, documentation portal) is outside what Application Gateway does.
Option D rebuilds a managed platform as application code. The company would own authentication, throttling, key issuance, documentation, versioning, and its own scaling and patching, and every one of those is a policy or a built-in feature in the managed service.