Microsoft Azure

Networking — Virtual Network & NSGs

Build an isolated private network with subnets and control traffic with Network Security Groups.

A VNet is your private network in a region, defined by an address space and divided into subnets.

A secure office complex: the VNet is the campus, subnets are buildings, and NSGs are the badge readers at each door that allow or deny based on who you are and where you came from. Private Endpoints are like installing a partner company's service desk inside your own lobby instead of sending staff out to the street.

Key Concepts

1
    VNet 10.0.0.0/16
      snet-gateway  10.0.1.0/24   Application Gateway
      snet-app      10.0.2.0/24   app tier, no public IP
      snet-data     10.0.3.0/24   database, private endpoint only
2
A subnet is regional, not zonal — unlike AWS, where each subnet sits in one AZ. Azure resources choose their zone independently of the subnet.
3
Azure reserves five addresses per subnet, so a /29 gives you three usable. Worth knowing before sizing something small.
4
NSGs are stateful allow and deny rules.
    priority 100  allow 443 from AppGateway-subnet
    priority 200  allow 1433 to snet-data
    priority 4096 DenyAllInbound   (default, always last)
5
Rules are evaluated by priority, lowest number first, and the first match wins. Return traffic is permitted automatically because they are stateful.
6
Application Security Groups replace IP lists. Tag VMs with an ASG and write rules against the group, so machines can scale and move without rule changes.
7
Service tags do the same for Azure services — Storage, Sql, AzureMonitor — instead of maintaining IP ranges that change.
StorageSqlAzureMonitor
8
Private Endpoints are the important modern pattern. They give a PaaS service — a storage account, SQL database, Key Vault — a private IP inside your VNet, so traffic never traverses the internet and the public endpoint can be disabled entirely. They need a Private DNS zone so the public hostname resolves to that private address.
9
Service Endpoints are the older, weaker alternative: traffic stays on the Azure backbone but the service keeps its public endpoint.
10
Beyond one VNet.
    VNet Peering    non-transitive -- A-B and B-C does NOT give A-C
    Hub and spoke   a hub VNet with shared firewall and gateway
    VPN / ExpressRoute   to on-premises
    Azure Firewall  central egress filtering with FQDN rules
11
Peering being non-transitive is the detail that catches people designing hub-and-spoke.
12
What the interviewer is probing.1. "How many usable addresses does a /29 subnet give you?" Probing: the reserved addresses. Stalls: "Eight." Moves up: three — Azure reserves five per subnet.
13
2. "Your NSG allows inbound 443 but traffic still fails. What do you check?" Probing: rule evaluation and the other direction. Stalls: "The rule is there, so it works." Moves up: rules evaluate by priority with the first match winning, and a lower-numbered deny can precede it; also check the outbound rules and the subnet-level NSG.
14
3. "What is a Private Endpoint and why prefer it to a Service Endpoint?" Probing: the modern pattern. Stalls: "They are the same." Moves up: a Private Endpoint gives the PaaS service a private IP in your VNet so the public endpoint can be disabled; a Service Endpoint keeps the public endpoint and only routes over the backbone.
15
4. "A is peered with B, and B with C. Can A reach C?" Probing: transitivity. Stalls: "Yes." Moves up: no — peering is not transitive, which is why hub-and-spoke needs explicit links or a firewall in the hub.