AZ-104 Implement and Manage Virtual Networking

Implement and Manage Virtual Networking Detailed Explanation

1. Implement and Manage Virtual Networks (VNets)

Azure Virtual Network (VNet) is the foundation of Azure networking. It allows you to securely connect Azure resources to each other, to the internet, and to your on-premises environment.

1.1 VNet Fundamentals

1.1.1 Logical Isolation

• A VNet provides logical isolation in Azure—your own private network environment in the cloud.

• Resources inside a VNet can communicate privately.

1.1.2 Address Space (CIDR Notation)

• When you create a VNet, you define an address space using CIDR format, such as 10.0.0.0/16.

• This space is further divided into subnets.

CIDR = Classless Inter-Domain Routing
10.0.0.0/16 means there are 65,536 IP addresses available.

1.1.3 Subnetting

• You divide your VNet into subnets to group resources logically.

  • Example: 10.0.1.0/24 for Web tier, 10.0.2.0/24 for App tier

• Subnets segregate traffic and help apply network security rules.

1.2 IP Addressing

1.2.1 Static vs Dynamic IPs

• Dynamic IP: Assigned automatically by Azure (default)

• Static IP: Manually assigned and never changes (useful for DNS, firewalls)

Applies to:

• Private IPs (within the VNet)

• Public IPs (internet-facing)

1.2.2 Reserved Public IPs and DNS Labels

• Public IPs can be:

  • Basic: Static or dynamic, not zone-aware

  • Standard: Always static, zone-aware

• DNS label:

  • Gives your public IP a friendly name

  • Example: mywebapp.eastus.cloudapp.azure.com

1.3 Subnet Configuration

1.3.1 Logical Segmentation

• Subnets are used to organize resources like:

  • VMs

  • Load balancers

  • App services (via integration)

• Helps apply different security rules and route tables to each segment.

1.3.2 Associate NSGs with Subnets

• NSGs (Network Security Groups) can be linked to subnets to control traffic rules for all resources within.

1.3.3 Subnet Delegation

• Allows you to dedicate a subnet to a specific Azure service.

  • Examples: Azure Bastion, App Service Environment, Azure NetApp Files

• Delegation enables the service to fully manage the subnet.

1.4 Network Interfaces (NICs)

1.4.1 NIC Basics

• Each VM must have at least one NIC.

• The NIC defines:

  • IP configuration (static/dynamic)

  • NSG rules

  • DNS settings

  • Associated subnet

1.4.2 NIC Management

• You can:

  • Attach or detach NICs (secondary only)

  • Change IP assignment

  • Apply NSGs at the NIC level

Primary NICs cannot be detached from the VM.

2. Configure Name Resolution

Name resolution (or DNS) ensures that IP addresses can be translated to human-readable names (and vice versa) within your Azure environment.

2.1 Azure-Provided DNS

2.1.1 Default DNS in VNets

• Azure provides built-in DNS services to resolve hostnames to internal IP addresses within a VNet.

• No configuration needed for most scenarios.

• Example: A VM named vm1 in VNet contoso-vnet can be resolved as:

  vm1.contoso-vnet.internal.cloudapp.net
  

2.1.2 Internal Name Resolution

• Azure auto-registers and resolves VMs by hostname within the same VNet.

• Works only if:

  • VMs are in the same region

  • Default DNS is used

• It does not support cross-VNet resolution unless using VNet peering + custom DNS.

2.2 Custom DNS

2.2.1 Assigning Your Own DNS Servers

• You can override Azure’s default DNS by specifying your own:

  • On-premises DNS server

  • BIND or Windows DNS in Azure

• Configuration is at the VNet level:

  1. Go to VNet > DNS Servers

  2. Choose Custom

  3. Add one or more DNS server IPs

VM NICs must be restarted to apply DNS changes.

2.2.2 Conditional Forwarding

• You can configure your DNS server to forward specific requests to:

  • Azure internal DNS (for .azure.com)

  • On-prem DNS servers

• This is useful for hybrid cloud scenarios or split-horizon DNS.

2.3 Private DNS Zones

2.3.1 What is a Private DNS Zone?

• A Private DNS Zone provides DNS resolution inside your VNets without requiring custom DNS servers.

2.3.2 Benefits

• No need to manage or maintain your own DNS servers

• Supports:

  • Automatic registration of VM names (with auto-registration enabled)

  • Custom DNS names

  • VNet linking

2.3.3 How It Works

1. Create a private DNS zone (e.g., internal.contoso.com)

2. Link it to one or more VNets

3. Enable auto-registration if needed

4. Create A records, CNAMEs, or allow Azure to register VMs automatically

Use cases:

• Custom internal DNS names

• Cross-VNet name resolution

• Hybrid network setups

3. Secure Access to Virtual Networks

Securing your network in Azure is essential to control traffic flow, prevent unauthorized access, and ensure compliance. Azure provides multiple layers of network security.

3.1 Network Security Groups (NSGs)

3.1.1 What is an NSG?

An NSG is a firewall-like filter that controls inbound and outbound traffic to:

• Subnets

• Network interfaces (NICs)

Each NSG contains security rules.

3.1.2 Security Rule Components

Each rule includes:

• Name

• Priority (lower number = higher priority)

• Source/Destination (IP, range, tag)

• Protocol (TCP, UDP, * for any)

• Port range

• Action (Allow or Deny)

NSG rules are stateful: if inbound traffic is allowed, the response is automatically allowed.

3.1.3 Best Practices

• Apply NSGs at the subnet level for shared rules.

• Apply at NIC level for fine-grained control.

• Use deny-by-default and only allow what’s needed.

3.2 Service Tags & Application Security Groups (ASGs)

3.2.1 Service Tags

• Predefined labels for common Azure services and groups of IPs.

• Examples:

  • Internet

  • VirtualNetwork

  • AzureLoadBalancer

  • Storage

Simplifies NSG rules by abstracting IP addresses.

3.2.2 Application Security Groups (ASGs)

• Logical groups for VMs with similar functions.

• Can be used in NSG rules to define source/destination by group name rather than IP.

Makes rules more readable and maintainable.

Example: Allow traffic from Web-ASG to App-ASG on port 80.

3.3 Azure Firewall

3.3.1 What is Azure Firewall?

Azure Firewall is a stateful, fully managed network security service.

Features:

• Packet filtering (L3/L4)

• Application rules (L7 filtering for HTTP/S)

• FQDN filtering

• Threat intelligence

• SNAT/DNAT

3.3.2 Use Cases

• Centralized control in hub-and-spoke architectures

• Audit and log all traffic

• Restrict access to known domains

Azure Firewall is highly scalable and integrates with Azure Monitor logs.

3.4 Just-In-Time (JIT) VM Access

3.4.1 What is JIT Access?

JIT allows time-limited access to VMs via RDP/SSH. It’s part of Microsoft Defender for Cloud (formerly Security Center).

3.4.2 How it works

• RDP/SSH ports are blocked by default.

• When needed, an admin can request access:

  • Define source IP, duration, port

• NSG rules are opened temporarily, then closed automatically.

Protects VMs from constant port scanning and brute-force attacks.

3.4.3 How to enable JIT

1. Go to Microsoft Defender for Cloud > JIT VM access

2. Select a VM and enable JIT

3. Configure access ports and allowed source IPs

4. Configure VNet Peering

VNet Peering allows you to connect two virtual networks seamlessly and securely, enabling private communication between them without using public IPs, VPNs, or gateways.

4.1 VNet-to-VNet Peering (Same/Different Region)

4.1.1 Same-Region Peering

• Low-latency, high-bandwidth connection between two VNets in the same region.

• Peered VNets can:

  • Share resources

  • Communicate via private IP addresses

  • Appear as one network to resources

No need for a VPN or public internet access.

4.1.2 Global VNet Peering

• Peers VNets across different regions.

• Still private and secure, using Microsoft’s backbone.

• Use case: multi-region applications, disaster recovery setups.

Supports cross-region workloads without traffic going over the public internet.

4.2 Peering Configuration

To peer two VNets:

1. Go to Virtual Network > Peerings > + Add

2. Choose:

   • The remote VNet

   • Name of the peering (on both sides)

   • Traffic settings:

     • Allow VNet access

     • Allow forwarded traffic

     • Allow gateway transit (for shared VPN connections)

Peering is non-transitive:
If VNet A peers with B, and B with C, A cannot communicate with C unless directly peered.

4.3 Peering Limits

Limits to Know

• Maximum peering connections per VNet: 500 (may vary with region/SKU)

• Each peering must be configured in both VNets

• Cannot directly peer VNets in different Azure AD tenants without extra configuration

All traffic between peered VNets remains within Azure’s private backbone, not exposed to the internet.

5. Configure VPN and ExpressRoute

Azure provides options to connect your on-premises network to Azure securely, either over the public internet (VPN) or through a private dedicated connection (ExpressRoute).

5.1 Site-to-Site (S2S) VPN

5.1.1 What is a Site-to-Site VPN?

A Site-to-Site VPN connects your on-premises network to an Azure Virtual Network using IPsec/IKE tunnels over the internet.

Best for:

• Permanent hybrid connectivity

• Businesses with on-premises data centers or offices

5.1.2 Requirements

• An on-prem VPN device (must be compatible with Azure)

• A public IP address for the VPN device

• A Virtual Network Gateway in Azure

• A local network gateway (represents the on-prem network)

5.2 Point-to-Site (P2S) VPN

5.2.1 What is a Point-to-Site VPN?

A P2S VPN is for individual users to connect securely from their devices (e.g., laptops) to Azure over the internet.

Best for:

• Remote workers or small teams

• Testing or development use cases

5.2.2 Authentication Methods

• Certificate-based authentication (generate and install client certs)

• Azure AD authentication (use user credentials and MFA)

5.3 ExpressRoute

5.3.1 What is ExpressRoute?

ExpressRoute provides a private connection from your on-premises infrastructure to Azure via a Microsoft partner provider.

Key Benefits:

• Not over the public internet

• High availability

• Consistent latency

• High bandwidth options (up to 10 Gbps)

5.3.2 Use Cases

• Enterprise-grade workloads

• Large-scale data transfers

• Financial services, healthcare, or regulated industries

5.4 Gateway Configuration

5.4.1 Virtual Network Gateway

A Virtual Network Gateway is required to create:

• S2S and P2S VPNs

• ExpressRoute connections

You must choose the gateway type:

• VPN: for IPsec/IKE-based tunnels

• ExpressRoute: for dedicated lines

5.4.2 SKU Selection

Choose a gateway SKU based on:

• Bandwidth needs

• Connection count

• Features (e.g., BGP support)

SKU	Type	Use
Basic	VPN	Entry-level, limited features
VpnGw1-5	VPN	Production-grade VPN
ErGw1-3	ExpressRoute	Dedicated private connectivity

Gateway creation may take up to 45 minutes. Plan accordingly.

6. Configure Load Balancing

Azure provides multiple load balancing options to distribute traffic, ensure high availability, and support global scalability. The right choice depends on traffic type, protocol layer, and deployment scope.

6.1 Azure Load Balancer (Layer 4)

6.1.1 What is Azure Load Balancer?

A Layer 4 (TCP/UDP) load balancer that distributes incoming traffic across backend resources (e.g., VMs) in a virtual network.

Best for:

• Load balancing VM traffic within a region

• Supporting high availability

6.1.2 Key Features

• Inbound NAT rules: Route specific ports to VMs (e.g., port 3389 to VM1)

• HA ports: Enable load balancing across all ports

• Health probes: Check VM status before forwarding traffic

• Outbound rules: Control internet traffic from backend pool

6.1.3 SKU Comparison

Feature	Basic	Standard
Backend pool size	Limited	Up to 1000
Availability zones	No	Yes
Diagnostics and metrics	No	Yes
SLA	None	99.99%

Use Standard Load Balancer for production workloads.

6.2 Application Gateway (Layer 7)

6.2.1 What is Application Gateway?

A Layer 7 (HTTP/HTTPS) load balancer for web applications.

Best for:

• Load balancing web traffic

• Advanced HTTP features

6.2.2 Key Features

• SSL termination: Offload HTTPS decryption

• Web Application Firewall (WAF): Protects against OWASP top 10 threats

• Cookie-based session affinity

• URL path-based routing: Send /images to server A, /api to server B

• Multi-site hosting: Host multiple domains on one gateway

6.3 Traffic Manager (DNS-Level Routing)

6.3.1 What is Traffic Manager?

Traffic Manager is a DNS-based load balancer that routes users to the best endpoint globally, based on various rules.

Best for:

• Global web applications

• Disaster recovery routing

6.3.2 Routing Methods

Method	Purpose
Performance	Route to closest endpoint
Priority	Use primary, failover to secondary
Geographic	Route based on user’s region
Weighted	Distribute based on percentages

Traffic Manager doesn’t handle actual traffic—it only resolves DNS to the right endpoint.

6.4 Azure Front Door

6.4.1 What is Azure Front Door?

Front Door is a global HTTP/HTTPS load balancer and content delivery service.

Best for:

• High-performance, low-latency global apps

• Advanced edge-based features

6.4.2 Key Features

• SSL offload

• Web Application Firewall (WAF)

• Global anycast IP

• URL-based routing

• Caching and CDN integration

• Health probes

Unlike Application Gateway, Front Door operates at the edge, not within a VNet.

Implement and Manage Virtual Networking (Additional Content)

1. User-Defined Routes (UDR)

User-Defined Routes allow you to override Azure’s default system routes and define custom traffic flow.

1.1 How to Configure

1. Create a route table:

   • Azure Portal → "Route tables" → "+ Add"

2. Add custom routes:

   • Specify address prefix (e.g., 0.0.0.0/0)

   • Choose next hop type: Virtual appliance, VPN gateway, or None (blackhole)

3. Associate the route table with a subnet.

1.2 Common Use Cases

• Next hop = NVA (Network Virtual Appliance):
  Redirect traffic to a firewall or inspection device.

• Blackhole route:
  Route traffic to None to block all traffic to a destination (e.g., 0.0.0.0/0 to block internet).

• Force tunneling:
  Redirect all internet-bound traffic back to on-premises via a VPN.

Exam Tip: Expect scenarios involving traffic control to/from subnets, and choosing between system route, UDR, or BGP route precedence.

2. Forced Tunneling

Definition: A technique that forces outbound internet traffic from Azure resources to go through on-premises infrastructure, typically for auditing or inspection purposes.

How It Works

• Use a custom route:

  • 0.0.0.0/0 → VPN Gateway IP

• Combine with a Site-to-Site VPN Gateway.

Why Use It

• Regulatory compliance

• Centralized monitoring and egress filtering

Implementation Steps

1. Set up a Site-to-Site VPN to on-premises.

2. Create a UDR for 0.0.0.0/0 with next hop set to VPN gateway.

3. Associate this route with the target subnet(s).

Exam Tip: Understand the routing order precedence and that forced tunneling requires disabling default internet access via UDR.

3. View Effective NSG Rules

Purpose: To troubleshoot and understand the actual security rules affecting a VM’s network interface.

How to View

• Azure Portal:

  • Go to VM → Networking → Network interface → Effective security rules

• Azure CLI:

  az network nic list-effective-nsg --name <NIC_NAME> --resource-group <RG_NAME>
  

Why It Matters

• Diagnosing conflicts between NSGs at subnet and NIC levels

• Verifying rule priority

• Confirming inbound and outbound allowed/denied traffic

Exam Tip: Effective security rules are calculated after all NSGs, priorities, and service tags are evaluated.

4. App Service VNet Integration Modes

App Services can connect to VNets, but the behavior depends on the integration mode.

4.1 Regional VNet Integration

• Works with VNets in the same region.

• Used for outbound access only (e.g., access to databases, APIs in VNet).

• Uses delegated subnet and private IPs.

4.2 Gateway-required Integration

• For cross-region scenarios.

• Uses a VPN Gateway to route traffic.

• Slower, more complex setup, but allows integration with remote VNets.

Important Limitation

• App Service cannot be accessed inbound from the VNet using VNet integration alone.

• To allow inbound access from a VNet, use Private Endpoint.

Exam Tip: Many questions test whether App Service can be accessed by other services inside a VNet—answer is No, unless Private Endpoint is configured.

5. Network Diagnostic Tools

Azure provides Network Watcher for diagnosing and monitoring network-related issues.

Key Tools Within Network Watcher

• IP Flow Verify:

  • Test if a specific inbound/outbound flow is allowed by NSG.

• NSG Flow Logs:

  • Logs NSG rule hits for auditing or traffic analysis.

• Packet Capture:

  • Collects live network traffic from VMs for deep analysis.

• Connection Troubleshoot:

  • Checks if traffic can flow between source and destination IPs/ports.

Enablement

• Enable Network Watcher per region or automatically via portal.

Exam Tip: You may be given a scenario with failed connectivity and asked which Network Watcher tool to use (e.g., use IP Flow Verify for NSG blockage).