Secure networking practice questions

The Azure Firewall is not in the same region as the spoke.

Why it fails: An Azure Firewall is a regional service, but it can inspect traffic for spokes in other regions when reached over global VNet peering. The hub VNet's firewall is accessed by its private IP address as a virtual-appliance next hop, and Azure's global peering forwards that traffic regardless of region mismatch. A regional difference alone cannot explain why on-premises traffic bypasses the firewall; the actual issue is the missing specific route for the on-premises prefix in the spoke's route table.

The ExpressRoute gateway's BGP routes are still overriding the UDR because gateway propagation is not fully disabled.

Why it fails: Disabling 'Virtual network gateway route propagation' on a route table stops learned ExpressRoute/BGP routes from being added to the spoke subnet's effective routes. If propagation were still partially enabled, the on-premises BGP route would show up, but it would not override a more-specific UDR that points to the firewall — longest-prefix match would prefer that UDR. The problem is not an incomplete propagation setting; it is that no UDR exists for the specific on-premises prefix, so the default 0.0.0.0/0 route never applies to that traffic.

The route table is not associated with the spoke subnet.

Why it fails: If the route table were not associated with the subnet, no UDR would apply at all, and traffic would use default routes. But internet traffic was being routed through the firewall, indicating the route table is associated.

The Azure Firewall is not configured with a default route.

Why it fails: The Azure Firewall is not configured with a default route. This is not the reason traffic bypasses the firewall because Azure Firewall does not require a default route on its own subnet to inspect traffic; it operates as a transparent layer-3/4 filter that processes packets forwarded to it via UDRs. The relevant routing is the user-defined route on the spoke subnet pointing to the firewall's private IP, not the firewall's internal routing table. Even if the firewall lacks a default route, it can still receive and inspect outbound traffic as long as the UDR is correctly configured and the firewall has a route back to the source subnet.

The virtual machines have public IP addresses assigned.

Why it fails: The virtual machines have public IP addresses assigned. This is the correct cause because when an Azure VM has a public IP address assigned to its network interface, Azure automatically performs default outbound SNAT using that public IP, which bypasses any UDRs pointing to the firewall. The traffic from the VM to the internet egresses directly through the public IP, and the route table is ignored for that outbound flow. To force traffic through the firewall, the VMs should use a NAT gateway or be deployed in a subnet without public IPs, with the UDR sending all internet-bound traffic to the firewall's private IP.

The VNet peering is not configured properly.

Why it fails: The VNet peering is not configured properly. This is not the cause because VNet peering is only required when the firewall is in a different virtual network than the VMs, and the scenario does not indicate that peering is misconfigured. Even if peering were involved, the peering connection would only affect routing between VNets; the issue described is about outbound internet traffic from VMs with public IPs, which is independent of peering. The presence of public IPs on the VMs is a far more direct and common explanation for why the firewall is not inspecting the traffic, making the peering configuration irrelevant to this specific failure.

The VNet peering is not configured to allow traffic from VNet-B to route through VNet-A.

Why it fails: VNet peering in Azure is bidirectional by default once established; it permits any-to-any traffic between the peered VNets, including traffic that enters one VNet and is routed to the other via an NVA. The act of routing through an NVA is governed by user-defined routes (UDRs) and IP forwarding, not by a separate peering toggle. Therefore, a missing 'allow traffic to route through' setting is not a valid failure mode because such a setting does not exist in Azure VNet peering.

The route table is not associated with the subnet in VNet-B.

Why it fails: The question explicitly states that the route table is associated with the subnet in VNet-B, so this cannot be the cause. Even if association were absent, traffic between directly peered VNets would still flow using the default system route, bypassing the NVA entirely and reaching VNet-A directly. In the described scenario, the intended NVA path is failing because the NVA itself cannot forward, not because the route table is missing.

The NVA does not have a public IP address.

Why it fails: An NVA in Azure forwards traffic using its private IP address; the public IP (if any) is only used for inbound internet-facing connections or outbound SNAT. In a VNet-to-VNet peering scenario, all traffic remains within the Azure backbone and uses private addressing. A public IP is irrelevant to the NVA's ability to route, so its absence would not cause the connectivity failure described.

The NVA's private IP address is not reachable from VNet-B

Why it fails: If the NVA were unreachable, traffic would fail, but the question states traffic still flows directly, not that it fails.

VNet peering system routes override user-defined routes

Why it fails: UDRs take precedence over system routes for the specified destination prefix. Peering system routes are overridden by UDRs.

The UDR must be applied to the gateway subnet of VNet-B

Why it fails: The UDR should be applied to the subnet where the source VMs are located, not the gateway subnet. The configuration described is correct in terms of subnet selection.

The SQL server's firewall also has a rule allowing all Azure services, which overrides the VNet rule

Why it fails: A firewall rule that allows all Azure services is broader in scope than a VNet rule; it permits connections from any Azure public IP used by other services, rather than restricting access. It cannot override a VNet rule because it does not deny traffic, and its presence would make access more permissive, not less. An authorization error indicates the client's source IP was not recognized by any allow rule, which the 'Allow Azure services' rule would have satisfied if the connection actually originated from an Azure service IP.

The virtual machine's operating system firewall is blocking outbound traffic

Why it fails: An operating system firewall blocking outbound traffic would prevent the VM from reaching the SQL server at the network layer, resulting in a connection timeout or unreachable host error, not an authorization failure. The error message from Azure SQL indicates the TCP connection was successfully established and the request reached the server, but the server rejected it based on identity or network rules. OS-level filtering would stop the request before SQL could evaluate any firewall rules, producing a different diagnostic signature.

The subnet's NSG is blocking outbound traffic to Azure SQL

Why it fails: While an NSG rule blocking outbound traffic to Azure SQL would prevent connectivity, the failure would manifest as a timeout or connection refused error, not an authorization error from SQL. Additionally, if the Microsoft.Sql service endpoint were correctly enabled on the subnet, the NSG would still apply, but the connection would still reach SQL, enabling the server to return a specific permission error. The most direct cause of an authorization error in this configuration is the service endpoint not being enabled, which breaks the VNet rule's source matching, not an NSG dropping the traffic.

The UDR on VNet-B must also include a route for the default route (0.0.0.0/0) to force all traffic through the NVA

Why it fails: The scenario only concerns traffic between VNet-B and VNet-A. A default route is not required to force traffic between the two VNets through the NVA; the specific route for the VNet-A address space should be sufficient.

VNet peering does not support user-defined routes

Why it fails: Azure VNet peering fully supports user-defined routes (UDRs). Route tables can be associated with subnets in either the hub or spoke VNet, and a UDR can specify a virtual appliance in a peered VNet as the next hop for traffic destined to the other VNet's address space. The claim that peering does not support UDRs is incorrect; peering actually relies on effective routes, which include both system routes and any user-defined routes applied to the source subnet.

The NVA must be deployed in the same subnet as the source VMs in VNet-B

Why it fails: An NVA does not need to reside in the same subnet as the source VMs in VNet-B. It can be placed in a different subnet within VNet-B or even in a different VNet entirely, such as the hub VNet, as long as the corresponding route tables use its private IP address as the next hop for the destination address range. The core requirement is that the NVA's network interface has IP forwarding enabled so it can accept and forward traffic not originally destined to its own IP, not that it shares the source subnet.

The Azure Firewall subnet is missing a route table entry for the 0.0.0.0/0 route

Why it fails: The Azure Firewall subnet (AzureFirewallSubnet) does require a default route to the Internet for the firewall's own outbound traffic, but this route is not what directs spoke traffic to the firewall. Spoke traffic is steered by a user-defined route (UDR) on the spoke subnet with a 0.0.0.0/0 address prefix and the firewall's private IP as the next hop. Missing a 0.0.0.0/0 route on the firewall subnet would cause the firewall to lose Internet connectivity, not cause spoke traffic to bypass it. The bypass occurs because the spoke subnet's route table either lacks the UDR or has a conflicting route, so the diagnostic focus should be on the spoke route table and its Effective Routes, not the firewall subnet.

The VNet peering does not allow forwarded traffic from the spoke to the firewall

Why it fails: Forwarded traffic is allowed by default when virtual network gateway is not used. The requirement for allowing forwarded traffic is the 'Allow virtual network gateway transit' setting in the hub and 'Use remote virtual network gateways' in the spoke, but this is for gateway transit, not for routing through a firewall instance.

The Azure Firewall is not configured with the 'Allow outbound traffic' rule

Why it fails: Firewall rules affect which traffic is allowed, not the routing path. Even without a rule, traffic would still reach the firewall (if routed), but be dropped. The issue is that traffic never reaches the firewall.

The UDR is not applied to the subnet in VNet-B

Why it fails: The scenario explicitly states that the UDR is already configured and applied to the subnet in VNet-B, so the route table is in effect. If no UDR were applied, traffic would simply follow the default system route to the peered VNet-A, which would also bypass the NVA entirely. Because the UDR is active, the cause must be downstream on the NVA side, not an absent route table assignment.

VNet peering does not support user-defined routes

Why it fails: User-defined routes are fully supported in conjunction with VNet peering. A custom route table applied to a subnet overrides the system route created by the peering, so traffic can be forced to the NVA rather than taking the direct peered path. The absence of a UDR for the peering itself is not the problem; in fact, the UDR is present and working as designed. The reason connectivity fails is that the NVA cannot forward packets without IP forwarding enabled.

The NVA must be in the same virtual network as the spoke

Why it fails: There is no Azure requirement that a network virtual appliance reside in the same virtual network as the spoke from which traffic originates. A hub-and-spoke topology with VNet peering between VNet-A and VNet-B is a standard design, and any UDR can specify an NVA's private IP in a peered VNet as the next hop. As long as the peering connection exists and the NVA's NIC has IP forwarding enabled, traffic can be routed across the peered topology. The NVA's location is not the issue in this scenario.

Deploy an Azure VPN Gateway in each VNet and create a site-to-site VPN connection between them.

Why it fails: This would create encrypted tunnels, but it introduces additional cost and complexity. Also, the connection would be through the gateways, not directly between VNets. It may not cover all traffic if there are multiple spoke VNets.

Configure a network security group (NSG) rule on each subnet to deny traffic that is not IPsec encapsulated.

Why it fails: NSGs filter by IP, port and protocol; they cannot identify or deny non-IPsec-encapsulated packets, so unencrypted traffic still passes. NSGs are tempting because they are the usual subnet-level control, and would be correct for restricting which flows are permitted, not for enforcing encryption.

Enable 'Allow gateway transit' on VNet-A and 'Use remote virtual network gateways' on VNet-B, and then create a VPN gateway in VNet-A.

Why it fails: This configuration enables transitive routing via a gateway, but does not encrypt the traffic between the VNets over peering. The gateway would only encrypt traffic going through it, but traffic between the VNets may still use the peering direct path unencrypted.

One inbound rule: Allow HTTPS from 203.0.113.0/24 with priority 100. No other rules. Rely on the default deny-all rule.

Why it fails: The default deny-all rule has priority 65000, which is lower than the allow rule. But any other traffic will be denied by the default rule. However, if there are other allow rules (like default allow vnet inbound), they may allow traffic from other sources. The scenario requires denying all other traffic, so a custom deny rule is needed to override any potential allow rules.

Two inbound rules: Deny All from Any with priority 100, and Allow HTTPS from 203.0.113.0/24 with priority 110.

Why it fails: The deny rule with priority 100 would block all traffic, including the HTTPS traffic from the corporate IP, because the deny rule is evaluated first (lower number = higher priority). The allow rule would never be applied.

One inbound rule: Deny All from Any with priority 100. No allow rules. Use application security groups.

Why it fails: A deny-all rule with no allow rule blocks the corporate HTTPS traffic the scenario requires, since NSG evaluation stops at the first match and priority 100 precedes any later allow. Application security groups group NICs, not external IP ranges. Such a baseline deny rule suits a default-deny posture paired with explicit allow rules.

Standard

Why it fails: DDoS Protection Standard is a paid tier that offers enhanced features like adaptive tuning, detailed metrics, and protection for multiple virtual networks. It is not required for a single App Service instance and would incur unnecessary cost.

Premium

Why it fails: There is no 'Premium' tier for Azure DDoS Protection. The available tiers are Basic and Standard.

No protection is needed because Azure App Service is inherently protected against DDoS attacks.

Why it fails: While Basic protection is automatic, it is not correct to say no protection is needed. Basic is sufficient, but it is a form of protection.

IKEv1 with DES

Why it fails: DES is a deprecated block cipher that uses a 56-bit key, making it trivially vulnerable to modern brute-force attacks; even the original 3DES variant is no longer recommended, and single DES is completely unacceptable for any IPsec tunnel. IKEv1 compounds this weakness with its older design, which lacks the security enhancements of IKEv2, so this option is severely under-secured and would never be selected.

IKEv2 with 3DES

Why it fails: While IKEv2 is a modern and secure key exchange protocol, 3DES is the weak link: it has a 64-bit block size, is susceptible to meet-in-the-middle attacks, and provides at most 112 bits of effective security, which falls short of the AES standard. For the same IKEv2 tunnel, AES256 offers significantly stronger encryption and addresses the performance and cryptographic deficiencies that make 3DES obsolete. Therefore, this is an inferior choice.

IKEv1 with AES128

Why it fails: IKEv1 is a legacy key exchange protocol that suffers from known design weaknesses, including a lack of built-in anti-DoS protection and reliance on the weaker pre-shared key authentication in aggressive mode, which is vulnerable to offline dictionary attacks. AES128, while adequate, provides a smaller key space than AES256 and is not considered a strong enough configuration for modern Azure VPN Gateway security. This combination is therefore not the best practice selection.

Azure Firewall with a routing table

Why it fails: Azure Firewall with a routing table is not the optimal solution here because, while it can filter internet traffic, it doesn't inherently provide private connectivity for Azure SQL Database. The requirement to prevent *direct* internet access to the Backend subnet, especially for a PaaS service like Azure SQL Database, is best met by a Private Endpoint, which brings the service into the virtual network privately. Azure Firewall is tempting as a centralised network security solution for filtering general inbound/outbound traffic, including internet access for IaaS resources, and would be appropriate for enforcing granular network and application rules across multiple subnets or controlling egress to the internet.

Service Endpoints

Why it fails: Service endpoints extend the VNet's identity and private address space to an Azure PaaS service by providing a direct route to that service over the Azure backbone, and they allow you to restrict access to the PaaS resource from selected subnets using service tags. However, they do not inspect or filter general TCP/UDP traffic, do not apply to non-PaaS destinations, and cannot deny inbound internet traffic to a subnet. In this scenario, a service endpoint would only help secure the database connection, not block internet clients from reaching the backend subnet.

Virtual Network Peering

Why it fails: VNet peering is a non-transitive, low-latency connection between two virtual networks that routes traffic between their address spaces using private IP addresses; it does not introduce any stateful filtering, packet inspection, or allow/deny rules. At best it can be used to connect a hub VNet that hosts a centralized firewall, but peering itself does not block internet traffic from reaching a backend subnet nor restrict access to Azure SQL Database. Therefore, peering is solely a connectivity mechanism, not a security control.

Enable Service Endpoint Policies

Why it fails: Service Endpoint Policies are a network security control that let you filter egress traffic from a virtual network to specific Azure PaaS resources, such as a particular Storage account, by restricting the service endpoints that can be reached. They do not create any IPsec or encryption tunnel between the peered VNets themselves. Traffic still traverses VNet peering without customer-managed encryption from an application perspective, so this does not satisfy the requirement to encrypt inter-VNet traffic.

VNet peering does not support encryption; use Global VNet peering

Why it fails: Global VNet peering simply extends peering across Azure regions, but it has exactly the same traffic behavior as regional peering: traffic travels over the Microsoft backbone without an IPsec tunnel. Peering, whether global or local, is not an encryption mechanism and does not provide confidentiality or integrity at the network layer between workloads. Replacing normal peering with Global VNet peering only solves a routing/topology problem, not the requirement to encrypt inter-VNet traffic.

Enable Azure Firewall

Why it fails: Azure Firewall is a cloud-native, stateful firewall that can inspect, filter, and log traffic between virtual networks, and it can even force traffic through a central security boundary, but it does not encrypt the traffic flowing through it. When traffic leaves Azure Firewall and continues over VNet peering, the packets are still unencrypted at the network layer. To provide encryption in transit for inter-VNet communication, you would need an IPsec VPN Gateway or another encryption solution, not simply enabling packet filtering.

Inbound NAT rule on Azure Load Balancer

Why it fails: An inbound NAT rule on an Azure Load Balancer maps external IP and port traffic to a backend VM, which is intended for exposing IaaS VMs rather than enabling outbound connectivity from a PaaS App Service to Azure SQL. App Service outbound traffic does not pass through a user-managed load balancer, and NAT rules do not integrate with Private Link, VNet service endpoints, or SQL firewall rules; therefore this option cannot establish or secure the required SQL access.

DDoS Protection Basic only

Why it fails: DDoS Protection Basic is a free, always-on layer-3/4 mitigation that protects public IP addresses from volumetric attacks, but it does not create any data path between App Service and Azure SQL nor restrict who or what can authenticate to the database. It does not bypass the SQL public endpoint, does not add Identity/AAD-based access, and does not affect outbound traffic from App Service, so by itself it completely fails the connectivity requirement.

Enable service endpoint only and leave public access open

Why it fails: Enabling a service endpoint alone does not make the Azure SQL database private; it only restricts access from specific virtual network subnets to the SQL server's public endpoint. If public network access remains open, the database is still reachable from the internet, though only from IPs or subnets that the firewall allows. This setup does not assign a private IP to the SQL server and still depends on the public endpoint with firewall rules, so it fails to provide true private-only connectivity. Service endpoints are a less secure legacy alternative and do not eliminate the public endpoint's existence.

Create an inbound NAT rule on Azure Load Balancer

Why it fails: An inbound NAT rule on an Azure Load Balancer forwards incoming traffic from the load balancer's public IP to a backend resource, typically a virtual machine running a workload. Azure SQL Database is a PaaS service with its own fully managed logical server, not a VM behind your load balancer, so a NAT rule cannot route to the SQL database. Even if you applied it to a VM hosting SQL, the traffic would still arrive via a public IP, violating the private-access requirement. This option is fundamentally misaligned with Azure SQL Database's architecture and provides no private connectivity.

Public IP addresses on every VM

Why it fails: Public IP addresses on spoke VMs do not, by themselves, force traffic through Azure Firewall; they create an independent Internet endpoint that can use Azure's default system route (0.0.0.0/0 -> Internet) for direct egress if the UDR is missing or overridden. In a hub-and-spoke design that must enforce centralized egress, every workload VM should normally have no public IP (or at minimum rely on the firewall's NAT), with all outbound traffic forced to the firewall. Therefore this answer is wrong because it does not meet the stated requirement as directly as configuring a default route with Azure Firewall as the next hop.

NSG rules that allow all inbound internet traffic

Why it fails: Network Security Group rules that permit all inbound Internet traffic are an ingress authorization mechanism, not a routing or egress enforcement mechanism. Even if such rules were used, they would not cause outbound traffic to pass through the firewall; the traffic would just be more exposed to inbound attacks. Since the requirement is about egress through Azure Firewall, this option is wrong both because it addresses the wrong direction and because it weakens the spoke's security posture.

Use Azure Front Door to route traffic between the web tier and the application tier.

Why it fails: Using Azure Front Door to route traffic between the web tier and the application tier is wrong because Front Door is a global layer-7 CDN and load balancer designed for inbound internet traffic to public endpoints, not for internal east-west communication between subnets within a virtual network. Front Door cannot address private IPs or internal VNet resources without public exposure, and adding it as an intermediary would introduce unnecessary latency and force traffic through Microsoft's edge, whereas internal traffic should use private load balancers or internal routing within the VNet.

Assign public IP addresses to the application tier virtual machines for monitoring purposes.

Why it fails: Assigning public IP addresses to the application tier virtual machines for monitoring purposes is wrong because it directly exposes the application-tier endpoints to the internet, negating the NSG deny rule and dramatically increasing the attack surface. Monitoring should instead be done through private IP connectivity, Azure Monitor agents, or a Log Analytics workspace with private link, which do not require any public address and keep sensitive internal services isolated from inbound internet traffic.

Configure a site-to-site VPN between the web tier and the application tier subnets.

Why it fails: Configuring a site-to-site VPN between the web tier and the application tier subnets is wrong because a site-to-site VPN connects an on-premises network to an Azure virtual network, not two subnets within the same VNet. Subnets in the same VNet already use Azure's internal routing and can communicate directly without any VPN, which would add redundant encryption overhead, failover complexity, and require virtual network gateways on both sides—a design that is unsupported and unnecessary; network segmentation between tiers is better achieved with NSGs, user-defined routes, or separate peered VNets.

Enable forced tunneling on the Azure Firewall to route traffic through an on-premises network.

Why it fails: Forced tunneling on Azure Firewall is a different feature that controls the firewall's own management and outbound traffic to route it through an on-premises network, not the spoke VMs' traffic. It does not inspect spoke-originated outbound traffic; instead it would send the firewall's management traffic to on-premises, which is unrelated to the goal of inspecting outbound traffic from the spoke VNet through the Azure Firewall.

Deploy a Network Virtual Appliance (NVA) in the spoke virtual network to handle outbound traffic.

Why it fails: Deploying an NVA in the spoke virtual network would bypass the Azure Firewall because spoke-originated traffic would be routed to the NVA via local routes, not to the centrally managed firewall in the hub. Even if the NVA were configured correctly, it would not integrate with Azure Firewall Manager, and the question explicitly requires using Azure Firewall, so an NVA in the spoke is an incorrect approach.

Set the Azure Firewall to 'Drop' mode for all outbound traffic by default.

Why it fails: Azure Firewall does not have a 'Drop' mode that can be globally enabled for all outbound traffic; instead, you enforce default-deny behavior by omitting allow rules in the policy. Setting a blanket deny-all rule would block all communication, including necessary outbound services, and it would not satisfy the requirement to selectively inspect and allow appropriate outbound traffic, so this is not a valid configuration.

Implement Azure ExpressRoute with Microsoft peering as the primary connectivity.

Why it fails: Azure ExpressRoute with Microsoft peering provides connectivity to Azure public services, such as Microsoft 365 and the internet, not to your virtual network. To connect to a VNet, you must use ExpressRoute private peering, which exposes the VNet's IP space over a private circuit. Using Microsoft peering for hybrid networking would fail because traffic to private VNet IPs is not routed over that peering type.

Use Azure Front Door to load balance traffic between the on-premises network and Azure.

Why it fails: Azure Front Door is a global, Layer-7 load balancer that routes HTTP/HTTPS traffic across multiple regions, but it cannot terminate IPsec tunnels or forward private IP packets. It operates at the application layer and is designed for web sites and APIs, not for connecting an on-premises network to Azure VNets. Using Front Door for hybrid connectivity would not establish a network link and is an invalid choice.

Set up a point-to-site VPN for all on-premises users to access Azure resources.

Why it fails: Point-to-site VPN enables individual client computers to connect from anywhere, but it does not connect an entire on-premises network or support routing of all datacenter workloads into Azure. It also does not provide site-to-site tunnel redundancy and is limited in throughput and concurrent connections for enterprise workloads. Therefore it is not suitable for a secure hybrid network that joins a datacenter to a VNet.