The chores that arrive with the second caller
A backend with one caller has no interesting problems. You wrote the API, you wrote the client, and if the two disagree you fix both in the same afternoon. Everything changes the day a second consumer appears — a partner, another team, a paying customer — because now the same list of chores arrives once per consumer and never leaves: prove who is calling, stop the eager from drowning the patient, count who used what, hide the backend's real address, keep last year's clients working while this year's ships, and hand a stranger enough documentation to integrate without a meeting. Solve those inside the backend and you will solve them again in the next backend, differently, forever. Azure API Management is where the estate solves them once — a managed front desk between every consumer and every backend, where the chores become configuration.
This class is deliberately long, so it is built as a track rather than a wall. It opens where most courses refuse to: with what an API even is — REST, the HTTP verbs, status codes, the request and response, and the contract two systems agree to keep. Only then does it build the gateway on top, one concern at a time, so that by the end APIM is not a product you memorised but a pattern you understand well enough to recognise in Kong, Apigee, or whatever the next employer runs.1
A gateway you can bypass is a suggestion.
The shape of the whole track, drawn once
Hold one picture before the eight parts. A request from a stranger arrives at a single front door; before your backend spends a cycle on it, the door has already checked the credential, counted the call against a limit, and decided whether this caller is even allowed this operation — and on the way back, it has tidied the response and hidden anything internal. Everything in this track is one station on that journey. The first part stands before the door, teaching the language the request is written in; the rest build the door itself, station by station.
The track — eight parts, language to lifecycle
The rest of Class Thirty-Eight is eight pages, each a full class in its own right with its own drills and situations. Read them in order the first time: the gateway parts lean on the API vocabulary the first part sets, and security and networking assume the anatomy in between. Later they work as reference — the page you reopen the afternoon you actually write a policy or argue a tier.
- 38a · What is an API?
- The grounding: REST, the HTTP verbs and status codes, the anatomy of a request and response, the contract two systems agree to keep, OpenAPI as its written form — and why, once an API has strangers, a gateway becomes inevitable.
- 38b · APIM architecture & tiers
- The three planes — gateway, management, developer portal — and the first real decision: Consumption vs Developer vs Basic/Standard/Premium and the v2 line, and when APIM earns its monthly line item at all.
- 38c · Importing & designing APIs
- Turning a backend into an API the gateway understands: operations, importing an OpenAPI spec instead of typing by hand, backends, and mock responses that let frontends integrate before the real service exists.
- 38d · Policies
- Everything the gateway does: the inbound / backend / outbound / on-error pipeline, rate-limit and quota, transformation, caching, and CORS — with a policy you can read line by line.
- 38e · Products, subscriptions & the portal
- How a consumer becomes a known, throttleable, billable identity: products bundle APIs with terms, subscriptions carry the keys, and the developer portal replaces the onboarding meeting.
- 38f · Security
- The door's locks, front and back: subscription keys, OAuth2 and JWT validation, client certificates and mTLS, and a managed identity to the backend so the gateway is the only road in.
- 38g · Networking
- Where the gateway sits on the wire: external vs internal VNet mode, private endpoints, the self-hosted gateway for hybrid estates, and fronting APIM with Application Gateway or Front Door.
- 38h · Versioning, revisions & observability
- Changing a thing strangers depend on: versions vs revisions, deprecation as a campaign not a flag day, and the App Insights and analytics that tell you who is calling what, and what is slow.
The one idea that carries the whole track
Under all eight parts is a single distinction, and if you carry nothing else, carry this: the gateway decides whether and how a request travels; the backend decides what it means. Authentication, rate limits, caching, header hygiene, versioning — all traffic-shaped work, all uniform across every operation, all the gateway's. Pricing rules, catalogue logic, what a discount is — application meaning, and it stays in the backend where a debugger can reach it. Almost every mistake in this domain is a violation of that line: business logic smuggled into policy XML, or a security control the backend was supposed to own quietly delegated to a gateway a caller can walk around.
The second idea is the one Class Nineteen taught at a smaller radius. A branch protected you from breaking your teammates; an API version protects you from breaking strangers who have contracts and invoices. The moment your API has consumers you do not control, changing it stops being a deploy and becomes diplomacy — and the whole back half of this track is the machinery that makes that diplomacy a checklist instead of a bad weekend.
The wholesale door gets a front desk
The track has a single spine: a sales win. Two outdoor-gear marketplaces and a regional chain want live access to Campux's catalog and stock levels. The first draft of the integration is an email thread offering the storefront backend's URL and a shared password — the kind of draft Class Thirty-One trained everyone to flinch at. Across the eight parts, that thread is replaced, one concern at a time: 38a names what the catalog endpoint already is; 38b picks the tier that carries a partner story; 38c imports the catalog's OpenAPI spec; 38d throttles it; 38e gives each partner their own key through a self-service portal; 38f closes the backend to everything but the gateway's identity; 38g decides where on the network the gateway lives; and 38h ships the inevitable breaking change without a single partner's integration falling over.
By the end, onboarding the third partner takes eleven minutes and zero meetings,2 a runaway partner sync becomes a 429 on one key instead of a Class Thirty-Six incident, and a breaking currency change ships as v2 beside v1 and is retired from a traffic chart. The email thread that almost shipped a shared password ends up printed and pinned above the team's whiteboard, annotated in red pen: this is what the front desk replaced.
Why this track pays for itself
Integration is where cloud engineers quietly become indispensable. Anyone can stand up a service; the person a business will not operate without is the one who can put five sprawling APIs behind one front door, hand partners a self-service portal, and change a contract without a support fire. That is a specific, rare, and legible skill, and it is exactly what an interviewer is straining to detect when they ask you to "design an API for external partners." The wrong answer reaches for a shared key and a public backend. The right answer walks the eight parts of this track without naming them.
So treat the parts as an investment with a return you can say out loud. Each is a paragraph in an interview and a task on the job, and together they move you from "I exposed an endpoint" to "I run the front desk the whole estate goes through." The parts build the hands; this hub rehearses the judgement they serve.
Fitting the lock on the front door
Five teams expose five APIs five different ways, and consumers are drowning. You put a gateway in front: one front door, consistent authentication, rate limits so one noisy caller cannot sink the rest, and a place to meter usage. The sprawl becomes a product with a door and a doorman — and you are the one who fitted the lock. Nothing in this track is glamorous; all of it is the reason the integration works on the Saturday it matters.
Examination
Four drills, then two situations. These test the judgement the track is built on; the hands are built in the eight parts. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. Traffic-shaped work — authentication, limits, caching, header hygiene, versioning — is uniform across every operation and belongs at the door. Application meaning — what a price is, what a discount does — belongs in the backend where a debugger can reach it. A, C, and D all draw the line in a place that feels tidy and is wrong: reads and writes both pass policy; external and internal callers both deserve the same front desk; and the gateway stores nothing durable. Miss this line and you will eventually find a pricing bug living in policy XML, in a place no developer thought to look — which is the single most expensive mistake this whole class exists to prevent.
B. A gateway operation is an HTTP verb plus a path; a rate limit answers with a 429; a subscription key rides in a header; a policy transforms a request body. Skip the language and every one of those becomes memorised noise. A is a caricature — the exam tests concepts, not trivia. C is wrong: APIM also fronts SOAP, GraphQL, and WebSocket APIs, and gRPC in the classic tiers, but REST is the shape you must understand first. D mistakes grounding for padding: a course that dives into APIM without defining an API produces engineers who can click through the portal and cannot reason about what they clicked.
Per-caller credentials, per-caller limits and attribution, and self-service onboarding. Each scales with the number of consumers and has no good home inside a single backend — which is precisely why the gateway exists. The two rejects are backend concerns that do not multiply per consumer: the storage engine and the response logic are the same whether one caller or a thousand call, and they belong where the application lives. The tell that a chore is the gateway's: ask "does this get worse each time a new stranger integrates?" Credentials, limits, and onboarding all do. Choosing a database does not.
# my plan for Class 38
1. Read 38a first — learn what an API is before
building a gateway on top of one.
2. Skip straight to 38d policies; the XML is the
only part that matters in interviews.
3. Do 38f security and 38g networking together;
the back door and the wire are one design.
4. Finish with 38h — versioning is how you change
the contract once strangers depend on it.
Line two. Policies act on products, subscriptions, operations, and identities — the anatomy 38b through 38e build. Jump to the XML and you can copy a rate-limit-by-key without understanding what the key is, which is exactly the borrowed-without-understanding habit the track is designed to prevent. The distractors are the plan working: line one is correct, and it is the reason the track opens with 38a at all (A inverts it); reading security and networking as one design is genuinely sound — the back door and the wire protect the same promise (C is wrong to call them unrelated); and versioning belongs at the end because it presupposes everything before it (D misreads it). The general rule: whenever someone skips the fundamentals "because interviews only test the advanced part," they have mistaken the part that is visible for the part that is load-bearing.
Start by naming the case where they win, because it exists and they can smell evasion. One API, one internal consumer, one team owning both sides: the middleware is genuinely enough, and APIM would be ceremony — a hop, a bill, and a second place to look during incidents, bought for no one. Class 3 taught the shape: every tool has a "when not to," and a gateway's is single consumer, single owner, no external contract. Saying this first is the credibility that makes the rest land.
Then name the variable that flips it: consumers you do not control. The middleware argument quietly assumes every caller is family. The moment partners, other teams, or paying customers integrate, the chores multiply per consumer — per-partner limits, revocable credentials, usage attribution, a portal, versioning with deprecation campaigns — and middleware answers none of them without the backend team building a small, bespoke, forever-maintained gateway of their own inside the app. The honest comparison is not "APIM versus nothing" but "APIM versus the gateway you will write by accident, one feature request at a time, with no portal and no Class 32 line item to warn you what it costs."
Close with the boundary drawn where it belongs. Their token validation and rate limiting are not wasted — defence in depth wants the backend suspicious even of the gateway (Class 31's layers). What moves to APIM is the multi-consumer work: the front desk, not the locks on the individual doors. The sentence that usually settles it: your middleware protects this API; the gateway is for the day this API has customers — and sales already made that day this quarter.
Name the frame before the steps. Open with the shape so they know you are not improvising: "I put a managed gateway in front of the catalog backend, and I never give partners the backend directly." Then walk the stations. The catalog is already an API — a set of GET operations over HTTP; I import its OpenAPI spec into APIM rather than retyping it. I pick the smallest tier that carries a developer portal and per-key limiting, because the partner story needs both. I publish the read-only operations as a Partner product with a rate limit and approval required.
Then make each partner a known identity. Each partner subscribes to the product through the developer portal and gets their own keys — which is what lets me throttle, meter, or revoke one partner without touching the others. A policy validates the caller and enforces the limit before the backend hears a thing. And I close the backend so it accepts only the gateway's managed identity: a gateway a partner can walk around is a suggestion.
Close on change over time, because that is the senior tell. "When the catalog schema has to change in a breaking way, I ship it as v2 beside v1, put the migration guide in the portal, and retire v1 from the per-subscription traffic chart — a checklist, not a flag day." Three minutes, one front desk walked station by station, and a plan for the day the contract changes: that is the answer that ends the integration portion of the interview and tells them you have done this, not read about it.
Five things worth carrying out of this hub
- The chores that justify a gateway all multiply per consumer: authenticate, limit, count, hide the backend, version, onboard. Solve them once at the front desk instead of once per backend, forever.
- The line the whole track hangs on: the gateway decides whether and how a request travels; the backend decides what it means. Almost every mistake in this domain crosses that line.
- The track starts with the language on purpose. You cannot read a gateway — verbs, status codes, headers, contracts — without first knowing what an API is, which is why 38a comes before APIM at all.
- Eight parts, language to lifecycle: what an API is, architecture & tiers, import & design, policies, products & subscriptions, security, networking, versioning & observability. Read them in order once, then keep them as reference.
- The pattern outranks the product. Learn it here on APIM and you will recognise the same nouns — consumer credentials, policies, versioned contracts — wearing different names in Kong, Apigee, or any rival gateway.
- This class teaches APIM because it is Azure's native gateway and the one AZ-400 expects, but the pattern outranks the product: consumers hold gateway credentials, policies shape traffic, contracts version beside each other. Meet Kong, Apigee, or a cloud rival's gateway and you will find the same nouns wearing different names. ↩
- "Eleven minutes, zero meetings" is a concrete figure carried from the case file, not a benchmark to quote. Real onboarding time depends on your approval workflow and how well the portal docs are written; treat the specific number with suspicion and the direction — self-service is dramatically faster than an email thread — as settled. ↩