Three planes under one name
"API Management" sounds like one box, and the portal encourages the illusion. It is really three cooperating parts, and keeping them apart is the difference between reasoning about the service and poking at blades. The gateway is the part that does the work at runtime: every partner request lands here, and here the policies run, the keys are checked, the calls are counted, and the backend is reached. It is the only part in the request's hot path — if it is down, traffic stops. The management plane is the control surface: the APIs, products, and policies you configure, reachable through the portal, the CLI, ARM/Bicep, and its own REST API. Changing configuration here never touches a live request; it updates what the gateway will do next. And the developer portal is the shop window: an auto-generated website where consumers discover your APIs, read documentation, and sign up — the subject of 38e.
The reason this split earns a whole section is that your work lands on different planes with different blast radii. A policy edit is a management-plane change that a future request feels. A tier upgrade rebuilds the gateway. A portal customisation touches neither the gateway nor the config. Engineers who blur the three end up frightened of routine changes and cavalier about risky ones; engineers who see the planes know exactly what a given change can and cannot break.
- The three planes
- Gateway — the runtime data plane every request flows through. Management plane — the control surface where APIs, products, and policies are defined. Developer portal — the consumer-facing site for discovery and sign-up. Only the gateway is in the request's path; the other two shape what it does.
A gateway is not a load balancer
Because the gateway sits in traffic, it looks like Class Thirteen's load balancer and is a different animal. A load balancer spreads identical traffic across identical copies and reads almost nothing — it checks health and picks a healthy backend. A gateway reads the request itself — who sent it, with which credential, to which operation — and applies policy before the backend ever hears about it. The two stack rather than compete: the gateway decides whether and how a request travels; the load balancer, further back, decides which copy answers it. You will often run both, in that order.
This is also where the bootcamp's recurring test travels in unchanged: a gateway a consumer can walk around is a suggestion, not a control. Every promise the gateway makes — limits, counts, authentication, versioning — holds only for traffic that actually goes through it. That fact drives the entire back half of this track (38f and 38g), where the backend is closed to everything but the gateway's identity. Hold it now, because it reframes the tier decision below: some of what you are buying at the higher tiers is precisely the ability to make "you must come through the front door" a routing fact instead of a polite request.
The first APIM decision is a billing decision.
The tiers — what you actually buy
Before a single API is imported, you choose a tier (a SKU), and that choice gates which features exist and what you pay every month whether or not a request arrives. The lineup is mid-evolution, so learn the shape rather than memorising a grid that will shift. There is a serverless option, a set of classic fixed tiers, and a newer "v2" line that rhymes with the classic tiers but does not map one-to-one.
| Tier | Billing | Fits | Watch for |
|---|---|---|---|
| Consumption | Per-call, serverless | Labs, spiky or unsure workloads, event-driven APIs | No developer portal; limited policy set; not for the partner story |
| Developer | Fixed monthly, cheap | Non-production — dev and test only | No SLA; never put production traffic on it |
| Basic / Standard / Premium (classic) | Fixed monthly, rising | Production; Premium adds VNet injection & multi-region | Networking & scale features concentrate at Premium; slow to provision |
| Basic v2 / Standard v2 / Premium v2 | Fixed monthly | Production on faster-provisioning infrastructure | No Developer v2; networking model differs from classic — read the grid |
Two takeaways survive the churn. First, Consumption is a different kind of thing: serverless and cheap to start, but it deliberately lacks the developer portal and several policies, so the moment your story involves partners signing up and per-key limits, Consumption is out — not on price, but on capability. Second, the networking features you will want in 38g live in the upper tiers, and exactly which tier enables VNet integration versus full VNet injection differs between the classic and v2 lines.1 The engineering lesson is the one Class Thirty-Two hammers: the tier is a recurring cost and a capability ceiling at once, so you read the current tier-comparison page for the features you actually need before you write a SKU string into a Bicep file.
When APIM earns it — and when it does not
A gateway is not free, in money or in operational surface, so Class Three's "when not to" applies with force. The honest test is the number of consumers you do not control. One API, one internal consumer, one team owning both sides: skip APIM. Middleware in the app is enough, and a gateway would be a hop, a monthly bill, and a second place to look during an incident, bought for nobody. The gateway earns its keep the moment any of these appear: consumers you do not control (partners, other teams, paying customers), the need to meter or bill usage, several backends that should present as one product, or a contract that outside parties will hold you to. Each of those is a chore that multiplies per consumer and has no good home inside a single backend.
Say the anti-pattern out loud so you catch it in reviews: standing up a Premium APIM in front of a single internal service "for consistency," or "so we're ready to scale," months before a second consumer exists. That is paying enterprise gateway prices to solve a problem you do not have yet — the mirror image of the middleware team that refuses APIM when partners are already knocking. The senior move is to name the variable (consumers you do not control) and let it, not fashion, decide.
Choosing the smallest tier that carries the story
With three partners incoming, Campux's first instinct is the cheapest line item: serverless Consumption, pennies per call. It fails on capability, not price. The partner story needs two things Consumption does not carry — a developer portal for self-service sign-up (38e) and per-key rate limiting (38d) — so the real floor is the smallest tier that includes both. That is Basic v2: production-grade, fast to provision, cheaper than Premium, and carrying the portal and per-key policies the story is built on. Premium's VNet injection and multi-region are genuinely useful, but Campux has three partners and one region, so paying for them now would be the exact "ready to scale" anti-pattern the section warns about.
The decision gets written down the way Class Thirty-Two taught: a one-line justification in the design doc — Basic v2 chosen for developer portal + per-key limiting; revisit at Premium if we need VNet injection or a second region. That sentence is what turns a tier from a guess into a reviewable decision, and it is the sentence a cost review will thank you for next quarter.
The planes, put on the wire
Assemble the picture before the next part imports an API into it. You have chosen a tier, which provisioned a gateway at a public hostname like campux-apim.azure-api.net. Behind it, the management plane is where you will define the catalog API, the Partner product, and the policies — none of which a request touches until the gateway is told to apply them. And the developer portal is sitting empty, waiting for products to publish. Part C fills the gateway with an API; Part D gives it behaviour; Part E opens the portal.
The tier line in the design review
Someone has written "API Management (Premium)" into the diagram for a service with one internal caller. You ask the one question that settles it: how many consumers do we not control, and do we need VNet injection or a second region today? The answer is "none yet, and no." The tier drops to the smallest one that carries what the story actually needs, a note records why, and the review moves on — several thousand a year saved by a single question about the variable that matters.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — a policy edit is a management-plane change. You updated what the gateway will do next, not the running gateway itself, so requests already being served are unaffected and the new limit governs future calls. This is exactly why knowing the planes calms you down: the change is safe to make in business hours because its blast radius is "future requests," not "everyone connected right now." A confuses a config change with a tier change — upgrading the SKU does rebuild the gateway, which is a different, heavier operation. C confuses policy with the portal, which is documentation. D is the fear that comes from not seeing the planes at all: it treats every change as maximally dangerous, which is how teams end up unable to ship a rate limit without a maintenance window they never needed.
C — the smallest tier that carries both required capabilities in production. The method is "list the features the story actually needs, then pick the cheapest tier that has all of them." Here that is the developer portal and per-key limits, in production — Basic v2 clears it. A fails on capability, not price: Consumption lacks the developer portal entirely, so cheapest is irrelevant. B fails on a word people skim past — Developer is explicitly non-production, with no SLA; it has the portal but must never carry partner traffic. D is over-buying: rate limiting is not a Premium-only feature, and reaching for Premium "to be safe" is the exact cost anti-pattern the class warns about — you would be paying for VNet injection and multi-region nobody asked for. Always design up from the requirement, not down from the biggest SKU.
Uncontrolled consumers, per-consumer metering, and several backends behind one product. Each is a chore that multiplies per consumer and has no clean home in a single app, which is the definition of gateway work. The two rejects are the twin failure modes. The single internal service with one caller is the textbook "when not to" — middleware suffices, and APIM would be a hop and a bill for no one. And "looks enterprise-ready" is buying an operational surface to decorate a diagram, which Class 32 will bill you for every month. The discipline: a gateway is justified by a problem you have, named as a variable (consumers you do not control), never by a posture you want to project.
# APIM design notes
1. The gateway is the only plane in the request path;
if it's down, partner traffic stops.
2. We'll define APIs, products, and policies on the
management plane, via Bicep in the repo.
3. Because the gateway sits in traffic, we can drop
our load balancer — APIM replaces it.
4. The developer portal is where partners sign up;
it isn't in the request hot path.
Line three — the gateway-equals-load-balancer confusion, which quietly deletes a component the system still needs. A gateway reads the request and applies policy — whether and how it travels; a load balancer spreads traffic across identical backend copies and reads only health — which copy answers. They sit in series, not in competition: partner traffic hits the gateway, and behind it a load balancer still fans requests across your backend instances. Drop the load balancer and a multi-instance backend loses its distribution and health-checking; the gateway will not do that job. The distractors are all correct as written: only the gateway is in the path (A is wrong to dispute line one), policies belong in Bicep in the repo — that is 38d's whole discipline (B), and the portal really is out of the hot path (D). The tell: any sentence claiming one component "replaces" another usually hides a job that still has to be done somewhere.
Agree with the instinct, then correct the category error. Starting small and moving up is exactly right as a habit — it is what §4 preaches. The mistake is not the instinct; it is treating this as a scale decision when it is a capability decision. "Move up later if we need to" assumes the missing pieces are about size, so a bigger box fixes them. But the developer portal and per-key limiting are not on Consumption at any volume — they are simply absent from that tier. The "if" is already resolved: we know we need both, today, because the partner story is the whole point.
Then make the cost of the wrong start concrete. Beginning on Consumption does not defer the decision; it schedules a migration. When the portal turns out to be missing, we do not upgrade a slider — we recreate the instance on a different tier line, re-import, re-issue keys, and re-point partners, mid-integration, under deadline. That is more expensive and more embarrassing than picking Basic v2 now, and it lands precisely when the partners are watching. Serverless-first is a good reflex applied to the wrong axis.
Close on the method, not just the answer. Offer the durable rule so the next decision is easy: list the features the story needs, pick the cheapest tier that has all of them, and write down why. Here that is Basic v2, with a note to revisit at Premium if we ever need VNet injection or a second region. The sentence that settles it: Consumption isn't a smaller version of what we need — it's a different tier that's missing two things we already know we need.
Open with the qualifying question, because agreeing too fast is a junior tell. "Before I agree, I want one number: how many consumers do we not control? And two capability questions: do we need to meter or bill per consumer, and do we need VNet integration or multiple regions?" That shows the interviewer you know a gateway is a cost and an operational surface, not a default — and that you have a specific variable, not a vibe, deciding it. If the honest answer is "one internal caller, no billing, one region," the senior move is to say APIM is probably overkill here.
Then give the plain-language model in three planes. "APIM is three things wearing one name. A gateway that every request flows through, where I check who's calling, limit them, and hide the real backend. A management plane where I define the APIs and policies — changing it doesn't touch live traffic. And a developer portal where outside consumers discover the API and sign up. Only the gateway is in the request's path; the other two shape what it does." Naming the planes tells them you can reason about blast radius, not just click blades.
Close on the tier, because that is where the money and the judgement meet. "Then I'd pick the smallest tier that carries the features the story needs — Consumption if it's spiky and internal, a Basic-or-Standard v2 once partners and a portal are involved, Premium only when VNet injection or multi-region are real requirements — and I'd write down why, so the cost review has an answer." That final move — requirement first, cheapest sufficient tier, decision recorded — is the one that reads as someone who has actually paid an Azure bill, not just drawn a diagram.
Five things worth carrying out of this part
- APIM is three planes under one name: the gateway (runtime, in the request path), the management plane (config, not in the path), and the developer portal (sign-up, not in the path). Knowing which plane a change lands on tells you its blast radius.
- A gateway is not a load balancer. The gateway reads the request and decides whether and how it travels; the load balancer decides which copy answers. They stack — you often run both.
- The first APIM decision is a billing decision. Consumption is serverless but lacks the portal and several policies; Developer is non-production; classic and v2 Basic/Standard/Premium are the production tiers, and the SKU grid moves.
- Pick the smallest tier that carries the features the story actually needs, and write down why. Reaching for Premium "to be ready" is a cost anti-pattern; refusing APIM when partners are knocking is the mirror one.
- The variable that decides whether APIM earns its keep is the number of consumers you do not control. One internal caller: skip it. Partners, billing, or several backends as one product: it pays.
- The tier grid is genuinely a moving target: the classic Developer/Basic/Standard/Premium tiers now share the catalogue with a v2 line whose feature and price boundaries have shifted more than once, and networking in particular does not map cleanly — classic reserved VNet injection for Premium, while the v2 line offers VNet integration at Standard v2. Treat the direction here (serverless lacks the portal; networking lives up-tier; the grid changes) as settled, and check the current pricing and tier-comparison pages before committing a SKU to a design. ↩
- "Serverless" for Consumption means no fixed monthly instance cost and per-call billing, which is genuinely different from the fixed tiers — but it also means cold-start latency on the first call after idle, and a capped set of features. It is excellent for event-driven or bursty internal APIs and wrong for a steady partner-facing product; the tier is a fit question, not a good/bad one. ↩