The chores that arrive with the second caller
The warehouse partner calls Campux’s order API successfully. A second partner joins, sends far more requests, and everyone’s checkout slows down. “Can we pause just that partner?” asks the manager. The backend team should not have to rebuild every caller rule inside every service. API Management gives the team a gateway at which to publish a contract, apply caller controls and observe requests. The backend still needs its own authentication and network design.
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 consumer sends a request to the gateway. If you have configured the policies, the gateway checks a token or subscription, applies a usage limit and forwards an allowed request to the backend. The backend still checks what that caller may do and produces the business response. A network rule or backend authentication must also prevent callers from bypassing the gateway. Part 38a teaches the language of the request; the remaining parts build and test those controls.
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 gets access: products bundle APIs, subscriptions issue revocable keys for access and usage tracking, and the developer portal can support onboarding. A key alone does not prove a caller’s identity.
- 38f · Security
- The door’s locks, front and back: subscription keys for access and metering, token or certificate validation for callers, and managed identity where the backend supports it. Restrict the backend route separately.
- 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
The gateway is a useful place for shared traffic rules such as token validation, usage limits and request routing. The backend remains responsible for business rules and should enforce the authorization and data checks it needs even when traffic comes through APIM. Both layers need telemetry. In the rest of this track, ask which rule belongs in each layer, then verify that a caller cannot reach an unprotected backend address.
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.
Continue with a supplied build
Follow the same fictional catalogue through this track. The supplied contract and worked checks let you practise without an Azure estate; the optional import/mock path makes real gateway requests. Each step states what it proves and what it does not.
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. The gateway can apply shared traffic controls; the backend interprets the request and enforces business rules. Both layers may need authentication and authorization. A, C and D divide the work by HTTP verb, caller location or data storage, none of which describes the gateway’s role. Test both the gateway policy and the backend path so the diagram matches the deployed system.
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.
Give each partner a separate subscription so its key can be revoked and its usage measured without affecting other partners. A subscription key identifies the subscription presented with the call; by itself it is not strong user or application authentication. Require and validate an appropriate token when the partner API needs authenticated callers, then apply per-partner limits. Configure the backend to accept only authorized gateway traffic using supported network restrictions and/or backend token validation; APIM’s managed identity can authenticate to a backend that supports it, but the identity alone does not close a public network path.
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
- As consumers grow, the gateway can centralize subscription access, token checks, limits, usage reporting and documentation. Configure each control and restrict direct backend access; keep business authorization in the service.
- The gateway applies shared traffic rules; the backend interprets requests and protects business data. Validate both layers and test that callers cannot bypass the intended controls.
- 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 track teaches APIM as Azure’s managed API gateway. Microsoft recommends using subscription keys alongside stronger authentication when an API requires it. See API authentication and authorization and secure APIM deployment for the current controls. ↩
- "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. ↩
Put an API behind API Management and say what the gateway now does for you.