VPC practice questions

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

The storage account requires HTTPS and the VM is using HTTP

Why it fails: Although the storage account has `supportsHttpsTrafficOnly` set to true and the VM would need to use HTTPS, an HTTP request would be rejected with an HTTP 400-level protocol error, not a network-layer connectivity/timeout failure. More importantly, even if the VM switched to HTTPS, it would still fail because the missing service endpoint on the subnet would prevent the storage account's virtual network rule from matching the traffic. Therefore, the protocol mismatch is not the root cause of the problem.

The storage account does not have a firewall rule for the VM's public IP

Why it fails: The storage account's network rule is configured to allow the virtual network or subnet, not a public IP address. If the subnet had a service endpoint enabled, Azure would rewrite the source IP to the VM's private IP, making the public IP rule unnecessary. The absence of a public IP firewall rule is irrelevant because the VM's traffic should be coming from the virtual network, not the public internet. Adding a public IP rule would expose the storage account to the internet and still would not fix the missing service endpoint.

The storage account uses GRS replication which is not supported with network rules

Why it fails: Geo-redundant storage (GRS) replicates data asynchronously to a paired region, and replication happens entirely within Azure's infrastructure. Network rules such as service endpoints and virtual network firewall rules are evaluated only on client requests to the storage account's public endpoint; the internal replication traffic is not subject to these rules. Changing the replication type would not affect the subnet's lack of a service endpoint, so GRS is not the reason for the denial.

Place all VMs in the same subnet and use a single Azure Load Balancer to distribute traffic.

Why it fails: This design eliminates any network segmentation between application and database tiers, so an attacker who compromises the web tier can directly reach backend databases on open ports, and a single public-facing load balancer exposes all VMs to the internet, including the data tier. An Azure Load Balancer (L4) only performs TCP/UDP distribution; it cannot provide layer-7 filtering, URL routing, or web application firewall protection, and it gives no mechanism to restrict traffic between tiers within the same subnet.

Use separate VNets for each tier and connect them with VNet peering.

Why it fails: Creating a separate VNet for each tier and interconnecting them with VNet peering introduces unnecessary overhead: peering is non-transitive, so you must manage multiple peering connections and complex network security groups across VNets, and you cannot leverage a single Azure Application Gateway in front of all tiers without additional hub infrastructure. Subnets inside one VNet already provide isolation with full control via NSGs and allow an application gateway to sit in the same VNet, giving the same security benefit at far lower complexity and cost.

Deploy all VMs in a single subnet and use Azure Firewall to inspect all inbound and outbound traffic.

Why it fails: Placing every VM in a single subnet collapses compartmentalization and forces Azure Firewall to act as a central inspection point for all traffic if you add complex user-defined routes; however, Azure Firewall is a managed stateful network firewall, not a substitute for subnet isolation, so you lose the ability to apply different NSG policies per tier and you incur significant cost for features that could be handled by simpler subnet-level NSGs. Furthermore, Azure Firewall does not provide web application firewall capabilities, so you still need an Application Gateway or other WAF device, making this design both expensive and architecturally flawed.

It allows subnet-b to use a different address space

Why it fails: Subnet address prefixes are governed by the subnet's own 'addressPrefix' (or 'addressPrefixes') property, which must fall within the parent virtual network's address space. A delegation entry only declares that the named Azure service is permitted to manage resources inside that subnet; it does not modify or expand the subnet's IP range. Selecting this option confuses IP allocation with the delegation's role.

It configures a firewall policy for subnet-b

Why it fails: Delegation simply hands operational control of the subnet to the service named in the 'serviceName' property, for example 'Microsoft.Web/serverFarms'. Azure Firewall policies are deployed as separate 'Microsoft.Network/firewallPolicies' resources and are attached to Azure Firewall instances or rule collection groups, not through subnet delegation. No firewall configuration is created or changed when a subnet is delegated, so this is an incorrect interpretation of the JSON.

It creates a peering connection to another virtual network

Why it fails: Virtual network peering requires an explicit 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings' resource that links two VNets by resource ID and configurations such as 'allowVirtualNetworkAccess'. A subnet delegation property is an array inside the subnet resource; it has no VNet-to-VNet connectivity semantics and cannot establish peering. Thus delegating subnet-b to a service has no effect on peering.

A public IP address on every private endpoint.

Why it fails: Assigning a public IP address to a private endpoint defeats the foundational purpose of Azure Private Link, because private endpoints are designed to expose a service with a NIC using only a private IP from a virtual network. A public IP on a private endpoint would bypass the private connectivity model, introduce an internet-facing attack surface, and still does nothing to route outbound traffic through a central firewall or NVA. Moreover, Azure does not support attaching a public IP to a private endpoint; the service is explicitly meant to be accessed over the private network path.

Basic SKU load balancers in each spoke.

Why it fails: Basic SKU load balancers in each spoke are unrelated to centralized outbound inspection and would not help route traffic to a central firewall; they are primarily for distributing inbound traffic to VMs within a single region or fault domain. Additionally, Basic load balancers lack critical features such as availability zones, HA ports, and scaling, making them unsuitable as a control point in a hub-and-spoke architecture. Centralizing outbound egress requires route table manipulation and inspection appliances, not per-spoke load balancers, so using them would add complexity without solving DNS resolution or outbound control.

Use Azure Front Door, service endpoints, and Azure SQL Database with firewall rules.

Why it fails: Azure Front Door is a global Layer 7 CDN/load balancer, not a regional gateway designed for a single three-tier application; it adds unnecessary latency and cost unless you need multi-region web acceleration. Service endpoints for Azure SQL Database still rely on the database's public endpoint and only restrict source IPs to the VNet, leaving the service vulnerable to data exfiltration if a compromised resource inside the VNet is able to reach it. Firewall rules on the SQL logical server complement service endpoints but do not replace Private Endpoints, which attach a private NIC to the VNet and remove public exposure entirely. Therefore, this architecture fails to meet the security and segmentation requirements of a private three-tier application.

Use Azure Load Balancer, Azure Firewall, and Azure SQL Database with public endpoint.

Why it fails: Azure Load Balancer operates at Layer 4 only, providing NAT and distribution rules over TCP/UDP without any awareness of HTTP paths or application-level inspection; it cannot protect against SQL injection or other web application attacks the way WAF does. Azure Firewall is a stateful network firewall that can enforce east-west and north-south rules, but it does not replace NSGs for fine-grained subnet-level filtering, and without a WAF the web tier remains exposed to application-layer threats. Exposing the Azure SQL Database via a public endpoint is a fundamental security anti-pattern because it makes the database reachable from the internet, forcing reliance on firewall IP rules that are static and often misconfigured. Consequently, this design lacks both required L7 protection for the web front end and private, secure connectivity to the data tier.

Use a single virtual network with three subnets, no NSGs, and Azure SQL Database with VNet injection.

Why it fails: Creating a single virtual network with three subnets and no NSGs removes all traffic filtering between tiers, allowing any resource in the web tier to freely communicate with the data tier, which violates the security principle of least privilege and greatly increases the blast radius of a compromised VM. VNet injection is supported for Azure SQL Managed Instance, but not for standard Azure SQL Database elastic pools or single databases; standard SQL Database uses logical server connectivity and cannot be directly injected into a subnet, so this premise is technically invalid. If you attempt to use this pattern without NSGs or a network virtual appliance, there is no mechanism to enforce security rules, and the database may inadvertently be exposed via service endpoints or firewall misconfigurations. Thus, the design lacks both the required traffic control and the correct PaaS connectivity model, making it unsuitable for a production three-tier environment.

Azure Load Balancer for front-end, NSGs on subnets, and VNet peering

Why it fails: A public Azure Load Balancer operates only at Layer 4 (TCP/UDP), distributing raw traffic without any TLS inspection, path-based routing, or web application firewall (WAF) capabilities; it cannot protect the front-end from application-layer attacks such as SQL injection or cross-site scripting. NSGs can segment subnets, but VNet peering is designed to connect virtual networks, not to secure or expose a public-facing web tier. Thus, this combination lacks the HTTP/HTTPS-aware protection required for a three-tier web application.

VPN Gateway for front-end, NSGs on subnets, and private endpoints

Why it fails: Azure VPN Gateway is built for encrypted site-to-site or point-to-site IPSec tunnels between on-premises networks and Azure; it is not a reverse proxy, load balancer, or public internet-facing entry point for web traffic. Private endpoints are used to consume Azure PaaS services privately from a VNet, not to expose an application's front-end to external users, and they provide no HTTP routing or WAF functionality. Forcing internet customers to establish a VPN tunnel is impractical and contradicts the goal of a publicly accessible three-tier web app.

Azure Firewall for all inbound traffic, NSGs on subnets, and VNet peering

Why it fails: Azure Firewall is a stateful network and application (FQDN) firewall that provides central rule enforcement and threat intelligence, but it lacks the web-specific capabilities required for a front-end tier—such as TLS termination, HTTP path routing, session stickiness, and managed WAF rulesets to block SQL injection and XSS. Routing all inbound web traffic through a single Azure Firewall creates a performance bottleneck and makes costs unjustifiably high for a load-balanced public web workload. While NSGs on subnets add useful segmentation, adding VNet peering does not solve the lack of Layer-7 web protection, so this design is mismatched for the application's requirements.

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

Why it fails: 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 it fails: 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 it fails: 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.

The peering command fails because the remote VNet does not exist.

Why it fails: The remote VNet is created earlier in the same Azure CLI script, so it exists in the same resource group before the peering command runs. The `az network vnet peering create` command would only fail with a 'ResourceNotFound' error if the remote VNet's name or resource group were invalid, but here the peering is established successfully.

A VNet with one subnet is created, and no peering is established.

Why it fails: The script executes two separate `az network vnet subnet create` commands, so both subnets are created. Because no command fails, the subsequent `az network vnet peering create` command runs and completes, establishing connectivity between the local and remote VNets.

Only the first subnet is created, and the peering is established.

Why it fails: The second `az network vnet subnet create` command does not fail; it successfully creates the subnet in the same VNet. The peering is then established after both subnets exist, so the final state includes both subnets, not just the first one.

Enable public IP addresses on all workload VMs

Why it fails: Assigning a public IP to every workload VM would directly expose those instances to inbound internet traffic, sharply increasing the attack surface and undermining the hub firewall's role as the centralized chokepoint. Workload VMs inside a hub-spoke design should remain private, using only private IPs, with inbound traffic mediated by the firewall or an application gateway if needed. A public IP does not support forced tunneling or enhance the outbound-inspection model, so it is neither necessary nor consistent with the architecture.

Deploy a NAT gateway in every spoke subnet

Why it fails: Placing an Azure NAT gateway in every spoke subnet would provide a dedicated outbound public IP and would send spoke outbound traffic directly to the internet, completely bypassing the hub firewall and defeating the forced-tunneling requirement. NAT gateways are not transitive and only alter outbound flow for the subnet to which they are attached, so they cannot be intercepted by the central NVA. This design also adds unnecessary per-subnet cost and fragments egress management across every spoke instead of concentrating it at the hub.

Deploy a VPN gateway in each spoke and configure site-to-site VPNs.

Why it fails: Deploying a VPN gateway in each spoke and configuring site-to-site VPNs is incorrect because it introduces unnecessary cost and complexity, and VPN gateways do not automatically redirect spoke-to-spoke traffic through a hub NVA. For traffic between peered VNets to traverse a central NVA, you need to override the direct peering route with a user-defined route (UDR), not an encrypted tunnel. Even with VPN gateways, you would still have to define UDRs to force traffic through the gateways, and the NVA in the hub would not be in the path unless explicitly routed. Thus, this approach fails to meet the requirement while adding significant overhead.

Configure NSG rules to block direct spoke-to-spoke traffic.

Why it fails: Configuring NSG rules to block direct spoke-to-spoke traffic is wrong because NSGs are stateful packet filters, not routing devices. An NSG can only allow or deny traffic based on source/destination IP and port, but it cannot change the next hop or force traffic to traverse an NVA. Blocking direct traffic would simply drop packets, which is not the same as routing them through the hub NVA. The correct solution must modify the routing table, not add filtering rules, because the issue is about path selection, not access control.

Enable BGP on the VNet peerings.

Why it fails: Enabling BGP on VNet peerings is incorrect because BGP is a dynamic routing protocol used with VPN gateways and ExpressRoute, not with VNet peering. VNet peering automatically exchanges routes between peered networks without any BGP configuration; there is no BGP setting to enable on a peering connection. Even if BGP were somehow enabled, it does not provide a mechanism to redirect traffic through an NVA—it only exchanges routing information. Therefore, this option has no effect on forcing spoke-to-spoke traffic through the hub NVA and is technically invalid in the Azure VNet peering context.