AZ-500 Secure networking — 20 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.

Question 16

A company runs a global web application on Azure App Service instances deployed in multiple Azure regions. They want to protect the application from common web attacks such as SQL injection and cross-site scripting (XSS) using a centralized set of managed rules that can be automatically updated. They also need to improve performance by terminating traffic at the nearest point of presence (POP) to end users. Which Azure service should they deploy in front of the App Service?

Accepted Answer

Azure Front Door with Web Application Firewall (WAF). Azure Front Door with WAF is correct because it provides global, centralized protection against common web attacks (SQL injection, XSS) using managed rule sets that are automatically updated, and it terminates traffic at the nearest point of presence (POP) to end users, improving performance through global load balancing and TLS termination. This meets both the security and performance requirements for a multi-region App Service deployment.

Answer

Azure Application Gateway with Web Application Firewall (WAF)

Answer

Azure Traffic Manager

Answer

Azure CDN (Content Delivery Network)

Question 17

A company has an Azure virtual network with two subnets: App and Data. The App subnet hosts web servers, and the Data subnet hosts SQL databases. Security policy requires that only HTTPS traffic from the App subnet is allowed to the Data subnet, and all other inbound traffic to the Data subnet must be blocked. The solution must use a single network security group (NSG) associated to the Data subnet. Which NSG inbound rule configuration meets the requirement?

Accepted Answer

Allow HTTPS from App subnet priority 100, then Deny All priority 200. Option A is correct because NSG rules are evaluated in priority order, with lower numbers processed first. By placing the Allow HTTPS rule at priority 100, it matches and permits traffic from the App subnet to the Data subnet. The subsequent Deny All rule at priority 200 then blocks all other inbound traffic, satisfying the security policy with a single NSG on the Data subnet.

Answer

Deny All priority 100, then Allow HTTPS from App subnet priority 200

Answer

Allow HTTPS from App subnet priority 100, and Deny All from any source priority 100 (duplicate priority)

Answer

Allow HTTPS from App subnet priority 100, no other rules

Question 18

A company deploys Azure Firewall in a hub VNet to inspect all outbound traffic from a spoke VNet. They enable VNet peering between the hub and spoke. They create a route table with a default route (0.0.0.0/0) pointing to the firewall's private IP as the next hop, and associate it with the spoke subnets. However, outbound traffic from the spoke subnets is still going directly to the internet, bypassing the firewall. What is the most likely cause?

Accepted Answer

The route table's next hop type is not set to 'Virtual appliance'. The most likely cause is that the route table's next hop type is not set to 'Virtual appliance'. When creating a custom route in Azure, the next hop type must be explicitly set to 'Virtual appliance' and the next hop address must be the firewall's private IP. If the next hop type is left as 'Internet' or another value, Azure will ignore the custom route and use the default system route for 0.0.0.0/0, which sends traffic directly to the internet without inspection.

Answer

The route table is not associated with the subnet

Answer

The hub-spoke peering is not configured correctly

Answer

Azure Firewall is in a different resource group

Question 19

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

Question 20

A company deploys multiple Azure virtual machines across several subnets in a virtual network. The VMs are grouped by application tiers: web, application, and database. The security team wants to apply network security group (NSG) rules that target all VMs in a specific tier, and they need a way to easily add or remove VMs from these groups without updating NSG rules. Which Azure feature should they use to define these logical VM groups?

Accepted Answer

Application Security Group (ASG).. Application Security Groups (ASGs) allow you to group VMs logically by application tier (e.g., web, application, database) without relying on IP addresses or subnet boundaries. NSG rules can reference ASGs as source or destination, so adding or removing a VM from an ASG automatically updates the effective security policy without modifying the NSG rules themselves.

Answer

Network security group (NSG) with multiple IP address ranges.

Answer

Azure Resource Manager tags.

Answer

Virtual Network peering.