AZ-500 Secure networking Practice Questions

Question 1

A company has a hub-spoke network topology. The hub virtual network contains an Azure Firewall and an ExpressRoute gateway for on-premises connectivity. The spoke virtual network hosts a critical application. They need to ensure that all outbound traffic from the spoke to the internet and to on-premises networks is routed through the Azure Firewall. They configure a user-defined route (UDR) on the spoke subnet with address prefix 0.0.0.0/0 and next hop as the Azure Firewall's private IP. They also disable 'Virtual network gateway route propagation' on the spoke subnet. However, traffic to on-premises still bypasses the firewall and goes through the ExpressRoute gateway. What is the most likely cause?

Accepted Answer

The spoke subnet does not have a route for the on-premises prefix pointing to the firewall.. The user-defined route (UDR) with 0.0.0.0/0 only covers traffic destined for the internet. Traffic to on-premises networks has a more specific destination prefix (e.g., 10.0.0.0/8). Without an explicit route for that on-premises prefix pointing to the Azure Firewall, the system uses the more specific route learned via ExpressRoute BGP, which directs traffic to the ExpressRoute gateway instead of the firewall. Disabling 'Virtual network gateway route propagation' prevents BGP routes from being added to the route table, but it does not remove existing learned routes; however, the core issue is the lack of a specific UDR for the on-premises prefix.

Answer

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

Answer

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

Answer

The route table is not associated with the spoke subnet.

Question 2

Your company has an Azure subscription with a hub-spoke network topology. The hub contains an Azure Firewall and a VPN gateway for on-premises connectivity. The spoke virtual network hosts a critical application. You need to ensure that all outbound traffic from the spoke to the internet and on-premises networks flows through the Azure Firewall. You configure a user-defined route (UDR) on the spoke subnet with the default route (0.0.0.0/0) pointing to the Azure Firewall private IP. However, traffic to on-premises still bypasses the firewall. What is the most likely cause?

Accepted Answer

The on-premises traffic uses a more specific route learned via BGP from the VPN gateway, which overrides the UDR. The most likely cause is that the on-premises traffic uses a more specific route learned via BGP from the VPN gateway, which overrides the user-defined route (UDR). In Azure, when a UDR and a BGP-propagated route both match traffic, the route with the most specific prefix (longest prefix match) wins. Since on-premises networks are typically advertised with specific IP prefixes (e.g., 10.0.0.0/16) rather than 0.0.0.0/0, the BGP-learned routes take precedence, causing traffic to bypass the Azure Firewall.

Answer

The UDR must be applied to the subnet that hosts the Azure Firewall

Answer

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

Answer

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

Question 3

A company has an Azure virtual network that uses Azure Firewall as the central traffic inspection point. They have a spoke VNet peered to the hub VNet. The spoke VNet contains a subnet with virtual machines. The security team wants to ensure that all outbound traffic from those virtual machines to the internet goes through the Azure Firewall. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) to the Azure Firewall's private IP. However, traffic from the VMs is still going directly to the internet. What is the most likely cause?

Accepted Answer

The virtual machines have public IP addresses assigned.. When a virtual machine in Azure has a public IP address assigned, Azure's default routing logic gives it a 'default outbound access' path that bypasses any user-defined route (UDR) pointing to the Azure Firewall. This is because Azure prefers the host's public IP route over a UDR for internet-bound traffic, unless the VM is explicitly configured to use a NAT gateway or Azure Firewall as the next hop. Therefore, even with the route table correctly associated, the VM will send traffic directly to the internet via its public IP.

Answer

The route table is not associated to the subnet.

Answer

The Azure Firewall is not configured with a default route.

Answer

The VNet peering is not configured properly.

Question 4

A company has a hub-spoke network topology with Azure Firewall deployed in the hub virtual network. Spoke virtual networks are peered to the hub. The security team needs to ensure that all outbound internet traffic from virtual machines in a spoke subnet goes through the Azure Firewall. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall private IP address. However, traffic from spoke VMs is still bypassing the firewall and going directly to the internet. What is the most likely reason?

Accepted Answer

The route table is not associated with the spoke subnet.. The most likely reason is that the route table containing the default route (0.0.0.0/0) pointing to the Azure Firewall private IP has not been associated with the spoke subnet. Without this association, the subnet continues to use system routes, which include a default route to the internet via the Azure default gateway, allowing traffic to bypass the firewall. Associating the route table with the subnet is a required step to override the system default route.

Answer

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

Answer

The spoke VNet peering does not allow gateway transit.

Answer

The route table has a higher priority than system routes.

Question 5

A company has two Azure virtual networks: VNet-A and VNet-B. They peer the VNets and deploy a network virtual appliance (NVA) in VNet-A. They want to inspect all outbound traffic from VNet-B to the internet using the NVA. They configure a user-defined route (UDR) in a route table associated with the subnet in VNet-B, with a default route (0.0.0.0/0) and next hop set to the private IP of the NVA in VNet-A. However, outbound traffic from VNet-B still goes directly to the internet. What is the most likely cause?

Accepted Answer

The NVA's network interface must have 'IP forwarding' enabled.. The most likely cause is that IP forwarding is disabled on the NVA's network interface. Even with a correct user-defined route (UDR) pointing 0.0.0.0/0 traffic to the NVA's private IP, Azure will drop packets destined to the NVA unless the NIC is configured to accept and forward traffic not addressed to itself. Enabling IP forwarding allows the NVA to act as a router, processing and forwarding packets between VNets.

Answer

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

Answer

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

Answer

The NVA does not have a public IP address.

Question 6

A company has two Azure virtual networks, VNet-A (hub) and VNet-B (spoke), connected via VNet peering. They deploy a network virtual appliance (NVA) in a subnet in VNet-A to inspect all traffic between the VNets. They configure a user-defined route (UDR) on the subnet in VNet-B with the destination address space of VNet-A (10.0.0.0/16) and the next hop set to the private IP of the NVA. However, traffic from VNet-B to VNet-A still bypasses the NVA and takes a direct path. What is the most likely cause?

Accepted Answer

The NVA network interface does not have IP forwarding enabled. Option D is correct because a network virtual appliance (NVA) requires IP forwarding to be enabled on its network interface to forward traffic not destined for itself. Without this setting, the NVA drops packets that arrive with a destination IP other than its own, causing the traffic to bypass the NVA and follow the default VNet peering route. Enabling IP forwarding allows the NVA to act as a router and forward traffic between VNets as specified by the user-defined route.

Answer

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

Answer

VNet peering system routes override user-defined routes

Answer

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

Question 7

A company has an Azure virtual network with a subnet that hosts Azure virtual machines. They want to restrict access to an Azure SQL Database so that only traffic originating from that specific subnet is allowed. They have enabled a service endpoint for Microsoft.Sql on the subnet and configured the SQL server firewall to allow only that subnet's virtual network rule. However, connections from the VMs to the SQL database are failing with an authorization error. What is the most likely cause?

Accepted Answer

The service endpoint for Microsoft.Sql was not enabled on the subnet before creating the firewall rule. The most likely cause is that the service endpoint for Microsoft.Sql was not enabled on the subnet before the virtual network (VNet) firewall rule was created on the SQL server. When a VNet rule is added to the SQL server firewall, Azure validates that the specified subnet has a service endpoint for Microsoft.Sql enabled. If the endpoint is not enabled at the time the rule is created, the rule will be created but will not be effective, and traffic from the subnet will not be recognized as originating from the VNet, resulting in authorization errors. The service endpoint must be enabled first to ensure the subnet's traffic is routed through the Azure backbone and correctly identified by the SQL server firewall.

Answer

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

Answer

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

Answer

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

Question 8

A company has two Azure virtual networks, VNet-A (hub) and VNet-B (spoke), connected via VNet peering. They deployed a network virtual appliance (NVA) in a subnet in VNet-A to inspect all traffic. They configured a user-defined route (UDR) on the subnet in VNet-B that points the VNet-A address space (10.0.0.0/16) to the private IP of the NVA. However, traffic initiated from VNet-B to VNet-A still takes a direct path and bypasses the NVA. What is the most likely cause?

Accepted Answer

The NVA does not have IP forwarding enabled on its network interface. The most likely cause is that the NVA's network interface does not have IP forwarding enabled. In Azure, a network interface must have the 'Enable IP forwarding' setting enabled to allow the NVA to receive traffic not destined to its own IP address and forward it to the intended destination. Without this setting, the NVA drops any traffic that is not addressed to its own IP, so even though the UDR on VNet-B directs traffic to the NVA's private IP, the NVA cannot forward it to VNet-A, and the traffic instead takes the direct VNet peering path.

Answer

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

Answer

VNet peering does not support user-defined routes

Answer

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

Question 9

A company has two Azure virtual networks, VNet-A and VNet-B, connected via VNet peering. They want all traffic between the VNets to be inspected by a network virtual appliance (NVA) deployed in a subnet in VNet-A. They have configured a user-defined route (UDR) on the subnet in VNet-B that points the destination address space of VNet-A to the private IP of the NVA. However, traffic between the VNets is still not passing through the NVA. What is the most likely cause?

Accepted Answer

The NVA's network interface (NIC) does not have IP forwarding enabled.. The most likely cause is that the NVA's network interface (NIC) does not have IP forwarding enabled. Even with a correctly configured UDR on VNet-B pointing traffic to the NVA's private IP, the NVA will drop any traffic not destined for its own IP unless IP forwarding is enabled on its NIC. This setting allows the NVA to accept packets with a destination other than itself and forward them based on its routing table, which is essential for traffic inspection scenarios.

Answer

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

Answer

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

Answer

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

Question 10

A company has an Azure virtual network (VNet) with multiple subnets. They deploy Azure Firewall in a hub VNet and peer spoke VNets. They want to force-tunnel all outbound traffic from a specific spoke subnet to the firewall for inspection. They have configured a route table on the spoke subnet with a default route (0.0.0.0/0) pointing to the Azure Firewall's private IP as the next hop. However, traffic is still bypassing the firewall. What is the most likely cause?

Accepted Answer

The route table on the spoke subnet has 'Propagate gateway routes' enabled, causing a conflicting route from the hub's VPN gateway. Option B is correct because when 'Propagate gateway routes' is enabled on the spoke subnet's route table, the VNet peering with the hub (which may have a VPN or ExpressRoute gateway) injects a system route for 0.0.0.0/0 with a next hop of the virtual gateway. This system route has a lower (better) route preference than the user-defined route (UDR) pointing to the Azure Firewall, causing traffic to bypass the firewall and go directly to the gateway.

Answer

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

Answer

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

Answer

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

Secure networking

AZ-500 Secure networking — Key Topics

Where candidates lose marks on Secure networking