How many Refer to the Exhibit Practice Questions questions are on this page?

This page has 9 Refer to the Exhibit Practice Questions scenario questions for the AZ-500 exam, each with detailed explanations and wrong-answer analysis.

How should I approach AZ-500 scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Microsoft Azure Security Engineer Associate AZ-500 questions

Scenario-based practice

Refer to the Exhibit Practice Questions

Practise Microsoft Azure Security Engineer Associate AZ-500 practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

AZ-500

exam code

Microsoft

vendor

Scenario guide

How to approach refer to the exhibit practice questions

Practise exhibit-style questions that ask you to read a topology, table, command output or diagram before choosing the best answer.

Quick answer

Exhibit-style questions test whether you can read a topology, command output, diagram or table before choosing the best answer.

How to extract the relevant detail from an exhibit.

How topology, command output or routing information affects the answer.

How to avoid answering from memory before reading the evidence.

How to map the exhibit back to the exam objective.

Practice scenarios

Question 1mediummultiple choice

Review the full subnetting walkthrough →

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?

A
The Azure Firewall is in a different region than the spoke VNet.
Why wrong: Azure Firewall is a managed service that is routable via a private IP; VNet peering, including global peering, enables connectivity between hub and spoke VNets in different regions. As long as the spoke subnet has a route table with a next-hop of the firewall's private IP, traffic will be forwarded to the firewall regardless of region. The absence of a regional match does not change routing behavior, so this cannot be the reason traffic bypasses the firewall.
B
The route table is not associated to the spoke subnet.
A user-defined route table only takes effect when it is explicitly associated with a subnet; simply creating a route table and adding a route to the firewall's private IP does nothing otherwise. Without that association, the subnet uses Azure's default system routes, which send traffic between peered VNets directly, bypassing the firewall entirely. This is the classic cause of 'spoke traffic isn't going through the firewall' when the routes appear to be configured correctly.
C
The Azure Firewall does not have the correct network and application rules configured.
Why wrong: Even if rules are missing, traffic would attempt to route through the firewall but be dropped, not bypass it. The question is about traffic bypassing the firewall entirely, which indicates a routing issue, not a rule issue.
D
The spoke VNet has the 'Use remote virtual network gateways' setting disabled.
Why wrong: The 'Use remote virtual network gateways' peering setting is specifically for gateway transit scenarios, where a VPN or ExpressRoute gateway in the hub is shared with peers, not for Azure Firewall, which is not a virtual network gateway. Azure Firewall is exposed via a standard private IP, and traffic is redirected to it using UDRs with next-hop type 'Virtual appliance'. Disabling this setting has no effect on firewall routing, so it cannot be the reason traffic is bypassing the firewall.

Full breakdown with real-world context →

Question 2easymultiple choice

Full question →

Refer to the exhibit. This is an excerpt from an Azure Policy assignment. What is the effect of the 'notScopes' property?

Exhibit

{
  "properties": {
    "enforcementMode": "Default",
    "scope": "/subscriptions/abc123/resourceGroups/RG-Prod",
    "notScopes": [
      "/subscriptions/abc123/resourceGroups/RG-Prod/providers/Microsoft.Compute/virtualMachines/VM-Sensitive"
    ]
  }
}

A
The policy will apply only to the VM-Sensitive virtual machine.
Why wrong: This misreads the assignment's notScopes as the target of the policy. The assignment is scoped to RG-Prod, so every resource in that resource group is within the policy's evaluation scope; notScopes only carves out one VM. A resource-group-level assignment cannot be reduced to a single virtual machine by using exclusions.
B
The policy will apply to all resources in RG-Prod except the entire resource group.
Why wrong: This conflates an excluded child resource with the assignment scope itself. notScopes accepts specific resource IDs within RG-Prod and cannot exclude the resource group that is the scope, because that would make the assignment empty and logically invalid. Therefore, the policy cannot apply to all resources except the entire RG—the scope already is RG-Prod.
C
The policy will apply to all resources in RG-Prod except the VM-Sensitive virtual machine.
The assignment's scope is RG-Prod, making every contained resource subject to policy evaluation. The notScopes array specifies the VM-Sensitive virtual machine resource ID, so that VM alone is excluded from compliance evaluation. All other resources, regardless of type, remain within the assignment's scope and are evaluated.
D
The policy will apply to the subscription but not to RG-Prod.
Why wrong: The assignment is explicitly defined at the RG-Prod resource group scope, not at a management group or subscription level. Azure Policy assignments are evaluated against their declared scope, so a resource-group-level assignment does not propagate to the subscription or apply to any resources outside RG-Prod. notScopes removes only a child resource; it does not widen the assignment scope.

Full breakdown with real-world context →

Question 3hardmultiple choice

Review the full subnetting walkthrough →

Your organization has multiple Azure subscriptions connected via a hub-spoke topology using Azure Firewall in the hub. You need to ensure that traffic between spoke VNets is routed through the firewall for inspection. You configure user-defined routes (UDRs) on the spoke subnets. However, traffic between spokes is still bypassing the firewall. What is the most likely reason?

A
Azure Firewall does not support traffic between spoke VNets.
Why wrong: Azure Firewall supports transit traffic between spokes.
B
The UDR on the firewall subnet does not include the spoke address spaces.
Why wrong: UDR on firewall subnet is not required for spoke-to-spoke; firewall handles routing.
C
The 'Allow gateway transit' setting is disabled on the spoke peering.
Why wrong: 'Allow gateway transit' is configured on the hub peering, not spoke.
D
The 'Use remote gateway' setting is disabled on the spoke VNet peering.
Spoke VNets must use remote gateway to route traffic through the hub firewall.

Full breakdown with real-world context →

Question 4hardmultiple choice

Full question →

Refer to the exhibit. A security administrator runs the Azure CLI commands to create a VM with a single NIC and applies an NSG rule to deny outbound TCP traffic to the Internet on ports 80 and 443. However, the VM can still access websites on the Internet. What is the most likely reason?

Network Topology

A
The NSG rule uses the 'Internet' service tag incorrectly; it should specify an IP range.
Why wrong: The 'Internet' service tag is valid for outbound rules to the internet.
B
The NSG is not associated with the NIC because the command did not specify the NIC correctly.
Why wrong: The command 'az network nic update' with --network-security-group associates the NSG to the NIC.
C
The NSG rule is applied at the NIC level, but the subnet's NSG (if any) has a default outbound allow rule that takes precedence.
If the subnet has no NSG, the default outbound allow rule permits traffic, and the NIC NSG rule is not evaluated because the first match (subnet default allow) applies.
D
The NSG rule should be an inbound rule to block outbound traffic.
Why wrong: Outbound traffic is controlled by outbound rules; inbound rules are for incoming traffic.

Full breakdown with real-world context →

Question 5hardmultiple choice

Read the full VPN explanation →

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?

A
The on-premises traffic uses a more specific route learned via BGP from the VPN gateway, which overrides the UDR
BGP-learned routes for on-premises networks are more specific than 0.0.0.0/0. They will be used even if a UDR for 0.0.0.0/0 exists. To force through firewall, you must either disable BGP route propagation or create specific UDRs for on-premises ranges.
B
The UDR must be applied to the subnet that hosts the Azure Firewall
Why wrong: User-defined routes in Azure are associated with source subnets, not with the subnet hosting the network virtual appliance. The AzureFirewallSubnet's route table governs only the firewall's own outbound traffic, not how workloads in the spoke select a next hop. In this scenario, the spoke's UDR already points 0.0.0.0/0 to the firewall's private IP, so that part is correctly configured. Modifying the firewall subnet's UDR would have no effect on spoke traffic because the firewall's route table is not consulted by intermediary devices when routing packets from the spoke.
C
The spoke subnet does not have 'GatewaySubnet' route propagation enabled
Why wrong: Route propagation refers to learning BGP routes from a VPN gateway. If it were disabled, the spoke would not learn on-premises routes and would use the 0.0.0.0/0 UDR for all traffic. In this case, the problem is that propagation is enabled and the more specific routes override.
D
The Azure Firewall is not configured with a route to the on-premises network
Why wrong: A missing route to the on-premises network on the Azure Firewall would cause the firewall to drop or discard packets it receives that are destined for those addresses; it would not cause the spoke to bypass the firewall. The reported symptom—traffic reaching on-premises without traversing the firewall—indicates the spoke's virtual machine is sending packets directly to the VPN gateway. This happens because the BGP-learned prefix for the on-premises network is more specific than the 0.0.0.0/0 UDR and thus wins on route preference. The firewall's own routing configuration is irrelevant here, since the firewall never even sees the bypassing traffic.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

Refer to the exhibit. You have an Azure Firewall policy with the shown rules. Traffic from 10.0.0.0/8 to www.google.com on HTTPS (443) is being blocked. What is the most likely reason?

Exhibit

{
  "properties": {
    "type": "Microsoft.Network/azureFirewalls",
    "sku": {
      "name": "AZFW_VNet",
      "tier": "Standard"
    },
    "applicationRuleCollections": [
      {
        "properties": {
          "priority": 200,
          "action": {
            "type": "Allow"
          },
          "rules": [
            {
              "name": "AllowGoogle",
              "protocols": [
                {
                  "protocolType": "Https",
                  "port": 443
                }
              ],
              "sourceAddresses": ["10.0.0.0/8"],
              "targetFqdns": ["*.google.com"]
            }
          ]
        }
      }
    ],
    "networkRuleCollections": [
      {
        "properties": {
          "priority": 100,
          "action": {
            "type": "Deny"
          },
          "rules": [
            {
              "name": "DenyAll",
              "protocols": ["Any"],
              "sourceAddresses": ["*"],
              "destinationAddresses": ["*"],
              "destinationPorts": ["*"]
            }
          ]
        }
      }
    ]
  }
}

A
The network rule collection with priority 100 denies all traffic, and it is evaluated before the application rule collection.
Network rules have higher priority than application rules when the action is Deny.
B
The application rule collection has an action of Deny.
Why wrong: The action is Allow.
C
The source address 10.0.0.0/8 is not included in the application rule.
Why wrong: The source address matches 10.0.0.0/8.
D
The application rule collection does not allow *.google.com.
Why wrong: The application rule does allow *.google.com.

Full breakdown with real-world context →

Question 7mediummultiple choice

Review the full routing breakdown →

A company has a hub-spoke network topology in Azure. The spoke virtual networks contain Azure virtual machines that need to access the internet. The security team requires that all outbound internet traffic from the spoke VMs passes through the Azure Firewall deployed in the hub virtual network for inspection and logging. Which configuration should be implemented to ensure this traffic is routed through the firewall?

A
Configure an Azure Load Balancer in the hub to distribute traffic from spokes to the firewall.
Why wrong: A load balancer distributes incoming traffic, but does not route outbound traffic from spoke VMs through the firewall. It would not force traffic to the firewall as a next hop.
B
Create a user-defined route (UDR) in the spoke subnet with 0.0.0.0/0 pointing to the private IP of the Azure Firewall.
The UDR with default route pointing to the firewall's private IP ensures that all outbound internet traffic from the spoke VMs is forwarded to the firewall for inspection and logging.
C
Use Azure Firewall Manager to automatically enforce a global default route on all spokes. This is the only configuration needed.
Why wrong: Azure Firewall Manager can be used to apply routes, but it must be configured to create UDRs on the spoke subnets. The statement is misleading because the route is still a UDR created by the manager; the key action is the route itself.
D
Enable IP forwarding on the NICs of the spoke VMs so they forward traffic to the firewall.
Why wrong: IP forwarding is used when a VM acts as a network appliance, not to force outbound traffic. The routing must be done at the subnet level via UDRs.

Full breakdown with real-world context →

Question 8hardmultiple choice

Review the full subnetting walkthrough →

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?

A
The route table is not associated with the spoke subnet.
A route table only takes effect when it is explicitly associated with a subnet. In this hub-spoke topology, the spoke subnet still has the default system routes, so traffic destined for the internet follows the default route and bypasses Azure Firewall. You must associate the custom route table—with a UDR that uses the firewall's private IP as the next hop and next hop type 'VirtualAppliance'—to the spoke subnet for forced tunneling to work.
B
Azure Firewall is not configured with DNAT rules for outbound traffic.
Why wrong: DNAT rules are used to translate inbound destination IP addresses and ports, mapping the firewall's public IP to an internal resource. Outbound traffic from a spoke does not require DNAT; Azure Firewall automatically performs source NAT (SNAT) on traffic leaving through its public IP. The failure here is due to the missing route table association, not because of absent DNAT rules.
C
The spoke VNet peering does not allow gateway transit.
Why wrong: Gateway transit is a peering option that lets a spoke VNet use the hub's VPN gateway to reach on-premises networks, not a requirement for Azure Firewall routing. Traffic to the firewall is driven by user-defined routes and the firewall's private IP as the next hop, not by the gateway transit setting. As long as VNet peering exists for basic connectivity, the firewall can be used as a next hop; disabling gateway transit does not prevent that.
D
The route table has a higher priority than system routes.
Why wrong: Incorrect. User-defined routes (in route tables) have a higher priority than system routes, so if the route table is associated, they would override the system default route. This statement is true but not a reason for failure.

Full breakdown with real-world context →

Question 9mediummultiple choice

Full question →

A company has a hub-spoke network topology in Azure. The hub virtual network contains an Azure Firewall. Spoke virtual networks are peered to the hub. The security team wants to inspect all traffic between virtual machines in different spoke virtual networks. What is the minimum configuration required?

A
Enable VNet peering gateway transit and allow forwarded traffic.
Why wrong: Enabling VNet peering gateway transit and allowing forwarded traffic in the hub-spoke topology permits spokes to use the hub's VPN/ExpressRoute gateway and allows traffic to be forwarded between peered networks, but it does not insert the Azure Firewall into the data path. Without user-defined routes that explicitly set the firewall's private IP as the next hop for inter-spoke traffic, packets flow directly across the peering connection, so no inspection or filtering occurs. This setting is necessary for certain hybrid routing scenarios but is not sufficient for forced tunneling through the central firewall.
B
Deploy a VPN gateway in each spoke and configure site-to-site VPNs to the hub.
Why wrong: Deploying a VPN gateway in every spoke and configuring site-to-site VPN tunnels to the hub creates an over-engineered mesh that is costly and adds unnecessary latency, but the fundamental flaw is that VPN gateways are not stateful inspection devices—they only encapsulate and decrypt traffic. Even with the tunnels in place, you would still need UDRs to direct the decrypted traffic to the Azure Firewall for inspection, and the VPN gateway itself cannot enforce application-layer policies or log flows. This approach is reserved for extending on-premises networks, not for inter-spoke security within Azure.
C
Define user-defined routes (UDRs) in each spoke that direct inter-spoke traffic to the Azure Firewall in the hub.
Defining user-defined routes (UDRs) on each spoke subnet whose address prefix covers the other spoke's address space and whose next hop is the Azure Firewall's private IP address ensures that any inter-spoke traffic is forced to traverse the hub firewall for inspection and policy enforcement. This is the canonical pattern for a hub-spoke architecture with forced tunneling, as the route table overrides the default system routes that would otherwise use the direct peering path. The firewall's network and application rules then filter, log, and optionally forward the traffic to the destination spoke.
D
Configure network security groups (NSGs) on each spoke subnet.
Why wrong: Configuring network security groups (NSGs) on the spoke subnets can filter traffic by source/destination IP, port, and protocol, and NSGs are stateful, but they are evaluated only at the subnet or NIC boundary—they do not influence the routing path. Inter-spoke traffic would still traverse the direct peering connection without visiting the firewall; NSGs are therefore a complementary security control, not a mechanism to centralize inspection. To force routing through the hub firewall, UDRs are required, making NSG-only configuration insufficient for the stated requirement.

Full breakdown with real-world context →

These AZ-500 practice questions are part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style AZ-500 questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Refer to the Exhibit Practice Questions

How to approach refer to the exhibit practice questions

Quick answer

Related AZ-500 topic practice pages

Secure identity and access practice questions

Secure compute, storage, and databases practice questions

Secure Azure using Microsoft Defender for Cloud and Microsoft Sentinel practice questions

Manage identity and access practice questions

Secure networking practice questions

AZ-500 fundamentals practice questions

AZ-500 scenario practice questions

AZ-500 troubleshooting practice questions

Practice scenarios

Refer to the exhibit. This is an excerpt from an Azure Policy assignment. What is the effect of the 'notScopes' property?

Exhibit

Refer to the exhibit. A security administrator runs the Azure CLI commands to create a VM with a single NIC and applies an NSG rule to deny outbound TCP traffic to the Internet on ports 80 and 443. However, the VM can still access websites on the Internet. What is the most likely reason?

Refer to the exhibit. You have an Azure Firewall policy with the shown rules. Traffic from 10.0.0.0/8 to www.google.com on HTTPS (443) is being blocked. What is the most likely reason?

Exhibit