Virtual Networks & Subnets

A Virtual Network is your private city in Azure. Everything inside the city is yours, private, isolated from other organisations, invisible to the public internet unless you explicitly open doors. When you create a VNet you define an address space, a range of IP addresses that exist within this city. Typically something like 10.40.0.0 slash 16, giving you 65,536 IP addresses. Subnets are the neighbourhoods within your city. You carve your address space into subnets. The web tier at 10.40.1.0 slash 24, the data tier at 10.40.2.0 slash 24, management at 10.40.3.0 slash 24. Resources in different subnets can communicate by default but you control that with Network Security Groups. CIDR notation: the slash number tells you how many bits are fixed. Slash 16 means 65,536 addresses. Slash 24 means 256 addresses. But Azure reserves 5 of those for internal use. The network address, the default gateway, two DNS addresses, and the broadcast address. So a slash 24 subnet gives you 251 usable IP addresses. That specific number, 251, appears on. the exam repeatedly. Special subnets have exact naming requirements. Bastion requires AzureBastionSubnet, exact case, no variations. Azure Firewall requires AzureFirewallSubnet. VPN and ExpressRoute require GatewaySubnet. These names are hardcoded requirements, not suggestions. Always use Standard SKU public IPs. They are static, zone-redundant, and secure by default. Basic SKU is being deprecated and is insecure by default because inbound connections are allowed from anywhere. VNets exist within one region. You cannot stretch a VNet across regions. To connect resources across regions, use VNet Peering. To connect to on-premises, use VPN Gateway or ExpressRoute, both requiring a GatewaySubnet inside your VNet. You can add address space to an existing VNet but cannot change an existing subnet's range if it has resources in it. Plan your subnets generously.. Remember: Slash 24 gives 251 usable IPs. Special subnets have exact names: AzureBastionSubnet, AzureFirewallSubnet, GatewaySubnet. Always use Standard SKU public IPs. VNet exists in one region.

CIDR — Understanding Address Spaces

Public IP — SKU Matters

Network Security Groups are Azure's traffic filtering layer. An NSG is a stateful packet inspector sitting at the boundary of a subnet or network interface. Stateful means if you allow an inbound connection, the return traffic is automatically allowed without needing an explicit outbound rule. Your NSG allows inbound HTTPS on port 443. When the VM responds, Azure knows this is return traffic for an allowed connection and lets it through automatically. NSG rules have a priority number. Lower number means higher priority. Each rule has a source, destination, protocol, port range, and action of allow or deny. First matching rule wins. Evaluation stops. Default rules are built into every NSG. 65000 AllowVnetInBound allows traffic between resources in the same VNet. 65001 AllowAzureLoadBalancerInBound allows health probe traffic. 65500 DenyAllInBound blocks everything else. Outbound defaults: 65000 allows VNet-to-VNet, 65001 allows internet outbound, 65500 denies everything else. Evaluation order. the exam tests constantly: for inbound traffic, the subnet NSG is evaluated first, then the NIC NSG. Both must allow the traffic. For outbound traffic, the NIC NSG is evaluated first, then the subnet NSG. Reversed order. This matters practically. If you add an allow rule to the subnet NSG for port 1433 but the NIC NSG has a deny rule for 1433, traffic is still blocked. Use Effective Security Rules in Network Watcher to see the combined result of all NSGs on a NIC. Classic production incident: all VMs show unhealthy behind a load balancer. The NSG looks fine for application traffic. The problem is health probe traffic comes from the AzureLoadBalancer service tag at IP 168.63.129.16. If your NSG does not allow this tag inbound on the probe port, probes fail and all VMs appear unhealthy. Application Security Groups let you tag VM NICs with a label instead of using IP addresses in rules. NSG rule says allow asg-web-servers to reach asg-db-servers on port 1433. Add a new VM, tag its NIC with the ASG, it is immediately covered. No IP management.. Remember: NSG is stateful, return traffic is automatic. Inbound: subnet first, NIC second. Outbound: NIC first, subnet second. Both must allow. AzureLoadBalancer tag must be allowed for health probes.

Application Security Groups (ASG)

Azure Bastion solves the problem of securely connecting to VMs without exposing RDP or SSH to the internet. The old approach: assign public IPs to VMs and open port 3389 or 22 in the NSG. This works but means those ports are exposed to the entire internet. Attackers scan for open RDP ports constantly. Within minutes of deploying a VM with port 3389 open, you will see authentication attempts in your logs. Azure Bastion is the secure alternative. You deploy one Bastion resource per VNet. Administrators connect through the Azure Portal using their browser over standard HTTPS on port 443. Bastion authenticates them using Entra ID credentials and Azure RBAC, then establishes the RDP or SSH connection to the target VM through the VNet's private network. The whole session runs as HTML5 in the browser. Result: VMs have no public IP addresses. Port 3389 and port 22 are never exposed to the internet. The only port needed is 443, the same port used for every website. Two exact requirements you must know for. the exam. The subnet must be named exactly AzureBastionSubnet with capital A, capital B, capital S. Not bastion-subnet. Not BastionSubnet. Exactly AzureBastionSubnet. Azure looks for this exact name. Deploy with any other name and deployment fails. The subnet must be slash 27 minimum, giving 32 IP addresses with 27 usable. Azure needs multiple IP addresses for Bastion's high availability. A slash 28 is not enough. Deployment fails. No other resources can share this subnet. The Bastion service itself needs a Standard SKU static public IP. Not Basic, not dynamic. Standard and static. Two SKUs for Bastion: Basic gives RDP and SSH connections only. Standard adds copy-paste between local machine and VM, file upload and download, connect by IP address, and reach VMs in peered VNets from one Bastion deployment.. Remember: Subnet name must be exactly AzureBastionSubnet, case-sensitive. Minimum slash 27. Standard SKU static public IP on Bastion itself. Standard Bastion SKU adds copy-paste and file transfer.

VNet Peering connects two Azure Virtual Networks so their resources can communicate privately through Microsoft's backbone network, not the public internet. Traffic between peered VNets never leaves Microsoft's infrastructure. Low latency, high bandwidth, private. From a routing perspective, once peered, a VM in VNet-A and a VM in VNet-B communicate as if they were in the same network. Their private IP addresses are directly reachable. The most important thing about peering: it is NOT transitive. Three VNets, A, B, and C. You peer A with B. You peer B with C. Can A reach C? No. Even though B is connected to both, traffic cannot transit through B automatically. Azure does not route traffic through an intermediate VNet unless you explicitly configure it with User-Defined Routes and a virtual appliance like a firewall. The second critical fact: peering requires both directions. Create peering from VNet-A to VNet-B and you see status as Initiated. Traffic still does not flow. You must also create the peering from VNet-B to VNet-A. Only when both show Connected does traffic flow. This catches people constantly in production. Team A creates their side, announces it is done, wonders why connectivity is not working. Because Team B has not created their side. Hub-spoke architecture uses peering at scale. One VNet is the hub, containing shared services like VPN Gateway, Azure Firewall, and Bastion. All other VNets are spokes that peer to the hub. Without a hub, 10 VNets needing to connect to each other require 45 peering connections. With hub-spoke, you need only 10. Three peering settings for hub-spoke: Allow Gateway Transit on the hub lets spokes use the hub's VPN Gateway without each spoke having its own. Use Remote Gateways on the spoke tells it to use the hub's gateway. Allow Forwarded Traffic on both permits traffic that originated outside a VNet to pass through. Peering requires non-overlapping address spaces. Two VNets with the same range cannot be peered.. Remember: Peering is NOT transitive. Requires both directions, both must show Connected. Hub-spoke for shared services. Allow Gateway Transit on hub, Use Remote Gateways on spoke.

# Direction 1: Dev → Prod
az network vnet peering create \
  -g RG-Dev --name Dev-to-Prod \
  --vnet-name vnet-dev \
  --remote-vnet /subscriptions/PROD-SUB-ID/resourceGroups/RG-Prod/providers/Microsoft.Network/virtualNetworks/vnet-prod \
  --allow-vnet-access --allow-forwarded-traffic

# Direction 2: Prod → Dev (REQUIRED — without this status = "Initiated")
az network vnet peering create \
  -g RG-Prod --name Prod-to-Dev \
  --vnet-name vnet-prod \
  --remote-vnet /subscriptions/DEV-SUB-ID/resourceGroups/RG-Dev/providers/Microsoft.Network/virtualNetworks/vnet-dev \
  --allow-vnet-access --allow-forwarded-traffic

# Verify — both should show "Connected"
az network vnet peering show -g RG-Dev --vnet-name vnet-dev \
  --name Dev-to-Prod --query peeringState

User-Defined Routes give you control over where Azure sends network traffic by overriding Azure's automatic routing decisions. By default Azure routes traffic automatically. VMs within the same VNet reach each other directly. Internet-bound traffic exits through the VNet's internet gateway. This works fine until you need all traffic to pass through a firewall first. That is where Route Tables come in. You create a Route Table resource, add routes, and associate it with a subnet. Each route has a destination address prefix and a next hop. Your firewall route table might have destination 0.0.0.0 slash 0, meaning everything, with next hop Virtual Appliance at 10.0.1.4, your firewall's private IP. That single route forces all traffic from VMs in that subnet through the firewall first. The most important routing rule: longest prefix match. If a packet matches multiple routes, Azure uses the most specific one, the route with the longest prefix. A route for 10.40.0.0 slash 16 is less specific than a route for 10.40.1.0 slash 24. If a packet is going to 10.40.1.5, the slash 24 route wins. Next hop types: Virtual Appliance means a specific IP, your firewall. VirtualNetworkGateway sends to your VPN or ExpressRoute gateway. VirtualNetwork keeps traffic within the VNet. Internet sends out to the public internet. None is a black hole, traffic silently dropped. The critical gotcha on. the exam: creating a Route Table and adding routes does absolutely nothing until you associate the Route Table with a subnet. The routes sit idle until associated. When troubleshooting a UDR that is not working, first check: is the route table associated to the correct subnet? Use Network Watcher's Next Hop feature to verify routing. Input a source VM and destination IP. Next Hop tells you where Azure will actually route that packet. If it says Internet when you expect VirtualAppliance, your UDR is not applied.. Remember: Route Table must be associated to a subnet, creating routes alone does nothing. Longest prefix match wins. None is a black hole. Use Network Watcher Next Hop to verify routing.

# Create route table
az network route-table create -g RG-Prod --name rt-spoke-web

# Add route: all internet → Firewall
az network route-table route create \
  -g RG-Prod --route-table-name rt-spoke-web \
  --name default-to-fw \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

# ASSOCIATE to subnet (required — without this nothing works)
az network vnet subnet update \
  -g RG-Prod --vnet-name vnet-prod \
  --name web-subnet \
  --route-table rt-spoke-web

Service Endpoints and Private Endpoints both help you access Azure PaaS services more securely, but they work completely differently. By default, your VM talking to Azure Storage takes a public internet path even though both are in Azure. Service Endpoints fix the routing. Enable a Service Endpoint for Microsoft.Storage on a subnet, and traffic from VMs in that subnet to Storage takes Microsoft's private backbone instead of the public internet. It is a routing change. The destination is still a public IP address but the path is private. Service Endpoints require exactly two steps. Step one: enable the endpoint type on the subnet. Step two: add a Virtual Network rule in the storage account's firewall settings. Miss either step and it does not work. Service Endpoints are free, easy to configure, and work for traffic originating from within Azure VNets. Limitation: they do not work for on-premises access. Private Endpoints are fundamentally different. Instead of a routing change, a Private Endpoint gives the PaaS service a private IP address inside your VNet. Your storage account gets a network interface with a private IP in your subnet. Traffic stays entirely within your VNet. You can disable the public endpoint entirely. Private Endpoints also work for on-premises access through VPN or ExpressRoute. But Private Endpoints have a critical dependency that is easy to miss: DNS. After creating a Private Endpoint, DNS still returns the public IP for the service. Your VM resolves the storage hostname and gets the public IP. Traffic tries to go to the public endpoint, bypassing your Private Endpoint entirely. The fix: create a Private DNS Zone for the service. For Blob storage that is privatelink.blob.core.windows.net. Add an A record mapping the hostname to its private IP. Link this zone to your VNet. Now VMs resolve to the private IP and traffic goes through the Private Endpoint. If you tick Integrate with private DNS zone when creating the Private Endpoint in the portal, Azure handles this automatically. In automation, it is a separate step easy to forget.. Remember: Service Endpoint is a routing change, free, Azure-only. Private Endpoint gives PaaS a private IP in your VNet, works for on-premises too. Private Endpoint requires Private DNS Zone linked to VNet for correct name resolution.

Azure DNS has two distinct modes: public zones for internet-facing name resolution and private zones for internal VNet name resolution. Public DNS Zones host the DNS records of your internet-facing domains. If you own kubemind.in, create a public DNS zone in Azure, transfer name server authority to Azure's DNS servers, and manage all records from Azure. Record types you need to know: A records map hostname to IPv4 address. CNAME records create an alias, one hostname pointing to another hostname. MX records direct email. TXT records store verification text. NS records delegate to nameservers.. The exam gotcha: you cannot create a CNAME record for the apex domain, also called the root or naked domain. The apex is yourcompany.com with no prefix. CNAME requires pointing to another hostname but DNS specifications say the apex must be an A or NS record. So if you want kubemind.in pointing to Azure Traffic Manager or Front Door, a CNAME does not work. The solution is Azure DNS Alias Records, an Azure-specific extension. An Alias record at the apex points directly to an Azure resource like Traffic Manager, Front Door, or a public IP. Azure resolves the current IP of that resource dynamically. As the resource IP changes, the alias automatically updates. Private DNS Zones are for internal name resolution within VNets. Create a zone like kube.internal, add A records for VMs and services, and link the zone to VNets. VMs in linked VNets resolve these internal names without them being visible on the internet. Most common use for Private DNS Zones: Private Endpoints. After creating a Private Endpoint for Cosmos DB, DNS still returns the public IP without a Private DNS Zone. Create a zone for privatelink.documents.azure.com, add an A record mapping the hostname to the private IP, link the zone to your VNet. Now VMs resolve to the private IP and traffic goes through the Private Endpoint. Linking with auto-registration means every VM that starts automatically gets a DNS A record.. Remember: CNAME cannot be at the apex domain, use Alias records instead. Private DNS Zone must be linked to VNet for Private Endpoint resolution to work.

Azure has four load balancing services and. the exam will present scenarios asking which one to choose. The decision comes down to: is this HTTP traffic or non-HTTP traffic, and is this regional or global? Azure Load Balancer operates at Layer 4, the transport layer, TCP and UDP. It distributes connections across backend VMs using a hash of source IP, source port, destination IP, destination port, and protocol. Fast, simple, the right choice for anything that is not HTTP. SQL Server connections, RDP, LDAP, custom TCP protocols. Application Gateway operates at Layer 7, the HTTP application layer. It reads the actual content of HTTP requests. It can route based on URL path, sending requests to slash api to one set of servers and slash images to another. It can route based on hostname. It does SSL termination, handling HTTPS decryption so backend servers only see plain HTTP. It has a built-in Web Application Firewall protecting against SQL injection and cross-site scripting. Application Gateway is regional, living in one Azure region. Azure Front Door is Application Gateway's global cousin. Same Layer 7 HTTP capabilities, URL routing, SSL, WAF, but operating globally across Microsoft's edge network. It uses anycast routing, meaning users connect to the nearest Front Door point of presence worldwide. Front Door also has CDN capabilities, caching static content at the edge. If your application serves users in India, the US, and Europe, Front Door routes each user to the nearest healthy backend automatically. Traffic Manager is DNS-based load balancing. It does not touch your actual traffic at all. It answers DNS queries and returns the IP address of the appropriate backend based on routing policies. Performance routing sends users to the lowest latency backend. Priority routing fails over to secondary when primary is unhealthy. Geographic routing sends users from specific countries to specific backends. No SSL offload, no URL routing, no WAF. Just DNS answers. Decision framework: non-HTTP traffic like SQL or RDP use Azure Load Balancer. HTTP with URL routing and WAF in one region use Application Gateway. HTTP with global users and CDN use Azure Front Door. DNS-based failover between regions use Traffic Manager. Standard Load Balancer requires Standard SKU public IP.. Remember: LB is Layer 4, App Gateway is Layer 7 regional, Front Door is Layer 7 global, Traffic Manager is DNS-based.

NAT Gateway solves the outbound connectivity problem. Many VMs needing to reach the internet with a predictable consistent public IP address. By default when a VM makes an outbound internet request, Azure assigns it a source IP from a shared pool. The IP is unpredictable and shared with other customers. If your application calls an external API that only accepts traffic from specific IPs, you cannot whitelist anything. If Azure exhausts shared SNAT ports under load, your connections get dropped silently. NAT Gateway fixes this. Create one NAT Gateway, assign it a public IP, and associate it with one or more subnets. Every VM in those subnets now makes outbound connections appearing to come from that NAT Gateway's public IP. Consistent, predictable, exclusively yours. The post office metaphor: without NAT Gateway, each VM writes its own return address on outbound mail and Azure might change those addresses. With NAT Gateway, there is one post office with one fixed address. All outbound mail goes out from the post office. Responses come back to the post office which routes them to the right VM internally. Practical benefits: external APIs whitelist one IP instead of tracking unpredictable dynamic IPs. You get consistent SNAT port availability, 64,000 ports per public IP, and you can attach up to 16 public IPs. For high-volume outbound scenarios like IoT telemetry senders, this eliminates SNAT exhaustion. Priority hierarchy for outbound connectivity that. the exam tests: if a VM has its own instance-level public IP, that IP is used directly and NAT Gateway is bypassed. If the VM's load balancer has outbound rules, those override NAT Gateway. If neither applies, NAT Gateway handles outbound. If nothing exists, Azure uses default SNAT from the shared pool. NAT Gateway cannot do inbound connections. NAT Gateway is strictly outbound only. For inbound you need a load balancer, a public IP on the VM, or Application Gateway.. Remember: NAT Gateway provides consistent outbound IP for all subnet VMs. Outbound only, no inbound. Priority: instance PIP, then LB outbound rule, then NAT Gateway, then default SNAT. Associate to subnet.

Azure Network Watcher is your diagnostic toolkit for Azure networking. Think of it as the debugger for your network, the equivalent of opening DevTools in a browser but for packet flows, routing decisions, and security rule evaluations. Without Network Watcher, when something is not connecting, you are guessing. With it, you get precise answers in seconds. Let me walk through the tools you need to know. IP Flow Verify answers one question: is a specific packet allowed or blocked by NSG rules? You specify a source IP, source port, destination IP, destination port, and protocol. Azure evaluates all NSGs on the path and tells you Allow or Deny and the exact rule name responsible. This is the tool when you suspect an NSG is blocking traffic. Next Hop answers a different question: where will Azure actually route a packet from this VM to this destination? It tells you the next hop type and IP. If you have a User-Defined Route sending traffic to a firewall, Next Hop confirms the UDR is working. If it says Internet when you expected VirtualAppliance, your route table is not associated to the subnet. Connection Troubleshoot tests actual end-to-end connectivity between two endpoints on a specific port and protocol. It simulates the connection and tells you if it succeeds or fails, and why. Effective Security Rules shows you the combined result of all NSGs applied to a specific NIC. Instead of opening each NSG separately, this one view merges subnet NSG and NIC NSG rules in priority order. NSG Flow Logs capture every allowed and denied flow through an NSG, written to a storage account. Essential for security investigations and compliance auditing. Packet Capture captures actual network traffic from a VM and saves it as a pcap file. Wireshark for your cloud VMs without installing anything on the VM.. The exam asks you to distinguish between IP Flow Verify and Next Hop. IP Flow Verify is for NSG diagnosis. Next Hop is for routing diagnosis.. Remember that and you will answer any Network Watcher scenario correctly.