The public door you never asked for
An Azure storage account has a name such as store.blob.core.windows.net. A public DNS lookup can return a public IP for that name. That does not prove anyone on the internet can read its data: network rules and identity or keys are separate checks. For a private workload, you can add a private endpoint, make its name resolve to a private IP from the right network, and disable public network access where the service supports it. Each step solves a different problem.
Think in three checks. Network: does a private endpoint give this client a path to the service? DNS: does the name resolve to that endpoint's private IP from the client's network? Access: does the service reject unwanted public traffic, and does the caller have permission? A private endpoint alone does not disable the public endpoint. A public DNS answer alone does not bypass a disabled public endpoint: the connection can fail instead. Service endpoints follow a different pattern and keep the service's public IP in DNS.1
Part 14a covers two ways for your workload to reach a supported Azure service. A service endpoint lets a resource firewall allow selected virtual-network subnets while the service name still resolves to a public IP; traffic uses Azure's backbone. A private endpoint is a network interface with a private IP in your VNet. To use that path by name, configure DNS for the clients that call it, commonly with a Private DNS zone linked to their VNet. Then verify the application works before disabling public network access. Authentication and authorization still matter.
Part 14b covers a service you publish for another network. With Private Link Service, you put your application behind a Standard Load Balancer and expose an alias. A consumer creates a private endpoint in their VNet targeting that service. Their connection needs approval, either manually or through a provider-configured auto-approval list. The consumer still needs a DNS name that resolves to their private endpoint; it need not be an Azure Private DNS zone. Private Link does not itself replace application authentication.2
A private route, a private DNS answer and permission are separate checks.
Use the same three-check method on both sides: test the route, test name resolution from the actual client, then test network rules and identity. If one check fails, find out which one before changing the others.
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
- Compare service endpoints with private endpoints, then verify DNS, the private path, public network access and identity. The labs show the CLI and portal flows.
- 14b · Private Link Service & the Limits
- Publish your own service behind a Standard Load Balancer, control who can request and approve a connection, and examine region, NAT-pool and cost limits.
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 | Network effect | DNS requirement | Taught in |
|---|---|---|---|---|
| Service endpoint | A subnet-to-service route plus resource firewall rule | Restricts which subnets can use the service's public endpoint | Service name still resolves to a public IP | 14a |
| Private endpoint | A NIC with a private IP mapped to a supported resource | Adds a private path; public access is a separate setting | Clients need a name resolving to the private IP, commonly via a linked Private DNS zone | 14a |
| Private Link Service | A provider service behind a Standard Load Balancer that consumers target with private endpoints | Provides private connectivity without VNet peering; approve connections and still authenticate callers | The consumer must resolve its application name to its private endpoint | 14b |
Service endpoints still use the service's public IP. Private endpoints add a private IP; you must separately decide whether to disable public network access. Private Link Service is the provider-side object that a consumer's private endpoint connects to. In every design, verify DNS from the client and require appropriate identity or application credentials.
A. Configure a service endpoint on the supported subnet and a resource firewall rule allowing only that subnet. The service still resolves to a public IP while traffic uses Azure's backbone. If the policy instead requires no public endpoint, use a private endpoint and disable public network access after testing. Identity or keys still control data access.
B. With the public resolver assumed in the question, the client receives a public IP, not the private endpoint's IP. If public network access is disabled, the later connection can fail; DNS success does not mean data access. Configure private DNS (or a correctly maintained custom DNS path), check the answer from the storefront, then test the application.
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 Azure SQL database each get a private endpoint for the needed service. The storefront needs network reachability to those private IPs and DNS answers that point to them. Test both applications from the storefront network, then disable public network access on each service and retest. Public DNS may still resolve their names, but public requests should be rejected. Storage permissions and SQL credentials remain required.
For the shipping partner, Campux publishes its own API behind a Standard Load Balancer as a Private Link Service. The partner creates a private endpoint in its network; Campux restricts visibility and approves the request manually or uses a carefully scoped auto-approval list. The partner maps its API name to its endpoint's private IP and still authenticates to the API. Campux must also verify that the API has no unintended public entry.
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 says, "make the order database private." First ask who connects and from where. Your own app reaching Azure SQL privately calls for a database private endpoint, working DNS, tested access and disabled public network access. A partner reaching an API you operate is a different provider-side design: the API may be published through Private Link Service. Do not treat that as a way to replace Azure SQL's own private endpoint.
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. Campux is the provider, so it publishes its API through Private Link Service behind a Standard Load Balancer. The partner creates a private endpoint in its own VNet. Campux controls visibility and approval; both sides still need application authentication. A is for reaching supported Azure services from selected subnets; B reverses who builds the endpoint; D adds network connectivity the requirement excludes.
B. A private endpoint adds a path, but the caller must use its private IP. Verify the application name from each consumer network. A linked Private DNS zone is common for Azure PaaS; the partner may instead use its own DNS. A public answer does not necessarily mean the connection succeeds, because public network access may be disabled.
Private IP, no required peering, public-IP DNS for service endpoints. A private endpoint is a NIC with a private IP. The consumer and provider VNets need not be peered. A service endpoint uses the supported service's public IP while allowing selected subnets through the service firewall. The false statements assume DNS changes automatically or that publishing Private Link Service removes other public access to the application; neither is safe to assume.
PLAN — Campux private connectivity, this sprint
1. Storage account -> private endpoint in the data subnet;
public access disabled after app requests work privately.
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. Keep the order API's public ingress enabled; Private
Link Service will automatically block that old route.
Line four. Private Link Service creates a private way to reach the API; it does not automatically remove an existing public listener, gateway or load-balancer rule. Verify the partner's private path and application authentication, then close the old public ingress if the requirement forbids it. Lines one through three can be valid, but line one also needs a working application test and authorization check before public access is disabled.
Split the mandate by provider and consumer. The storefront consumes storage and SQL through their private endpoints, with DNS and network access configured for the storefront. Campux provides the partner API through Private Link Service behind a Standard Load Balancer; the partner creates its own private endpoint.
Test each consumer path before cutover. Create the storage and SQL private endpoints, configure the correct DNS for the storefront, and check both DNS answers and real application requests. Confirm credentials and firewall rules. Disable public network access one service at a time and retest from both allowed and disallowed networks. A private DNS answer by itself is not proof that the application will stay available.
Publish the partner API deliberately. Put the API behind a Standard Load Balancer and Private Link Service, limit visibility, and approve the partner connection after verification (or use a scoped auto-approval list). The partner configures DNS and authenticates to the API. Test the private path, then remove or block any old public route to the API. Monitor the cutover; no sequence can promise zero errors without testing the actual clients.
Keep the shared mechanism. Private Link connects a consumer's private endpoint to a supported Azure resource or to a provider's Private Link Service. The consumer needs a usable private path and name. A DNS error can break either design.
Keep the object names distinct. The consumer creates a private endpoint; the provider publishes Private Link Service. Connections can be approved manually or automatically under the provider's rules. Even a private endpoint to an Azure service can involve a connection approval workflow, depending on permissions and how it was requested.
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
- A public DNS answer does not prove public access. Check DNS, the network path, public-access settings and authorization separately.
- Service endpoints keep a public-IP DNS answer; private endpoints add a private IP but do not themselves turn off public access.
- 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 can connect across tenants without VNet peering. Control connection approval, DNS, application authentication and any old public route.
- 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.
- Microsoft documents these as separate controls: private endpoints do not automatically restrict public access; private endpoint DNS must resolve to the private IP for the intended clients; service endpoints keep public-IP DNS answers. ↩
- Microsoft's Private Link Service overview distinguishes visibility from manual and automatic connection approval. ↩
Separate DNS, private reachability, public-access settings and identity when choosing private connectivity.