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

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 route table is not associated to the subnet.. A user-defined route (UDR) that points 0.0.0.0/0 to the Azure Firewall's private IP takes precedence over the system route to the internet, even for VMs with public IP addresses. Azure routing uses UDRs ahead of system routes for overlapping prefixes. If traffic is still going directly to the internet, the most likely cause is that the route table is not associated with the subnet. Without association, no custom routes apply, and the VM uses default internet routing.

Answer

The Azure Firewall is not configured with a default route.

Answer

The virtual machines have public IP addresses assigned.

Answer

The VNet peering is not configured properly.

Question 3

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 4

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. 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 5

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. If the service endpoint is enabled and the VNet rule is configured as stated, connections from the subnet should be allowed. The authorization error likely stems from a different misconfiguration (e.g., wrong region, incorrect subnet in the rule), but none of the provided options accurately describe the cause. Option A is inconsistent with the given scenario.

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 6

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. In Azure, a network interface must have IP forwarding enabled for the NIC to receive packets that are not destined to its own IP address. When IP forwarding is disabled on the NVA's NIC, Azure does not deliver the traffic to the NVA; instead, the UDR is ineffective and the packet is routed via the system route for VNet peering, causing the traffic to bypass the NVA and take the direct 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 7

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

Question 8

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

Accepted Answer

IP forwarding is not enabled on the NVA's network interface. The NVA must have IP forwarding enabled on its network interface to forward traffic that is not destined to its own IP address. Without IP forwarding, the NVA will drop packets routed to it via the UDR, causing traffic to fall back to the default peered path. Enabling IP forwarding allows the NVA to act as a router and forward traffic between VNet-A and VNet-B as intended.

Answer

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

Answer

VNet peering does not support user-defined routes

Answer

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

Question 9

A company has two Azure virtual networks (VNet-A and VNet-B) connected via VNet peering. They need to ensure that all traffic between the two VNets is encrypted using IPsec and that no traffic can bypass the encryption. The security team has enabled the 'Use remote virtual network gateways' setting on the peering. However, traffic is still flowing unencrypted. What additional configuration is required to enforce encryption for all traffic between the VNets?

Accepted Answer

Enable 'Azure virtual network encryption' on both VNets and configure the encryption policy.. Azure Virtual Network Encryption provides a platform-level encryption mechanism that encrypts all traffic between virtual networks, including VNet peering traffic, without requiring a VPN gateway. Enabling this feature on both VNets and configuring the encryption policy ensures that all inter-VNet traffic is encrypted using IPsec, and since it is enforced at the infrastructure level, no traffic can bypass the encryption. The 'Use remote virtual network gateways' setting alone does not encrypt traffic; it only allows a VNet to use a remote gateway for transit routing.

Answer

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

Answer

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

Answer

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.

Question 10

A company has an Azure virtual network with a subnet hosting internal web applications. The security team needs to allow inbound HTTPS traffic only from the company's corporate network IP range (203.0.113.0/24). All other inbound traffic must be denied. They want to use a network security group (NSG) associated with the subnet. Which inbound security rule configuration meets this requirement?

Accepted Answer

Two inbound rules: Allow HTTPS from 203.0.113.0/24 with priority 100, and Deny All from Any with priority 110.. NSGs process rules in priority order, and the default implicit deny rule only applies if no explicit rule matches. By placing an explicit 'Deny All from Any' rule with a higher priority number (110) after the explicit 'Allow HTTPS' rule (priority 100), traffic from 203.0.113.0/24 on HTTPS is allowed, and all other inbound traffic is explicitly denied, ensuring no unintended implicit allow or bypass.

Answer

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

Answer

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

Answer

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

Secure networking

AZ-500 Secure networking — Key Topics

Where candidates lose marks on Secure networking