Azure AZ-204 API Management Guide

This lesson covers the API gateway lane Microsoft expects developers to know: how APIs are published, grouped, protected, and transformed through Azure API Management. On the exam, the hardest part is usually not naming API Management. It is separating gateway concerns from backend concerns, and separating products, subscriptions, policies, and authentication without mixing them together.

API product: Grouping in API Management that bundles APIs, policies, and subscription behavior for consumers.

Policy: Rule that changes or validates API traffic behavior at the gateway layer.

What Azure is really testing here

Microsoft is usually testing whether you can tell which problem belongs at the API gateway and which one belongs in the app or identity layer.

• Use API Management when the question is about publishing APIs, protecting them consistently, applying transformations, throttling access, or exposing a developer-facing gateway.
• Use products when the question is about packaging APIs for consumers and controlling how consumers subscribe.
• Use policies when the question is about changing request or response behavior at the gateway without changing backend code.
• Use identity and app code when the question is really about application authorization logic, not gateway traffic handling.

Fast API Management chooser

Products, subscriptions, and policies are not the same thing

    flowchart LR
	  A["Client app"] --> B["API Management gateway"]
	  B --> C{"What does the stem want?"}
	  C -->|Package APIs for consumers| D["Product"]
	  C -->|Grant keyed access| E["Subscription"]
	  C -->|Transform, validate, throttle, cache, route| F["Policy"]
	  C -->|Run business logic| G["Backend service"]

How strong AZ-204 answers usually reason

1. Decide whether the problem is at the gateway or in the backend app.
2. If it is a gateway problem, decide whether it is about consumer packaging, access, or traffic behavior.
3. Choose product for packaging, subscription for keyed access, and policy for runtime enforcement or transformation.
4. Keep application authentication and authorization separate unless the stem explicitly combines them with gateway policy.

Common traps

Harder scenario question

A team exposes the same backend through one public partner API and one internal mobile API. Partners need quota limits and approval-based access. Internal apps need different transformations and no partner-facing onboarding experience. The strongest first design is to publish the APIs through API Management, separate them with the right products or API scopes, and apply policies at the scope that matches the traffic behavior you need.

Decision order that usually wins

1. Separate managed API publishing, gateway behavior changes, and consumer-facing packaging.
2. If the problem is publishing APIs behind a managed gateway with subscriptions and policies, think API Management.
3. If the problem is changing request or response behavior without touching backend code, think APIM policy.
4. If the problem is bundling APIs for consumers, think APIM product.
5. Keep gateway policy logic separate from backend application logic.

Quiz