The public door you never asked for
The storage account you built in Class Twelve has a public address the day it is born. So does an Azure SQL database, a Key Vault, a Cosmos DB — nearly every platform service Azure hands you arrives with a fully-qualified name that resolves on the open internet, whether you asked for that or not. Access is gated by keys and identity, so the door is locked. But a locked door is still a door: it sits on a public street, every scanner on the internet can see it, and rattling the handle costs an attacker nothing. For a service with a genuinely public job — a storefront, an API you want the world to call — that is exactly right. For the parts of your estate that should only ever be spoken to from inside your own network, a locked public door is a weaker promise than no door at all, and the gap between those two promises is the whole of this class.
Closing that door properly turns out to need two moves, and the entire subject collapses into confusion the moment someone conflates them. The first is a networking move: give the service a genuine presence inside your own virtual network, so a request never has to touch the public internet to reach it. The second — quieter, and the one that undoes the first when it is forgotten — is a naming move: make the service's name actually resolve to that private presence, rather than to the public address it has always answered on. Build the corridor and skip the directory, and your traffic walks straight back out through the public door you believed you had closed. Azure gives you two networking answers of different strength for the first move, and then it demands, without exception, that you get the second one right regardless of which you chose.
Part 14a spends its whole page on that half of the story, because it is the half nearly everyone needs: you are the one reaching in, to a storage account or a database that is yours, and you want it reachable only from your own network. A service endpoint is the half-measure — it tightens who may knock on the still-public door, over Azure's own backbone, but the door itself never moves. A private endpoint is the real answer: a network interface of your own, holding a private address from your subnet, that lets you switch the public door off entirely. And then there is the trap that catches nearly everyone who builds one anyway — a private endpoint whose name was never pointed at it is not private, it is decorative, and the fix is a Private DNS zone, linked to the network doing the asking.1
Part 14b turns the same mechanism around. Every move in 14a puts you on the consumer side, reaching into a resource that belongs to you. But the identical plumbing — Private Link, an address that resolves privately, a connection that never touches the public internet — also lets you be the resource someone else reaches into, without ever handing them a route into your network or a role in your subscription. That is Private Link Service: you publish an alias behind your own load balancer, a stranger in another company, another tenant, creates a private endpoint against it, and nothing flows until you approve the specific connection. Reaching in and being reached are not two unrelated skills. They are the same corridor, built once, walked in whichever direction the relationship requires — and the DNS discipline from 14a does not disappear on the provider side, it simply moves to a different name.
Same corridor. The direction is the only thing that changes.
Hold that one idea and both halves teach themselves: a private door is a networking fact plus a naming fact, and whichever side of the door you are standing on, both facts still have to be true before you get to call anything private.
The track — two parts
The rest of Class Fourteen is two pages, each a full class in its own right with its own drills and its own labs. The first stays on the side you will use nearly every week: reaching privately into a service that is yours. The second flips the arrow, for the week you need to publish a service of your own to someone outside your network entirely — and it prices the limits that decide whether that design actually holds at the edges.
- 14a · Private Endpoints
- Service endpoints versus private endpoints, held apart on five real questions, and the Private DNS zone trap that leaves a perfect-looking endpoint quietly answering in public. Two labs build the pattern for real, once by CLI and once by hand in the portal.
- 14b · Private Link Service & the Limits
- Publishing your own service behind a Standard Load Balancer for a stranger's tenant to reach, the Pending-until-approved handshake that is the entire security model, and the region, NAT-pool and cost limits that decide whether the design scales past one partner.
The one table both halves fill in
Before either part teaches its half in full, hold the shape of all three tools at once. Every private-connectivity decision on the exam and in a design review is really a question of which row the sentence in front of you is describing.
| Tool | What it is | What it closes | DNS it needs | Taught in |
|---|---|---|---|---|
| Service endpoint | A subnet-level firewall trust, over Azure's backbone | Nothing — the resource keeps its public IP and name | None | 14a |
| Private endpoint | A NIC of your own, holding a private IP, mapped to one resource | The resource's public door, once you disable it | A linked Private DNS zone, or the name resolves public | 14a |
| Private Link Service | An alias, published behind your Standard Load Balancer, for someone else's private endpoint to target | The need to peer networks or share identity with a consumer | None of your own — the consumer's side still needs its own zone | 14b |
Read the third column and the whole class turns into one sentence: a service endpoint closes nothing, a private endpoint closes your own public door, a Private Link Service closes the need to trust a stranger with anything more than one approved connection. Read the fourth column and you know exactly which page to reopen the next time a requirement names one of these three by accident instead of by need.
A. Say "restrict, remove, or publish" over the sentence. This one restricts, and it says in as many words that the public address may stay, so the lighter tool is the honest answer. B builds more isolation than you were asked for and bills you for it. C is the wrong side of the door entirely — nobody outside your network is involved. D reaches for a gateway to solve a problem that is a firewall setting on the resource.
B. This is the networking fact holding while the naming fact does not. Azure keeps the public chain resolvable on purpose, so a client partway through moving to private access keeps working — which means a missing zone link fails quietly toward the public address instead of erroring. A is the assumption that costs people an afternoon; the record is only repointed for networks the zone is linked to. C would at least be loud, and that is exactly what does not happen. D belongs to the provider side of the class, where a load balancer is involved; reaching into your own resource never uses one.
Where Campux lands, and why
The running client makes the choice concrete. Campux Retail's storefront talks to two resources that have no business answering on the public internet — its storage account and its Azure SQL database — and, separately, needs to hand one shipping partner a way into an internal API without ever peering networks with a company Campux does not control. Two different requirements, and the mistake most beginners make is reaching for the same tool for both.
One page reaches in, the other publishes out
The storage account and the database both get a private endpoint in the data subnet — a NIC of their own, a private IP each, public access disabled once the private path is proven. The storefront, joined to the VNet, resolves both names through a Private DNS zone linked to that network, so nothing on the public internet can reach either resource at all. Miss the zone and the names quietly fall back to public — the trap 14a spends a whole page making sure you never meet in production. This is the pattern most weeks actually need: two resources, reached privately, from a workload already living on Campux's own network.
The shipping partner's connection is a different shape entirely, because the partner is not on Campux's network and never will be. Campux publishes its order-status API behind a Standard Load Balancer as a Private Link Service, hands the partner one alias, and waits. The partner's own private endpoint, built in their tenant, requests a connection; Campux approves it by hand, once, and revokes it the same way if the relationship ever ends. No peering, no shared role, no route into either company's network — one approved door, exactly as wide as the one relationship it serves.
Two requirements, two halves of the same mechanism. The parts ahead build each one in full; this hub is where you learn to tell which requirement you were actually handed.
"Just make the database private" is not one task
A ticket lands: "make the order database private." You ask the question the class taught before touching anything — private from whom? From the internet at large, reached by your own app, is a private endpoint and a linked DNS zone, built in an afternoon. Private, but reachable by a partner's own systems in their own tenant, is a Private Link Service and an approval you will make by hand. Naming which requirement you actually have, before you open the portal, is the difference between a fix that ships once and one you rebuild next week when the real ask surfaces.
Examination
Four drills, then two situations. These test the judgement that spans both halves of the track; the hands are built on the two pages themselves. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. The requirement names the provider side exactly: publish a service for a stranger, in a different tenant, to reach without peering or shared identity. That is what Private Link Service is built for — an alias, a Pending connection, an approval you control. A is the wrong direction entirely; a service endpoint only restricts who reaches your own public IP, and does nothing for a partner in another tenant. B describes the consumer side of Private Link, which the partner would build, not Campux. D solves the problem with the exact cooperation the requirement rules out. Read the sentence for whose side of the door it is describing before reaching for a tool.
B. Every private endpoint — whether it targets your own storage account or a Private Link Service you published — is only as private as the DNS resolving its name. Build the NIC and forget to link the zone to whichever network is doing the lookup, and the name falls back to whatever it resolved to before, public or otherwise. A is false: a Standard Load Balancer is a Private Link Service requirement, not a private endpoint one. C is false — the whole point of Private Link, on either side, is that peering is never required. D is a non-answer; cost does not cause a failure, it just was not asked about. The DNS discipline from 14a travels with the mechanism wherever it is used.
The private endpoint's identity, the no-peering property, and the service endpoint's ceiling. A private endpoint is always the same object — a NIC with a private IP — no matter which resource or alias it targets, and neither half of this class ever needs the two sides to peer, which is the entire selling point of Private Link over a VPN or peering design. A service endpoint's limit is likewise constant: it restricts, it never removes, on either side of the door. The two false statements are the load-bearing traps: DNS is never automatic, it is Azure's own fallback design that makes a missing zone fail silently rather than loudly; and a Private Link Service lives in the region of its own load balancer and cannot be moved out of it — a provider who wants a second region stands up a second load balancer and a second service there.
PLAN — Campux private connectivity, this sprint
1. Storage account -> private endpoint in the data subnet;
public access disabled once resolution is verified.
2. Order API -> Private Link Service behind a Standard
Load Balancer, alias handed to the shipping partner.
3. Partner's connection request approved by hand, once,
after checking it against the partnership paperwork.
4. Private Link Service visibility set to "Anyone with your
alias," so future partners can self-serve without a ticket.
Line four. Visibility does not approve anything — it decides who is allowed to ask. Set to "Anyone with your alias," the service accepts a connection request from any subscription that holds the string, and the alias is one string, not a secret issued per partner. So line four gives away the exposure control that made lines two and three worth doing, and it does not even buy what the teammate wanted: requests still arrive Pending and still need a hand. Lines one through three are the design working correctly — verify resolution before disabling the public door, publish behind the mandatory Standard Load Balancer, and approve each connection against real paperwork. The fix for the scaling complaint hiding behind line four is to keep visibility restricted to named subscriptions and add the trusted ones to the auto-approval list. That is the setting that removes the ticket, and it removes it only for partners you named.
Split the mandate into its two real shapes first. The storage account and the database are both "we reach our own resource privately" — 14a's whole page, private endpoints plus linked Private DNS zones for both. The partner-facing API is "someone else reaches our resource privately" — 14b's page, a Private Link Service behind a Standard Load Balancer. Treating all three as the same task is the mistake the mandate tempts you into.
Build the consumer-side pair first, and verify before disabling anything. For storage and the database: create each private endpoint, create and link the Private DNS zone, confirm from inside the VNet that each name resolves to its private IP, then — only then — disable public access on each, one at a time. Nothing customer-facing breaks, because the private path is proven before the public one closes.
Publish the API last, because it needs a different piece of infrastructure to exist first. Stand the order API behind a Standard Load Balancer, publish the Private Link Service, hand the partner the alias, and hold visibility to a named allow-list rather than open. Their connection lands Pending; approve it by hand once you have checked it against the partnership record. The mandate is satisfied resource by resource, not by one setting — and the order matters because the API's design depends on infrastructure the storage account and database never needed.
Concede the real overlap before correcting the claim. Both objects are built on Azure Private Link, both involve an address that resolves privately, and both refuse to work if the DNS is wrong. The developer has noticed something true — this is one mechanism, not two unrelated ones — and dismissing that outright would lose an argument that has a real point buried in it.
Name the one difference that makes collapsing the terms dangerous. A private endpoint is what you build to reach in to a resource — yours or someone else's alias. A Private Link Service is what you build to be reached — it is the thing a private endpoint on the far side connects to. Calling both "a private endpoint" in the docs would make a runbook unreadable the first time it needs to say who approves a connection, because only the Private Link Service side has an approval step at all; a plain private endpoint into your own storage account never asks anyone's permission.
Offer the fix that keeps the useful insight without the confusion. Document the shared mechanism once — Private Link, DNS discipline, no peering required — and then keep the two object names, because they answer different questions: "what did we build to reach something" versus "what did we build so something could reach us." One page can hold both ideas; one term for both objects cannot.
Five things worth carrying out of this hub
- Every PaaS service is born public. Closing that door properly is a networking fact — a private endpoint — plus a naming fact — a linked Private DNS zone — and both must hold, or the door only looks closed.
- A service endpoint restricts who reaches a still-public address; only a private endpoint can remove the public door entirely. Reach for the lighter tool only when the requirement is genuinely the lighter one.
- Reaching into your own resource and publishing your own resource are the same mechanism, aimed in opposite directions — 14a is the first, 14b is the second, and each needs the other's context to make full sense.
- Private Link Service crosses tenants without peering or shared identity because approval, not networking, is the security boundary: nothing flows until the provider approves the specific connection.
- The interview question is never "do you know these three tools" — it is "which one does this sentence actually ask for." Table 1 is built to answer that on sight.
- The DNS fallback described in §1 is deliberate on Microsoft's part, not an oversight: the privatelink CNAME a private endpoint creates is publicly resolvable so that a client partway through migrating to private access keeps working rather than breaking outright. The cost of that kindness is that a forgotten or unlinked Private DNS zone fails silently toward the public address instead of erroring, which is exactly why both parts of this class insist on verifying resolution from inside the network before trusting any of it. ↩