VPC practice questions

Use an Azure Load Balancer and configure NSGs on each subnet.

Why wrong: Azure Load Balancer operates at Layer 4 (TCP/UDP) and only distributes traffic based on IP address and port rules. It cannot provide SSL termination, web application firewall (WAF) capabilities, or path-based routing, all of which are essential for protecting and properly routing HTTP(S) requests in a multi-tier web application. Configuring NSGs on each subnet adds basic network-level filtering, but NSGs alone cannot inspect or sanitize application-layer traffic, leaving the web tier vulnerable to SQL injection, XSS, and other OWASP threats. Therefore, this option is incorrect because it lacks the required Layer 7 features.

Use Azure Firewall to inspect all traffic and allow internet traffic to the web tier.

Why wrong: Azure Firewall is a stateful firewall that operates at layers 3-4 with some layer 7 capabilities, but it is not optimized for inbound web traffic with SSL offloading and URL routing like a WAF-enabled service.

Use Azure Front Door to expose the web tier and NSGs for internal isolation.

Why wrong: Azure Front Door is incorrect because it is a global service designed for distributing traffic across multiple regions or public endpoints, whereas this scenario describes a multi-tier application primarily within a single virtual network. While Front Door offers SSL termination, WAF, and URL-based routing, its global scope is not the primary requirement for exposing a web tier residing regionally within a VNet. It would be appropriate for a globally distributed application requiring cross-region traffic management and acceleration.

Set route tables on spoke subnets with a 0.0.0.0/0 route to the Internet

Why wrong: Setting a 0.0.0.0/0 user-defined route on spoke subnets with next hop Internet only affects default outbound traffic, sending it directly to the internet. It does nothing to route spoke-to-spoke traffic through the hub NVA, because inter-spoke traffic targets the peer address space, not the default route. Such a route would actually bypass the hub for any outbound internet traffic and still fail to inspect east-west traffic. Thus this configuration does not enforce centralized inspection for inter-spoke communications.

Configure Azure Firewall in the hub with forced tunneling to on-premises

Why wrong: Forced tunneling with Azure Firewall sends internet-bound traffic to on-premises via a VPN/ExpressRoute connection, typically by adding a default route to the hub's gateway. It does not influence routing between spoke virtual networks, which requires explicit routes to the hub NVA for the destination spoke prefix. Azure Firewall can inspect inter-spoke traffic only when UDRs are applied to spokes with the Firewall's private IP as next hop; forced tunneling alone doesn't set that up. This option confuses internet egress control with east-west traffic inspection.

Use VNet peering with gateway transit enabled

Why wrong: Enabling gateway transit on the hub peering only allows spoke virtual networks to use the hub's VPN/ExpressRoute gateway for connectivity to on-premises networks. It does not create any routes that send spoke-to-spoke traffic through the hub NVA, nor does it make peering transitive. Without UDRs on the spokes, traffic from one spoke to another is dropped at the hub because the spoke has no route to its peer's address space. Gateway transit is a distinct feature for remote gateway access, not a routing mechanism for east-west inspection.

Azure Virtual Network with a single subnet and application security groups.

Why wrong: A single subnet offers no Layer-3 separation between tiers; all virtual machines remain in the same broadcast domain and share the same route table and subnet-level policies. Application Security Groups (ASGs) only group VM NICs by workload attributes (for example, 'Web' or 'App') and require explicit NSG rules referencing those ASGs to filter traffic between them, which is essentially logical tag-based control rather than a physical or network boundary. Additionally, ASGs cannot replace subnet segregation for capabilities like service endpoints, route tables, or VNet peering filters, and misconfigurations can leave unexpected traffic flows. This makes the solution less secure and harder to manage at scale, which is why it is incorrect for a three-tier architecture.

Azure Virtual Network with subnets and Azure Firewall.

Why wrong: Azure Virtual Network with subnets provides logical segmentation, but Azure Firewall primarily offers centralised network security policy enforcement and traffic filtering for perimeter security or across virtual network boundaries. While it can filter inter-subnet traffic with User Defined Routes, it is not the most direct mechanism for granular network isolation *between tiers* within a single virtual network. This is typically achieved more precisely using Network Security Groups (NSGs) on each subnet to control ingress and egress traffic flows. Azure Firewall is highly effective for securing internet access and managing outbound traffic from the application.

Azure Virtual Network with subnets and a network virtual appliance (NVA).

Why wrong: While subnets provide basic isolation, an NVA requires complex routing and manual management to enforce granular traffic filtering between tiers. This approach is typically utilised when organisations require third-party security features or deep packet inspection that native Azure Network Security Groups do not offer. In this scenario, the requirement for tier isolation and internet access control is satisfied by using subnets combined with Network Security Groups (NSGs) rather than external appliances.

Use VNet peering with user-defined routes (UDRs) in each spoke and Azure Route Server.

Why wrong: VNet peering is non-transitive, so a hub-and-spoke design with peerings alone cannot route between spokes or from a spoke to on-premises. UDRs must be manually added to every spoke subnet to force traffic to an NVA, and Azure Route Server only advertises routes learned from its BGP peer (the NVA) to the hub — it does not automatically propagate connectivity to all spokes. As the number of spokes and regions grows, maintaining these UDRs and BGP peering for each NVA becomes a significant administrative burden and is prone to route misconfiguration.

Create a single large VNet and use network security groups (NSGs) to isolate traffic.

Why wrong: A single Azure VNet is scoped to one region and cannot span multiple regions, so it cannot directly interconnect spoke networks in different regions as the scenario requires. While NSGs can filter East-West traffic within a VNet, they do not route traffic, integrate with NVAs, or provide connectivity to on-premises sites; you would still need additional VPN/ExpressRoute tunnels and peering to extend outside the VNet. This approach also hits subscription and address space limits and is a poor architectural pattern for regional isolation, redundancy, or management separation.

Use Azure Firewall in the hub VNet and configure forced tunneling via custom routes.

Why wrong: Placing Azure Firewall in a conventional hub VNet only works if you manually create UDRs on every spoke subnet to send traffic to the firewall's private IP, and forced tunneling specifically influences internet-bound traffic, not transitive spoke-to-spoke or branch-to-spoke routing. The hub VNet still relies on non-transitive VNet peering and separate VPN/ExpressRoute gateways, so you must continually manage custom routes and ensure the firewall receives traffic from all regions and on-prem sites. Azure Firewall does not automatically exchange routing information between spokes or branches, and this configuration lacks the simplified routing tables and dynamic propagation that a secured Virtual WAN hub provides.

Deploy network virtual appliances (NVAs) in each spoke VNet and configure user-defined routes (UDRs) to route internet traffic to the NVAs

Why wrong: Placing NVAs in each spoke replicates the security stack per workload rather than centralizing it. Each spoke then needs its own HA pair or scale set, its own user-defined route table pointing 0.0.0.0/0 to the NVA's internal IP, and the operational burden of patching, licensing, and failover for every appliance. This also scatters outbound public IPs across spokes, defeating the requirement for a single, centrally controlled egress and inspection point.

Use Azure Application Gateway with Web Application Firewall (WAF) in the hub VNet to inspect all traffic

Why wrong: Application Gateway with WAF is a layer-7 reverse proxy designed for inbound HTTP/S traffic directed to backend pools, not a general-purpose firewall for outbound connections from VMs. It cannot intercept arbitrary protocols, raw TCP/UDP, or non-web egress, and its WAF rule set evaluates inbound request payloads rather than outbound traffic. Therefore, placing it in the hub does nothing to force or filter spoke internet egress; it would only front-end specific applications.

Deploy Azure Firewall in each spoke VNet and use Azure Monitor to aggregate logs

Why wrong: Deploying Azure Firewall separately in every spoke distributes the security boundary and creates per-spoke egress, eliminating the centralized hub inspection point and the single public outbound IP the requirement asks for. Azure Monitor can aggregate logs, but logging aggregation is not an enforcement mechanism and does not create a common routing path or consistent firewall policy. Management, upgrade, cost, and rule synchronization overhead are multiplied across every spoke.