Unit 6 - Practice Quiz

An Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure. It provides a secure and isolated environment for your virtual machines and other resources.

Subnets allow you to segment a virtual network into one or more smaller networks. This helps with IP address allocation, network organization, and applying security policies to groups of resources.

A Network Security Group (NSG) contains a list of security rules that allow or deny network traffic to and from Azure resources. It functions as a basic firewall at the network level.

Azure processes NSG rules in priority order, starting with the lowest number. Once a rule matches the traffic, processing stops, and that rule is applied.

VNet peering allows resources in two different virtual networks to communicate with each other with low latency and high bandwidth, as if they were in the same network. All traffic remains on the private Microsoft backbone network.

If the IP address spaces of two VNets overlap, Azure cannot create a peering connection because it would be unable to determine how to route the traffic between them.

A route table contains a set of rules, called routes, that determine where network traffic is sent. You can associate a route table with a subnet to control the flow of its outbound traffic.

A Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route on the Azure backbone network. It ensures traffic from your VNet to the Azure service remains on the Azure network.

An Azure Load Balancer improves application availability and scalability by distributing network traffic among multiple virtual machines in a backend pool.

The standard Azure Load Balancer is a Layer 4 load balancer. It makes routing decisions based on information from the Transport layer, such as source IP address, source port, destination IP address, destination port, and protocol.

Azure Application Gateway is a Layer 7 load balancer. This allows it to make intelligent routing decisions based on HTTP request attributes like URL path or host headers, making it ideal for managing web application traffic.

The Web Application Firewall (WAF) is a security feature that protects web applications from common vulnerabilities and exploits by inspecting incoming web traffic and blocking malicious requests.

Azure CDN reduces latency by caching static content (like images, videos, and scripts) at strategically placed physical nodes (Points of Presence) around the world, delivering it to users from the closest location.

Azure Front Door is a modern cloud CDN service that provides global load balancing and site acceleration for web applications. It operates at Layer 7 and routes client requests to the best-performing application backend.

Azure VNets use CIDR notation (e.g., 10.1.0.0/16) to define the private IP address range for the network and its subnets.

NSGs can be applied at two different levels for filtering traffic: to a subnet to protect all resources within it, or directly to a specific NIC attached to a VM for more granular control.

VNet peering is non-transitive. If VNet A is peered with VNet B, and VNet B is peered with VNet C, VNet A and VNet C cannot communicate with each other unless a direct peering is established between them.

A health probe is used by the load balancer to periodically check if the backend virtual machines are responsive. If a VM fails the health probe, the load balancer stops sending traffic to it until it becomes healthy again.

Azure Application Gateway can terminate the SSL/TLS connection at the gateway. This offloads the CPU-intensive encryption and decryption work from your web servers, allowing them to focus on serving application logic.

A Private Endpoint is a network interface that connects you privately and securely to a service like Azure Storage or SQL Database. It uses a private IP address from your VNet, effectively bringing the service into your virtual network.

To determine the appropriate subnet size, we find the smallest CIDR block that meets the host requirement. A /26 block provides usable IPs (sufficient for 50 hosts). A /25 block provides usable IPs (sufficient for 100 hosts). A /27 block provides usable IPs (sufficient for 20 hosts). This option correctly allocates the most efficient CIDR blocks for each tier's needs.

Azure NSG rules are processed in order of priority, from the lowest number to the highest. Rule 1 has a priority of 200, which is lower than Rule 2's priority of 300. Therefore, Rule 1 is evaluated first. Since it denies all traffic on port 22 from any source, the administrator's connection attempt will be blocked, and Rule 2 will never be evaluated.

Azure VNet peering is non-transitive. This means that if VNet-A is peered with VNet-B, and VNet-B is peered with VNet-C, there is no implied or automatic peering between VNet-A and VNet-C. To enable direct communication between resources in VNet-A and VNet-C, a dedicated peering connection must be explicitly created between them.

The standard way to control routing behavior in an Azure VNet is by using Route Tables and User-Defined Routes (UDRs). To force traffic through an NVA, you would create a UDR for the address prefix 0.0.0.0/0 (representing all internet traffic) and set the 'Next hop type' to 'Virtual appliance' and the 'Next hop IP address' to the private IP of your NVA. This Route Table is then associated with the source subnet.

Session persistence, also known as source IP affinity or sticky sessions, is the feature designed for this scenario. By configuring session persistence on a load balancing rule, you instruct the load balancer to use a hash of the source IP (and sometimes protocol and port) to map traffic to a specific backend server, ensuring subsequent requests from the same client are sent to the same server.

Multi-site listening functionality allows you to configure more than one listener on the same port of the Application Gateway. This enables you to host multiple websites on a single Application Gateway instance. The gateway uses the host header from the incoming HTTP request to determine which listener should process the request and which backend pool to route it to.

Azure Front Door is a global, scalable entry-point that uses the Microsoft global edge network. It is designed for this exact scenario. It provides Layer 7 load balancing, uses anycast to route clients to the nearest Point of Presence (POP), and offers priority-based routing with health probes for seamless regional failover. While Traffic Manager also provides DNS-based routing, Front Door operates at the HTTP layer, offering additional features like SSL offloading and WAF.

When NSGs are applied at both the subnet and NIC levels, they are processed in a specific order. For inbound traffic, the subnet-level NSG is evaluated first. If it allows the traffic, the NIC-level NSG is then evaluated. The traffic is only permitted if it passes through the 'Allow' rules of both NSGs. A 'Deny' at either level will block the traffic.

To enable gateway transit, you must configure both sides of the peering connection. The VNet with the gateway (the hub) must be configured to 'Allow gateway transit'. The VNet without the gateway (the spoke) must be configured to 'Use the remote virtual network's gateway'. This allows the spoke VNet to leverage the hub's gateway for external connectivity.

Service Endpoints provide secure and direct connectivity to Azure services over the Azure backbone network. By enabling the Microsoft.Sql service endpoint on a subnet, traffic from that subnet to Azure SQL uses private source IPs. You can then configure the SQL Database's firewall to only allow traffic from that specific subnet, effectively locking it down from the public internet. While Private Endpoints also work, Service Endpoints are a more direct solution when a private IP in the VNet is not strictly required.

The v2 generation of Application Gateway SKUs (Standard_v2 and WAF_v2) provides autoscaling. To add Web Application Firewall (WAF) capabilities to a Standard_v2 SKU, you must create a separate WAF Policy and associate it with the gateway or a specific listener. The older WAF SKU is part of the v1 generation and does not support autoscaling. Therefore, to get both autoscaling (v2) and WAF protection, you must use a v2 SKU (Standard_v2 is sufficient) and attach a WAF Policy.

Azure CDN is the service specifically designed for caching static content at strategically placed points of presence (POPs) around the globe. When a user requests content, it is served from the closest POP, which significantly reduces latency and improves performance. While Azure Front Door also has caching capabilities, its primary purpose is global traffic routing and application acceleration, whereas CDN's core function is static content caching and delivery.

Azure VNets support multiple, non-contiguous address spaces. You can add a new address space to an existing VNet without any service disruption. The correct procedure is to navigate to the VNet's settings, go to the 'Address spaces' section, and add the new CIDR block (192.168.4.0/22). After it's added, you can then create new subnets within that new address space.

Unlike the Basic SKU, the Standard SKU Load Balancer is secure by default and does not provide automatic outbound connectivity. To enable it, you must explicitly define outbound connectivity. The recommended way is to create an outbound rule that specifies which backend pool can use the load balancer's public frontend IP for Source Network Address Translation (SNAT) to access the internet.

A fundamental requirement for VNet peering is that the virtual networks being peered must have non-overlapping IP address spaces. In this scenario, the address space of VNet-B (10.0.0.0/24) is a subset of the address space of VNet-A (10.0.0.0/16), which constitutes an overlap. Azure cannot create the peering because it would be unable to route traffic correctly between them.

The key distinction is that a Private Endpoint projects the PaaS service directly into your VNet by assigning it a private IP address from one of your subnets. This makes the PaaS service appear as if it's a native part of your VNet. This allows connectivity from on-premises networks (via VPN/ExpressRoute) and peered VNets, which is not possible with Service Endpoints. Service Endpoints only secure the connection from a specific subnet to the service's public endpoint.

SSL/TLS termination is the process where the Application Gateway (or any reverse proxy) decrypts incoming HTTPS traffic from clients. It then forwards the requests to the backend servers over unencrypted HTTP. This offloads the computationally expensive decryption and encryption tasks from the backend servers, freeing up their CPU cycles to serve content. It is secure as long as the backend network is properly isolated.

Service Tags are Microsoft-managed labels that represent a group of IP address prefixes for a given Azure service. Using a Service Tag like AzureBackup or Storage in the source or destination of an NSG rule simplifies rule creation. Microsoft automatically updates the IP addresses included in the tag, ensuring your rule stays current without manual intervention.

The Load Balancer will mark a backend instance as unhealthy only after it fails a number of consecutive probes equal to the 'unhealthy threshold'. In this case, the probe interval is 5 seconds and the threshold is 2. Therefore, the Load Balancer must wait for two failed probes. Minimum time = (Probe Interval) (Unhealthy Threshold) = 5 seconds 2 = 10 seconds.

Azure Front Door's primary role is that of a global HTTP/S load balancer and application delivery network. It excels at routing traffic to the best (lowest latency, highest priority) origin and providing fast, automatic failover if an origin becomes unhealthy. While Azure CDN is excellent for caching and delivering static content from a single origin (or with some manual failover configurations), dynamic site acceleration and intelligent global routing between multiple active origins is the core competency of Azure Front Door.

Azure processes NSG rules in a specific order. For inbound traffic, rules in the NSG associated with the subnet are processed first. If traffic is allowed by the subnet NSG, rules in the NSG associated with the NIC are processed next. In this scenario, the nsg-subnet rule (Priority 200) allows traffic from asg-web. However, the traffic must then be evaluated by nsg-nic. The rule in nsg-nic (Priority 300) explicitly denies all traffic on port 443. Since there is a matching Deny rule at the NIC level, the traffic is ultimately blocked. A Deny rule at either level will block the traffic.

Azure routing decisions are based on the longest prefix match. When you create a Service Endpoint for an Azure service like Microsoft.Storage, Azure adds more specific system routes for the public IP address prefixes of that service to the subnet's effective route table. These routes have a next hop type of VirtualNetworkServiceEndpoint. Because these routes (e.g., 13.78.144.0/21) are more specific than the 0.0.0.0/0 UDR, traffic destined for the storage account will match the Service Endpoint route and travel directly over the Azure backbone, bypassing the NVA.

Azure VNet peering is not transitive. This means if VNet-A is peered with VNet-B, and VNet-B is peered with VNet-C, there is no implied connectivity between VNet-A and VNet-C. The 'Gateway Transit' feature extends this limitation. While it allows VMs in VNet-B to use the gateway in VNet-A, it does not extend this capability another hop to VNet-C. The remote gateway is only visible to directly peered networks. To enable connectivity from VNet-C to VNet-A, a direct peering between VNet-A and VNet-C would be required.

Azure Load Balancer processes rules with a specific precedence. Inbound NAT rules are evaluated before load balancing rules. Even though an HA Ports rule is configured to handle all traffic, the more specific inbound NAT rule for TCP port 22 will match the incoming SSH request first. Therefore, the traffic is directed specifically to the target defined in the NAT rule (NVA-1) and is not subject to the HA Ports load balancing logic.

In Azure Application Gateway WAF v2, custom rules are processed before managed rules. Rules are processed in priority order (lower number means higher priority). In this case, the custom rule with priority 50 runs first. Since the request matches the custom rule's condition (correct X-Internal-Token header) and the action is Allow, the WAF stops processing further rules and allows the request to pass to the backend. The managed ruleset is never evaluated for this specific request. This behavior is useful for creating exceptions to managed rules.

While you can configure a VNet's DNS settings to point to any IP address, DNS queries are standard network traffic. For a VM in vnet-isolated to reach the DNS server in vnet-hub, there must be a network path between them. Since vnet-isolated is not peered with vnet-hub, there is no route from the vnet-isolated address space to the vnet-hub address space. The DNS query from the VM will be sent, but it will be unable to reach the destination IP of the DNS server, causing the resolution to time out and fail. VNet peering or another routing mechanism (like a VNet gateway) would be required to establish this connectivity.

Azure Front Door uses a two-step process for routing: priority and then weight. It first sends all traffic to the available, healthy backends in the highest-priority group (Priority 1). Only if all backends in the Priority 1 group become unhealthy will it fail over to the next priority group (Priority 2). In this scenario, even though the West US backend is unhealthy, the East US backend is in the same priority group (Priority 1) and is still healthy. Therefore, 100% of the traffic will be directed to the remaining healthy backend in the highest-priority group, which is the East US App Service. The weights are only used to distribute traffic among healthy backends within the same priority group.

This scenario highlights a critical conflict between UDR-based forced tunneling and Service Endpoints. While a Service Endpoint creates a more specific route for storage traffic, the UDR for 0.0.0.0/0 to the firewall will still override it for public endpoints. The traffic is sent to the Azure Firewall. The source IP of the traffic is now the firewall's IP, not the VM's private IP. The storage account's firewall rule is configured to allow access from the VNet/subnet, which works by checking if the source private IP originates from the allowed subnet. Since the traffic now originates from the firewall, it is no longer coming from an IP within the authorized subnet, and the storage account will deny the connection. The solution to this problem is to use Private Endpoints instead of Service Endpoints in forced tunneling scenarios.

A fundamental requirement for VNet peering is that the address spaces of the two virtual networks must not overlap. This rule extends to the entire peered network topology. When you attempt to peer VNet-A with VNet-B, Azure checks for overlaps not only with VNet-B itself but also with all of VNet-B's existing peers. Since the address space of VNet-C (10.0.0.0/24) is a subset of VNet-A's address space (10.0.0.0/16), this constitutes an overlap. As a result, the peering operation between VNet-A and VNet-B will fail validation and cannot be created.

Floating IP, also known as Direct Server Return (DSR), changes the IP address mapping. Without Floating IP, the backend VM would see traffic coming from the load balancer's internal IP and would respond back through the load balancer. With Floating IP enabled, the destination IP of the packet arriving at the VM is the load balancer's frontend IP, not the VM's private IP. The VM's network stack is configured (e.g., via a loopback adapter) to accept traffic for this IP. For the return path (Direct Server Return), the VM must send the response packet with its source IP set to the load balancer's frontend IP. This makes the return traffic appear to come directly from the load balancer, maintaining a symmetric flow from the client's perspective.

In Azure Application Gateway v2, rewrite sets can be associated with a routing rule. When associated with a path-based routing rule, the rewrite configuration applies to all requests that match the parent rule, regardless of which path-based rule is ultimately chosen. The gateway first evaluates the listener (contoso.com), then the path-based rule (/images/*), determining the backend is ImagePool. Because the request matches the parent routing rule, the associated rewrite set is executed, adding the X-Request-Source header before the request is forwarded to a backend server in ImagePool.

NSG rule processing is based on priority, with the lowest number having the highest priority. When the VM initiates an outbound connection to www.bing.com (which is hosted in Azure and thus its IP is in the AzureCloud service tag range) on port 80, the NSG evaluates its outbound rules. The rule with priority 100 is checked first. The request matches this rule (Source: VM's IP is within Any, Destination: www.bing.com IP is within AzureCloud). Since the action is Allow, processing stops, and the traffic is permitted. The rule with priority 200, which would deny the traffic, is never evaluated because a matching rule with a higher priority has already been found.

This setup is a standard and recommended pattern for hub-spoke private endpoint DNS resolution. The VM in the spoke VNet is configured to use the custom DNS server in the hub. When it tries to resolve mydb.database.windows.net, it sends the query to the hub's DNS server. This DNS server, in turn, forwards the query to the Azure-provided DNS (168.63.129.16). Because the hub VNet is linked to the privatelink.database.windows.net Private DNS Zone, Azure DNS will respond with the private 'A' record from that zone. This private IP is then returned to the custom DNS server, and finally back to the VM in the spoke. Therefore, linking the zone to the hub (where DNS resolution happens) is sufficient.

The Azure CDN Rules Engine provides granular control over content delivery and caching, and its rules take precedence over the origin's HTTP headers. In this scenario, the request URL /dynamic/script.js matches the condition (Path contains /dynamic/). The corresponding action is to Bypass cache. This action explicitly instructs the CDN edge node (POP) to not cache the content and to forward every request for this asset directly to the origin. The Cache-Control: max-age=3600 header sent by the Blob Storage origin is effectively ignored by the CDN for any path matching this rule.

While subnet delegation does place certain restrictions on a subnet to ensure compatibility with the service being deployed, the specific delegation for ASEv3 (Microsoft.Web/hostingEnvironments) explicitly allows and requires the association of an NSG. The platform needs an NSG to function correctly and applies its own set of required rules. However, you are still permitted to add your own custom rules to the NSG, as long as they don't conflict with the required platform rules. Therefore, you can associate an NSG and add a custom rule to block specific outbound traffic.

When a Standard SKU public load balancer has a backend pool, it automatically provides outbound SNAT (Source Network Address Translation) for the VMs in that pool, provided they do not have their own instance-level public IPs. The VMs' private IPs are translated to the public IP of the load balancer for outbound connections. This is an implicit configuration. While it's best practice to configure explicit outbound connectivity using a NAT Gateway or outbound rules for better control over SNAT port allocation and to avoid SNAT exhaustion, the default behavior does provide internet access.

Azure has specific constraints on the Application Gateway subnet. One of the most critical is that while you can associate a route table, it cannot contain a User-Defined Route (UDR) for 0.0.0.0/0 that points to a virtual appliance like Azure Firewall. Doing so is an unsupported configuration that will break the control plane communication required for the Application Gateway to function correctly. Traffic to the backend pools must have a direct network path. To inspect traffic, the firewall should be placed in front of the Application Gateway (for ingress) or other architectural patterns must be used, but you cannot force egress traffic from the App Gateway subnet through a firewall via a 0.0.0.0/0 UDR.

One of the key benefits of VNet peering, including Global VNet Peering, is that all traffic between the peered networks travels across the Microsoft private global backbone, not the public internet. This provides a more secure and reliable connection. However, data transfer is not free. For traffic crossing regional boundaries via Global VNet Peering, specific cross-region (inter-continental in this case) data transfer rates apply. These rates are different and typically higher than the rates for data transfer within the same region or for standard internet egress.

This scenario describes a classic asymmetric routing problem. The outbound traffic from Subnet-A to Subnet-B is forced through the NVA by the UDR. However, the VM in Subnet-B has no UDR telling it to do the same for the return traffic. It will check its effective route table. Since Subnet-A is in the same VNet, the system route for the VNet address space will be used, which has a next hop type of VNet. This means the return packet will be sent directly to the original VM's IP in Subnet-A, bypassing the NVA. The NVA sees the request go out but not the reply come back, which can break stateful firewalls or other inspection appliances. To fix this, a corresponding UDR would need to be applied to Subnet-B forcing traffic destined for Subnet-A back through the NVA.

Azure VNets support multiple, non-contiguous address spaces. When you add an address space to a VNet, Azure automatically updates the system route tables for all subnets within that VNet to include routes for all configured address spaces. The next hop for these routes is VirtualNetwork. Therefore, a VM in a subnet from the 192.168.0.0/24 range can communicate directly with a VM in a subnet from the 10.10.0.0/16 range as if they were in the same address block. No additional configuration like UDRs or gateways is needed for this intra-VNet communication.