Secure networking practice questions

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

Why wrong: Azure Firewall can be in a different region than the spoke VNet. Regional differences do not affect routing if the firewall is accessible via the hub VNet.

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

Why wrong: Disabling gateway route propagation removes learned routes from the subnet's effective routes. If properly disabled, BGP routes should not be present. This is not the cause.

The route table is not associated with the spoke subnet.

Why wrong: 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 UDR must be applied to the subnet that hosts the Azure Firewall

Why wrong: UDRs are applied to source subnets, not the firewall subnet. The spoke subnet UDR is correctly configured.

The spoke subnet does not have 'GatewaySubnet' route propagation enabled

Why wrong: Route propagation refers to learning BGP routes from a VPN gateway. If it were disabled, the spoke would not learn on-premises routes and would use the 0.0.0.0/0 UDR for all traffic. In this case, the problem is that propagation is enabled and the more specific routes override.

The Azure Firewall is not configured with a route to the on-premises network

Why wrong: The firewall needs a route to the on-premises network to forward traffic, but that does not explain why traffic bypasses the firewall from the spoke.

The route table is not associated to the subnet.

Why wrong: The scenario states the route table has been configured on the subnet, so association is likely correct.

The Azure Firewall is not configured with a default route.

Why wrong: The firewall itself does not need a default route for this scenario; it only inspects traffic sent to it.

The VNet peering is not configured properly.

Why wrong: Peering allows traffic between VNets; the route table pointing to the firewall's private IP should work if peering is set and the firewall is properly configured.

Azure Firewall is not configured with DNAT rules for outbound traffic.

Why wrong: Incorrect. DNAT rules are used to translate destination addresses for inbound traffic, not for routing outbound traffic. Outbound traffic uses the firewall's public IP via SNAT, which doesn't require DNAT rules.

The spoke VNet peering does not allow gateway transit.

Why wrong: Incorrect. Gateway transit is needed when using a VPN gateway in the hub as a transit point, not for Azure Firewall. Forced tunneling to Azure Firewall relies on route tables, not peering settings.

The route table has a higher priority than system routes.

Why wrong: Incorrect. User-defined routes (in route tables) have a higher priority than system routes, so if the route table is associated, they would override the system default route. This statement is true but not a reason for failure.

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

Why wrong: VNet peering allows traffic between VNets; no additional setting is needed to route through an NVA once UDRs and IP forwarding are in place.

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

Why wrong: The question states the route table is associated. If it were not, the traffic would indeed go direct, but the most likely cause given correct association is IP forwarding.

The NVA does not have a public IP address.

Why wrong: The NVA routes traffic using its private IP; a public IP is not required for this scenario.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: Allowing all Azure services provides broader access, not less; it would not cause an authorization error.

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

Why wrong: While possible, OS firewall issues typically produce different error messages (e.g., connection timeout) and are less specific to the service endpoint scenario.

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

Why wrong: An NSG blocking outbound traffic would cause a similar issue, but the most likely cause related to the described configuration is the service endpoint not being properly enabled.

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 wrong: 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 wrong: VNet peering supports user-defined routes. You can apply UDRs to subnets in one VNet to control traffic to the peered VNet.

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

Why wrong: The NVA can be in a different VNet as long as routing is correctly configured. The issue is not about the NVA's location but about forwarding capabilities.

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

Why wrong: If the UDR were not associated, the traffic would follow default routes. The problem states they configured a UDR on the subnet, so association is assumed. This is not the most likely cause.

The VNet peering connection is not in a 'Connected' state.

Why wrong: If the peering were not connected, there would be no traffic at all. The traffic is flowing but not through the NVA, indicating peering is functional.

The NVA is deployed in the same subnet as the source VMs.

Why wrong: The NVA is in a subnet in VNet-A, and the UDR points to it. The location of the NVA relative to the source subnet does not affect the need for IP forwarding.

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

Why wrong: The firewall subnet itself does not need a default route for spoke traffic; it needs the correct routing to send inspected traffic out. This is not the most likely cause of spoke traffic bypassing.

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

Why wrong: 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 wrong: 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 wrong: The question states the UDR is configured on the subnet, so this is not the cause.

VNet peering does not support user-defined routes

Why wrong: VNet peering works with UDRs; system routes can be overridden by UDRs on the subnet.

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

Why wrong: The NVA can be in a different VNet (hub) as long as there is peering and UDRs pointing to it.

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

Why wrong: 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 wrong: NSGs work at layer 3/4 and cannot inspect IPsec encapsulation. This is not feasible.

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 wrong: 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.

The Azure Firewall is in a different region than the spoke VNet.

Why wrong: Azure Firewall can be in a different region as long as VNet peering exists between the hub and spoke. Regional differences do not prevent routing; peering supports cross-region connectivity.

The Azure Firewall does not have the correct network and application rules configured.

Why wrong: Even if rules are missing, traffic would attempt to route through the firewall but be dropped, not bypass it. The question is about traffic bypassing the firewall entirely, which indicates a routing issue, not a rule issue.

The spoke VNet has the 'Use remote virtual network gateways' setting disabled.

Why wrong: This setting is required for gateway transit scenarios (e.g., VPN gateway), not for Azure Firewall. For Azure Firewall, the spoke routes directly to the firewall's private IP via peering; no gateway setting is needed.

4

Why wrong: Four rules would be excessive; a rule to deny all traffic is unnecessary because the default deny already exists.

5

Why wrong: Five rules are not needed; only three allow rules are required.

2

Why wrong: Two rules are insufficient because three separate services (HTTP, HTTPS, RDP) must be allowed from different source addresses.

Configure a Network Security Group (NSG) on the subnet hosting the private endpoint to deny outbound traffic to the public endpoint's IP addresses.

Why wrong: This is incorrect because NSGs cannot block traffic destined to the public endpoint from within the VNet if the client chooses to resolve the public endpoint. Furthermore, NSGs do not control traffic from on-premises.

Enable Azure SQL Auditing and configure a log analytics workspace to monitor for public endpoint calls, then manually block them.

Why wrong: This is a detective measure, not a preventative one. It does not enforce that only private endpoint connections are used; it only alerts after the fact.

Configure a service endpoint for Azure SQL on the VNet and associate a firewall rule allowing only the VNet traffic.

Why wrong: Service endpoints provide secure routing but still allow the server's public endpoint to be used if the private endpoint is not enforced. This does not enforce exclusive use of the private endpoint.

Azure Application Gateway with Web Application Firewall (WAF)

Why wrong: Application Gateway provides WAF and SSL termination, but it is a regional service. It does not provide the global load balancing and performance improvements from the nearest POP that Azure Front Door offers.

Azure Traffic Manager

Why wrong: Traffic Manager is a DNS-based load balancer that does not provide web application firewall capabilities or SSL termination. It only routes traffic at the DNS level.

Azure CDN (Content Delivery Network)

Why wrong: Azure CDN provides caching and performance improvements but does not include a managed web application firewall. While it can be used with WAF on origin, it does not have built-in WAF managed rules.

Deny All priority 100, then Allow HTTPS from App subnet priority 200

Why wrong: Incorrect. The Deny All rule has higher priority (100) and would block all traffic, including HTTPS from App subnet, before the Allow rule is evaluated.

Allow HTTPS from App subnet priority 100, and Deny All from any source priority 100 (duplicate priority)

Why wrong: Incorrect. NSG rules cannot have the same priority. Additionally, this configuration does not guarantee the correct order of evaluation.

Allow HTTPS from App subnet priority 100, no other rules

Why wrong: Incorrect. Without a Deny All rule, the default implicit allow rule will permit all other inbound traffic to the Data subnet.

The route table is not associated with the subnet

Why wrong: The question states the route table is created and associated, so this is unlikely unless misstated.

The hub-spoke peering is not configured correctly

Why wrong: VNet peering is required for connectivity, but if peering is misconfigured, traffic would not flow at all, not bypass the firewall.

Azure Firewall is in a different resource group

Why wrong: Resource group location does not affect routing; firewalls can be in any resource group.

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 wrong: 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 wrong: 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 wrong: This would block all inbound traffic, including HTTPS from the corporate network, which is not allowed. ASGs do not change the need for allow rules.

Network security group (NSG) with multiple IP address ranges.

Why wrong: Using IP ranges in NSG rules requires manual updates when VMs are added or removed. It does not provide the logical grouping and automatic membership that ASGs offer.

Azure Resource Manager tags.

Why wrong: Tags are metadata and do not influence network security. NSG rules cannot directly reference tags; tags are used for cost management and organization, not for networking.

Virtual Network peering.

Why wrong: VNet peering connects separate virtual networks but does not help group VMs within a subnet or apply security rules based on application tier.