Resolve a private zone across a peering, and trace a name from query to answer.
This class has two halves. The road between the office and Azure (VPN or ExpressRoute) is a design decision you will read about and choose between; you will not build it here. The names that have to resolve on both sides of that road are what you practise.
The road back to the old building
Not everything moves on the first weekend, and some of it should not. Campux's point-of-sale batch job — the one you refused to migrate in Class Three, with its licence nailed to a physical machine — stays in the office for a final year. But the storefront it feeds now lives in Azure, so the two must talk. You need a road between the office and the cloud, private and encrypted, and you need it sized to the traffic that will actually cross it rather than the traffic you fear.
The road is a site-to-site VPN, and it runs on a resource called a VPN gateway.
- S2S VPN
- A site-to-site VPN: an encrypted IPsec tunnel across the public internet between your on-premises network and an Azure VNet, terminated on each side by a gateway, so the two networks reach each other by private address.
The honesty this section is named for is about sizing. A VPN gateway is a real resource that sits in a dedicated GatewaySubnet, comes in tiers that differ by throughput and tunnel count, bills by the hour for as long as it exists, and takes a genuinely long time — tens of minutes — to provision.1 Choose the tier by the bandwidth the bridge will actually carry and the number of connections it must hold, not by the biggest number on the page. Campux's bridge carries a nightly batch reconciliation and some administrative traffic — a modest tier, sized to that, is the correct and cheaper answer. Over-buying gateway throughput is the network version of the oversized VM from Class Eleven.
ExpressRoute: when the cheque is worth writing
A site-to-site VPN encrypts traffic over the public internet. ExpressRoute connects your network to Microsoft through a connectivity provider without routing the circuit over the public internet. The route is private; encrypt sensitive application traffic separately, because ExpressRoute does not encrypt all traffic by default.
- ExpressRoute
- A private, dedicated circuit between your network and Azure, provisioned via a partner. Higher bandwidth, more consistent latency, and no public internet in the path — at a materially higher cost and a longer lead time to install.
The engineering question is never "which is better" — it is "when is the cheque worth writing." ExpressRoute earns its cost when you have sustained, high-bandwidth traffic between on-premises and Azure, when you need predictable latency a shared internet path cannot promise, or when a regulator or contract forbids sensitive traffic from crossing the public internet even encrypted. Absent one of those, a site-to-site VPN is the right tool, and reaching for ExpressRoute "to be safe" buys a monthly circuit charge and weeks of provider lead time to solve a problem you do not have.
| Question | Site-to-site VPN | ExpressRoute |
|---|---|---|
| Path | Encrypted over the public internet | Private provider connection; encryption is a separate decision |
| Bandwidth / latency | Modest; best-effort internet | High; consistent, provider-backed |
| Cost & lead time | Gateway charges; allow time to provision | Circuit and provider charges; plan for provider provisioning |
| Reach for it when | A modest or temporary bridge | Sustained bandwidth, predictable latency, or a no-internet mandate |
There is a third mode for an individual machine: a point-to-site VPN. A laptop connects through an Azure VPN gateway using a configured client, authentication method, and supported tunnel protocol such as OpenVPN, IKEv2, or SSTP. It does not require an office firewall or a whole-office tunnel. When one remote engineer needs private access to a VM, consider point-to-site; then check client routes, DNS, gateway capacity, and who is allowed to connect.
Azure DNS: hosting the directory
A road moves packets by address; people and applications work by name, and something must translate. That something is DNS, and Azure will host your domain's public directory for you.
- DNS zone
- The authoritative records for a domain's names, such as the mapping from store.campux.co to an address. A public zone can be delegated on the internet; a private zone is reached through linked VNets or configured private DNS forwarding.
Hosting a public DNS zone on Azure works the way domain delegation always has, and the one step people miss is the handoff. When you create the zone, Azure assigns it four name servers. The domain does not actually resolve through Azure until you go to wherever you bought the domain — the registrar — and point its delegation at those four name servers. Create the zone, add your records, forget the delegation, and nothing happens: the internet still asks the old name servers. Inside the zone you manage record sets — an A record to an address, a CNAME to another name, and so on — and this is the ordinary, public half of naming.
Record sets, TTL, and the apex a CNAME cannot hold
A zone holds record sets, each with a name and type: A maps a name to an IPv4 address, AAAA to IPv6, CNAME aliases one name to another, MX routes mail, and TXT can carry verification text. Each record set has a TTL, the time a caching resolver may reuse an answer before asking again. If an old answer has already been cached, changing the record or lowering its TTL now will not clear that cache. For a planned change, lower the TTL before the old TTL expires, then verify from the clients that matter. Some resolvers cache differently, so do not promise instant failover.
One constraint bites everyone once. The zone apex — campux.co with no host in front — cannot hold a CNAME, because the DNS standard forbids a CNAME from sitting beside the SOA and NS records the apex is required to carry. So the classic "point the naked domain at my Azure front end" request is illegal as a CNAME. Azure's answer is the alias record: an A record at the apex that points at an Azure resource — a public IP, Traffic Manager, or Front Door — and quietly follows that resource's address as it changes, giving you CNAME-like behaviour at the apex without the forbidden record.
Private DNS zones, and the link that makes them visible
A public zone can answer internet queries after delegation. A private DNS zone has no public delegation. Azure-provided DNS can answer it for linked VNets; other networks need a configured resolver and forwarding path. That is how the privatelink name from Class Fourteen can return a private address to an authorized client.
- Private zone
- An Azure Private DNS zone has no public delegation. Linked VNets can resolve it through Azure-provided DNS; other networks can reach those answers through an appropriately configured private resolver and forwarding path. A private endpoint's zone holds the record for its private IP.
Two moving parts make a private zone useful. A virtual-network link lets that VNet resolve the zone through Azure-provided DNS. Other clients need a DNS forwarding path into a VNet that has the link. Autoregistration is a separate switch on the link: it maintains DNS records for VM network interfaces in that VNet. Only one autoregistration-enabled zone is permitted per VNet.2 Autoregistration does not create private endpoint records.
The private endpoint's DNS zone group handles a different record. With the correct privatelink.blob.core.windows.net zone attached, it creates and manages the A record for the endpoint's private IP. A client still requests campuxstore.blob.core.windows.net; the service's CNAME leads it to the privatelink name. Remember the split: autoregistration is for VM records, while a zone group integrates a private endpoint with its private zone.
| Trait | Public DNS zone | Private DNS zone |
|---|---|---|
| Who can resolve it | Internet clients, once delegated | Linked VNets directly; other clients through configured private DNS forwarding |
| Name servers | Four assigned; you delegate at the registrar | None — no internet presence |
| Where records come from | You, by hand or automation | You, plus autoregistration (VMs) and DNS zone groups (private endpoints) |
| The everyday job | store.campux.co → a public address | privatelink.blob… → a private endpoint IP |
A private zone is not published on the internet. A linked VNet can ask Azure-provided DNS for its records; an office resolver cannot use a VNet link. The office needs a reachable DNS forwarding path into Azure before it can receive the same private answer. The VPN supplies network reachability, but it does not create that DNS path for you.
Why the office and the cloud disagree on names
Here is the question that trips every hybrid deployment and appears in this class's second situation: a name resolves correctly from inside Azure, and wrongly — or not at all — from the office, even though the VPN is up and packets flow. The road is fine. The directories disagree.
Both sides must agree on the name.
With Azure-provided DNS selected, a VNet uses the platform resolver at 168.63.129.16. It can see private zones linked to that VNet, so campuxstore.blob.core.windows.net can resolve to the private endpoint IP through the service's CNAME chain.3 A VNet configured with custom DNS depends on that server's forwarding setup. The office cannot use a VNet link; without a conditional forwarder to Azure, its resolver may obtain the public answer. In this example public network access has separately been disabled on the storage account, so the public path fails while a correctly configured private path works.
- Private Resolver
- The Azure DNS Private Resolver: a managed resolver placed in your VNet that on-premises DNS servers can forward to, so a query from the office is answered by the Azure-side directory — including the private zones — without hard-coding anything.
The fix, therefore, is not on the road; it is in the directories. You give on-premises DNS a way to ask the Azure side — an Azure DNS Private Resolver in the VNet, or a forwarding VM — and configure a conditional forwarder on the office resolvers for the relevant zones.4 Now a lookup from the office is forwarded across the bridge to the Azure resolver, which answers from the private zone, and both sides finally agree. Whenever hybrid DNS "half works," this asymmetry — who can see which zone — is the first thing to check.
Inside the resolver: two doors, two directions
Think of Azure DNS Private Resolver as two optional doors. It is a managed resource in your VNet; each endpoint uses a dedicated subnet. Add an inbound endpoint for queries entering Azure, an outbound endpoint and ruleset for queries Azure must forward elsewhere, or both when the workloads need both directions.
- Inbound endpoint
- An IP address inside the VNet that accepts DNS queries arriving from outside — from on-premises. Your office resolver's conditional forwarder points at this address; it is the door the office knocks on to borrow Azure's directory, private zones included.
- Outbound endpoint
- The door facing the other way. It lets Azure send queries out — to your on-premises DNS — so a workload in Azure can resolve an internal name only the corporate directory knows, such as the old file server a migrated app still calls by hostname.
- Forwarding ruleset
- The list of rules bound to the outbound endpoint. Each rule maps a domain suffix — corp.campux.local — to the on-premises DNS servers that own it. The ruleset is itself linked to the VNets that should obey it, so you choose which networks forward which names where.
Configure only the directions your workloads need. For office → Azure, point a conditional forwarder on the office DNS server at the resolver's inbound endpoint. Scope it to the name clients actually request, such as blob.core.windows.net; the Azure-side resolver can then follow the service's CNAME to the linked private zone. For Azure → office, if cloud workloads still need corporate names, link a forwarding ruleset to the relevant VNets and use the outbound endpoint to reach corporate DNS. The managed resolver can replace a DNS forwarding VM for this job; neither direction appears automatically when a VPN connects.
For several VNets, a hub can host the resolver while spokes use either of two valid DNS designs. One is to keep Azure-provided DNS in each spoke and link a forwarding ruleset to it. A rule forwards the required private-zone suffix to the hub's inbound endpoint; the hub VNet must be linked to that private zone. This ruleset-link design does not itself require VNet peering. The other design sets a spoke's custom DNS server to the reachable inbound endpoint IP, which requires a working network path to the hub. Test the actual name from a client in each spoke. If a ruleset forwards a suffix to the hub inbound endpoint, do not link that ruleset to the same hub VNet: the query can loop back into itself.
The lane diagram below shows the on-premises → Azure door in use, and the single lane where it is never opened at all — the query that slips out to public DNS because no forwarder ever sent it across the bridge.
Play it through
Three minutes, one bridge and one link. Watch the office ask public DNS for a name that lives in a private zone it cannot see, and watch the storage account refuse the public address that comes back. Then bridge it with a resolver and a forwarder — the shape of fix on-premises always needs — before linking a second virtual network to the zone directly, the fix a VNet gets and on-premises cannot use. It plays on its own and stops when it needs your hands.
Campux's bridge, with an expiry
The last year of the POS system on-premises
Campux builds a site-to-site VPN from the HQ firewall to the production VNet, terminated on a modestly-sized VPN gateway in the GatewaySubnet. Not ExpressRoute: the bridge is temporary — one year until the POS licence is renegotiated — and carries a nightly batch, not a torrent, so a provider circuit and its monthly cheque would be paying for reliability and bandwidth the job never uses. This is Class Five's discipline exactly: the bridge is a transition state with an end date, not a destination.
Then the harder half. The storefront in Azure reaches its storage over a private endpoint, so its name lives in a privatelink private DNS zone that only the VNet can see. For the on-premises POS job to reach anything in Azure by name, Campux stands up an Azure DNS Private Resolver in the VNet and points the office DNS servers at it with a conditional forwarder. Now the office and the cloud resolve the same names to the same private addresses — the deliberate DNS gotcha from Class Fourteen, this time solved across the bridge before it bites. When the licence is resolved and the POS job finally migrates, the VPN and the resolver come down together, and the bridge closes as planned.
The official module, and a CAMPUX overview
Host your domain on Azure DNS
learn.microsoft.com/training/modules/host-domain-azure-dns/
The bridge: Create a VPN gateway in the portal (docs tutorial)
learn.microsoft.com/azure/vpn-gateway/tutorial-create-gateway-portal
A short walkthrough of the hybrid bridge and why the office and the cloud disagree on names will live here. Video to be added.
Host a DNS zone the CLI way
Above, a resolver bridged the office and a link joined a new VNet. Below is the ordinary, public half of naming — the resolver and its two endpoints come back in Lab 3. The VPN gateway from §1 takes tens of minutes and bills heavily, so it is not a quick lab — but the DNS half is fast, cheap, and where the real hybrid pain lives. You will host a public zone, add a record, and read the name servers you would have to delegate to.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)
Create a uniquely named throwaway resource group and a public DNS zone. The reserved .example name is for learning; you do not need to own it:
RG="rg-campux-dns-$RANDOM" az group create --name "$RG" --location westeurope az network dns zone create --resource-group "$RG" \ --name campux-lab.example
What just happened: Azure created the authoritative directory for that name and assigned it four name servers. The domain will not resolve on the real internet until you delegate to them at a registrar — the step everyone forgets.Add an A record in the zone:
az network dns record-set a add-record --resource-group "$RG" \ --zone-name campux-lab.example --record-set-name store --ipv4-address 203.0.113.10
On screen: you just mapped store.campux-lab.example to an address. This is a record set — the ordinary, public half of naming.Read the name servers Azure assigned — the delegation target:
az network dns zone show --resource-group "$RG" \ --name campux-lab.example --query nameServers
The lesson: these four names are what you would enter at your registrar to make the zone authoritative on the internet. Without that handoff, the zone exists but no one on the internet consults it.Ask one of those name servers directly for the record you made. Predict the address first:
NS=$(az network dns zone show --resource-group "$RG" \ --name campux-lab.example --query "nameServers[0]" -o tsv) nslookup store.campux-lab.example "$NS"
Checkpoint: the answer shows 203.0.113.10. You asked Azure's server by name, so this works before any delegation. Ask your normal resolver instead (nslookup store.campux-lab.example with no server) and it fails, because the internet has not been told where this zone lives. Same name, two answers, depending on who you ask: that is the whole of §4 in miniature.Tear down:
az group delete --name "$RG" --yes --no-wait
Check first: this deletes the temporary group you just created. Do not substitute a group that holds other resources.
Host a DNS zone by hand
Now do it by clicking — the zone's overview is where the name servers are shown, and the record-set panel is where naming happens. Use a throwaway resource group.
Go to portal.azure.com and sign in.
In the search bar at the top, type DNS zones, select it, then click + Create.
Basics tab: subscription, a throwaway resource group, and the zone name campux-lab.example. Review + create.On screen: a public DNS zone by default — the kind reachable from the internet, as opposed to the private zones linked to a VNet you met in Class Fourteen.
Open the zone and read the Overview: the four Name servers are listed there.On screen: this is the delegation target. In a real setup you copy these to your registrar; until then the zone is authoritative only in Azure's eyes.
Click + Record set, add an A record named store pointing at an address, and save.On screen: the record set editor exposes the TTL — how long resolvers cache the answer. A high TTL means a change takes time to spread, which is exactly why DNS failover is never instant.
Tear down: delete the throwaway resource group.
Portal wording drifts; if a label here does not match your screen, the anchors are the DNS zones service, the zone's Name servers on Overview, and the Record set editor. The .example domain is reserved for documentation and will never resolve publicly — perfect for a throwaway lab.
See why the two sides disagree
Open the pieces that decide who can resolve what, and read the split that §4 is about.
If you kept a Private DNS zone from Class Fourteen, open it and read its Virtual network links. If you deleted the earlier lab resources, use the resolver and zone diagrams in §4 instead; no new billable resource is needed for this observation.Notice: linked VNets can query the zone directly through Azure-provided DNS. The office is not on this list; it needs forwarding to a resolver in a linked VNet. A spoke can also use an appropriate forwarding ruleset instead of a direct zone link.
On a VNet, open DNS servers under Settings.On screen: "Default (Azure-provided)" means resolution uses 168.63.129.16, which sees the linked private zones. Setting custom DNS servers here is how you point a VNet at your own resolver instead.
Search DNS Private Resolver in the top bar and open the service (create one only if you want to — it bills).On screen: inbound and outbound endpoints. The inbound endpoint is the address your on-premises DNS forwards to; it is the bridge that lets the office borrow Azure's directory, the fix for §4's disagreement.
Zoom out: the road is easy; two worlds agreeing on names is the hard part
You can size a VPN gateway against ExpressRoute. Now reason about what a hybrid link does to the whole system, because the tunnel being up is not the same as the two sides agreeing what a name means.
The VPN is up, so everyone assumes DNS works — until the office resolves an Azure name to nothing and the "network outage" is really a naming disagreement. What makes the two directories agree, and who checks it?
Hybrid couples the cloud’s usefulness to the on-prem link and to DNS resolution on both sides; a system is only as available as its narrowest agreement, not its fattest pipe.
The bottleneck is rarely bandwidth; it is the resolvers and the trust between them. Sizing the gateway does not fix a name that will not resolve.
A gateway sized for one nightly batch becomes the single point of failure once the whole estate leans on cross-boundary traffic.
Name resolution one person configured by hand becomes the thing nobody can debug when a merger adds a third DNS authority to the disagreement.
The engineer who ships is asked "can they reach it?" The engineer who gets promoted is asked "and do both sides agree what the name means?" — and joined the directories on purpose.
The problem wearing a networking costume
A migrated app in the office cannot reach a service in Azure — it keeps resolving the wrong address. You trace it to DNS, wire conditional forwarding so on-premises and cloud names resolve consistently across the link, and the mysterious "works in Azure but not from the office" ticket closes. Half of hybrid networking, you learn, is really a name-resolution problem wearing a networking costume.
This is the whiteboard round of an interview. Rehearse it where it is cheap.
Packets flowing is not names resolving. A VPN can be perfectly up while the office resolves an Azure name to nothing — or the wrong address — because the two directories were never joined. The tunnel is the easy half; the hard half of every hybrid deployment is DNS. If your sketch stops at the road, you have drawn the part that rarely breaks and skipped the part that always does. Add the resolvers on both sides and show the name being answered the same way from each.
Check both sides of hybrid DNS
Use the fictional evidence below. This is a desk exercise; it does not provision Azure resources or measure a live service.
Training trace A, office client: account.blob.core.windows.net → public address Training trace B, VNet client: same name → private endpoint 10.20.2.5 Office forwarder: no route to the intended private resolver
Start with the comparison: same name, two clients, two answers. Write down which answer each client got and why.
Identify which client still lacks the desired private resolution.
Draw the conditional forwarding and reachable resolver path needed by that client.
After a real configuration change, repeat DNS from that same client and test an authorised read; do not count a public-DNS lab as this proof.
Check your reasoning after you finish
The office client still follows public resolution. Repair the appropriate forwarding/resolver path and verify it from the office location. A private DNS answer alone does not prove routing or data permission.
Examination
The Whiteboard above, four drills here, 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.
A. A site-to-site VPN tunnels IPsec-encrypted traffic across the public internet. B is the trap: ExpressRoute is the opposite — a private, dedicated circuit that never touches the internet, which is the whole reason it costs more. C connects a PaaS service into a VNet, not two networks; D is naming, not a transport. If the words "encrypted" and "over the internet" appear together, it is a VPN.
C. ExpressRoute earns its higher cost and lead time when the traffic is heavy and sustained, the latency must be predictable, or a rule forbids the public internet even encrypted. A is the "to be safe" reflex that buys a monthly circuit for a problem you do not have; B is exactly the case a VPN handles well and cheaply — Campux's bridge. D confuses transport with naming: DNS resolves across a VPN just as well, given the resolver setup of §4.
Delegate public zones, use Azure-provided DNS for directly linked private zones, and use a linked forwarding ruleset when a spoke must ask the hub. On-premises resolvers do not automatically receive private answers; they need a reachable forwarding path into Azure. Public zones need no VPN once delegated.
HYBRID PLAN — Campux POS bridge
1. Site-to-site VPN from HQ to the production VNet over IPsec.
2. VPN gateway deployed into a dedicated GatewaySubnet.
3. On-prem apps reach Azure resources by private IP over the tunnel.
4. On-prem servers will resolve Azure private DNS names automatically
once the tunnel is up.
Line four. The tunnel carries packets, not directory knowledge. On-premises resolvers still consult their own DNS, which cannot see Azure's private zones — so a name in a privatelink zone resolves to a public IP or fails, even with the VPN perfectly up. Lines one to three are correct: IPsec VPN, the required dedicated GatewaySubnet, private-IP reachability over the tunnel.
Consider the consequence. Shipped as written, packets flow but the POS job cannot find anything by name, and the team burns a day debugging the "broken VPN" that is not broken. The fix is a DNS Private Resolver in the VNet plus a conditional forwarder on the office resolvers — the naming half the plan forgot. Reaching resources needs both a road and a shared directory.
The road works; the directories differ. That the VPN is up and private IPs ping is the clue, not a contradiction — connectivity is fine. Resolution differs because the two sides ask different DNS. From the Azure VM, Azure-provided DNS at 168.63.129.16 can see the private zone and returns the private endpoint IP. From the office, the machine asks the corporate resolver, which has never heard of that private zone and returns the public IP instead.
Name the asymmetry precisely. Azure-provided DNS can answer the private zone for a linked VNet. The office is not a VNet and cannot acquire that link; its DNS server needs a forwarding path into a linked VNet. The VPN moves packets but does not configure DNS forwarding.
Give the office a DNS path into Azure. Place a Private Resolver inbound endpoint (or a forwarding VM) in the linked VNet. Point the office conditional forwarder for blob.core.windows.net at it, because the client starts with account.blob.core.windows.net. The Azure resolver follows the service's CNAME into the linked private zone and returns the private IP. Then test the lookup and an authorized storage request from the office; a correct DNS answer alone does not prove the application can connect.
Grant the instinct, then size it. Wanting the bridge to be reliable is reasonable; ExpressRoute is simply the wrong instrument for this particular bridge. It is built for sustained, high-bandwidth, latency-sensitive connectivity — none of which a once-a-night batch job needs.
Price the mismatch in the director's terms. ExpressRoute means a connectivity provider, weeks of lead time, and a monthly circuit charge — for a connection that will be torn down in a year and is idle most of every day. A site-to-site VPN is live within the hour, costs a fraction, and comfortably carries a nightly reconciliation. Paying for ExpressRoute here is paying for reliability the workload cannot use.
Tie it to the decision already made. Class Five settled that this bridge is a transition state with an end date, not a destination. The connection should match: a VPN for the temporary year, and if a future workload ever genuinely needs sustained bandwidth to Azure, ExpressRoute gets revisited on its own merits. "Rock solid" for this traffic is a well-sized VPN, not an over-bought circuit.
Five things worth carrying out of this class
- A site-to-site VPN is an encrypted tunnel over the internet, terminated on a gateway in a GatewaySubnet. Size it to real traffic.
- ExpressRoute is a private, dedicated circuit — worth its cost only for sustained bandwidth, predictable latency, or a no-internet mandate.
- Azure DNS hosts public zones; the step people forget is delegating to the four assigned name servers at the registrar.
- Inside a VNet, Azure DNS at 168.63.129.16 sees linked private zones. On-premises resolvers do not — that asymmetry is the hybrid DNS problem.
- Fix hybrid resolution in DNS, not the network: a Private Resolver plus a conditional forwarder makes both sides agree on the name.
- Gateway provisioning genuinely takes a while — commonly on the order of half an hour or more — and the SKU sets both throughput and how many tunnels it can hold. Treat the exact minutes and per-SKU numbers as things that drift and belong on the current pricing and specs pages; the durable point is that a gateway is a real, hourly-billed resource you size to the traffic, not a switch you flip for free. ↩
- The "one autoregistration-enabled private zone per virtual network" rule is the durable point; a VNet can still be linked to many private zones, but only one of those links may carry autoregistration. Treat any specific per-zone or per-link count as a number that drifts and belongs on the current limits page — the shape of the constraint, not the digit, is what you carry into a design. ↩
- 168.63.129.16 is a fixed, Azure-wide virtual IP for the platform's DNS and health services — the same address in every VNet. It is one of the few magic numbers worth memorising, because "is the VNet using 168.63.129.16 or a custom resolver?" is the first question when private-zone resolution misbehaves inside Azure. ↩
- The Azure DNS Private Resolver is the managed way to bridge on-premises and Azure resolution; before it existed, teams ran a DNS forwarder on a small VM for the same purpose, and you will still see that pattern in older estates. Either way the idea is identical — give on-premises DNS something in the VNet to forward to. It bills while it runs, so in a lab, create it only to look and then delete it. ↩
Make names resolve correctly in both directions between an office and Azure, and say when the link should be a VPN or ExpressRoute.
Play the lesson above to stamp this class.