AZ-500 Secure networking — Timed 15 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

Question 11

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 12

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.. Option A is correct because 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 13

A company is designing a hub-spoke network topology with Azure Firewall in the hub virtual network. Spoke virtual networks are peered to the hub. They want 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's private IP address as the next hop. However, traffic is still bypassing the firewall. What is the most likely cause?

Accepted Answer

The route table is not associated to the spoke subnet.. The most likely cause is that the route table with the default route (0.0.0.0/0) pointing to the Azure Firewall's private IP has not been associated to the spoke subnet. Without this association, the route table is not applied to the subnet's traffic, so the default system route (which directs internet traffic directly to the internet) remains in effect, bypassing the firewall. Associating the route table to the subnet is a required step for user-defined routes (UDRs) to influence traffic flow.

Answer

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

Answer

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

Answer

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

Question 14

A company has an Azure virtual network with a subnet that hosts a web application. They need to allow inbound HTTP (port 80) and HTTPS (port 443) traffic from a specific source IP range (203.0.113.0/24) to the web servers. Additionally, they need to allow inbound RDP (port 3389) traffic from a management subnet (10.0.1.0/24). They want to block all other inbound traffic. They are using a network security group (NSG) associated with the subnet. What is the minimum number of inbound security rules required?

Accepted Answer

3. The correct answer is A (3 rules) because an NSG includes default rules that already block all inbound traffic by default. You only need explicit allow rules for the three permitted traffic types: HTTP (port 80) from 203.0.113.0/24, HTTPS (port 443) from 203.0.113.0/24, and RDP (port 3389) from 10.0.1.0/24. The default deny rule handles blocking all other traffic, so no additional deny rule is required.

Answer

4

Answer

5

Answer

2

Question 15

A company has an Azure SQL Database with a private endpoint connection. The database is accessed from on-premises via ExpressRoute and from other Azure virtual networks (VNets) via VNet peering. The security team wants to ensure that all queries from both on-premises and peered VNets go through the private endpoint and NEVER use the public endpoint, even as a fallback. Which additional configuration is required to enforce this?

Accepted Answer

Disable public network access on the Azure SQL server.. Option C is correct because disabling public network access on the Azure SQL server explicitly blocks all traffic that does not originate from a private endpoint. This setting ensures that even if a client attempts to connect using the public endpoint (e.g., via a misconfigured connection string or DNS resolution fallback), the server will reject the connection. This is the only configuration that enforces the requirement that all queries—from on-premises via ExpressRoute or from peered VNets—must go through the private endpoint and never use the public endpoint.

Answer

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

Answer

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

Answer

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