Phase 06 — Azure Networking & the Software-Defined Network

Difficulty: ⭐⭐⭐⭐☆ (the mechanism is exact; the judgment is hard) Estimated Time: 1–1.5 weeks (14–20 hours) Prerequisites: Phase 00 (control plane vs data plane), and ideally Phases 03–05 (identity and governance) — because in a regulated estate, the network is the second perimeter after identity, and a landing zone hands you the hub-and-spoke you deploy into.

Why This Phase Exists

Every other phase assumes packets reach the right place and the wrong packets do not. This phase is where that assumption gets built. In Azure there is no physical network you can trace with a cable — the VNet, the subnet, the firewall, the route, the load balancer are all software running on the hosts, enforced by the virtual filtering platform (VFP) on every NIC. That is the gift and the curse: the network is programmable, versioned, and policy-driven (the gift), and it is invisible unless you understand the algorithms that decide each packet's fate (the curse).

The JD is explicit that this is a principal-level expectation:

"Networking is software-defined. You can evaluate an NSG rule set in priority order, compute effective routes with longest-prefix matching across system/UDR/BGP routes, and explain why a Private Endpoint changes DNS resolution and how that breaks (and fixes) connectivity."

Those three sentences are three engines, and this phase makes you build them. Not because you will reimplement Azure, but because the engineer who has implemented NSG priority evaluation never again guesses why a packet was dropped — they read the effective-rules dump the way they read code. The single most common production network incident in Azure is a broken Private Endpoint DNS resolution, and the single most common interview trap is priority ordering / longest-prefix match. Both are in this lab.

The mental model: the four questions every packet answers

A packet leaving a VM in Azure passes through four decisions, in order. Hold this picture — it is the spine of the whole phase:

            ┌─────────────────────────────────────────────────────────────┐
   VM NIC → │ 1. NSG (outbound)   2. Route table        3. NSG (inbound,    │ → destination
            │    allow/deny?         where's next hop?      at the dest)     │
            │    priority order      longest-prefix        allow/deny?       │
            └─────────────────────────────────────────────────────────────┘
                          ▲                                   ▲
              and BEFORE any of it: 0. DNS — what IP is the destination?
              (the Private Endpoint override lives here — and breaks here)

Numbered the way you debug them: (0) DNS resolves the name to an IP — and a Private Endpoint silently rewrites that IP; (1) the source NSG decides if the flow may leave; (2) the route table picks the next hop by longest-prefix match (this is where a firewall UDR intercepts everything); (3) the destination NSG decides if the flow may arrive. Miss any one and the packet vanishes with no error. The lab builds engines for 0, 1, and 2 (DNS, NSG, routes) plus the address math underneath all of it.

Concepts

The VNet / subnet model — a software-defined L3 network: a private CIDR (RFC 1918) scoped to one region and one subscription, carved into subnets. There is no router; the host enforces routing and filtering in software. Azure reserves 5 IPs per subnet and the smallest usable subnet is /29.
Network Security Groups (NSGs) — stateful, priority-ordered (100..4096) allow/deny rules evaluated lowest-number-first, first-match-wins, with default rules (allow VirtualNetwork↔VirtualNetwork + AzureLoadBalancer inbound, deny the rest). Stateful means return traffic is implicit — you never write a return rule.
Effective routes & UDR — the per-NIC route table is the union of system routes, your UDRs, and BGP-learned routes. The next hop is chosen by longest-prefix match; on a tie, UDR > BGP > system. A 0.0.0.0/0 UDR to a VirtualAppliance force-tunnels all egress through a firewall/NVA.
Private Endpoint / Private Link — a private IP for a PaaS resource that rewrites DNS: the public FQDN (e.g. acct.blob.core.windows.net) resolves to the private IP via a Private DNS zone (privatelink.blob.core.windows.net) linked to the VNet. The #1 failure is broken DNS (the zone isn't linked → still resolves public). Service endpoints are the older, coarser alternative (keep traffic on the backbone, but the resource keeps its public IP).
Topology — hub-and-spoke with VNet peering, an Azure Firewall in the hub, and the load-balancing trinity: Front Door (global L7), Application Gateway (regional L7 + WAF), Load Balancer (regional L4). Where each sits is an exam and an architecture question.

Labs

Lab 01 — Network Engine (flagship, implemented)

Field	Value
Goal	Build the four decision engines of Azure's SDN: subnet/CIDR math (5 reserved IPs, /29 minimum, split), the NSG priority/first-match/default-rule evaluator, the effective-route longest-prefix engine with UDR>BGP>system tie-break, and the Private Endpoint DNS-override resolver
Concepts	reserved IPs and the /29 floor; stateful priority-ordered first-match NSG evaluation; longest-prefix routing and route origin tie-break; the Private DNS override and its #1 failure mode
Steps	1. CIDR math (`subnet_usable_hosts`, `cidr_contains`, `split_subnet`); 2. `NsgRule` + `evaluate_nsg` with defaults; 3. `Route` + `effective_next_hop`; 4. `PrivateZone` + `resolve_fqdn`
How to Test	`pytest test_lab.py -v` — 25 tests: the −5 and /29 boundary, containment both ways, NSG priority/first-match/default allow+deny, longest-prefix /32 vs /0 and the UDR>system tie, and private-vs-public DNS with/without a link
Talking Points	"Walk me through NSG evaluation order." "A packet is dropped and every rule looks fine — where do you look?" "Why does my storage account still resolve to a public IP after I created the Private Endpoint?" "Force all egress through a firewall — what exactly do you change?"
Resume bullet	Built a network-policy decision engine (NSG priority evaluation, longest-prefix effective routing, Private Endpoint DNS override) that reproduces the real allow/deny, force-tunnel, and broken-DNS failure modes

→ Lab folder: lab-01-network-engine/

Integrated-Scenario Suggestions (carried through the whole track)

The network is the substrate the rest of the platform deploys into. Keep these in mind — each maps a JD theme onto the engines you build here:

Hub-and-spoke landing-zone network — a hub VNet with Azure Firewall and a VPN/ER gateway, peered to app/data spokes; a UDR in every spoke forcing 0.0.0.0/0 to the firewall; NSGs per subnet tier (web/app/data). Your effective_next_hop and evaluate_nsg are the verifier for "does this packet take the path I think?"
Private-only PaaS — storage, Key Vault, SQL, and Service Bus exposed only via Private Endpoints, public access disabled, with a centralised Private DNS zone resolver linked to every spoke. Your resolve_fqdn reproduces the make-or-break DNS step.
Zero-trust micro-segmentation — deny-by-default NSGs, Application Security Groups per workload role, just-in-time access; the platform team owns the rule baseline, app teams request exceptions. Your priority/first-match engine is the policy the baseline encodes.
Ingress trinity — Front Door (global routing + WAF + caching) → Application Gateway (regional L7 + WAF + path routing) → internal Load Balancer (L4) → AKS/VMSS. The framing question: which layer terminates TLS, which does WAF, which does L4?
Hybrid connectivity — ExpressRoute + VPN with BGP route propagation into the hub, and the route-table arithmetic (BGP-learned vs UDR override) that decides whether on-prem traffic transits the firewall. Your route-origin tie-break is exactly this decision.

Guides in This Phase

HITCHHIKERS-GUIDE.md — the 30-minute orientation: the numbers, the az one-liners, the war stories; read first
WARMUP.md — the full professor primer; read slowly, with the subnet math
BROTHER-TALK.md — the candid version: why DNS is always the answer

Key Takeaways

The Azure network is software-defined: NSGs, routes, firewalls, and load balancers are algorithms running on the hosts. Learn the algorithm and the network stops being a black box.
NSG = priority order, first match wins, stateful, deny-by-default. A low-number Deny shadows a high-number Allow. Return traffic is implicit.
Routing = longest-prefix match, UDR > BGP > system. A /32 UDR pins one host; a /0 UDR force-tunnels the world through your firewall.
Private Endpoint = a private IP + a DNS rewrite. When Private Link "doesn't work," it is almost always the DNS zone not linked to the VNet — and the symptom is a public IP where you expected a private one.
Topology is a tradeoff, not a default: hub-and-spoke centralises the firewall and the bill; Front Door vs App Gateway vs Load Balancer is L7-global vs L7-regional vs L4.

Deliverables Checklist

Lab 01 implemented; all 25 tests pass against solution.py and your lab.py
You can compute usable hosts for any prefix and state Azure's /29 floor from memory
You can hand-evaluate an NSG rule set in priority order and name the deciding rule
You can read an effective route table and predict the next hop by longest-prefix match
You can diagnose a "Private Endpoint not working" report as a DNS-link problem and say exactly which az network private-dns ... link is missing
You can draw the hub-and-spoke + firewall + Private DNS topology from memory and place Front Door / App Gateway / Load Balancer at the right layer

Principal Azure Cloud Engineer & Architect