Microsoft AZ-104 - Microsoft Azure Administrator -Virtual Networking
Implement and Manage Virtual Networking — 15–20% of exam
Configure and manage virtual networks in Azure
Create and configure virtual networks and subnets
Create and configure virtual network peering
Configure public IP addresses
Configure user-defined routes
Other Azure Network Topics (Express Route)
Azure Virtual WAN
File share settings, configure identity-based access for storage
Azure network performance Optimizations and Redundancy
Troubleshoot network connectivity
Configure secure access to virtual networks
Create and configure network security groups (NSGs) and application security groups
Evaluate effective security rules in NSGs
Implement Azure Bastion
Configure service endpoints for Azure platform as a service (PaaS)
Configure private endpoints for Azure PaaS
Configure name resolution and load balancing
Configure Azure DNS
Configure an internal or public load balancer
Troubleshoot load balancing
Configure and manage virtual networks in Azure
Create and configure virtual networks and subnets
Create and configure virtual network peering
Configure public IP addresses
Configure user-defined routes
Other Azure Network Topics (Express Route)
Azure Virtual WAN
File share settings, configure identity-based access for storage
Azure network performance Optimizations and Redundancy
Troubleshoot network connectivity
Create and configure virtual networks and subnets
An Azure virtual network (VNet) provides a private network for Azure resources. It belongs to a subscription and is deployed in a specific region. Its address space, for example, 10.0.0.0/16, is divided into subnets with non-overlapping address ranges. VNets and their subnets span availability zones within that region.
In the diagram:
Subnet1: 10.0.1.0/24; NIC1 uses 10.0.1.4.
Subnet2: 10.0.2.0/24; NIC2 uses 10.0.2.4.
Each /24 contains 256 IPv4 addresses. Azure reserves the first four and last address, leaving 251 assignable addresses.
An Azure network interface (NIC) connects a virtual machine to a subnet within a VNet. Every Azure VM requires at least one NIC for network communication. A VM can have multiple NICs, depending on the selected VM size.
For a VM with multiple NICs:
One NIC is designated as the primary NIC.
NICs can connect to different subnets, but all must connect to the same VNet.
The VM size determines the maximum supported NIC count.
IP configuration: Configure dynamic or static private IP allocation on the Azure NIC. Azure DHCP delivers the primary private IPv4 configuration to the guest operating system, even when the address allocation is static.
Configure public IP addresses
Azure NAT Gateway
Azure NAT Gateway provides outbound internet connectivity for VMs that use private IP addresses. Associate the NAT gateway with the workload subnet and configure its public IP address or public IP prefix. Internet services see the gateway’s public address rather than the VM’s private address. Individual VMs do not require public IP addresses.
VMs initiate outbound connections through source network address translation (SNAT).
Replies to those established connections are allowed.
Internet hosts cannot initiate new inbound connections through NAT Gateway. This restriction applies to the NAT path; a separate public Load Balancer can still provide inbound access.
Azure VPN Gateway (Not necessarily Internet access)
Azure VPN Gateway provides the separate encrypted connection to an on-premises network. Deploy a virtual network gateway of type VPN in the dedicated GatewaySubnet. A site-to-site connection uses an IPsec/IKE tunnel between the Azure VPN gateway and the on-premises VPN device. A local network gateway is an Azure configuration resource representing the on-premises endpoint and address ranges.
Load balancers
A Standard public Load Balancer exposes a public frontend IP address and distributes incoming TCP/UDP connections across healthy backend VMs using their private IP addresses. Configure a backend pool, load-balancing rule, health probe, and NSG rules that permit application traffic and health probes. Microsoft Learn
The diagram shows a zone-redundant frontend serving VMs in three availability zones. Health probes identify unhealthy backends so new connections can be directed to healthy instances. NAT Gateway can provide separate outbound connectivity for connections initiated by these backend VMs. Microsoft Learn
The dotted red lines represent availability-zone divisions within one region. The VNet and subnet extend across those zones; they are not separate subnets. Resource groups are logical management containers, and their resources can reside in different regions.
AZ-104 question: Encrypted connectivity to on-premises
Correct answer: a virtual network gateway, configured as a VPN gateway. Its public IP supports the tunnel endpoint; the gateway establishes the encrypted connection.
Other option | Why it does not meet the requirement |
Private endpoint connection | Provides private access to a specific service; it does not establish a site-to-site VPN. |
Public IP address | An address alone provides no encrypted tunnel. |
Internet routing | Controls traffic routing; it does not establish a VPN tunnel. |
Exam tip: “VNet to on-premises” plus “encrypted” points to VPN Gateway. ExpressRoute provides private connectivity but is not encrypted by default.
Create and configure virtual network peering
Virtual network peering connects Azure VNets so their resources can communicate using private IP addresses over Microsoft’s backbone. They function as one network for connectivity purposes while remaining separate VNets with their own configurations and security controls. No public IP address or VPN gateway is required for the peering connection.
Peering type | Connects | Example |
Regional VNet peering | VNets within the same Azure region | East US → East US |
Global VNet peering | VNets in different Azure regions | East US → West Europe |
Both provide low-latency, high-bandwidth connectivity. Peering can also connect VNets across subscriptions and Microsoft Entra tenants when the required permissions are configured.
If VNet A peers with B, and B peers with C, A does not automatically gain connectivity to C.
To connect A and C, either:
Create direct A–C peering.
Design a transit path through Azure Firewall or a network virtual appliance, with appropriate routes and forwarding settings.
Selecting Allow forwarded traffic alone does not create that transit path.
Gateway transit is a separate configuration that lets a spoke use a hub’s VPN or ExpressRoute gateway. Peering alone does not automatically share the hub’s NAT Gateway or internet egress.
Peering Configuration and Costs
For standard VNet peering:
Confirm non-overlapping address spaces and permissions on both VNets.
Open Virtual network → Peerings → Add.
Select the remote VNet and configure both directional peering resources.
Confirm Connected on both sides.
Test private-IP connectivity and check NSGs, routes, and host firewalls. Configure Azure Private DNS or custom DNS for cross-VNet name resolution.
Peering traffic is charged at both ends. For 100 GB sent from A to B:
Endpoint | Charge |
VNet A | 100 GB outbound |
VNet B | 100 GB inbound |
Total = (100 × A’s outbound rate) + (100 × B’s inbound rate).
Return traffic incurs corresponding charges in the reverse direction. Regional and global peering have different rates; global pricing depends on geographic billing zones, which are different from availability zones. Use Azure’s current pricing when estimating costs rather than relying on the screenshot’s rates.
Configure user-defined network routes
Address Spaces, Subnets, and Default Routing
An address space is the IP range, or ranges, allocated to a VNet. A subnet divides that space into smaller ranges. CIDR notation determines the range size: 10.0.0.0/24 contains 256 IPv4 addresses, while a /16 contains 65,536.
A route table contains destination prefixes and next hops that determine where traffic goes. Azure automatically provides system routes for each subnet, including routes within the VNet and a default IPv4 route, 0.0.0.0/0, with next hop Internet. You do not need a custom route-table resource for normal routing between subnets.
Azure supports dual stack, allowing a VNet, subnet, and supported NIC configurations to use both IPv4 and IPv6. Azure IPv6 subnets use /64 prefixes. IPv4 and IPv6 routing must be considered separately; an IPv4 route does not control IPv6 traffic. Check IPv6 support for each service in the traffic path.
User-Defined Routes: Inspect Traffic Through a Hub
A user-defined route (UDR) changes the next hop for a destination range. Custom routes supplement system routes and can override applicable routes; they do not replace the entire system table.
The hub diagram uses these routes:
Associated subnet | Destination | Next-hop type | Next-hop IP |
Spoke1 workload subnet | 10.2.0.0/16 | Virtual appliance | 10.0.1.4 |
Spoke2 workload subnet | 10.1.0.0/16 | Virtual appliance | 10.0.1.4 |
Traffic between the spokes passes through Azure Firewall. The reverse route keeps replies on the inspected path. Configure the required peering forwarding settings and firewall permissions. For a VM-based network virtual appliance, enable NIC IP forwarding and forwarding inside the appliance.
To configure a UDR:
Create a Route table.
Select Routes → Add.
Enter the destination prefix, next-hop type, and next-hop IP where required.
Associate the table with each applicable subnet.
Verify the VM NIC’s Effective routes and test connectivity.
A subnet supports one custom route-table association; a table can serve multiple subnets in the same region and subscription.
Route Selection and Internet Access
Azure normally selects the longest matching prefix first. A /16 peering route therefore takes precedence over a /0 UDR. For identical prefixes, the usual priority is UDR → BGP → system route, with special rules for certain platform routes.
Objective | Configuration |
Inspect default-route IPv4 traffic | 0.0.0.0/0 → Virtual appliance, using the firewall’s private IP |
Discard default-route IPv4 traffic | 0.0.0.0/0 → None; more-specific routes still apply |
Control IPv6 default traffic | Configure IPv6 routes separately using ::/0 |
Other Azure Network Topics (Express Route)
Choose the Right Azure Private Connectivity
Technology | Main purpose | Typical use case |
VNet Peering | Connect Azure virtual networks | Allow application VMs in one VNet to communicate with database VMs in another |
Azure Private Link | Provide private access to a specific service | Access Azure Storage, SQL Database, or a provider’s application through a private endpoint |
ExpressRoute | Connect an on-premises network privately to Microsoft’s cloud | Support enterprise hybrid applications and large data transfers |
VNet Peering provides private-IP connectivity between VNets over Microsoft’s backbone. It supports same-region and cross-region connections, but peering is not automatically transitive. learn.microsoft.com
Private Link exposes a specific service through a private endpoint; it does not connect entire VNet address spaces. ExpressRoute provides the private hybrid connection into Microsoft’s network. These technologies can work together: an on-premises application can use ExpressRoute to reach a private endpoint in Azure. Microsoft Learn
Exam distinction: ExpressRoute private peering is the circuit’s routing relationship for reaching private Azure resources. It is different from VNet Peering.
Private Link—Consumer and Provider
Azure Private Link enables private access to supported Azure PaaS services and customer or partner services over Microsoft’s backbone.
A Private Endpoint is a network interface that receives a private IP address from a subnet in the consumer’s VNet. It represents access to a particular service or subresource, for example, an Azure Storage account’s Blob service. The service itself remains hosted outside the consumer subnet.
For a working connection:
Ensure the private endpoint connection is approved.
Configure DNS so the service name resolves to the endpoint’s private IP address.
Configure the service’s public network access separately if public access must be disabled.
Continue using the required application authentication and encryption.
Private Link Service publishes your own application for private consumption. In the standard pattern illustrated, your backend workload sits behind an Azure Standard Load Balancer.
You create the Private Link Service on the provider side; consumers create private endpoints and request access. Consumer-to-provider VNet peering is unnecessary.
ExpressRoute—Private Connectivity, Dynamic Routing, and Multicloud
Azure ExpressRoute provides private connectivity between on-premises networks and Microsoft’s cloud, avoiding the public internet. Provisioned circuit bandwidth and BGP routing support predictable connectivity for organizations operating across multiple locations. learn.microsoft.com
BGP Routing and Traffic Engineering
ExpressRoute uses Border Gateway Protocol (BGP) to dynamically exchange routes. With multiple circuits, organizations can influence path selection, distribute traffic across suitable paths, and configure failover.
Routing capability | Purpose |
Local preference | Prefer a particular circuit for traffic traveling from on-premises to Azure |
AS-path prepending | Influence which circuit Azure uses to reach on-premises destinations |
Regional BGP communities | Identify Azure regional prefixes and apply routing policies |
Equal-cost multipath (ECMP) | Share traffic across eligible paths with equivalent routing attributes |
These capabilities help avoid unnecessary detours and improve circuit utilization. BGP does not increase purchased bandwidth or automatically select the lowest-latency path; effective traffic engineering requires routing policies, capacity planning, and monitoring.
Global Reach and Multi-Region Connectivity
ExpressRoute Global Reach connects on-premises networks through eligible ExpressRoute circuits. For example, datacenters in two locations can communicate through Microsoft’s backbone rather than relying exclusively on a separate intersite WAN.
For a multi-region Azure architecture, combine appropriately scoped circuits, VNet gateway connections, and BGP policies to reach the required regions and choose suitable paths. Global Reach specifically provides on-premises-to-on-premises connectivity; it does not peer Azure VNets or guarantee optimal performance. Available throughput and latency depend on circuit capacity, geography, provider connectivity, and routing design.
Cloud Exchanges and Multicloud Connectivity
A cloud exchange provider can connect an enterprise network to Azure through ExpressRoute and to other clouds through their respective private connectivity services. When the provider supports the necessary routing, this architecture can also enable private cloud-to-cloud communication.
This approach can support:
Private connectivity across multiple cloud providers.
Provisioned bandwidth and more predictable performance than internet-based paths.
Centralized routing and security inspection, where designed into the architecture.
Consistent security policies must be configured and enforced through firewalls, segmentation, access controls, and monitoring across the connected environments. The exchange connection alone does not provide policy consistency. Microsoft Learn
Additional ExpressRoute Features
Feature | Purpose |
ExpressRoute Direct | Dedicated dual 10, 100, or 400 Gbps ports, subject to availability |
ExpressRoute Metro | Resilience through two peering locations within one metropolitan area |
FastPath | Eligible data traffic bypasses the gateway; the gateway remains for route exchange |
ExpressRoute provides private connectivity, but traffic is not encrypted by default. Apply appropriate encryption where required.
Azure Virtual WAN
Azure Virtual WAN combines networking, routing, and optional security services through Microsoft-managed regional virtual hubs. It can connect branches, datacenters, remote users, and Azure VNets through a common transit architecture.
How the Diagram Works
Branches connect through site-to-site VPN, including supported SD-WAN partner integrations.
Remote users connect through point-to-site VPN.
Datacenters can use ExpressRoute private connectivity.
Spoke VNets connect to the virtual hub.
In Standard Virtual WAN, hubs interconnect automatically over Microsoft’s backbone, enabling transit between connected regions.
You explicitly create the hubs and required gateways; a hub is not automatically deployed in every Azure region.
Basic versus Standard
Capability | Basic | Standard |
Site-to-site VPN | Yes | Yes |
Point-to-site/User VPN | No | Yes |
ExpressRoute | No | Yes |
VNet-to-VNet transit | No | Yes |
Inter-hub transit | No | Yes |
Azure Firewall or supported hub NVA | No | Supported |
Unlike ordinary VNet peering, Standard Virtual WAN provides managed transitive connectivity. Reachability still depends on routing configuration and security policies.
Routing and Security
Virtual hubs use route tables, route association, and route propagation to control traffic paths. Routing intent can steer selected private or internet-bound traffic through Azure Firewall or another supported security solution.
Keep filtering and encryption separate:
Capability | Security function |
S2S VPN | Encrypts site-to-Azure traffic using IPsec/IKE |
P2S VPN | Provides an encrypted remote-user connection using the configured VPN protocol |
ExpressRoute | Provides private connectivity; encryption is not enabled by default |
IPsec over ExpressRoute | Adds VPN encryption over the private ExpressRoute path |
Azure Firewall | Inspects and filters routed traffic; does not automatically encrypt private connections |
Virtual WAN and SD-WAN
Microsoft describes Virtual WAN as a cloud-based SD-WAN. It supplies managed Azure connectivity and transit infrastructure and integrates with premises-based SD-WAN/SASE products. Partner devices or supported hub NVAs can provide additional vendor-specific capabilities.
More generally, SD-WAN separates centralized management and control from packet forwarding, applying policies across available transports. Those transports can include broadband internet, MPLS, cellular, and private connections.
SD-WAN can reduce dependence on MPLS, but it does not inherently replace it. Cost savings and configuration effort depend on the design, provider contracts, licensing, resilience, and operational requirements.
Correction: SD-WAN is not secure merely because an ISP supports HTTPS. Security comes from configured mechanisms such as encrypted tunnels, device authentication, segmentation, and access policies. HTTPS commonly protects management interfaces or application sessions; it does not encrypt every WAN flow.
Supporting Terms
Term | Meaning |
Point of Presence (PoP) | A physical location where a provider offers network access or interconnection, such as a carrier or colocation facility |
Hop | A forwarding step through a network device; it does not necessarily mean changing provider networks |
MPLS | Multiprotocol Label Switching: forwards traffic along label-switched paths using labels rather than performing a conventional destination-IP lookup at every forwarding step |
SD-WAN overlay | A logical, policy-controlled network built over underlying transport connections |
MPLS does not inherently guarantee the shortest or lowest-latency path, and private transport alone does not imply encryption.
Configuration Outline
Create a Virtual WAN and select Basic or Standard.
Create regional virtual hubs with appropriate, non-overlapping address spaces.
Deploy the required VPN/ExpressRoute gateways and connect sites and users.
Connect spoke VNets and configure route association/propagation.
Add optional inspection and routing intent.
Validate connectivity, failover, capacity, monitoring, and costs.
AZ-104 exam tip: Choose Standard Virtual WAN when the requirement includes ExpressRoute, remote-user VPN, inter-hub connectivity, or VNet transit. It can simplify larger networks, but a conventional hub-and-spoke design may be more economical for a small deployment.
File share settings, configure identity-based access for storage
For the AD DS approach illustrated, first enable on-premises AD DS authentication on storage1. This requires registering the storage account with AD DS using a computer or service logon account and configuring the corresponding domain properties on the storage account. Simply synchronizing identities to Microsoft Entra ID does not enable Azure Files authentication.
How the connection works
Assuming Server1 is domain-joined, a signed-in domain user requests a Kerberos service ticket from an on-premises domain controller. Server1 presents that ticket when connecting to the Azure file share over SMB. In this configuration, AD DS issues the ticket; Microsoft Entra ID holds the synchronized identities used for Azure role assignments.
Configure access in this order:
Enable the identity source: Configure AD DS integration for storage1.
Assign share-level permissions: Grant the appropriate Azure role, such as Storage File Data SMB Share Contributor, to a synchronized user or group.
Configure directory/file permissions: Apply Windows ACLs, commonly called NTFS permissions.
Mount and test: From Server1, connect to \\storage1.file.core.windows.net\share1. DNS, storage network access, and TCP 445 connectivity must also work.
Both the share-level permissions and the directory/file permissions must permit the requested operation.
Other option | Why it is not the first step |
Modify a local group on Server1 | Does not enable storage-account authentication or grant Azure share permissions |
Modify file-share security settings from Server1 | File and directory permissions are configured after establishing the identity integration |
Enable a SAS | SAS tokens do not authenticate Azure Files SMB mounts; they support applicable REST access scenarios |
Exam tip: Azure Files supports three SMB identity sources: on-premises AD DS, Microsoft Entra Domain Services, and Microsoft Entra Kerberos. Only one identity source can be enabled per storage account. Current Microsoft Entra Kerberos documentation covers both hybrid and cloud-only identity scenarios, subject to their requirements.
Azure network performance Optimizations and Redundancy
The diagram separates four capabilities that address different needs: application latency, connectivity between regions, specialized HPC communication, and disaster recovery.
1. Low-Latency Application and Database VMs
Combine a proximity placement group (PPG) with Accelerated Networking on supported VMs:
PPG: Places VMs physically close together to reduce communication latency.
Accelerated Networking: Uses SR-IOV to bypass the host’s virtual switch, reducing latency, jitter, and CPU overhead.
This combination can benefit latency-sensitive application and database tiers. However, a PPG cannot span availability zones, so physical proximity must be balanced against resilience requirements.
2. Regional and Cross-Region Connectivity
VNet Peering connects VNets within a region; Global VNet Peering connects VNets across regions. Both use Microsoft’s backbone for private, high-bandwidth communication.
Correction: Global VNet Peering has no separate “premium routing” setting and does not guarantee the lowest latency or highest bandwidth. Geographic distance, VM network limits, and application behavior still affect performance.
3. HPC, RDMA, and Kernel Bypass
Supported Azure HPC VM sizes provide InfiniBand networking with Remote Direct Memory Access (RDMA). With compatible drivers and application libraries such as MPI/UCX, this supports low-latency, high-throughput communication for tightly coupled simulations and distributed HPC/AI workloads.
The distinction is important:
Technology | Optimization |
Accelerated Networking / SR-IOV | Bypasses the host virtual switch |
RDMA with compatible software | Supports direct memory transfers that bypass the normal kernel networking path |
Enabling Accelerated Networking does not automatically enable RDMA or guest kernel bypass. For database workloads, start with supported Accelerated Networking and appropriate VM sizing; specialized networking requires explicit support from the database and deployment architecture.
4. Disaster Recovery and Connectivity Restoration
Azure Site Recovery replicates protected VMs and uses network mappings to place recovered VMs in the intended target VNet. Preconfigure target subnets and NIC settings before failover.
Recovery plans can sequence VM startup and run automation for dependent tasks. Plan and test DNS updates, routes, NSGs, load balancers, and hybrid connectivity. Network mappings alone do not provide automatic end-to-end application recovery; failover must be initiated or triggered through separately configured orchestration. Microsoft Learn
Performance checks: Measure latency, jitter, throughput, and CPU utilization under realistic load. Select a VM size with sufficient network capacity—adding NICs does not multiply the VM’s aggregate bandwidth limit.
Troubleshoot network connectivity
Azure Network Watcher—Scope, Features, and Settings
Correct exam answer: 2 instances. Network Watcher is enabled once per subscription per region, regardless of the number of VNets or subnets. Microsoft Learn
Region | Virtual networks | Network Watcher instances |
East US | VNet1: two subnets; VNet2: four subnets | 1 |
West Europe | VNet3: four subnets; VNet4: two subnets | 1 |
Total | Four VNets, twelve subnets | 2 |
Network Watcher is normally enabled when a VNet is created or updated in a region. Automatically created instances use NetworkWatcherRG. If automatic enablement was explicitly disabled, enable it manually in each required region. Microsoft Learn
Choose the tool based on the troubleshooting question:
Tool | What it helps answer |
Connection troubleshoot | Can this source reach the destination and port now? |
IP flow verify | Does a security rule allow or deny this VM traffic? |
NSG diagnostics | Which applicable NSG rules affect the specified flow? |
Effective security rules | What combined subnet/NIC security rules apply? |
Next hop | Where will traffic to this destination be routed? |
Packet capture | What packets are actually being transmitted or received? |
VPN troubleshoot | Is a supported VPN gateway or connection experiencing problems? |
Connection monitor | How do reachability and latency change over time? |
Topology | Which network resources exist, and how are they related? |
VNet flow logs / Traffic Analytics | Which flows occur, and what traffic patterns need investigation? |
Network Watcher primarily diagnoses infrastructure networking; application monitoring requires complementary tools.
Settings to configure
Correct region, resource scope, and RBAC permissions.
Source, destination, direction, protocol, and ports.
Required agents/extensions for the selected feature.
Packet-capture filters, duration, and output location.
Flow-log storage, retention, optional analytics, and associated costs.
Connection Monitor test frequency, thresholds, and alerting.
Enabling Network Watcher does not automatically configure every monitor, capture, or log.
Current logging guidance: Use VNet flow logs for new deployments. New NSG flow logs cannot be created after June 30, 2025; existing NSG flow logs retire September 30, 2027.
Troubleshooting Beyond Network Watcher
Start with a repeatable investigation:
Define the symptom: Record affected users, source/destination, protocol, port, timing, and recent changes.
Check DNS and endpoints: Confirm the hostname resolves to the expected public or private IP.
Check the path: Inspect effective routes, peering, UDRs, NSGs, firewalls, outbound connectivity, and return routing.
Check the service: Confirm it is listening, healthy, and accepting the expected protocol and identity.
Correlate and retest: Compare application, network, and deployment evidence; validate recovery against a healthy baseline.
A successful ping alone does not establish that HTTPS, SMB, or a database connection works.
Azure Monitor, Anomaly Detection, and Capacity
Use Azure Monitor metrics, logs, dashboards, and alerts to identify trends and correlate failures. Dynamic thresholds learn historical metric patterns; Application Insights Smart Detection identifies supported application anomalies.
These are specific capabilities, not a universal predictive network optimizer. Autoscale applies to supported resources. Predictive autoscale for VM scale sets forecasts CPU requirements, rather than automatically resizing every network resource. Microsoft Learn
Application Performance and User Experience
Application Insights provides distributed tracing, dependency telemetry, and Application Map. Combine these with availability tests and browser telemetry to relate user-visible delays to failing dependencies or application changes.
Instrumentation is required, and an application dependency map is not a complete network packet-path map.
Service Mesh Security
An AKS service mesh such as Istio can provide mutual TLS, workload authentication, and authorization policies. When connectivity fails, investigate certificates, proxy/sidecar health, authorization rules, timeouts, and retries alongside NSGs and routes. Mesh security complements underlying network controls. Microsoft Learn
Edge and Hybrid Connectivity
Azure Stack Edge supports local processing and cloud data transfer. Troubleshooting includes link health, DNS, proxy/firewall settings, transfer errors, and upload backlog. Bandwidth schedules can help transfers coexist with other workloads; the device does not automatically optimize every cloud connection.
Network Automation and Lifecycle Management
Use ARM and Bicep to deploy consistent network configurations. Review what-if output before changes, investigate deployment failures, and validate deployed NSGs, routes, DNS, and private endpoints. Infrastructure as code reduces configuration inconsistency but still requires connectivity testing.
Automated Disaster Recovery Validation
Run Site Recovery test failovers in an isolated test network. Recovery plans and runbooks can sequence recovery and execute configured validation steps. Test DNS, required ports, dependencies, routing, and application performance; measure recovery time and clean up test resources afterward. These checks require explicit configuration and scripts.
Configure secure access to virtual networks
Create and configure network security groups (NSGs) and application security groups
Evaluate effective security rules in NSGs
Azure Firewall
Implement Azure Bastion
Configure service endpoints for Azure platform as a service (PaaS)
Configure private endpoints for Azure PaaS
Create and configure network security groups (NSGs) and application security groups
NSGs, ASGs, and Service Tags
A Network Security Group (NSG) filters inbound and outbound traffic using stateful network rules. Associate an NSG with a subnet, a network interface, or both.
Each security rule contains:
Property | Purpose |
Name | Unique rule name within the NSG |
Source / destination | IP address, CIDR range, service tag, or supported ASG reference |
Source / destination ports | Individual ports, lists, or ranges |
Protocol | For example, TCP, UDP, ICMP, or Any |
Action | Allow or Deny |
Priority | Custom-rule value from 100–4096; lower numbers are evaluated first |
Direction | Inbound or outbound |
The first matching rule determines the result. Two rules cannot have the same priority within the same direction in one NSG.
Application Security Groups
An ASG groups VM network interfaces by application role, such as ASG-Web, ASG-App, and ASG-DB. NSG rules then reference those groups instead of individual VM addresses.
The diagram allows application-tier access to the database on TCP 1433 while denying direct web-tier access. ASGs contain membership information; the NSG enforces the rules. NICs within an ASG must belong to the same VNet. When both source and destination use ASGs, both groups’ NICs must be in that VNet.
Service Tags
A service tag represents Microsoft-maintained IP prefixes. For example, Storage.EastUS represents Azure Storage address ranges in East US. It does not identify one storage account or grant data permissions. The VirtualNetwork tag can include connected networks, including peered VNets, not just the local VNet.
Configuration sequence: Create the NSG → add rules → associate subnets/NICs → configure ASG membership → validate traffic.
Updated limits: Microsoft currently lists 2,000 rules per NSG and 5,000 NSGs per region per subscription, updating the supplied 1,000-rule figure and scope.
Evaluate effective security rules in NSGs
Evaluate Effective NSG Security Rules
When both subnet and NIC NSGs exist, both must allow a new flow:
Direction | Evaluation order |
Inbound | Subnet NSG → NIC NSG |
Outbound | NIC NSG → subnet NSG |
Priorities are evaluated within each NSG, not across a merged global list. A subnet allow at priority 100 therefore cannot override a NIC deny at priority 200.
Default NSG rules
Priority | Inbound | Outbound |
65000 | Allow VirtualNetwork traffic | Allow VirtualNetwork traffic |
65001 | Allow AzureLoadBalancer traffic | Allow Internet traffic |
65500 | Deny remaining traffic | Deny remaining traffic |
Default rules cannot be deleted, but matching custom rules take precedence. Outbound Internet is allowed by the default NSG rules, although routing and an outbound connectivity method must also be available.
NSGs are stateful: replies to an allowed connection are permitted without a separate reverse-direction allow rule. Rule changes affect new connections and may not terminate existing sessions.
To investigate:
Open the VM’s NIC and inspect Effective security rules.
Confirm subnet/NIC NSG associations and ASG membership.
Use IP flow verify or NSG diagnostics for the actual source, destination, protocol, and ports.
Check effective routes, DNS, the guest firewall, and the application listener.
Effective security rules aggregate applicable NSG rules; they do not prove end-to-end connectivity or include every external firewall policy.
Azure Firewall
Azure Firewall is a managed, stateful firewall with built-in high availability and managed scaling. It provides centralized network and application filtering. Traffic is denied unless a rule allows it. Scaling remains subject to SKU and service limits.
In the illustrated hub-and-spoke design:
Deploy the firewall in a dedicated AzureFirewallSubnet, at least /26.
Peer workload spokes with the hub.
Associate workload subnets with UDRs directing selected traffic to the firewall’s private IP.
Configure forward and return paths, required peering forwarding settings, and firewall rules.
Use specific destination routes for spoke-to-spoke inspection; a /0 route does not override more-specific routes. Microsoft Learn
A hub is a common architecture, not a requirement that every firewall have its own otherwise-empty VNet.
Firewall Tags and Rule Types
Capability | Example | Purpose |
Network rule + service tag | Destination Storage.EastUS, TCP 443 | Filter using Microsoft-managed IP prefixes |
Application rule + FQDN tag | Destination WindowsUpdate | Permit the Microsoft-maintained domain group |
Application rule + explicit FQDN | An approved application hostname | Control access to specified application endpoints |
DNAT rule | Public IP/port → internal destination | Publish an explicitly permitted inbound service |
Service tags and FQDN tags are different from Azure resource metadata tags. Microsoft maintains FQDN-tag membership; you cannot create your own FQDN tags.
For conventional internet egress, Azure Firewall can SNAT traffic to its configured static public IP addresses, allowing external systems to identify approved source addresses.
Threat Intelligence, Inspection, and Logging
Standard/Premium: Threat-intelligence filtering can operate in Alert or Alert and deny mode. Known malicious destinations are not automatically blocked in alert-only mode.
Premium: Adds capabilities including TLS inspection and IDPS; configure the required policies and certificates.
Monitoring: Enable diagnostic settings to send relevant firewall logs to destinations such as Log Analytics, and monitor health, throughput, latency, and SNAT utilization. Microsoft Learn
NSGs provide workload segmentation; Azure Firewall provides centralized traffic inspection. They are commonly used together.
Implement Azure Bastion
Azure Bastion provides the management connection path. Just-in-time access controls when management ports accept new connections. They address different needs and can be combined.
How Azure Bastion Works
Azure Bastion is a managed service for accessing Windows and Linux VMs through RDP or SSH.
In the browser-based connection illustrated:
The administrator signs in to the Azure portal.
The browser connects to Bastion over HTTPS/TLS on TCP 443.
Bastion connects to the VM’s private IP, normally using TCP 3389 for RDP or TCP 22 for SSH.
The administrator authenticates to the guest operating system.
The target VM needs no public IP address or internet-facing RDP/SSH port. Supported Bastion configurations can also reach VMs in peered VNets.
How to Configure Bastion
For the conventional dedicated deployment shown:
Choose a SKU and VNet. Select features appropriate to browser access, native clients, scaling, and auditing.
Create AzureBastionSubnet. Dedicated Basic, Standard, and Premium deployments require this exact subnet name and a /26 or larger subnet.
Configure a Standard, static public IP for the public deployment.
Configure network access. If using an NSG on the Bastion subnet, include all required Bastion service rules. The VM-side NSGs and guest firewall must permit the connection from AzureBastionSubnet.
Grant permissions. Administrators need the necessary Azure resource permissions plus valid guest OS credentials or a supported Microsoft Entra sign-in configuration.
Connect and validate. Open the VM’s Connect → Bastion experience and test access.
SKU exceptions: Developer uses a different shared architecture. Premium supports private-only deployment, without a Bastion public IP, and optional session recording.
Bastion Compared with Just-in-Time Access
Control | Main purpose | What it changes |
Azure Bastion | Provides a secure RDP/SSH connection path | Proxies management connections to private VM addresses |
Defender for Cloud JIT VM access | Limits network access by source, port, and time | Temporarily adjusts supported NSG/firewall rules |
Microsoft Entra PIM | Provides time-bound privileged-role activation | Controls when an administrator’s eligible role becomes active |
JIT VM access is available through Microsoft Defender for Servers Plan 2 in Microsoft Defender for Cloud, formerly Azure Security Center. An authorized user requests specified ports, source addresses, and a time window. Defender checks permissions and temporarily permits access. On expiry, it restores the network rules; established sessions are not interrupted.
PIM can add time-bound role activation alongside Bastion, but it does not replace network access controls or guest OS authorization.
Using Bastion and JIT Together
Protect the target VM’s management ports with JIT, then request a temporary window before connecting through Bastion.
The allowed VM-side source must account for AzureBastionSubnet, because Bastion initiates that connection, not the administrator’s public IP. Review existing rule precedence so a standing allow rule does not undermine the intended restriction. JIT is optional for Bastion; it is not automatically enabled when Bastion is deployed.
Audit Logging
Use complementary evidence rather than treating one log as a complete audit trail:
JIT activity: Review access requests and changes through Defender for Cloud and Azure Activity Log.
Bastion diagnostics: Enable audit logs to track connection activity and centralize them through Azure Monitor.
Guest OS auditing: Collect Windows/Linux logs for activity performed inside the VM.
Premium session recording: Enable separately when recorded sessions are required.
JIT request auditing and Bastion connection logs do not automatically record every administrative command.
Configure service endpoints for Azure platform as a service (PaaS)
Service Endpoints—Subnet Identity and PaaS Firewall
A VNet service endpoint provides a direct route from an enabled subnet to a supported Azure service over Microsoft’s backbone. The service still uses its public endpoint; no private endpoint NIC or private destination IP is created in your VNet. Source resources do not need public IP addresses for this access.
To configure the Storage example:
Open the VNet’s Subnets settings and enable Microsoft.Storage on the workload subnet.
In the storage account’s Networking settings, restrict public endpoint access to selected networks and allow that VNet/subnet.
Confirm that NSGs, routing, and the application’s data permissions allow the required operation.
Optionally associate a Storage service endpoint policy with the subnet.
Enabling a service endpoint alone does not restrict the storage account to that subnet; configure the service’s network rules too.
The diagram distinguishes two controls:
Control | What it restricts |
Storage account network rule | Which networks may access this storage account |
Service endpoint policy | Which Storage accounts the subnet may access through service endpoints |
For example, an endpoint policy can allow storage1 while denying other storage accounts. This reduces a specific data-exfiltration path; it is not a guarantee against every exfiltration method.
Private Endpoints, Access a Specific Service Through a Private IP
A private endpoint creates a network interface with a private IP from your subnet and maps it to a specific supported resource/subresource, for example, storage1’s Blob service. Traffic uses Azure Private Link over Microsoft’s backbone. The Storage service itself is not moved into your subnet.
Configure it by:
Selecting the target resource and subresource, such as blob.
Choosing the private endpoint’s VNet and subnet.
Obtaining automatic or manual connection approval.
Configuring private DNS and linking the appropriate client VNets.
Restricting or disabling the service’s public network access where required.
Testing name resolution and authorized application access. learn.microsoft.com
For Blob Storage, clients continue using: storage1.blob.core.windows.net
Within the correctly configured client network, DNS resolves that name through the Private Link alias to the endpoint’s private IP, such as 10.0.2.5. Use a private DNS zone group or managed DNS records; VM-style DNS auto-registration is not the mechanism for creating these endpoint records. On-premises clients also need suitable DNS forwarding. learn.microsoft.com
Partner-specific application access
To publish your own application, the standard illustrated pattern uses:
Partner Private Endpoint → Private Link Service → Standard Load Balancer → application backends
The provider controls connection approval. Partners gain access to the published service without requiring broad VNet peering or corporate network access. Application authentication and authorization still apply.
Service Endpoint versus Private Endpoint
Characteristic | Service endpoint | Private endpoint |
Service destination | Public service endpoint | Private IP in your VNet |
Main scope | Subnet identity for supported services | Specific resource/subresource |
Private endpoint NIC | No | Yes |
DNS | Normally retains public service resolution | Requires appropriate private resolution |
Public access control | Restrict the service endpoint using network rules | Configure public access separately |
On-premises access | Does not directly extend subnet service-endpoint identity on-premises | Reachable over suitable VPN/ExpressRoute connectivity and DNS |
Both require separate data-access permissions.
App Service and AKS, Complementary Network Controls
App Service: inbound and outbound are separate
Private endpoint: Provides private inbound access to the app.
VNet integration: Lets the app initiate outbound connections into or through a VNet.
Hybrid connectivity: VPN or ExpressRoute can carry those outbound calls to an on-premises API or database.
VNet integration does not make the app’s inbound endpoint private. Microsoft Learn
For regional integration, use a supported App Service tier and a same-region VNet with an integration subnet delegated to Microsoft.Web/serverFarms. Keep it separate from the private endpoint subnet. Configure DNS, NSGs, routes, return connectivity, and application permissions. App Service remains a managed service outside that integration subnet.
AKS: network policy and service mesh
Control | Responsibility |
Kubernetes NetworkPolicy | Pod ingress/egress controls using selectors, IP ranges, protocols, and ports |
Service mesh, such as Istio | Configured mTLS, service identity, and application-level authorization |
Private endpoint | Private access from the workload to a specific PaaS resource |
Use a supported network-policy engine and explicitly configured policies. Standard Kubernetes NetworkPolicy does not encrypt traffic; service-mesh encryption and authorization require their own configuration. These controls complement NSGs, private DNS, and PaaS permissions.
Configure name resolution and load balancing
Configure Azure DNS
Configure an internal or public load balancer
Troubleshoot load balancing
Configure Azure DNS
Azure Public DNS—Zones, Delegation, and Records
DNS resolves names to addresses and other service information. Azure Public DNS hosts authoritative DNS zones using Microsoft’s infrastructure. It does not sell domain registrations.
A DNS zone contains records for a namespace such as contoso.com. A record set groups records with the same name and type. Its TTL specifies how long resolvers may cache the answer. Microsoft Learn
Record | Purpose |
A | Maps a name to an IPv4 address |
AAAA | Maps a name to an IPv6 address |
CNAME | Aliases one hostname to another |
MX | Identifies mail servers and their preference |
CAA | Identifies certificate authorities permitted to issue certificates |
NS | Identifies authoritative name servers |
PTR | Maps an address to a name through reverse DNS |
SRV | Identifies a service’s target, port, priority, and weight |
TXT | Stores text, including verification and email-policy information |
SOA | Stores zone administration and timing information |
Azure supports these common public DNS record types.
Configure a public domain
Register the domain with a registrar.
Create its public DNS zone in Azure.
At the registrar, or parent zone,delegate it to Azure’s assigned name servers.
Create the required records and test resolution.
Creating the Azure zone alone does not update the domain’s delegation. Multiple authoritative name servers provide DNS redundancy; they are not simply primary and backup application destinations.
Azure alias records
An alias is an Azure record-set capability for supported A, AAAA, and CNAME records, rather than a separate DNS protocol record type. It can reference supported Azure resources or compatible record sets, reducing dangling references.
An apex A/AAAA alias can be useful where a normal CNAME is prohibited, for example, at contoso.com
Private DNS Across VNets, Two Different Requirements
Scenario 1: Custom domain, four VNets, minimal administration
Answer: an Azure Private DNS zone.
Create contoso.com, link all four VNets, and enable auto-registration on their links. Azure then maintains eligible VM records as VMs are created, their addresses change, or they are deleted. Clients can resolve names such as vm2.contoso.com. Microsoft Learn
Important distinctions:
A VNet can have one auto-registration zone and multiple resolution-only zone links.
A zone can serve multiple linked VNets, including across regions.
DNS links provide resolution, not network connectivity.
Peering provides connectivity but does not automatically share private DNS zones.
Custom DNS clients need forwarding that can resolve the private zone.
Linking a zone does not automatically change the guest OS’s DNS suffix. Microsoft Learn
Exam tip: “Custom namespace + multiple VNets + minimal record maintenance” points to Private DNS with auto-registration.
Scenario 2: All VNets use VM1 as their DNS server
Answer: configure network peering.
Configuring VM1’s IP as the DNS server does not create a path to it. Peer each client VNet directly with VM1’s VNet, as shown. Permit UDP and TCP 53 through applicable NSGs and the DNS server’s host firewall. VM1 must also contain the required zones or forwarding configuration.
After changing VNet DNS settings, restart affected VMs or renew their DHCP configuration so they obtain the updated settings.
This topology lets all clients reach VM1; it does not automatically provide spoke-to-spoke application connectivity because ordinary VNet peering is non-transitive.
Hybrid DNS and Private Endpoint Resolution
Azure DNS Private Resolver provides managed hybrid DNS forwarding:
Component | Function |
Inbound endpoint | Provides a reachable private IP for on-premises DNS to resolve Azure-visible names |
Outbound endpoint | Sends matching queries from Azure toward configured DNS servers |
Forwarding ruleset | Specifies which namespaces go to which target DNS servers |
Private DNS zone links | Make private namespaces visible to the relevant Azure resolution environment |
Each resolver endpoint uses a dedicated delegated subnet. Configure network reachability, DNS permissions, and forwarding rules carefully to avoid loops.
An alternative is an Azure-hosted DNS forwarder VM that forwards appropriate queries to 168.63.129.16. On-premises DNS cannot query this Azure platform address directly; it needs a reachable Private Resolver inbound endpoint or Azure-hosted forwarder.
Private endpoints for Storage and Key Vault
Service | Private DNS zone |
Blob Storage | |
Key Vault |
Configure endpoint records using private DNS zone groups or managed DNS records. Clients retain the normal service hostname, but resolve it to the private endpoint IP from the intended networks. VM auto-registration is not the mechanism for managing private endpoint records.
A private endpoint does not automatically disable public access. Configure the PaaS public-network setting separately, retain authentication and authorization, and verify that applications resolve and use the private path.
Availability, Load Distribution, and Failover
Azure Private DNS uses resilient distributed infrastructure, and private endpoints are zone-agnostic. Neither eliminates the need to design backend availability, regional recovery, or redundant hybrid connectivity.
DNS availability is different from application failover. Multiple A records alone do not remove unhealthy destinations. For suitable public applications, Traffic Manager adds DNS-based endpoint health monitoring and failover; caching means redirection is not instantaneous. Private applications need an appropriate private load-balancing and recovery design.
Configure an internal or public load balancer
Choose the Right Service
Service | Primary function | Typical use |
Azure Load Balancer | Layer 4 TCP/UDP flow distribution | Public or private services running on VMs/VM scale sets |
Application Gateway | Regional Layer 7 application routing | Hostname/path routing, TLS termination, regional WAF |
Azure Front Door | Global Layer 7 application delivery | Multi-region routing, edge acceleration, caching, WAF |
These services can be combined, for example, Front Door can distribute requests to regional Application Gateways. They are not all required in every architecture.
Configure a Public or Internal Azure Load Balancer
Azure Load Balancer distributes TCP/UDP flows among eligible backend instances.
Public Load Balancer: Uses a public frontend IP for internet-facing connectivity.
Internal Load Balancer: Uses a private frontend IP, reachable through suitable VNet, peering, VPN, or ExpressRoute connectivity.
Backend VMs do not need individual public IP addresses. Microsoft Learn
Configure these components:
Component | Configuration |
Frontend IP | Public IP or private subnet IP |
Backend pool | Destination VM/VM scale-set instances or supported IP configurations |
Health probe | TCP, HTTP, or HTTPS test used to assess backend availability |
Load-balancing rule | Frontend IP, protocol/port, backend port, pool, and probe |
Security controls | Permit application traffic and health probes through NSGs and guest firewalls |
Default distribution uses a flow hash, rather than simple per-request round robin. An existing connection is not continuously moved between backends. Microsoft Learn
Important distinctions
An HTTP/HTTPS health probe does not make Load Balancer a Layer 7 router.
It does not perform hostname/path routing or terminate application TLS.
Configure outbound connectivity separately where required. A public Standard Load Balancer supports outbound rules; NAT Gateway is another common option. Microsoft Learn
Application Gateway, Regional Application Routing
Application Gateway accepts web requests through a listener, evaluates routing rules, and sends requests to a healthy backend or configured redirect destination. A private frontend makes Application Gateway internal; it does not create a separate Azure Load Balancer resource.
Its main configuration elements are:
Element | Purpose |
Frontend | Public IP, private IP, or supported combination |
Listener | Matches frontend IP, port, protocol, and optional hostname |
Routing rule | Connects the listener to backend routing or redirection |
Backend pool | VMs, VM scale sets, IP addresses, FQDNs, or services such as App Service |
Backend HTTP settings | Backend protocol/port, host handling, timeout, cookie affinity, connection draining, and TLS configuration |
Health probe | Tests the backend using the configured host, path, protocol, and port |
Listeners and Rule Priority
Basic listener: Accepts requests matching its frontend/protocol/port without hostname-specific selection.
Multi-site listener: Selects traffic using configured hostnames.
Application Gateway v2: Uses explicit rule priorities, with lower numbers evaluated first.
Give specific hostnames precedence over broader wildcard or catch-all listeners. Within path-based routing, place specific paths before broad wildcard paths. Microsoft Learn
TLS, Key Vault, WAF, and Health
Application Gateway can terminate client TLS and establish a separate HTTPS connection to the backend. Backend certificate trust, hostname, and SNI must be correct.
For Key Vault integration, configure a user-assigned managed identity, appropriate secret access, and network reachability. A versionless secret URI allows Application Gateway to discover renewed certificate versions.
Use WAF_v2 when application-layer firewall protection is required. Configure probes to represent meaningful application health; a probe that always returns success can hide dependency failures.
Front Door, Global Routing, Acceleration, and Caching
Azure Front Door Standard/Premium accepts HTTP/HTTPS traffic at Microsoft’s global edge and routes requests to configured origin groups.
Origins: Application Gateway, App Service, or other supported HTTP services.
Origin selection: Uses health and configured priority, latency, and weighting behavior.
Caching: Serves eligible cached responses at the edge when enabled; dynamic or uncached requests reach an origin.
Security: Supports TLS and WAF capabilities. Premium supports Private Link to supported origins.
Secure the origin so users cannot bypass Front Door and its intended security controls.
Troubleshoot Load Balancing
Investigate from the client-facing configuration toward the backend:
Symptom | Checks |
Frontend unreachable | DNS, frontend IP/domain, listener/rule ports, client connectivity, NSGs, and routing |
Load Balancer backend unhealthy | Pool membership, probe protocol/port/path, service listener, guest firewall, and probe-source access |
Application Gateway 502 | Backend Health details, DNS, probe settings, routing, TLS trust, hostname/SNI, and host headers |
Application Gateway timeout/504 | Backend response time, request timeout, application dependencies, and network reachability |
Wrong application/backend | Listener hostname, rule priority, path-map order, and backend targets |
Front Door origin errors | Origin health, host header, TLS certificate name/trust, origin restrictions, and Private Link approval |
Unexpected cached content | Cache rules, cache keys, TTL, response headers, and purge requirements |
For Azure Load Balancer, allow probe traffic from the AzureLoadBalancer service tag in NSGs and 168.63.129.16 in applicable guest firewall rules. Probe access and application access are separate checks.
Use Health Probe Status and Data Path Availability metrics for Load Balancer; Backend Health, access logs, and WAF logs for Application Gateway; and access, WAF, and health-probe logs for Front Door. A healthy probe does not prove every user transaction works, test the actual application URL or port from the relevant network.
Comments