CCNA Virtual Network Questions — Page 2 of 4

MCQmedium

A company already uses the address space 10.20.0.0/16 for a hub virtual network and 10.21.0.0/16 on-premises. A new spoke virtual network will be peered to the hub and may later connect to the on-premises network. Which address space should the administrator choose for the spoke to avoid future routing conflicts?

A.10.20.64.0/19

B.10.21.0.0/16

C.10.22.0.0/16

D.10.20.128.0/17

AnswerC

This range does not overlap with either the hub VNet or the on-premises network. It also provides a full /16, which leaves enough room for multiple subnets and future growth while keeping peering and hybrid connectivity straightforward.

Why this answer

Option C (10.22.0.0/16) is correct because it is a unique, non-overlapping address space that does not conflict with the existing hub VNet (10.20.0.0/16) or the on-premises network (10.21.0.0/16). When a spoke VNet is peered to the hub and later connected to on-premises via VPN or ExpressRoute, Azure requires that all peered and connected address spaces be unique to avoid routing conflicts. Choosing a completely separate /16 ensures no future overlap.

Exam trap

The trap here is that candidates often assume any address space outside the hub's /16 is safe, but they forget to check for overlap with the on-premises network (10.21.0.0/16) or incorrectly think that a smaller subnet within the hub's range (like 10.20.64.0/19) can be used if it is not currently in use, ignoring that Azure requires completely non-overlapping ranges for peered VNets.

How to eliminate wrong answers

Option A (10.20.64.0/19) is wrong because it falls within the hub VNet's 10.20.0.0/16 range, causing an immediate IP address overlap that would prevent VNet peering from succeeding. Option B (10.21.0.0/16) is wrong because it exactly matches the on-premises address space, which would create a routing conflict when the spoke later connects to on-premises (Azure cannot distinguish between the on-premises network and the spoke VNet). Option D (10.20.128.0/17) is wrong because it is a subset of the hub's 10.20.0.0/16, overlapping with the hub VNet and breaking peering due to non-unique address ranges.

Practice this question →

MCQhard

A storage account must be reachable only from a single subnet. The team wants to keep the storage public endpoint in place, avoid a private endpoint, and avoid managing any custom DNS records. Which change best meets the requirement?

A.Add a network security group rule to the subnet that allows outbound TCP 443 to the storage account.

B.Enable a service endpoint for Microsoft.Storage on the subnet and add the subnet to the storage account firewall allow list.

C.Create a private endpoint and set the storage account to use a private DNS zone.

D.Create a route table that sends storage traffic through an Azure Firewall appliance.

AnswerB

This is the correct approach when the service must remain on the public endpoint but be accessible only from a specific subnet. The service endpoint lets Azure recognize the subnet as an allowed source while traffic still uses the storage account's public FQDN. Adding that subnet to the storage firewall enforces the restriction without requiring private endpoints or custom DNS management.

Why this answer

Option B is correct because enabling a service endpoint for Microsoft.Storage on the subnet injects the subnet's identity into the traffic to the storage account, allowing the storage account firewall to permit access only from that subnet while keeping the public endpoint active. This avoids the need for a private endpoint, custom DNS records, or additional routing appliances, directly meeting the requirement of restricting access to a single subnet.

Exam trap

The trap here is that candidates often confuse network security groups (NSGs) with storage account firewalls, thinking an NSG rule on the subnet can restrict access to the storage account, when in fact the storage account firewall must explicitly allow the subnet via a service endpoint or virtual network rule to enforce subnet-level restriction.

How to eliminate wrong answers

Option A is wrong because adding an NSG rule that allows outbound TCP 443 to the storage account does not restrict inbound access to the storage account; the storage account's public endpoint remains open to all traffic, and the NSG only controls traffic within the subnet, not the storage account's firewall. Option C is wrong because creating a private endpoint would remove the public endpoint from use (or require disabling public access) and would involve managing private DNS zones or custom DNS records, which the team explicitly wants to avoid. Option D is wrong because creating a route table to send storage traffic through an Azure Firewall does not restrict access to a single subnet; it forces traffic through a firewall for inspection but still leaves the storage account's public endpoint accessible from any source, and it adds management overhead for the firewall and routing.

Practice this question →

MCQhard

A subnet NSG contains these inbound rules: Priority 100 denies TCP 8443 from VirtualNetwork to any destination, Priority 110 allows TCP 8443 from AzureLoadBalancer to any destination, and Priority 200 allows TCP 8443 from ASG-Web to ASG-App. The app VM NIC has no additional inbound rules. Web servers are members of ASG-Web and the app VM is a member of ASG-App. The web tier still cannot connect to TCP 8443. What should the administrator change?

A.Move the allow rule for ASG-Web to ASG-App to a priority lower than 100.

B.Replace ASG-Web with the VirtualNetwork service tag in the allow rule.

C.Add a route table that sends TCP 8443 traffic to the app subnet.

D.Create a second NSG on the app NIC with an allow rule at priority 50.

AnswerA

NSG rules are processed in priority order, and the first matching rule wins. The deny rule at priority 100 matches traffic from the web tier because it comes from the same virtual network. Moving the specific allow rule to a lower number than 100 lets it match first while still keeping the source and destination restricted to the intended application security groups.

Why this answer

The correct answer is A because NSG rules are evaluated in priority order, from lowest to highest number. The deny rule at priority 100 explicitly blocks TCP 8443 from VirtualNetwork, which includes traffic from ASG-Web (since ASG-Web members are within the virtual network). The allow rule at priority 110 only permits traffic from AzureLoadBalancer, not from ASG-Web.

The allow rule at priority 200 is never evaluated because the deny rule at priority 100 matches first. By moving the allow rule for ASG-Web to ASG-App to a priority lower than 100 (e.g., 90), it will be evaluated before the deny rule, allowing the web servers to connect.

Exam trap

The trap here is that candidates often assume a more specific rule (like ASG-Web to ASG-App) will override a broader deny rule, but NSG priority is strictly numeric, not based on specificity, so a lower-priority allow rule is never evaluated if a higher-priority deny rule matches first.

How to eliminate wrong answers

Option B is wrong because replacing ASG-Web with the VirtualNetwork service tag would still match the deny rule at priority 100 (since VirtualNetwork includes all virtual network traffic, including ASG-Web), and the allow rule at priority 200 would still be blocked. Option C is wrong because route tables control traffic routing between subnets, not NSG rule evaluation; adding a route table does not bypass NSG deny rules. Option D is wrong because creating a second NSG on the app NIC with an allow rule at priority 50 would still be overridden by the subnet NSG's deny rule at priority 100, as NSGs are evaluated in order (subnet NSG first, then NIC NSG) and the subnet NSG deny would block the traffic before the NIC NSG allow is considered.

Practice this question →

MCQeasy

Based on the exhibit, two development virtual networks must be peered so the workloads can exchange traffic directly. What should the administrator do first?

A.Create a VPN gateway in each VNet before attempting peering.

B.Change one VNet to a non-overlapping address space before creating the peering.

C.Add a user-defined route to each subnet so the VNets can ignore the overlap.

D.Enable service endpoints on both VNets to allow cross-network communication.

AnswerB

Azure VNet peering does not allow overlapping address spaces. The first step is to redesign one network so its address range does not intersect the other. After the address conflict is removed, peering can be created normally and traffic can flow directly between the VNets.

Why this answer

Azure Virtual Network peering requires that the address spaces of the peered VNets do not overlap. Overlapping address spaces cause routing conflicts because Azure cannot determine which VNet should receive traffic destined for the overlapping range. Therefore, the administrator must first change one VNet to a non-overlapping address space before creating the peering.

Exam trap

The trap here is that candidates often assume overlapping address spaces can be resolved with routing tweaks (like UDRs) or additional gateways, but Azure explicitly blocks VNet peering when address spaces overlap, requiring a non-overlapping address space as a prerequisite.

How to eliminate wrong answers

Option A is wrong because VPN gateways are not required for VNet peering; peering uses the Azure backbone network directly, not a VPN tunnel. Option C is wrong because user-defined routes cannot override the fundamental routing conflict caused by overlapping address spaces; Azure will still see the addresses as ambiguous and may drop or misroute traffic. Option D is wrong because service endpoints are used to secure access to Azure PaaS services (like Storage or SQL) from a VNet, not to enable direct traffic exchange between two peered VNets.

Practice this question →

MCQeasy

Based on the exhibit, which Azure connectivity option should the administrator use for the branch office?

A.Point-to-site VPN for each user laptop.

B.VNet peering between the branch office and Azure.

C.A service endpoint on the Azure subnet.

D.A site-to-site VPN connection to an Azure VPN gateway.

AnswerD

A site-to-site VPN is designed for a branch office network with a single edge device. It creates encrypted connectivity over the internet to Azure so users can reach private resources without setting up individual tunnels on every laptop.

Why this answer

A site-to-site VPN connection to an Azure VPN gateway (Option D) is the correct choice because it provides a persistent, encrypted tunnel between the branch office's on-premises network and Azure, enabling seamless connectivity for all users and devices at the branch without requiring per-user configuration. This aligns with the typical scenario where a branch office needs constant, secure access to Azure resources, and the VPN gateway supports IPsec/IKE protocols for site-to-site connections.

Exam trap

The trap here is that candidates often confuse VNet peering (Option B) as a hybrid connectivity solution, but it only works between Azure VNets and cannot connect on-premises networks, making site-to-site VPN the correct choice for branch office connectivity.

How to eliminate wrong answers

Option A is wrong because a point-to-site VPN requires each user laptop to individually establish a VPN connection, which is not scalable for a branch office with multiple users and does not provide network-level connectivity for all devices. Option B is wrong because VNet peering is used to connect virtual networks within Azure, not to connect an on-premises branch office to Azure; it does not support hybrid connectivity across the internet. Option C is wrong because a service endpoint is a feature that extends a VNet's private IP space to Azure PaaS services, but it does not provide any VPN or connectivity between an on-premises branch office and Azure; it only secures traffic to specific Azure services from within the VNet.

Practice this question →

MCQmedium

A VM cannot connect to another VM on TCP 1433. You need to determine whether an NSG is blocking the flow and identify which rule applies. Which Network Watcher tool should you use?

A.Packet capture

B.IP flow verify

C.Connection troubleshoot

D.Effective routes

AnswerB

IP flow verify is the Network Watcher feature that tests a specific source, destination, protocol, and port against NSG rules. It shows whether the traffic is allowed or denied and which rule is responsible.

Why this answer

IP flow verify is the correct Network Watcher tool because it tests whether a packet is allowed or denied to or from a specific VM, based on a 5-tuple (source IP, destination IP, protocol, source port, destination port). For TCP 1433 (SQL Server), you can specify the exact flow parameters, and IP flow verify will evaluate all effective security rules, including NSG rules, and return the specific rule that allowed or denied the traffic.

Exam trap

The trap here is that candidates often confuse 'Connection troubleshoot' with 'IP flow verify' because both diagnose connectivity issues, but Connection troubleshoot provides a broader end-to-end path analysis without pinpointing the exact blocking rule, whereas IP flow verify is specifically designed to test a single flow and identify the exact NSG rule that applies.

How to eliminate wrong answers

Option A is wrong because Packet capture captures raw network traffic on a VM for analysis, but it does not evaluate NSG rules or identify which specific rule is blocking traffic; it requires manual inspection of captured packets. Option C is wrong because Connection troubleshoot checks end-to-end connectivity and can identify issues like NSG blocking, but it does not directly tell you which specific NSG rule is applying; it provides a diagnostic of the overall connection path. Option D is wrong because Effective routes shows the effective routing table for a VM or subnet, which is used for diagnosing routing issues, not for evaluating NSG rule evaluation or filtering decisions.

Practice this question →

MCQmedium

A three-tier application uses separate web and app VMs that are scaled in and out regularly. The administrator must allow only the web tier to connect to the app tier on TCP 8080 without continually updating IP addresses. What should be configured in the NSG rule?

A.Use application security groups for the web and app tiers and reference those groups in the NSG rule.

B.Add a subnet-to-subnet peering connection between the web and app subnets.

C.Create a load balancer backend pool rule for TCP 8080.

D.Use a user-defined route that sends TCP 8080 traffic to the app tier.

AnswerA

Application security groups let the administrator group VMs by role rather than by IP address. The NSG rule can then allow traffic from the web ASG to the app ASG on TCP 8080. This is a good fit for environments that scale or change frequently because the NSG does not need constant editing whenever VM addresses change.

Why this answer

Application security groups (ASGs) allow you to group VMs logically by their application role (e.g., web tier, app tier) and reference those groups directly in NSG rules. This eliminates the need to maintain individual IP addresses or CIDR ranges when VMs scale in or out, because the NSG rule dynamically applies to all VMs in the ASG. By creating an inbound NSG rule that allows TCP 8080 from the web-tier ASG to the app-tier ASG, the administrator achieves the required connectivity without manual IP updates.

Exam trap

The trap here is that candidates often confuse network-level controls (like UDRs or VNet peering) with application-layer access control, or they incorrectly assume that a load balancer rule can replace a security rule for source-based filtering.

How to eliminate wrong answers

Option B is wrong because subnet-to-subnet peering is a VNet peering concept that connects entire virtual networks, not a mechanism to filter traffic between tiers within the same VNet; it does not replace the need for NSG rules to control port-specific access. Option C is wrong because a load balancer backend pool rule distributes incoming traffic to backend VMs, but it does not restrict which source tier can connect to the app tier on TCP 8080; it also requires static IP addresses or DNS names for the backend, not solving the dynamic IP update problem. Option D is wrong because a user-defined route (UDR) controls the next hop for traffic (e.g., forcing traffic through a firewall or virtual appliance), but it does not filter or allow traffic on a specific port; UDRs operate at the network layer (L3) and cannot enforce TCP port-based access control.

Practice this question →

MCQeasy

A VM in a subnet must send traffic to 172.16.0.0/16 through a network virtual appliance, but all other destinations should continue using the default Azure system routes. What should the administrator add to the subnet route table?

A.A route for 0.0.0.0/0 with next hop Virtual appliance.

B.A route for 172.16.0.0/16 with next hop Virtual appliance.

C.An NSG deny rule for all other destinations.

D.A service endpoint for the 172.16.0.0/16 network.

AnswerB

A specific user-defined route for the target prefix sends only that traffic to the appliance while other traffic still uses system routes.

Why this answer

Option B is correct because the requirement is to route traffic destined for 172.16.0.0/16 through a network virtual appliance (NVA) while leaving all other traffic to use the default Azure system routes. Adding a user-defined route (UDR) with destination 172.16.0.0/16 and next hop Virtual appliance overrides the default system route for that specific prefix, ensuring traffic to that range is forwarded to the NVA. All other destinations remain unaffected because the 0.0.0.0/0 default route is not modified.

Exam trap

The trap here is that candidates often confuse the 0.0.0.0/0 route (which controls all internet-bound traffic) with a specific prefix route, mistakenly thinking they must add a default route to force traffic through the NVA, when in fact only the specific destination prefix needs a custom route.

How to eliminate wrong answers

Option A is wrong because adding a route for 0.0.0.0/0 with next hop Virtual appliance would force all internet-bound and other external traffic through the NVA, which violates the requirement that only traffic to 172.16.0.0/16 should use the appliance. Option C is wrong because an NSG deny rule for all other destinations would block traffic to those destinations entirely, rather than allowing them to use default routes; NSGs are stateful filters, not routing controls. Option D is wrong because a service endpoint is used to secure direct connectivity to Azure PaaS services (like Azure Storage or SQL) over the Azure backbone, not to route traffic to an on-premises or virtual network range through an NVA.

Practice this question →

MCQmedium

A VM sends traffic to 172.16.5.10, but the administrator suspects the traffic is taking an unexpected next hop. They want to see the effective route table applied to the VM NIC, including system routes, user-defined routes, and propagated routes. Which Network Watcher tool should be used?

A.IP flow verify

B.Effective routes

C.Packet capture

D.Connection troubleshoot

AnswerB

Effective routes displays the full route set that applies to a VM NIC, including system, user-defined, and propagated routes. That makes it the right tool when you need to understand why traffic is taking a particular next hop.

Why this answer

Effective routes is the correct Network Watcher tool because it displays the complete route table applied to a VM NIC, including system routes, user-defined routes (UDRs), and BGP-propagated routes from virtual network gateways. This allows the administrator to see exactly which next hop is selected for traffic to 172.16.5.10 based on the longest prefix match, identifying any unexpected routing behavior.

Exam trap

The trap here is that candidates often confuse IP flow verify (which checks NSG rules) with effective routes (which checks routing), leading them to pick A when the question explicitly asks about the route table and next hop, not firewall rules.

How to eliminate wrong answers

Option A is wrong because IP flow verify checks whether traffic is allowed or denied by network security groups (NSGs) for a specific source/destination IP and port, but it does not show the effective route table or next hop information. Option C is wrong because packet capture captures raw network traffic packets for deep inspection, but it does not provide a consolidated view of the effective routes applied to the NIC. Option D is wrong because Connection troubleshoot diagnoses connectivity issues by checking NSG rules, DNS resolution, and latency, but it does not display the effective route table or next hop selection.

Practice this question →

MCQmedium

A subnet contains several application servers. You need to allow inbound TCP 3389 only from a management subnet named Subnet-Mgmt and deny RDP from all other sources. What should you do?

A.Create an NSG rule allowing TCP 3389 from the Subnet-Mgmt address range and rely on the default deny afterward.

B.Create a route table that sends RDP traffic to the management subnet.

C.Deploy a private endpoint for each application server.

D.Enable service endpoints on the application subnet.

AnswerA

This is the correct way to permit RDP from a specific source while denying other sources.

Why this answer

Option A is correct because Network Security Groups (NSGs) in Azure filter traffic based on rules that are evaluated in priority order. By creating an inbound rule that allows TCP 3389 (RDP) from the Subnet-Mgmt address range, and relying on the default implicit deny rule that blocks all other inbound traffic, you effectively restrict RDP access to only the management subnet. No additional configuration is needed to deny traffic from other sources, as the default deny handles that automatically.

Exam trap

The trap here is that candidates often think they need to explicitly create a deny rule for all other sources, not realizing that NSGs have a built-in default deny rule that automatically blocks traffic not matching any allow rule.

How to eliminate wrong answers

Option B is wrong because route tables control the path traffic takes through the network, not the permission to access a resource; sending RDP traffic to the management subnet via a route does not deny RDP from other sources and could actually route traffic incorrectly. Option C is wrong because private endpoints are used to securely access Azure PaaS services (like Azure SQL or Storage) over a private IP address, not to filter inbound RDP traffic to application servers; they do not provide network-level access control for VM RDP. Option D is wrong because service endpoints extend a virtual network's private address space to Azure services (like Azure Storage or SQL Database) to improve security, but they do not filter inbound RDP traffic to VMs; they are unrelated to RDP access control.

Practice this question →

MCQmedium

Backend virtual machines are rebuilt frequently and often receive different private IP addresses. An administrator must allow the frontend tier to reach the backend tier on TCP 8443 without editing NSG rules every time the backend IP changes. What should the administrator use in the NSG rule?

A.A static private IP address for each backend VM.

B.An Application Security Group that contains the backend VMs.

C.A user-defined route pointing frontend traffic to the backend subnet.

D.A private endpoint for the backend tier.

AnswerB

Application Security Groups let the administrator group backend VMs logically and reference that group in NSG rules instead of individual IP addresses. This is ideal when backend IPs change or VMs are replaced. The NSG rule remains stable while the backend membership changes, which reduces operational overhead and improves consistency.

Why this answer

An Application Security Group (ASG) allows you to group backend VMs logically and reference that group in a Network Security Group (NSG) rule. When backend VMs are rebuilt and receive new private IPs, you simply add the new VMs to the same ASG, and the existing NSG rule (which references the ASG as the destination) automatically applies to the new IPs without any manual rule edits. This decouples security policy from dynamic IP addresses, making it the ideal solution for frequently changing backend IPs.

Exam trap

The trap here is that candidates often confuse Application Security Groups (logical grouping for NSG rules) with User-Defined Routes (path control) or Private Endpoints (PaaS connectivity), leading them to pick a routing or endpoint solution instead of the correct security-grouping mechanism.

How to eliminate wrong answers

Option A is wrong because assigning a static private IP address to each backend VM would require manual reconfiguration or scripting every time a VM is rebuilt, and it does not scale or automate the process of keeping the NSG rule valid when VMs are replaced. Option C is wrong because a user-defined route (UDR) controls the next hop for traffic (routing path), not the security filtering of traffic; it cannot replace an NSG rule that allows or denies traffic on TCP 8443. Option D is wrong because a private endpoint is used to securely connect to Azure PaaS services (e.g., Azure SQL, Storage) over a private IP, not to group and secure traffic between frontend and backend VMs within a virtual network.

Practice this question →

MCQeasy

Based on the exhibit, what should the administrator do so the hub and spoke can be peered successfully?

A.Keep the current ranges and enable gateway transit on the peering.

B.Change the spoke VNet to a non-overlapping address space.

C.Add another subnet inside the spoke VNet and reuse the current address space.

D.Create a network security group on the spoke subnet before peering.

AnswerB

Azure VNet peering requires unique, non-overlapping IP ranges. Changing the spoke to a different CIDR block resolves the conflict and allows the peering to be created.

Why this answer

VNet peering requires that the address spaces of the peered VNets do not overlap. Overlapping IP ranges cause routing conflicts and prevent successful peering. Changing the spoke VNet to a non-overlapping address space resolves this issue and allows the peering to be established.

Exam trap

The trap here is that candidates may think overlapping subnets can be worked around by using NSGs or gateway transit, but Azure VNet peering strictly requires non-overlapping VNet address spaces at the time of peering creation.

How to eliminate wrong answers

Option A is wrong because enabling gateway transit on the peering does not resolve overlapping address spaces; it only allows the spoke to use the hub's VPN/ExpressRoute gateway, but the peering itself will still fail if IP ranges overlap. Option C is wrong because adding another subnet within the same overlapping address space does not eliminate the conflict; the entire VNet address space must be unique for peering to succeed. Option D is wrong because creating a network security group (NSG) on the spoke subnet does not affect the underlying IP address overlap; NSGs filter traffic but do not resolve routing conflicts caused by overlapping ranges.

Practice this question →

MCQmedium

A subnet has a user-defined route for 0.0.0.0/0 that sends traffic to a network virtual appliance at 10.10.1.4. The VM in the subnet still reaches an Azure Storage account using the public endpoint, but the administrator expected all outbound traffic to go through the NVA. What is the most likely reason?

A.Azure always ignores user-defined routes for storage traffic.

B.The storage account traffic is using a more specific route than the 0.0.0.0/0 route.

C.NSG outbound rules override user-defined routes in Azure.

D.The subnet needs a public IP address assigned to each VM for the route to take effect.

AnswerB

Route selection prefers the most specific matching prefix. If a more specific route exists for the storage destination, it can win over the default route to the NVA. This is why forced tunneling designs must be checked against specific system or learned routes. Understanding route precedence is essential when traffic does not follow the default next hop that appears to be in place.

Why this answer

The most likely reason is that the storage account traffic is using a more specific route than the 0.0.0.0/0 route. Azure uses longest prefix match routing, so a route with a smaller prefix (e.g., a specific public IP range for Azure Storage) will take precedence over the default route. The 0.0.0.0/0 route only applies when no more specific route exists, and Azure automatically adds platform routes for Azure services like Storage, which can override user-defined routes.

Exam trap

The trap here is that candidates often assume a default route (0.0.0.0/0) will catch all outbound traffic, forgetting that Azure's platform routes for Azure services (like Storage) can be more specific and take precedence over user-defined routes.

How to eliminate wrong answers

Option A is wrong because Azure does not ignore user-defined routes for storage traffic; it respects them unless a more specific route (like a service tag or platform route) exists. Option C is wrong because NSG outbound rules do not override user-defined routes; NSGs filter traffic based on rules, but routing decisions are made by the route table, not NSGs. Option D is wrong because a public IP address on a VM is not required for a user-defined route to take effect; the route applies to all outbound traffic from the subnet regardless of public IP assignment.

Practice this question →

MCQmedium

Two VM scale sets named Web and App run in separate subnets. The App subnet NSG already contains Deny-All-Inbound at priority 300. The business wants only the Web tier to connect to the App tier on TCP 8443, and any new scale-out instances must be included automatically. What should the administrator add?

A.A rule that allows TCP 8443 from the current Web subnet address range to the App subnet.

B.An inbound allow rule using source WebASG, destination AppASG, TCP 8443, with a priority lower than 300.

C.A load balancer NAT rule that maps port 8443 from the Internet to the App tier.

D.A service endpoint for Microsoft.Web on both subnets.

AnswerB

Application security groups let you target groups of VMs by workload rather than by static IPs. A rule that allows TCP 8443 from WebASG to AppASG will automatically include future scale-set instances as they join the ASGs. The rule must also have a lower priority number than the existing deny rule, otherwise the deny will win first.

Why this answer

Option B is correct because it uses an Application Security Group (ASG) as the source and destination, which automatically includes all current and future VM instances in the Web and App scale sets. The rule allows TCP 8443 from WebASG to AppASG with a priority lower than 300 (e.g., 250) so it is evaluated before the Deny-All-Inbound rule at priority 300. This ensures that only the Web tier can connect to the App tier on the specified port, and new scale-out instances are included automatically without manual NSG updates.

Exam trap

The trap here is that candidates often choose a static subnet-based rule (Option A) because it seems simpler, failing to recognize that ASGs are required to automatically include new scale-out instances without manual NSG updates.

How to eliminate wrong answers

Option A is wrong because it uses a static subnet address range, which does not automatically include new scale-out instances that may have different IP addresses, and it would require manual updates to the NSG rule. Option C is wrong because a load balancer NAT rule maps inbound traffic from the Internet to the App tier, which violates the requirement that only the Web tier should connect, and it exposes the App tier to external access. Option D is wrong because a service endpoint for Microsoft.Web enables secure connectivity to Azure Web services (like Azure App Service) but does not control traffic between VMs in different subnets or scale sets.

Practice this question →

MCQmedium

Based on the exhibit, which Network Watcher tool should the administrator use to identify the exact NSG rule that is blocking TCP 1433 traffic?

A.Connection troubleshoot

B.IP flow verify

C.Next hop

D.Packet capture

AnswerB

IP flow verify returns whether a flow is allowed or denied and shows the matching NSG rule.

Why this answer

IP flow verify is the correct Network Watcher tool because it tests whether a packet is allowed or denied to or from a specific virtual machine based on a 5-tuple (source IP, destination IP, source port, destination port, and protocol). By specifying TCP 1433 as the destination port, the tool evaluates all effective security rules (NSG and ASG) and returns the exact rule name and direction that is blocking the traffic.

Exam trap

The trap here is that candidates often confuse 'Connection troubleshoot' (which tests end-to-end connectivity but not rule-level blocking) with 'IP flow verify' (which explicitly evaluates NSG rules), leading them to select A instead of B.

How to eliminate wrong answers

Option A is wrong because Connection troubleshoot checks end-to-end connectivity (including latency, packet loss, and routing) but does not pinpoint which specific NSG rule is blocking traffic; it only reports that connectivity failed. Option C is wrong because Next hop shows the next hop type and IP address for a packet but does not evaluate NSG rules or indicate whether traffic is allowed or denied. Option D is wrong because Packet capture captures raw network packets for analysis but does not interpret NSG rules or identify which rule is blocking traffic; it requires manual inspection of the capture.

Practice this question →

MCQmedium

An administrator is deploying a new VPN gateway in an existing VNet. The GatewaySubnet currently uses a /28 range, and the deployment fails because the selected gateway configuration does not have enough available IP addresses. What is the best action?

A.Move one of the gateway's NICs into a normal workload subnet.

B.Expand GatewaySubnet to a larger range, such as /27, and redeploy the VPN gateway.

C.Create a private endpoint inside GatewaySubnet to reserve extra addresses.

D.Enable BGP so the gateway needs fewer IP addresses.

AnswerB

GatewaySubnet is a dedicated subnet for VPN gateway resources, and the gateway requires enough free IP addresses to deploy and operate. If the current prefix is too small for the chosen configuration, the correct fix is to expand the subnet to a larger size, such as /27, if the VNet address space allows it. After resizing, the administrator can retry the gateway deployment with adequate capacity.

Why this answer

The GatewaySubnet requires a minimum /27 range to support most VPN gateway SKUs, as Azure reserves several IP addresses for internal use and the gateway instances need at least 3–6 usable IPs depending on the SKU. Expanding the subnet to /27 provides enough addresses (32 total, minus reserved) to satisfy the gateway's allocation requirements, allowing the deployment to succeed.

Exam trap

The trap here is that candidates assume a /28 subnet is always sufficient because it works for smaller gateways, but they overlook that larger SKUs or active-active configurations require more IPs, and Azure's reservation of 5 addresses per subnet further reduces usable space.

How to eliminate wrong answers

Option A is wrong because moving a gateway's NIC into a normal workload subnet violates the Azure requirement that all gateway VMs must reside exclusively in the GatewaySubnet; placing NICs elsewhere breaks connectivity and is not supported. Option C is wrong because a private endpoint does not reserve IP addresses for the gateway; it is used for secure access to PaaS services and does not increase the available IP count in the GatewaySubnet. Option D is wrong because enabling BGP does not reduce the number of IP addresses the gateway needs; BGP is a routing protocol that adds configuration complexity but does not change the subnet size requirement.

Practice this question →

MCQhard

Based on the exhibit, what should the administrator change to allow only the web tier to reach the app tier on TCP 8443?

A.Move the allow rule for WebTier-ASG to a priority lower than 100.

B.Change the deny rule source from VirtualNetwork to Internet.

C.Associate the NSG with the virtual machine NIC instead of the subnet.

D.Replace the ASG destination with the subnet address range.

AnswerA

The deny rule at priority 100 matches all traffic from VirtualNetwork to AppTier-ASG on TCP 8443, including the web tier. The allow rule must evaluate first.

Why this answer

The exhibit shows a default-deny NSG rule at priority 100 that blocks all traffic from VirtualNetwork to VirtualNetwork. To allow only the web tier (WebTier-ASG) to reach the app tier (AppTier-ASG) on TCP 8443, the administrator must move the allow rule for WebTier-ASG to a priority lower than 100 (e.g., 90). This ensures the allow rule is evaluated before the deny rule, as NSG rules are processed in priority order (lowest number first).

Exam trap

The trap here is that candidates often overlook the default-deny rule at priority 100 and assume any allow rule will work regardless of priority, failing to realize that NSG rules are processed in strict priority order and a higher-priority deny will override a lower-priority allow.

How to eliminate wrong answers

Option B is wrong because changing the deny rule source from VirtualNetwork to Internet would block internet traffic but still block the web tier's traffic to the app tier, as the web tier is within the same virtual network. Option C is wrong because associating the NSG with the VM NIC instead of the subnet would only apply the NSG to that specific VM, not to all VMs in the app tier, and would not resolve the priority conflict between the allow and deny rules. Option D is wrong because replacing the ASG destination with the subnet address range would remove the granularity of the application security group, potentially allowing unintended traffic from other subnets, and does not address the rule priority issue.

Practice this question →

MCQmedium

A subnet must send traffic to on-premises networks through a VPN gateway, but internet-bound traffic should use the Azure platform's normal outbound path and not be forced through a virtual appliance. The administrator wants to avoid creating a 0.0.0.0/0 user-defined route. Which design meets the requirement?

A.Associate a route table that contains only the specific on-premises prefixes and leave gateway route propagation enabled.

B.Add a 0.0.0.0/0 route to the VPN gateway and disable gateway route propagation.

C.Create a service endpoint for the subnet and use it as the default next hop.

D.Attach an NSG rule that allows on-premises traffic and blocks all internet traffic.

AnswerA

This lets the subnet use specific routes for on-premises destinations through the VPN gateway while leaving the default internet route untouched. Because there is no 0.0.0.0/0 UDR, Azure can use the normal system route for internet traffic. Keeping gateway route propagation enabled also allows learned gateway routes to appear when appropriate.

Why this answer

Option A is correct because it uses a route table with only the specific on-premises prefixes, which forces traffic destined for those prefixes through the VPN gateway, while leaving gateway route propagation enabled. With gateway propagation enabled, the VPN gateway's learned routes (including the 0.0.0.0/0 route from the on-premises network) are not automatically added to the subnet's route table unless explicitly propagated; instead, the subnet's effective routes combine the user-defined routes (UDRs) for on-premises prefixes with the Azure default system routes, which include a 0.0.0.0/0 route to the internet. This ensures internet-bound traffic uses the Azure platform's normal outbound path without a forced tunnel through the virtual appliance or VPN gateway.

Exam trap

The trap here is that candidates often assume that to send traffic to on-premises networks, they must create a 0.0.0.0/0 UDR to the VPN gateway, but the correct approach is to use specific prefix routes and leave gateway propagation enabled to avoid overriding the default internet path.

How to eliminate wrong answers

Option B is wrong because adding a 0.0.0.0/0 route to the VPN gateway and disabling gateway route propagation would force all internet-bound traffic through the VPN gateway, which violates the requirement that internet traffic should use the Azure platform's normal outbound path. Option C is wrong because a service endpoint does not act as a default next hop for internet traffic; it only provides direct connectivity to Azure PaaS services over the Azure backbone, and it cannot replace a 0.0.0.0/0 route or control outbound internet routing. Option D is wrong because an NSG rule that blocks all internet traffic would prevent the subnet from reaching the internet entirely, which contradicts the requirement that internet-bound traffic should use the normal outbound path; NSGs are stateful filters, not routing mechanisms.

Practice this question →

MCQmedium

You need to control inbound and outbound traffic to resources in a subnet by allowing or denying traffic based on IP address, port, and protocol. Which Azure feature should you use?

A.A network security group

B.A route table

C.A private DNS zone

D.Azure Advisor

AnswerA

NSGs are the Azure feature used to allow or deny traffic based on rule criteria.

Why this answer

A network security group (NSG) is the correct Azure feature because it contains security rules that allow or deny inbound and outbound traffic at the subnet or network interface level based on source/destination IP address, port, and protocol (TCP, UDP, or Any). This directly matches the requirement to control traffic by these three parameters.

Exam trap

The trap here is that candidates often confuse a route table (which controls traffic routing) with an NSG (which controls traffic filtering), especially since both are associated with subnets in the Azure portal.

How to eliminate wrong answers

Option B is wrong because a route table controls the path that network traffic takes (next hop) rather than filtering traffic based on IP, port, and protocol. Option C is wrong because a private DNS zone is used for name resolution within a virtual network, not for traffic filtering. Option D is wrong because Azure Advisor provides recommendations for best practices (cost, security, reliability, performance) but does not enforce traffic rules.

Practice this question →

MCQmedium

A company has frontend and backend VMs in the same subnet. Security rules must allow the frontend tier to reach only the backend tier on TCP 443, without assigning rules to individual VM IP addresses. What should the administrator use in the NSG rule?

A.A user-defined route that sends frontend traffic to the backend subnet.

B.A network security group rule that references both subnets by address prefix only.

C.Application security groups for the frontend and backend VMs.

D.A VNet peering connection between the two tiers.

AnswerC

ASGs let you group VMs by workload role and reference those groups in NSG rules.

Why this answer

Option C is correct because Application Security Groups (ASGs) allow you to group VMs logically by their application tier (e.g., frontend, backend) without relying on individual IP addresses. You can then create an NSG rule that uses the frontend ASG as the source and the backend ASG as the destination, restricting traffic to TCP 443. This meets the requirement of not assigning rules to individual VM IPs while ensuring only frontend VMs can reach backend VMs within the same subnet.

Exam trap

The trap here is that candidates assume subnet-based NSG rules are sufficient for tier isolation, but since both tiers share the same subnet, a subnet-to-subnet rule would allow all VMs in that subnet to communicate, failing the requirement to restrict traffic to only frontend-to-backend on TCP 443.

How to eliminate wrong answers

Option A is wrong because a user-defined route (UDR) controls the next hop for traffic (e.g., forcing it through a firewall or virtual appliance), not the security filtering of allowed traffic; it does not restrict which VMs can communicate on TCP 443. Option B is wrong because referencing both subnets by address prefix would allow any VM in the frontend subnet to communicate with any VM in the backend subnet, but since both tiers are in the same subnet, a subnet-based rule would allow all VMs in that subnet to communicate with each other, failing to isolate the frontend and backend tiers. Option D is wrong because VNet peering connects separate virtual networks, not tiers within the same subnet; it is irrelevant for intra-subnet traffic filtering.

Practice this question →

Multi-Selecteasy

Which two statements about application security groups and service tags are correct? Select two.

Select 2 answers

A.An application security group lets you reference a set of virtual machines in NSG rules.

B.A service tag is a Microsoft-managed label for a service or address range.

C.Application security groups are used to assign Azure roles.

D.Service tags are custom labels you create for your own subscriptions.

E.Service tags create a private IP address for a service.

AnswersA, B

Correct because ASGs let you group VMs logically and then use the group name in NSG rules.

Why this answer

Option A is correct because an application security group (ASG) allows you to group virtual machines logically, and then reference that group as a source or destination in network security group (NSG) rules. This simplifies rule management by decoupling the rule from individual VM IP addresses or NICs, enabling dynamic membership based on application tiers.

Exam trap

The trap here is confusing application security groups (which handle network traffic filtering) with Azure RBAC roles (which handle access control), and assuming service tags are user-defined labels rather than Microsoft-managed, dynamic IP prefix groups.

Practice this question →

Multi-Selecthard

A Windows VM in VNet-App must access an Azure Files share over a private IP address. The storage account must not be reachable through its public endpoint, and the VM should resolve the file share name without custom host-file entries. Which three actions are required? Select three.

Select 3 answers

A.Create a private endpoint for the file service in VNet-App.

B.Create and link the private DNS zone privatelink.file.core.windows.net to VNet-App.

C.Disable public network access on the storage account.

D.Enable a service endpoint for Microsoft.Storage on the subnet instead of a private endpoint.

E.Grant the VM's managed identity the Storage File Data SMB Share Reader role to create the private path.

AnswersA, B, C

A private endpoint places the storage service on a private IP in the virtual network.

Why this answer

Option A is correct because a private endpoint assigns a private IP address from VNet-App to the Azure Files service, enabling the VM to access the file share over a private IP without traversing the public internet. This is required to meet the requirement that the storage account must not be reachable through its public endpoint.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, thinking both provide private IP access, but service endpoints only provide a public endpoint route through the VNet and do not block public internet access.

Practice this question →

MCQmedium

A VM-based application must connect to Azure SQL Database over a private IP inside the VNet. The SQL server name must resolve to that private IP, and public network access must remain disabled. What should the administrator deploy?

A.A service endpoint for Microsoft.Sql on the subnet.

B.A private endpoint for the SQL server and a private DNS zone linked to the VNet.

C.A user-defined route that points SQL traffic to the Internet.

D.An NSG rule that allows TCP 1433 from the subnet to Azure SQL.

AnswerB

Private endpoints place the PaaS service behind a private IP address in the virtual network. For name resolution to work correctly, the SQL server name must also resolve through a private DNS zone linked to the VNet. This design keeps public network access disabled while allowing the VM to reach Azure SQL entirely over private connectivity. It is the right fit when both private IP access and DNS integration are required.

Why this answer

A private endpoint assigns the Azure SQL Database a private IP from the VNet, ensuring traffic stays within the Microsoft backbone. A private DNS zone linked to the VNet allows the SQL server name (e.g., server.database.windows.net) to resolve to that private IP, meeting the requirement for name resolution. Public network access is disabled via the SQL server's firewall settings, which is a prerequisite for private endpoint connectivity.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, assuming both provide private IP connectivity, but service endpoints only provide source VNet identity and do not assign a private IP to the Azure service.

How to eliminate wrong answers

Option A is wrong because a service endpoint for Microsoft.Sql does not assign a private IP to the SQL server; it only extends the VNet's identity to the Azure SQL service, and the SQL server still uses a public endpoint, which cannot be used when public network access is disabled. Option C is wrong because a user-defined route pointing SQL traffic to the Internet would force traffic out to the public internet, violating the requirement for private IP connectivity and disabling public access. Option D is wrong because an NSG rule allowing TCP 1433 from the subnet to Azure SQL does not change the fact that the SQL server's public endpoint is used; it only controls firewall-level access, not private IP resolution or disabling public network access.

Practice this question →

MCQmedium

A web tier and an app tier run on separate Azure VMs in the same region. Each VM's NIC is added to an application security group named WebASG or AppASG. The administrator must allow only the web tier to connect to the app tier on TCP 8443, and future VM scale-outs must be included automatically. Which NSG rule should be created?

A.An inbound rule that uses the current web VM's private IP as the source and the current app VM's private IP as the destination.

B.An inbound rule with source WebASG, destination AppASG, protocol TCP, and destination port 8443.

C.A route table that sends TCP 8443 traffic from the web subnet to the app subnet.

D.An Azure Firewall application rule collection that permits all traffic between the two subnets.

AnswerB

Using application security groups is the best fit because the rule follows the role of the VM, not a fixed IP address. When new web or app VMs are added to their respective ASGs, the NSG rule automatically covers them. This provides least-privilege connectivity between tiers while keeping the configuration maintainable during scale-out and redeployment events.

Why this answer

Option B is correct because application security groups (ASGs) allow you to configure network security as a natural extension of an application's structure, enabling you to group VMs by their roles (e.g., web tier, app tier) and define rules based on those groups. By creating an inbound NSG rule with source WebASG and destination AppASG on TCP port 8443, any VM added to WebASG can initiate traffic to any VM in AppASG, and future scale-outs are automatically included without manual IP updates. This approach is dynamic, scalable, and aligns with the requirement for automatic inclusion of new VMs.

Exam trap

The trap here is that candidates often confuse network security groups (NSGs) with route tables, thinking that routing can enforce access control, or they default to using static IP addresses in NSG rules, missing the dynamic, group-based capability of application security groups that automatically includes new VMs.

How to eliminate wrong answers

Option A is wrong because it uses static private IP addresses as source and destination, which would require manual updates whenever VMs are added or removed during scale-outs, failing the 'future VM scale-outs must be included automatically' requirement. Option C is wrong because a route table controls the path traffic takes between subnets, not the security policy; it does not filter traffic based on port or protocol, and it cannot enforce that only the web tier can connect to the app tier on TCP 8443. Option D is wrong because an Azure Firewall application rule collection is designed for filtering outbound HTTP/HTTPS traffic based on FQDNs, not for controlling inbound inter-VM traffic within the same region; it is an over-engineered and costly solution that does not leverage the simpler, native ASG capability.

Practice this question →

100

MCQmedium

A web app in VNet1 must access a storage account by using a private IP address, and the storage account has public network access disabled. The app resolves the storage FQDN from inside the VNet. What should you deploy?

A.A service endpoint on the subnet so the storage account gets a private IP.

B.A private endpoint for the storage account and the required private DNS zone linkage.

C.A storage account firewall rule that allows the VNet and a public DNS record update.

D.A SAS token created for the application service principal.

AnswerB

A private endpoint gives the storage account a private IP address inside the virtual network, which is exactly what the scenario requires. Because the app must resolve the storage FQDN from within the VNet, private DNS is also needed so name resolution points to the private address instead of the public endpoint. This is the standard design for fully private access to Azure Storage.

Why this answer

A private endpoint assigns the storage account a private IP address from the VNet, enabling access via a private IP while public network access is disabled. The required private DNS zone linkage ensures the storage FQDN resolves to that private IP from within the VNet, meeting both requirements.

Exam trap

The trap here is confusing service endpoints (which only provide source VNet identity and no private IP) with private endpoints (which provide a true private IP and DNS resolution), leading candidates to choose option A incorrectly.

How to eliminate wrong answers

Option A is wrong because a service endpoint does not assign a private IP to the storage account; it only extends the VNet identity to the service, and the storage account still uses a public IP. Option C is wrong because a storage account firewall rule allows traffic from the VNet but does not provide a private IP, and a public DNS record update would not resolve to a private IP inside the VNet. Option D is wrong because a SAS token provides delegated access via the public endpoint, which is disabled, and does not involve private IP resolution or VNet integration.

Practice this question →

101

MCQmedium

Two virtual networks were created in different subscriptions. VNet-A uses 10.4.0.0/16 and VNet-B uses 10.4.128.0/17. You try to create peering between them, but Azure rejects the request. What is the best fix?

A.Enable gateway transit on both VNets before creating the peering.

B.Add a route table to one VNet so the address spaces no longer overlap.

C.Change one VNet to a non-overlapping address range, then create the peering again.

D.Create a private endpoint between the two VNets instead of peering.

AnswerC

Azure virtual network peering requires non-overlapping address spaces, so renumbering is the correct fix.

Why this answer

VNet peering requires that the address spaces of the two virtual networks do not overlap. VNet-A uses 10.4.0.0/16, which covers 10.4.0.0 to 10.4.255.255, and VNet-B uses 10.4.128.0/17, which falls entirely within that range (10.4.128.0 to 10.4.255.255). Azure rejects the peering because overlapping address spaces would cause routing conflicts.

The only correct fix is to change one VNet's address space to a non-overlapping range, then recreate the peering.

Exam trap

The trap here is that candidates may think adding a route table or enabling gateway transit can fix the overlap, but Azure enforces a strict non-overlapping address space requirement for VNet peering at the time of creation, and no routing configuration can bypass this fundamental constraint.

How to eliminate wrong answers

Option A is wrong because gateway transit is used to allow a peered VNet to use a VPN gateway in another VNet, and it does not resolve overlapping address spaces; overlapping ranges still prevent peering regardless of gateway settings. Option B is wrong because route tables (user-defined routes) control traffic flow within a VNet but cannot change the underlying address space of the VNet; the address space overlap remains, so peering is still rejected. Option D is wrong because a private endpoint provides private connectivity to a specific Azure service (e.g., Storage, SQL) and is not a substitute for VNet peering; it cannot connect two entire VNets together.

Practice this question →

102

MCQmedium

A company wants to peer a new spoke virtual network to an existing hub VNet. The hub uses 10.40.0.0/16, and the new spoke was created with 10.40.128.0/17 because that range seemed available in the branch office plan. Peering creation fails. What should the administrator do?

A.Add a second address prefix to the spoke VNet and keep the overlapping range.

B.Change the spoke VNet to a non-overlapping address space before peering.

C.Enable gateway transit on the hub VNet before retrying peering.

D.Create custom DNS records for the spoke VNet so the address ranges no longer conflict.

AnswerB

Azure VNet peering requires non-overlapping IP ranges. The spoke must use an address space that does not conflict with the hub or any connected network.

Why this answer

VNet peering requires that the address spaces of the peered virtual networks do not overlap. The hub uses 10.40.0.0/16, and the spoke uses 10.40.128.0/17, which is a subset of the hub’s range. Azure blocks peering when there is any overlap to prevent routing conflicts.

The correct fix is to change the spoke VNet to a non-overlapping address space, such as a different RFC 1918 range like 10.1.0.0/16, before attempting to peer.

Exam trap

The trap here is that candidates assume a subnet range like 10.40.128.0/17 is 'available' because it is not used by the hub’s subnets, but Azure VNet peering checks the entire VNet address space, not just the subnets, so any overlap at the VNet level causes failure.

How to eliminate wrong answers

Option A is wrong because adding a second address prefix to the spoke VNet does not resolve the overlap; Azure still sees the overlapping 10.40.128.0/17 range and will reject the peering, and overlapping address spaces cannot coexist in a peered topology. Option C is wrong because gateway transit is a feature that allows a spoke to use the hub’s VPN/ExpressRoute gateway, but it does not fix address space conflicts; peering will still fail due to overlapping ranges. Option D is wrong because custom DNS records are used for name resolution, not for routing or address space conflicts; overlapping IP ranges are a Layer 3 routing issue that DNS cannot resolve.

Practice this question →

103

MCQmedium

You create a private endpoint for an Azure Storage account. Virtual machines in VNet-App must resolve the storage account name to the private IP address of the endpoint. What should you configure?

A.A private DNS zone linked to VNet-App

B.A user-defined route on the subnet

C.An additional public IP address

D.An Azure Firewall policy

AnswerA

A private DNS zone provides the required private name resolution.

Why this answer

A private DNS zone linked to VNet-App is required because Azure Private Endpoint uses a private IP address from the virtual network, but the storage account's fully qualified domain name (FQDN) must resolve to that private IP within the VNet. By linking a private DNS zone (e.g., `privatelink.blob.core.windows.net`) to VNet-App and configuring an A record for the endpoint's private IP, VMs can resolve the storage account name to the correct private address. Without this, DNS resolution would fall back to the public IP, defeating the purpose of the private endpoint.

Exam trap

The trap here is that candidates often confuse network-level controls (like UDRs or firewalls) with DNS resolution, assuming they can force traffic to a private IP without configuring name resolution, but private endpoints require explicit DNS configuration to ensure the FQDN resolves to the private IP.

How to eliminate wrong answers

Option B is wrong because a user-defined route (UDR) controls network traffic flow (next-hop routing) at Layer 3, not DNS name resolution; it cannot map a hostname to an IP address. Option C is wrong because an additional public IP address is unrelated to private endpoint connectivity—private endpoints use private IPs, and adding a public IP would not influence DNS resolution within the VNet. Option D is wrong because an Azure Firewall policy governs traffic filtering and inspection, not DNS resolution; it does not create DNS records or manage name-to-IP mappings.

Practice this question →

104

MCQeasy

An administrator needs two non-overlapping VNets in the same region to communicate directly over private IP addresses without deploying a gateway. What should be configured?

A.VNet peering between the two virtual networks.

B.A site-to-site VPN gateway connection.

C.A service endpoint on both subnets.

D.A route table with default routes to each VNet.

AnswerA

VNet peering provides private, low-latency communication between virtual networks when their address spaces do not overlap.

Why this answer

VNet peering enables direct connectivity between two Azure virtual networks using private IP addresses across the Microsoft backbone, without requiring a gateway or public internet. It supports non-overlapping address spaces in the same region and provides low-latency, high-bandwidth communication. This matches the requirement exactly.

Exam trap

The trap here is that candidates confuse VNet peering with VPN gateways or service endpoints, assuming a gateway is always required for cross-VNet communication or that service endpoints can connect VNets, when in fact peering is the direct, gateway-free solution for private IP connectivity.

How to eliminate wrong answers

Option B is wrong because a site-to-site VPN gateway connection requires a VPN gateway in each VNet, incurs additional cost and latency, and is not needed for direct private IP communication within the same region. Option C is wrong because service endpoints extend a VNet's private address space to Azure PaaS services (like Storage or SQL), not to another VNet; they do not enable VNet-to-VNet traffic. Option D is wrong because route tables with default routes (0.0.0.0/0) direct traffic to a network virtual appliance or internet, not to another VNet; custom routes can influence traffic but cannot establish direct VNet-to-VNet connectivity without peering or a gateway.

Practice this question →

105

MCQmedium

An administrator is troubleshooting inbound HTTPS to a VM. The subnet NSG has these custom rules: Deny-Internet-Inbound at priority 150, Allow-HTTPS-Admin at priority 200, and the default deny rules remain in place. The administrator’s client is on the internet and should be able to reach the VM on TCP 443. What change will fix the problem?

A.Move the allow rule to a lower priority number than the deny rule.

B.Change the allow rule source from Internet to Any and keep the same priority.

C.Create a route table to the VM subnet so traffic reaches the VM faster.

D.Associate an application security group with the VM and leave the rules unchanged.

AnswerA

NSG rules are evaluated in priority order, and the lowest number wins. Because the deny rule at 150 is evaluated before the allow rule at 200, inbound HTTPS is blocked even though an allow rule exists. Making the allow rule higher priority than the deny rule, such as 100, lets the permitted traffic match first and be accepted.

Why this answer

The correct answer is A because Network Security Group (NSG) rules are evaluated in priority order, with lower numbers evaluated first. The Deny-Internet-Inbound rule at priority 150 is evaluated before the Allow-HTTPS-Admin rule at priority 200, so the deny rule blocks the inbound HTTPS traffic before the allow rule can be processed. Moving the allow rule to a lower priority number (e.g., 140) ensures it is evaluated first, permitting the traffic from the internet on TCP 443.

Exam trap

The trap here is that candidates often assume NSG rules are evaluated in the order they are listed or that allow rules automatically override deny rules, but Azure NSGs strictly evaluate by priority number, so a deny rule with a lower number will block traffic even if an allow rule with a higher number exists.

How to eliminate wrong answers

Option B is wrong because changing the source from 'Internet' to 'Any' does not change the priority evaluation order; the deny rule at priority 150 will still block the traffic regardless of the source. Option C is wrong because route tables control the path traffic takes through the network, not the filtering of traffic; they do not override NSG rules or fix the priority issue. Option D is wrong because associating an application security group (ASG) with the VM does not alter the priority of existing NSG rules; the deny rule at priority 150 will still be evaluated first and block the traffic.

Practice this question →

106

Multi-Selecteasy

A team wants an Azure VM in a subnet to reach a storage account securely without opening the account to the entire internet. Which two configuration choices can be used to achieve this? Select two.

Select 2 answers

A.Private endpoint

B.Service endpoint

C.Enable anonymous blob access

D.Move the account to the Archive tier

E.Apply a delete lock to the storage account

AnswersA, B

A private endpoint gives the storage account a private IP address in the virtual network.

Why this answer

Private endpoint (A) assigns a private IP address from the VM's subnet to the storage account, enabling secure connectivity over the Microsoft backbone network without exposing the account to the public internet. Service endpoint (B) extends the virtual network identity to the storage account via its public endpoint but restricts access to traffic originating from the specified subnet, also avoiding full internet exposure. Both options satisfy the requirement for secure, subnet-restricted access.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, thinking both are interchangeable, but service endpoints still use the storage account's public endpoint (just restricted by subnet), while private endpoints use a private IP from the subnet, making private endpoints the more secure choice for scenarios requiring complete isolation from the internet.

Practice this question →

107

MCQmedium

A route table contains these entries: 10.0.0.0/8 with next hop Virtual appliance, and 10.1.1.0/24 with next hop Virtual network gateway. Which next hop will Azure use for traffic to 10.1.1.5?

A.Virtual appliance, because the broader 10.0.0.0/8 route was created first.

B.Virtual network gateway, because the /24 route is more specific than the /8 route.

C.Internet, because Azure always prefers the default system route for public addresses.

D.None, because Azure ignores overlapping route entries in the same table.

AnswerB

The most specific matching prefix wins, so the /24 route takes precedence for 10.1.1.5.

Why this answer

Azure uses the most specific route prefix (longest prefix match) to determine the next hop for traffic. For destination 10.1.1.5, the route 10.1.1.0/24 (prefix length 24) is more specific than 10.0.0.0/8 (prefix length 8), so the next hop Virtual network gateway is selected, regardless of the order in which routes were created.

Exam trap

The trap here is that candidates mistakenly believe route creation order or the 'broader' route being created first determines priority, but Azure always uses the most specific prefix match, not the order of route entries.

How to eliminate wrong answers

Option A is wrong because Azure does not use route creation order to resolve overlapping routes; it always uses the longest prefix match (most specific route). Option C is wrong because the destination 10.1.1.5 is within the private IP range defined by the user-defined routes, and Azure does not fall back to the default Internet route when a more specific custom route exists. Option D is wrong because Azure does not ignore overlapping route entries; it evaluates them and selects the most specific match, and overlapping routes are allowed in the same route table.

Practice this question →

108

MCQhard

A storage account has a blob private endpoint in VNet-A. A VM in peered VNet-B can reach the storage account by private IP, but name resolution for the storage account still returns the public IP address. The private DNS zone privatelink.blob.core.windows.net is already linked only to VNet-A. What should the administrator do next?

A.Create a second private endpoint in VNet-B for the same storage account.

B.Enable a service endpoint on VNet-B and remove the private endpoint.

C.Add a user-defined route in VNet-B that points the storage FQDN to the private IP.

D.Create a virtual network link from the private DNS zone to VNet-B.

AnswerD

Private endpoint access depends on correct DNS resolution to the private endpoint IP. Because the private DNS zone is linked only to VNet-A, VNet-B does not receive the private name mapping. Linking the zone to VNet-B allows resources in the peered VNet to resolve the blob endpoint name to the private IP as intended.

Why this answer

The private DNS zone `privatelink.blob.core.windows.net` is linked only to VNet-A, so VMs in VNet-B cannot resolve the storage account's FQDN to its private IP. By creating a virtual network link from the private DNS zone to VNet-B, the zone's records become available for resolution in VNet-B, allowing the VM to resolve the storage FQDN to the private endpoint's IP address instead of the public IP.

Exam trap

The trap here is that candidates assume private endpoint connectivity alone ensures name resolution, but they forget that DNS resolution requires the private DNS zone to be linked to the peered VNet, not just the VNet where the endpoint resides.

How to eliminate wrong answers

Option A is wrong because creating a second private endpoint in VNet-B for the same storage account is unnecessary and would create duplicate endpoints; the existing private endpoint in VNet-A is already reachable via peering, and the issue is DNS resolution, not connectivity. Option B is wrong because enabling a service endpoint on VNet-B and removing the private endpoint would revert to public IP connectivity, defeating the purpose of private connectivity and introducing security risks. Option C is wrong because adding a user-defined route (UDR) in VNet-B that points the storage FQDN to the private IP is not how DNS resolution works; UDRs control traffic routing based on IP prefixes, not FQDN resolution, and cannot override DNS responses.

Practice this question →

109

MCQmedium

A storage account has public network access disabled. An application runs on a VM in a VNet and must access the storage account over a private IP address. The team also wants the storage name to resolve to a private address inside the VNet without changing application code. What should the administrator create?

A.A service endpoint on the subnet and a storage account firewall rule allowing that subnet.

B.A private endpoint for the storage account and a corresponding private DNS zone link.

C.An account SAS token with read/write permissions for the application.

D.Allow trusted Microsoft services to bypass the storage firewall.

AnswerB

A private endpoint places the storage service on a private IP inside the VNet, and DNS integration allows the storage FQDN to resolve to that private address. That combination meets both requirements: private connectivity and no application code changes. This is the standard pattern when public network access is disabled.

Why this answer

A private endpoint assigns the storage account a private IP from the VNet, making it accessible over a private IP address. A corresponding private DNS zone link (e.g., privatelink.blob.core.windows.net) ensures the storage account name resolves to that private IP inside the VNet without modifying application code, meeting both requirements.

Exam trap

The trap here is that candidates confuse service endpoints with private endpoints, assuming both provide private IP connectivity, when only private endpoints assign a private IP and require a private DNS zone for name resolution.

How to eliminate wrong answers

Option A is wrong because a service endpoint does not provide a private IP address; it only extends the VNet identity to the storage account over the public endpoint, so the storage name would still resolve to a public IP. Option C is wrong because an SAS token controls authentication and authorization, not network-level private IP connectivity or DNS resolution. Option D is wrong because allowing trusted Microsoft services bypasses the firewall but still uses the public endpoint and public IP, failing to provide private IP access and private DNS resolution.

Practice this question →

110

MCQmedium

After a private endpoint for an Azure Blob Storage account is created, VMs in the same VNet still resolve the storage name to the public IP address. The administrator wants the name to resolve to the private endpoint address instead. What should be configured?

A.Link the private DNS zone for blob storage to the virtual network.

B.Create a route table that sends storage traffic to the private endpoint subnet.

C.Enable a service endpoint on the subnet that hosts the VMs.

D.Assign a public IP address to the private endpoint subnet.

AnswerA

Private endpoints require private DNS so clients resolve the storage name to the endpoint's private IP instead of the public address. For Blob Storage, the relevant zone is the privatelink.blob.core.windows.net zone, and it must be linked to the VNet used by the clients. Once linked, Azure can answer DNS queries with the private endpoint address, which makes access work consistently without manual hosts file edits.

Why this answer

When a private endpoint is created for Azure Blob Storage, the private DNS zone (privatelink.blob.core.windows.net) must be linked to the virtual network to enable automatic resolution of the storage account's FQDN to the private endpoint's private IP address. Without this link, VMs in the VNet continue to use public DNS resolution, which returns the public IP. Linking the private DNS zone to the VNet ensures that DNS queries from VMs resolve to the private endpoint address via Azure's DNS infrastructure.

Exam trap

The trap here is that candidates often confuse network-level controls (like route tables or service endpoints) with DNS resolution, assuming they can redirect traffic to the private endpoint without addressing how the name is resolved to an IP.

How to eliminate wrong answers

Option B is wrong because a route table controls network traffic flow (next hop) but does not affect DNS name resolution; it cannot change how the storage account's FQDN resolves to an IP address. Option C is wrong because a service endpoint provides direct connectivity to Azure services over the Microsoft backbone but does not alter DNS resolution; the storage name would still resolve to the public IP unless a private DNS zone is linked. Option D is wrong because assigning a public IP address to the private endpoint subnet defeats the purpose of a private endpoint, which is to use a private IP from the VNet; it would not change DNS resolution behavior and would expose the endpoint publicly.

Practice this question →

111

MCQmedium

You have two virtual networks in the same Azure region named VNet-App and VNet-DB. Resources in the two networks must communicate privately over the Azure backbone without using VPN gateways. What should you configure?

A.Virtual network peering

B.A site-to-site VPN

C.A network security group

D.An Azure Firewall policy only

AnswerA

VNet peering enables private communication between the VNets over the Azure backbone.

Why this answer

Virtual network peering connects two Azure virtual networks in the same region via the Microsoft backbone infrastructure, enabling private IP communication without a VPN gateway or public internet. This is the correct solution because it meets the requirement for private, low-latency connectivity between VNet-App and VNet-DB using Azure's high-speed backbone.

Exam trap

The trap here is that candidates often confuse network security groups (NSGs) or Azure Firewall as connectivity solutions, when they are only security controls that require an existing network path (like peering) to function.

How to eliminate wrong answers

Option B is wrong because a site-to-site VPN requires a VPN gateway in each virtual network and routes traffic over the public internet or ExpressRoute, which adds latency and cost, and is unnecessary for intra-region peering. Option C is wrong because a network security group (NSG) is a stateful firewall that filters traffic at the subnet or NIC level but does not provide connectivity between virtual networks. Option D is wrong because an Azure Firewall policy alone cannot establish network connectivity; it is a security rule set applied to Azure Firewall, which itself requires a gateway or peering to route traffic between VNets.

Practice this question →

112

MCQmedium

An operations team wants device-generated log messages collected centrally so engineers can review interface changes, warnings, and errors from one place. Which technology is most directly associated with that goal?

A.Syslog

B.NetFlow

C.DHCP relay

D.Port security

AnswerA

This is correct because Syslog is used for centralized event and log reporting.

Why this answer

Syslog (A) is the standard protocol for collecting and centralizing log messages from network devices, servers, and other infrastructure. It allows engineers to forward interface changes, warnings, and errors to a central syslog server, enabling unified review and alerting. This directly matches the goal of centralized device-generated log collection.

Exam trap

The trap here is that candidates confuse NetFlow (traffic flow analysis) with syslog (log message collection), because both involve network monitoring, but NetFlow does not capture device-generated log messages like interface changes or errors.

Why the other options are wrong

NetFlow is primarily used for monitoring and analyzing network traffic rather than collecting log messages. It provides flow data but does not centralize log messages for review.

DHCP relay is primarily used to forward DHCP packets between clients and servers across different subnets, not for collecting log messages. It does not provide centralized logging capabilities for interface changes, warnings, or errors.

Port security is a feature used to control access to a switch port by limiting the devices that can connect, but it does not collect or centralize log messages for review. It focuses on securing network access rather than log management.

Practice this question →

113

MCQmedium

A company has a virtual machine in a subnet that must access an Azure Storage account. The storage account should remain reachable through its public endpoint, but access must be limited to that subnet, and the traffic should stay on the Azure backbone rather than the internet. Which feature should the administrator configure on the subnet?

A.A private endpoint for the storage account.

B.A service endpoint for Microsoft.Storage.

C.A site-to-site VPN connection to the storage account.

D.An application security group assigned to the storage account.

AnswerB

A service endpoint extends the subnet's identity to the storage service and keeps traffic on the Azure backbone while still using the storage account's public endpoint. This fits when the organization wants network restriction by subnet without introducing a private IP for the service. The storage firewall can then allow only the selected subnet.

Why this answer

A service endpoint for Microsoft.Storage extends the virtual network identity to the storage account, allowing traffic from the subnet to the storage account's public endpoint to be routed over the Azure backbone network rather than the internet. This satisfies the requirement to limit access to the subnet while keeping the public endpoint reachable and traffic within Azure's infrastructure.

Exam trap

The trap here is that candidates often confuse private endpoints with service endpoints, mistakenly thinking a private endpoint is required to keep traffic on the Azure backbone, but a private endpoint removes public endpoint access, whereas a service endpoint preserves it while still routing traffic internally.

How to eliminate wrong answers

Option A is wrong because a private endpoint assigns a private IP address to the storage account within the virtual network, which removes access through the public endpoint entirely, contradicting the requirement that the storage account remain reachable through its public endpoint. Option C is wrong because a site-to-site VPN connection is used to connect on-premises networks to Azure, not to restrict access from a specific subnet to a PaaS service while preserving public endpoint access. Option D is wrong because an application security group is a logical grouping of virtual machines for network security policy enforcement, not a feature that can be assigned to a storage account or that controls network-level access to Azure PaaS services.

Practice this question →

114

MCQmedium

A spoke VM can connect to a hub VM by IP address after peering is configured, but it cannot resolve internal host names such as app01.corp.local. The hub has a DNS server at 10.50.1.4 that hosts those records. What should the administrator configure so the spoke VMs use that DNS server?

A.Add an NSG rule allowing UDP and TCP port 53 between the VNets.

B.Set the spoke VNet's custom DNS server to 10.50.1.4.

C.Create a private endpoint for the hub DNS server.

D.Enable remote gateways on the spoke peering.

AnswerB

The spoke VNet must be told to use the DNS server that contains the internal zone records. By configuring 10.50.1.4 as the custom DNS server for the spoke VNet, new and existing VMs in that VNet can query the hub-based resolver for names such as app01.corp.local. Peering alone does not change DNS behavior, so the DNS server setting is the missing configuration.

Why this answer

Option B is correct because the spoke VNet must be configured to use a custom DNS server to override Azure's default internal name resolution. By setting the spoke VNet's DNS server to 10.50.1.4, all VMs in the spoke will query that server for hostname resolution, including app01.corp.local. This is a VNet-level setting that applies to all VMs in the spoke, and it does not require any changes to NSGs or peering configurations.

Exam trap

The trap here is that candidates often confuse VNet peering with DNS resolution, assuming that peering automatically enables name resolution across VNets, when in fact you must explicitly configure a custom DNS server or use Azure Private DNS Zones to resolve private hostnames.

How to eliminate wrong answers

Option A is wrong because NSG rules control traffic filtering, not DNS resolution configuration; UDP/TCP port 53 may already be allowed by default in VNet peering, and the issue is that the spoke VMs do not know which DNS server to query, not that traffic is blocked. Option C is wrong because a private endpoint is used to securely connect to Azure PaaS services (e.g., Azure SQL, Storage) over a private IP, not to redirect DNS queries from a VNet to a custom DNS server. Option D is wrong because enabling remote gateways on the spoke peering allows the spoke to use the hub's VPN/ExpressRoute gateway for outbound connectivity, but it does not configure the spoke's DNS resolver to point to the hub's DNS server.

Practice this question →

115

MCQhard

You are planning a subnet for an application tier in a new spoke virtual network. The subnet must support 34 VM NICs, 5 private endpoints, and 6 extra IP addresses for short-term scale-out during maintenance windows. Azure reserves 5 IP addresses in every subnet. What is the smallest subnet prefix that meets the requirement?

A./27

B./26

C./25

D./28

AnswerB

A /26 provides 59 usable addresses after Azure reservations, which covers all required and buffer IPs.

Why this answer

The subnet must support 34 VM NICs, 5 private endpoints, and 6 extra IPs for scale-out, totaling 45 required IPs. Azure reserves 5 IP addresses in every subnet (first 4 and last 1). Therefore, the subnet needs at least 50 usable IP addresses.

A /26 subnet provides 64 total IPs, of which 59 are usable (64 - 5), meeting the requirement. /27 provides only 32 total IPs (27 usable), which is insufficient.

Exam trap

The trap here is that candidates often forget to add the 5 Azure-reserved IPs to the total requirement, leading them to incorrectly select /27 (thinking 34+5+6=45 fits in 32 usable IPs) or /28 (underestimating the scale-out need).

How to eliminate wrong answers

Option A is wrong because a /27 subnet provides only 32 total IP addresses (27 usable after Azure's 5 reserved IPs), which is less than the required 50 IPs. Option C is wrong because a /25 subnet provides 128 total IPs (123 usable), which far exceeds the requirement but is not the smallest prefix that meets it. Option D is wrong because a /28 subnet provides only 16 total IPs (11 usable), which is far too small for the 50 IPs needed.

Practice this question →

116

MCQmedium

A hub VNet already has a VPN gateway connected to on-premises. A spoke VNet in the same region must reach on-premises networks through that existing gateway, and you do not want to deploy a separate VPN gateway in the spoke. What peering settings should you use?

A.Create peering only; the spoke will automatically use the hub gateway without extra settings.

B.Enable Use remote gateways on the hub peering and Allow gateway transit on the spoke peering.

C.Enable Allow gateway transit on the hub peering and Use remote gateways on the spoke peering.

D.Create a service endpoint from the spoke VNet to the on-premises network.

AnswerC

In a hub-spoke design, the hub VNet that owns the VPN gateway must allow gateway transit, and the spoke must be configured to use the remote gateway. This lets the spoke route on-premises traffic through the hub without deploying its own gateway. The direction of these settings matters, and reversing them breaks the design.

Why this answer

Option C is correct because to enable a spoke VNet to use a hub VNet's VPN gateway for on-premises connectivity without deploying a separate gateway, you must configure the hub peering with 'Allow gateway transit' and the spoke peering with 'Use remote gateways'. This allows the spoke to route traffic through the hub's VPN gateway, leveraging the existing site-to-site VPN connection to on-premises.

Exam trap

The trap here is confusing which peering direction gets which setting: candidates often mistakenly enable 'Use remote gateways' on the hub side and 'Allow gateway transit' on the spoke side, which is the reverse of the correct configuration.

How to eliminate wrong answers

Option A is wrong because simply creating a peering does not automatically enable gateway transit; the spoke VNet would not have a route to the hub's VPN gateway without explicit settings. Option B is wrong because it reverses the required settings: 'Use remote gateways' must be on the spoke peering (not the hub), and 'Allow gateway transit' must be on the hub peering (not the spoke). Option D is wrong because a service endpoint provides private connectivity to Azure PaaS services (like Azure Storage or SQL Database) over the Microsoft backbone, not to on-premises networks via a VPN gateway.

Practice this question →

117

MCQhard

Third-party support engineers connect from the public internet and need browser-based RDP and SSH access to Azure VMs that have only private IPs. The security team will not allow public IPs on the VMs, inbound 3389 or 22 from the internet, or a client VPN on each laptop. What should you deploy?

A.Azure Bastion

B.VPN Gateway with point-to-site configuration

C.A public load balancer with inbound NAT rules

D.A NAT gateway attached to the VM subnet

AnswerA

Azure Bastion provides secure browser-based RDP and SSH access without exposing the VMs to public IP-based inbound traffic.

Why this answer

Azure Bastion provides secure, seamless browser-based RDP and SSH connectivity to Azure VMs directly from the Azure portal over TLS, without requiring public IPs on the VMs or exposing inbound RDP/SSH ports (3389/22) to the internet. It uses a hardened bastion host deployed in a dedicated subnet, which brokers the connection via the Azure portal, satisfying the security team's constraints of no public IPs on VMs, no inbound internet access to those ports, and no client VPN software.

Exam trap

The trap here is that candidates often confuse Azure Bastion with a NAT gateway or VPN Gateway, mistakenly thinking any 'gateway' solution provides inbound RDP/SSH access, but Bastion is the only option that delivers browser-based connectivity without public IPs, client VPNs, or open inbound ports.

How to eliminate wrong answers

Option B (VPN Gateway with point-to-site configuration) is wrong because it requires installing a VPN client on each laptop, which the security team explicitly prohibits, and it still relies on the VMs having private IPs but does not inherently block inbound RDP/SSH from the internet if misconfigured. Option C (A public load balancer with inbound NAT rules) is wrong because it requires public IPs on the load balancer and inbound NAT rules that map to RDP/SSH ports on the VMs, directly violating the 'no inbound 3389 or 22 from the internet' rule. Option D (A NAT gateway attached to the VM subnet) is wrong because a NAT gateway only provides outbound internet connectivity for VMs (source network address translation), not inbound RDP/SSH access from the internet.

Practice this question →

118

MCQmedium

An NSG is associated with a subnet. It contains these inbound rules: - Priority 100: Deny TCP 443 from Internet to Any - Priority 200: Allow TCP 443 from 203.0.113.0/24 to Any A tester at 203.0.113.10 browses to the VM's HTTPS endpoint in that subnet. What happens?

A.The request is allowed because the more specific source range matches first.

B.The request is denied because the priority 100 deny rule matches before the allow rule.

C.The request is denied only if the VM has no public IP address.

D.The request is allowed because default NSG rules always override custom rules.

AnswerB

Azure NSGs evaluate rules by priority, and the lowest number is processed first. Both rules match this HTTPS traffic, but the deny rule at priority 100 is considered before the allow rule at priority 200. Because the first match wins, the packet is blocked even though the source is in the allowed range.

Why this answer

The correct answer is B. Network Security Group (NSG) rules are evaluated in priority order, from lowest to highest numeric value. The priority 100 rule explicitly denies TCP 443 from the Internet (which includes the 203.0.113.0/24 range), and it is evaluated before the priority 200 allow rule.

Since the deny rule matches first, the traffic is blocked regardless of the more specific source IP in the allow rule.

Exam trap

The trap here is that candidates mistakenly believe NSG rules are evaluated based on the specificity of the source or destination (like a firewall with longest-prefix matching), but Azure NSGs strictly use priority-based evaluation where lower numeric priority wins.

How to eliminate wrong answers

Option A is wrong because NSG rules are processed by priority number, not by specificity of the source range; a lower priority number (100) is evaluated before a higher one (200), so the deny rule matches first. Option C is wrong because NSG rules apply to traffic destined for any VM in the subnet, regardless of whether the VM has a public IP address; the NSG filters traffic at the subnet level before it reaches the VM. Option D is wrong because default NSG rules have higher priority numbers (65000 and above) and are evaluated after custom rules; custom rules always take precedence over default rules when they match.

Practice this question →

119

MCQhard

A subnet has a user-defined route for 0.0.0.0/0 that sends traffic to a network virtual appliance at 10.1.0.4. The same virtual network is peered to a hub VNet that has a system route for 10.50.16.0/20. A VM in the subnet sends traffic to 10.50.18.25. Which next hop will Azure use?

A.Internet, because the default route overrides more specific routes.

B.Network virtual appliance at 10.1.0.4, because user-defined routes always win over system routes.

C.Virtual network peering, because the /20 peering route is more specific than 0.0.0.0/0.

D.None, because Azure disables routing when a subnet has both peering and a UDR.

AnswerC

Azure first selects the most specific matching prefix. The destination 10.50.18.25 falls inside the /20 peering route, which is more specific than the 0.0.0.0/0 forced-tunneling route. Because the longest prefix wins, traffic is sent over the peering path rather than to the NVA or the internet.

Why this answer

Azure uses the most specific route (longest prefix match) to determine next hop. The destination 10.50.18.25 falls within the 10.50.16.0/20 range of the peering route, which is more specific than the 0.0.0.0/0 UDR. Therefore, the traffic is routed via the virtual network peering, not the NVA.

Exam trap

The trap here is that candidates assume user-defined routes always override system routes, but Azure uses longest prefix match first, so a more specific system route (like a peering route) will take precedence over a less specific UDR.

How to eliminate wrong answers

Option A is wrong because Azure does not use the default route (0.0.0.0/0) when a more specific route (10.50.16.0/20) exists; longest prefix match applies. Option B is wrong because user-defined routes do not always win over system routes; route specificity takes precedence, and the peering route is a system route with a longer prefix. Option D is wrong because Azure does not disable routing when both peering and a UDR exist; it evaluates all routes and selects the most specific match.

Practice this question →

120

MCQmedium

An NSG attached to a subnet contains these inbound rules: Deny-All-Inbound at priority 200, Allow-HTTPS-Admin at priority 250 from 203.0.113.20/32, and Allow-HTTPS-Internet at priority 300. A VM in the subnet cannot receive HTTPS from the admin workstation even though the source IP is correct. What should the administrator change?

A.Change the protocol from TCP to Any on the allow rule.

B.Move the Allow-HTTPS-Admin rule to a priority number lower than 200.

C.Associate a NAT gateway with the subnet.

D.Enable service endpoint policies on the subnet.

AnswerB

NSG rules are processed in priority order, and the lowest number wins. Because Deny-All-Inbound is at priority 200, it is evaluated before the allow rule at 250 and blocks the traffic. Moving the allow rule to a smaller number than 200 lets the admin workstation's HTTPS traffic match the allow rule first.

Why this answer

The Deny-All-Inbound rule at priority 200 blocks all traffic, including HTTPS from the admin workstation, because NSG rules are evaluated in priority order (lowest number first). The Allow-HTTPS-Admin rule at priority 250 is never reached since the deny rule with a higher priority (lower number) matches first. To allow the admin traffic, the allow rule must have a priority lower than 200 (e.g., 150) so it is evaluated before the deny rule.

Exam trap

The trap here is that candidates assume a higher priority number means higher precedence, but in Azure NSGs, a lower numeric priority value (e.g., 200) is evaluated before a higher one (e.g., 250), so the deny rule blocks the traffic before the allow rule is checked.

How to eliminate wrong answers

Option A is wrong because changing the protocol from TCP to Any would not bypass the priority issue; the Deny-All-Inbound rule at priority 200 still blocks all traffic regardless of protocol. Option C is wrong because a NAT gateway provides outbound internet connectivity for a subnet, not inbound access control, and does not affect NSG rule evaluation. Option D is wrong because service endpoint policies secure outbound traffic to Azure services (e.g., Storage, SQL) and do not influence inbound NSG rule priority or allow inbound HTTPS traffic.

Practice this question →

121

Multi-Selecthard

Two virtual networks are in different subscriptions. VNet-A uses 10.20.0.0/16 and VNet-B uses 10.20.128.0/17. A design review also states that traffic between two spoke VNets should flow through a hub VNet instead of directly between spokes. Which two statements are correct? Select two.

Select 2 answers

A.The two VNets cannot be peered until one address space is changed because the ranges overlap.

B.VNet peering is transitive, so spoke-to-spoke traffic will automatically use the hub peering.

C.To reach another spoke through the hub, you need an explicit design such as gateway transit or routing controls.

D.Overlapping CIDR blocks are allowed if the VNets are placed in separate resource groups.

E.If the hub has a VPN gateway, spoke traffic to other spokes is routed automatically without additional configuration.

AnswersA, C

Azure peering does not allow overlapping address spaces, even across subscriptions.

Why this answer

Option A is correct because VNet peering in Azure requires that the address spaces of the peered VNets do not overlap. VNet-A uses 10.20.0.0/16 and VNet-B uses 10.20.128.0/17, which are overlapping ranges (10.20.128.0/17 is a subset of 10.20.0.0/16). Azure will reject the peering request until one of the address spaces is changed to eliminate the overlap.

Exam trap

The trap here is that candidates often assume VNet peering is transitive (like in some other cloud providers) or that a VPN gateway automatically routes spoke-to-spoke traffic, but Azure requires explicit routing configuration for transitive traffic through a hub.

Practice this question →

122

MCQeasy

Based on the exhibit, what inbound NSG rule should the administrator add to allow only the web tier to reach the app tier on TCP 8080?

A.Source: WebASG, Destination: AppASG, Protocol: TCP, Port: 8080, Priority: 250

B.Source: Internet, Destination: VirtualNetwork, Protocol: TCP, Port: 8080, Priority: 250

C.Source: AppASG, Destination: WebASG, Protocol: TCP, Port: 8080, Priority: 250

D.Source: WebASG, Destination: AppASG, Protocol: TCP, Port: 8080, Priority: 350

AnswerA

This rule uses application security groups to target the web tier and app tier precisely. Priority 250 is evaluated before the deny rule at 300, so the allowed web-to-app traffic can pass while everything else remains blocked.

Why this answer

Option A is correct because the inbound NSG rule must allow traffic from the web tier (source: WebASG) to the app tier (destination: AppASG) on TCP port 8080. A priority of 250 is lower than the default rules (65000+) and ensures this rule is evaluated before any higher-numbered deny rules, while being high enough to leave room for more specific rules if needed.

Exam trap

The trap here is that candidates often confuse the source and destination in NSG rules, mistakenly thinking the rule should allow the app tier to receive traffic from the web tier by setting the source to AppASG and destination to WebASG, which is the reverse of the required direction.

How to eliminate wrong answers

Option B is wrong because it sets the source to 'Internet' and destination to 'VirtualNetwork', which would allow any internet traffic to reach any VM in the virtual network on TCP 8080, not just the web tier to the app tier. Option C is wrong because it reverses the source and destination (AppASG to WebASG), which would allow the app tier to initiate connections to the web tier on TCP 8080, opposite of the requirement. Option D is wrong because it uses a priority of 350, which is higher than the default deny rule (65000) but still lower than the default allow rules; however, the question does not specify a need for a specific priority value, and 250 is a more common choice for custom rules, but the key issue is that priority 350 is not inherently wrong—the trap is that the question expects the lowest possible priority number to ensure evaluation order, but 250 is acceptable; however, the correct answer must match the exhibit's implied priority range, and 350 is too high to guarantee precedence over other potential rules.

Practice this question →

123

MCQmedium

Two VNets are peered successfully, and a VM in the spoke can reach a private endpoint in the hub by IP address. However, the VM cannot resolve the storage account name to the private endpoint FQDN. The private DNS zone is linked only to the hub VNet. What should the administrator do?

A.Add a route table to the spoke subnet pointing to the private endpoint IP.

B.Link the private DNS zone to the spoke VNet as well.

C.Enable gateway transit on the peering connection.

D.Create an NSG rule to allow DNS traffic to the storage account.

AnswerB

Private DNS zones must be linked to every VNet that needs to resolve the private endpoint name through Azure-provided DNS behavior. Since the spoke VNet is not linked to the zone, its VM does not receive the private endpoint record and cannot resolve the storage account FQDN correctly. Linking the zone to the spoke VNet allows name resolution to return the private IP.

Why this answer

The VM can reach the private endpoint by IP, confirming that network connectivity (peering and routing) is working. However, name resolution fails because the private DNS zone, which contains the private endpoint FQDN mapping, is linked only to the hub VNet. By linking the private DNS zone to the spoke VNet (option B), the spoke VMs will use Azure-provided DNS to resolve the storage account name to the private IP, enabling seamless name resolution across the peered VNets.

Exam trap

The trap here is that candidates often assume that VNet peering automatically extends DNS resolution for private endpoints, but in reality, each VNet must be explicitly linked to the private DNS zone for name resolution to work across the peering.

How to eliminate wrong answers

Option A is wrong because adding a route table to the spoke subnet pointing to the private endpoint IP would force traffic to the private endpoint IP for all destinations, which is unnecessary and could break routing; the issue is DNS resolution, not routing. Option C is wrong because gateway transit is used to allow a spoke VNet to use a VPN gateway or ExpressRoute gateway in the hub VNet, which is unrelated to DNS resolution of private endpoints. Option D is wrong because an NSG rule to allow DNS traffic to the storage account is irrelevant; DNS queries are sent to Azure's DNS resolver (168.63.129.16) or a custom DNS server, not directly to the storage account, and the storage account itself does not serve DNS.

Practice this question →

124

MCQmedium

A VM in a spoke subnet must send all traffic destined for 172.16.0.0/12 to a firewall appliance at 10.1.1.4. All other destinations should continue to use Azure system routes. Which user-defined route should the administrator add to the subnet route table?

A.Destination 0.0.0.0/0 with next hop Internet.

B.Destination 172.16.0.0/12 with next hop Virtual appliance and next hop address 10.1.1.4.

C.Destination 172.16.0.0/12 with next hop Virtual network gateway.

D.Destination 172.16.0.0/12 with next hop None.

AnswerB

A UDR should match the exact destination prefix that must be redirected. By adding 172.16.0.0/12 with next hop type Virtual appliance and the firewall private IP, Azure sends only that traffic to the appliance. All other traffic continues to follow the built-in system routes.

Why this answer

Option B is correct because a user-defined route (UDR) with destination 172.16.0.0/12 and next hop type 'Virtual appliance' (with IP 10.1.1.4) overrides the default Azure system route for that prefix, forcing all traffic to the 172.16.0.0/12 range through the firewall at 10.1.1.4. This satisfies the requirement while leaving all other destinations (including 0.0.0.0/0) to be handled by Azure's default system routes.

Exam trap

The trap here is that candidates often confuse the 'Virtual appliance' next hop with 'Virtual network gateway' or assume a default route (0.0.0.0/0) is needed, but the requirement specifically limits the forced tunneling to only the 172.16.0.0/12 range, not all traffic.

How to eliminate wrong answers

Option A is wrong because a 0.0.0.0/0 route with next hop Internet would send all traffic (including 172.16.0.0/12) to the internet, bypassing the firewall entirely. Option C is wrong because next hop 'Virtual network gateway' is used for VPN or ExpressRoute traffic, not for directing traffic to a firewall appliance; it would route the 172.16.0.0/12 traffic to a gateway instead of the firewall. Option D is wrong because next hop 'None' drops all traffic destined for 172.16.0.0/12, which does not meet the requirement to send it to the firewall.

Practice this question →

125

MCQeasy

Based on the exhibit, which subnet prefix should be used for Subnet A so it can support about 30 VM NICs?

A./28

B./27

C./26

D./25

AnswerC

A /26 subnet is the smallest option listed that can support about 30 VM NICs after Azure reserves its five addresses. /26 provides 64 total addresses and enough usable IPs for the requirement, leaving a little room for growth. This is the most efficient choice among the options shown.

Why this answer

Option C (/26) is correct because a /26 subnet provides 64 IP addresses (2^(32-26) = 64), of which 62 are usable for VM NICs after reserving the network address and broadcast address. This comfortably supports about 30 VM NICs while leaving room for growth.

Exam trap

The trap here is that candidates often forget Azure reserves five IP addresses per subnet (not just the network and broadcast), leading them to incorrectly choose /27 thinking 30 usable IPs are enough, when in reality only 25 are available.

How to eliminate wrong answers

Option A (/28) is wrong because a /28 subnet provides only 16 IP addresses total, with 14 usable — far too few for about 30 VM NICs. Option B (/27) is wrong because a /27 subnet provides 32 IP addresses total, with 30 usable — this exactly matches the requirement but leaves no room for growth or Azure reserved addresses (Azure reserves the first four and last address in each subnet), reducing usable IPs to 27, which is insufficient. Option D (/25) is wrong because a /25 subnet provides 128 IP addresses total, with 126 usable — this is excessive for supporting about 30 VM NICs and wastes IP address space.

Practice this question →

126

MCQhard

A storage account must remain reachable through its public endpoint for an on-premises integration server, but only one Azure subnet should be allowed to access it from Azure. The team does not want private endpoints or DNS changes. What should the administrator configure?

A.Add a private endpoint and disable public network access

B.Enable a service endpoint on the subnet and add that subnet to the storage account networking rules

C.Create a SAS token restricted to that subnet

D.Assign Storage Blob Data Reader to the subnet

AnswerB

A service endpoint lets traffic from the chosen Azure subnet reach the storage account over the Microsoft backbone while still using the account's public endpoint. Adding the subnet to the storage account firewall rules then restricts Azure access to only that subnet. This meets the requirement to keep public access available for the on-premises integration server while tightly limiting Azure-based access without private endpoints or DNS changes.

Why this answer

Option B is correct because a service endpoint extends the virtual network identity to the storage account, allowing you to restrict access to a specific subnet while keeping the public endpoint enabled for on-premises access. This meets the requirement of allowing only one Azure subnet to access the storage account from Azure without using private endpoints or DNS changes.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, assuming that service endpoints require disabling public access or that private endpoints are the only way to restrict subnet access, when in fact service endpoints allow selective subnet access while keeping the public endpoint active.

How to eliminate wrong answers

Option A is wrong because adding a private endpoint and disabling public network access would block the on-premises integration server from reaching the storage account via its public endpoint, which contradicts the requirement. Option C is wrong because a SAS token restricts access based on the token's permissions and expiry, not by subnet; SAS tokens cannot restrict access to a specific Azure subnet. Option D is wrong because assigning Storage Blob Data Reader to a subnet is not a valid configuration; Azure RBAC roles are assigned to identities (users, groups, service principals), not to subnets.

Practice this question →

127

MCQmedium

A storage account must be reachable only from a single Azure VNet. The team wants the storage account to have a private IP in that VNet and wants to disable public network access. Which solution should the administrator implement?

A.Configure a service endpoint on the subnet and keep public network access enabled.

B.Create a private endpoint for the storage account and disable public network access.

C.Assign a shared access signature and rely on IP-based firewall rules.

D.Use a route table to force traffic to the storage account over the virtual network gateway.

AnswerB

A private endpoint places a private IP address in the VNet for the storage service, allowing traffic to stay on the private network path. Disabling public network access ensures the service cannot be reached through its public endpoint.

Why this answer

A private endpoint assigns the storage account a private IP from the VNet, making it accessible only within that VNet over a private connection. Disabling public network access ensures no traffic can reach the storage account from the internet, meeting both requirements. This is the only option that provides a private IP and blocks all public access.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, assuming a service endpoint provides a private IP, when in fact it only provides a public endpoint with a VNet source identity.

How to eliminate wrong answers

Option A is wrong because a service endpoint does not assign a private IP to the storage account; it only extends the VNet identity to the service via public endpoints, and keeping public network access enabled violates the requirement to disable public access. Option C is wrong because a shared access signature (SAS) provides delegated access via the public endpoint, and IP-based firewall rules still rely on the public endpoint, neither of which gives the storage account a private IP or disables public network access. Option D is wrong because a route table with forced tunneling over a virtual network gateway does not assign a private IP to the storage account and does not disable public network access; it only influences traffic routing, not the storage account's accessibility.

Practice this question →

128

MCQmedium

A hub VNet is peered to two spoke VNets. The spokes can reach the hub, but they cannot communicate with each other through the hub. The administrator wants centralized inspection in the hub. What should be deployed and configured?

A.An Azure Firewall or other NVA in the hub, plus user-defined routes and forwarding support.

B.Only additional peering links between the hub and both spokes.

C.A private endpoint in the hub for each spoke subnet.

D.A service endpoint on each spoke subnet to the hub VNet.

AnswerA

Peering is non-transitive, so centralized inspection requires a forwarder and explicit routing.

Why this answer

Option A is correct because Azure Firewall or an NVA in the hub can inspect traffic between spokes, but by default, Azure routing does not forward spoke-to-spoke traffic through the hub. To force this traffic through the firewall, you must configure user-defined routes (UDRs) on the spoke subnets with a next hop of the firewall's private IP, and enable IP forwarding on the NVA. This setup enables centralized inspection and transitive routing through the hub.

Exam trap

The trap here is that candidates assume VNet peering is transitive by default, similar to a router, but Azure explicitly requires UDRs and a forwarding device to enable spoke-to-spoke communication through a hub.

How to eliminate wrong answers

Option B is wrong because adding more peering links between the hub and spokes does not enable transitive routing; VNet peering is non-transitive by default, so spokes cannot communicate through the hub without explicit routes. Option C is wrong because a private endpoint in the hub provides private connectivity to a specific Azure service (e.g., Storage, SQL) from spoke subnets, but it does not route general IP traffic between spokes or enable inspection. Option D is wrong because a service endpoint extends a VNet's identity to an Azure service over the Microsoft backbone, but it does not route traffic between VNets or provide any forwarding or inspection capability.

Practice this question →

129

MCQmedium

A private endpoint was created for Azure SQL Database in VNet A. A VM in peered VNet B can reach other resources, but it resolves the SQL server name to the public IP and connection attempts fail because public network access is disabled. What is the best fix?

A.Add an outbound NSG rule allowing TCP 1433 to the internet.

B.Link the appropriate private DNS zone to VNet B.

C.Assign a public IP address to the private endpoint.

D.Replace the private endpoint with a service endpoint.

AnswerB

Clients in VNet B must resolve the SQL server name to the private endpoint address. Linking the private DNS zone to VNet B allows the VM to receive the correct private IP mapping through DNS.

Why this answer

When public network access is disabled on an Azure SQL Database, the private endpoint in VNet A provides a private IP address for the SQL server. However, for VMs in peered VNet B to resolve the SQL server's fully qualified domain name (FQDN) to that private IP instead of the public IP, the private DNS zone (typically `privatelink.database.windows.net`) must be linked to VNet B. Without this link, DNS resolution falls back to the public IP, causing connection failures because public access is disabled.

Exam trap

The trap here is that candidates assume DNS resolution works automatically across peered VNets, but private DNS zones are not transitive and must be explicitly linked to each peered VNet for private IP resolution to succeed.

How to eliminate wrong answers

Option A is wrong because adding an outbound NSG rule allowing TCP 1433 to the internet does not fix DNS resolution; the VM already can reach other resources, and the issue is that the SQL server name resolves to a public IP, which is unreachable due to disabled public network access. Option C is wrong because a private endpoint does not use a public IP address; assigning a public IP to it would break the private connectivity model and is not supported. Option D is wrong because replacing the private endpoint with a service endpoint would expose the SQL server to the entire VNet B via its public IP (though over the Azure backbone), but public network access is disabled, so service endpoints would also fail; moreover, service endpoints do not provide private IP resolution and lack the network isolation that private endpoints offer.

Practice this question →

130

MCQhard

You create a private endpoint for an Azure Storage account and disable public network access on the account. A VM in a peered VNet cannot reach the storage account by name. The private endpoint resides in VNet-App. What is the most likely missing configuration?

A.A private DNS zone linked so the relevant VNet can resolve the storage account to the private endpoint IP

B.An NSG rule allowing outbound DNS to 8.8.8.8

C.A Recovery Services vault in the peered VNet

D.A public IP address on the private endpoint NIC

AnswerA

Without correct DNS integration, clients continue resolving the public name instead of the private endpoint address.

Why this answer

When you create a private endpoint for an Azure Storage account and disable public network access, the storage account's public DNS name must resolve to the private endpoint's private IP address within the VNet. This requires a private DNS zone (privatelink.blob.core.windows.net) linked to the VNet where the VM resides. Without that DNS zone link, the VM in the peered VNet will resolve the storage account name to the public IP, which is unreachable because public access is disabled, causing the connection failure.

Exam trap

The trap here is that candidates assume VNet peering automatically extends DNS resolution for private endpoints, but Azure requires explicit private DNS zone links to each VNet that needs to resolve the private endpoint name.

How to eliminate wrong answers

Option B is wrong because outbound DNS to 8.8.8.8 is not required; Azure VMs use Azure DNS (168.63.129.16) by default, and the issue is DNS resolution to the private endpoint IP, not internet DNS access. Option C is wrong because a Recovery Services vault is unrelated to private endpoint connectivity; it is used for backup and disaster recovery, not for network name resolution. Option D is wrong because a private endpoint NIC does not use a public IP address; it is assigned a private IP from the VNet subnet, and adding a public IP would defeat the purpose of a private endpoint.

Practice this question →

131

MCQmedium

A team is creating a new spoke VNet that will later be peered to an existing hub VNet and connected to on-premises networks. The proposed address space for the spoke is 10.60.1.0/24. The hub already uses 10.60.0.0/16. What should the administrator do before deploying the spoke?

A.Use the proposed address space because the spoke subnet is smaller than the hub address space.

B.Choose a non-overlapping address space for the spoke, such as 10.61.1.0/24.

C.Create a private endpoint in the spoke to separate its routing table from the hub.

D.Enable gateway transit on the hub peering before creating the spoke.

AnswerB

VNet peering requires non-overlapping address spaces. Because 10.60.1.0/24 is contained inside the hub's 10.60.0.0/16 range, the spoke cannot be safely peered as proposed. The correct fix is to pick a different CIDR block that does not overlap with the hub or any other connected network, such as 10.61.1.0/24.

Why this answer

Option B is correct because VNet address spaces must not overlap when peered or connected via VPN/ExpressRoute. The proposed spoke address 10.60.1.0/24 falls within the hub's 10.60.0.0/16 range, creating an overlap that would prevent successful peering and routing. A non-overlapping address space like 10.61.1.0/24 ensures unique IP ranges, allowing proper route propagation and connectivity.

Exam trap

The trap here is that candidates mistakenly think a smaller subnet within a larger address space is acceptable for VNet peering, but Azure requires completely non-overlapping address spaces to avoid routing ambiguity.

How to eliminate wrong answers

Option A is wrong because using a subnet that is a subset of the hub's address space still causes overlap; Azure VNet peering requires non-overlapping address spaces regardless of subnet size. Option C is wrong because a private endpoint does not separate routing tables; it provides private connectivity to PaaS services and does not resolve address space overlap issues. Option D is wrong because enabling gateway transit on the hub peering is a configuration step done after the VNets are created and peered, not a prerequisite for deploying the spoke; it also does not fix overlapping address spaces.

Practice this question →

132

MCQeasy

Based on the exhibit, the administrator cannot create VNet peering between the hub and spoke networks. What should be changed?

A.Change the hub VNet to use a smaller subnet mask.

B.Change the spoke VNet address space so it does not overlap the hub.

C.Add a route table to the spoke VNet before creating peering.

D.Enable a service endpoint on both VNets.

AnswerB

This is the correct fix because Azure VNet peering requires non-overlapping IP ranges. The exhibit shows the spoke range sits inside the hub range, which causes the peering attempt to fail. Readdressing the spoke to a unique CIDR block resolves the conflict and allows the peering to be created.

Why this answer

VNet peering requires that the address spaces of the peered VNets do not overlap. Overlapping address spaces cause routing conflicts because Azure cannot distinguish between resources in the hub and spoke when IP addresses are identical or within the same CIDR range. Changing the spoke VNet address space to a non-overlapping range resolves this issue and allows peering to be established.

Exam trap

The trap here is that candidates often confuse VNet peering prerequisites with routing or security features, mistakenly thinking route tables or service endpoints are required, when the core requirement is non-overlapping address spaces.

How to eliminate wrong answers

Option A is wrong because changing the hub VNet to use a smaller subnet mask does not resolve address overlap; it only reduces the number of available IPs in the hub, but the spoke address space still overlaps. Option C is wrong because route tables are used to control traffic flow after peering is established, not as a prerequisite for creating peering; peering itself does not require a route table. Option D is wrong because service endpoints are used to secure Azure service access to a VNet, not to enable VNet peering; peering is a Layer 3 connectivity feature independent of service endpoints.

Practice this question →

133

Multi-Selecteasy

A new spoke virtual network will peer with an existing hub that uses 10.10.0.0/16 and an on-premises network that uses 10.20.0.0/16. Which two address spaces could you assign to the new spoke without overlapping those ranges? Select two.

Select 2 answers

A.10.11.0.0/16

B.10.10.128.0/17

C.192.168.50.0/24

D.10.20.1.0/24

E.10.10.1.0/24

AnswersA, C

Correct because this range does not overlap with the existing hub or on-premises address spaces.

Why this answer

Option A (10.11.0.0/16) is correct because it is a distinct subnet within the private 10.0.0.0/8 range that does not overlap with the hub's 10.10.0.0/16 or the on-premises 10.20.0.0/16. Azure virtual network peering requires non-overlapping address spaces to enable direct routing between resources without conflict.

Exam trap

The trap here is that candidates often assume any /16 or /24 within the 10.0.0.0/8 range is safe, but they must check for subnet overlap with both the hub and on-premises networks, not just the hub's primary range.

Practice this question →

134

MCQmedium

A network team wants all routers to send log messages to a centralized server at 192.0.2.50. Which command should be added to the router configuration?

A.snmp-server host 192.0.2.50

B.archive 192.0.2.50

C.ntp server 192.0.2.50

D.logging host 192.0.2.50

AnswerD

This is correct because `logging host` identifies the destination Syslog server.

Why this answer

The correct command is 'logging host 192.0.2.50' because it configures the router to send syslog messages to a centralized syslog server at that IP address. Syslog is the standard protocol (UDP port 514) used by network devices for event logging, and the 'logging host' command directs the router to forward all configured logging levels to the specified server.

Exam trap

Microsoft often tests the distinction between syslog (logging host) and SNMP (snmp-server host), as candidates confuse sending log messages with sending SNMP traps, but SNMP traps are for specific events like interface status changes, not general syslog messages.

Why the other options are wrong

The command 'snmp-server host 192.0.2.50' is used to configure a Simple Network Management Protocol (SNMP) trap destination, not for sending log messages. Therefore, it does not fulfill the requirement of sending logs to a centralized server.

The command 'archive 192.0.2.50' is incorrect because it is used for configuring archive settings, not for sending log messages to a centralized server. Log messages require the 'logging host' command instead.

The command 'ntp server 192.0.2.50' is used to configure a Network Time Protocol server for time synchronization, not for sending log messages to a centralized server.

Practice this question →

135

MCQmedium

Frontend VMs in one subnet must reach backend VMs on TCP 8443. The backend VMs are rebuilt frequently, so their private IP addresses change often. The administrator wants to avoid updating NSG rules every time the backend IPs change. What should be used in the NSG rule?

A.Application Security Groups for the frontend and backend tiers.

B.A service endpoint on the backend subnet.

C.A route table with a next hop of Virtual network gateway.

D.A private endpoint for each backend VM.

AnswerA

Application Security Groups let you reference groups of VMs in NSG rules instead of individual IP addresses. That is ideal when backend IPs change often because the rule continues to target the backend application tier rather than a specific address. The administrator can place the frontend VMs in one ASG and the backend VMs in another, then allow TCP 8443 between those groups without constantly editing the NSG.

Why this answer

Application Security Groups (ASGs) allow you to group VMs logically by function (e.g., frontend, backend) and reference those groups in NSG rules. Since the backend VMs are rebuilt frequently and their private IPs change, using ASGs in the NSG rule (source = frontend ASG, destination = backend ASG, port = 8443) eliminates the need to update IP addresses manually. The NSG rule remains valid as long as the VMs are assigned to the correct ASG, regardless of IP changes.

Exam trap

The trap here is that candidates often confuse Application Security Groups with Network Security Groups themselves, or think that service endpoints or private endpoints are designed for VM-to-VM communication, when in fact they are for securing access to Azure PaaS services.

How to eliminate wrong answers

Option B is wrong because a service endpoint extends your VNet to Azure service resources (e.g., Azure Storage, SQL Database) over the Azure backbone, not to other VMs within the same VNet; it does not help with dynamic IPs between frontend and backend VMs. Option C is wrong because a route table with a next hop of Virtual network gateway forces traffic through a VPN gateway or ExpressRoute, which adds latency and is unnecessary for intra-VNet communication; it does not address NSG rule updates. Option D is wrong because a private endpoint assigns a private IP from your VNet to an Azure PaaS service (e.g., Azure SQL, Storage), not to a VM; it cannot be used to make backend VMs reachable via a static NSG rule when their IPs change.

Practice this question →

136

MCQmedium

Based on the exhibit, which address space can you assign to the new spoke virtual network so it can be peered to the hub and later connected to on-premises without an IP overlap?

A.10.50.128.0/17

B.10.51.0.0/16

C.10.52.0.0/16

D.10.50.0.0/24

AnswerC

This range does not overlap either existing network and is valid for peering and later hybrid connectivity.

Why this answer

Option C (10.52.0.0/16) is correct because it does not overlap with the hub virtual network's address space (10.50.0.0/16) or the on-premises network (10.51.0.0/16). This allows the spoke VNet to be peered to the hub and later connected to on-premises via a gateway in the hub without IP address conflicts, which is a requirement for successful VNet peering and VPN/ExpressRoute connectivity.

Exam trap

The trap here is that candidates often assume any address outside the hub's exact /16 is safe, forgetting to check the on-premises range (10.51.0.0/16), leading them to pick option B, which overlaps with on-premises and would break hybrid connectivity.

How to eliminate wrong answers

Option A (10.50.128.0/17) is wrong because it falls within the hub VNet's 10.50.0.0/16 range, causing an IP overlap that would prevent VNet peering. Option B (10.51.0.0/16) is wrong because it overlaps with the on-premises network's 10.51.0.0/16 address space, which would cause routing conflicts when connecting via the hub's gateway. Option D (10.50.0.0/24) is wrong because it is a subset of the hub VNet's 10.50.0.0/16 range, resulting in an immediate IP overlap that blocks peering.

Practice this question →

137

MCQmedium

Administrators need to connect to Windows and Linux VMs from the Azure portal using a browser. The VMs do not have public IP addresses, and the security team does not want a VPN client installed on admin laptops. Which service should be deployed?

A.Azure VPN Gateway

B.Azure Load Balancer

C.A network security group with RDP and SSH rules

D.Azure Bastion

AnswerD

Azure Bastion provides secure browser-based RDP and SSH to VMs that have no public IP addresses. It keeps management traffic inside Azure and avoids exposing administrative ports to the internet or requiring a client VPN on the administrator's device.

Why this answer

Azure Bastion provides secure, seamless RDP and SSH connectivity to Azure VMs directly from the Azure portal over TLS, without requiring public IP addresses on the VMs or a VPN client on the admin's laptop. It uses a hardened bastion host deployed in the same virtual network, acting as a jump server that brokers browser-based connections, meeting both the security and connectivity requirements.

Exam trap

The trap here is that candidates often confuse Azure Bastion with a VPN gateway or assume that an NSG with RDP/SSH rules alone is sufficient for secure browser-based access, overlooking the requirement for no public IPs and no client software.

How to eliminate wrong answers

Option A is wrong because Azure VPN Gateway requires a VPN client installed on admin laptops to establish a site-to-site or point-to-site tunnel, which the security team explicitly does not want. Option B is wrong because Azure Load Balancer distributes network traffic across multiple VMs for high availability and scaling, but does not provide secure administrative access or browser-based RDP/SSH connectivity. Option C is wrong because a network security group (NSG) with RDP and SSH rules only controls inbound traffic to VMs; it does not eliminate the need for public IP addresses or provide browser-based access, and exposing RDP/SSH directly (even with NSG rules) violates the security team's requirement to avoid public exposure.

Practice this question →

138

Multi-Selecthard

A company wants encrypted connectivity between its on-premises network and an Azure VNet. The organization has one edge VPN device at headquarters, and the Azure design must support a classic site-to-site tunnel rather than individual user VPN connections. Which three prerequisites are required? Select three.

Select 3 answers

A.Deploy a virtual network gateway in a dedicated GatewaySubnet.

B.Assign a public IP address to the Azure VPN gateway.

C.Configure the on-premises VPN device with a public IP and supported IKE/IPsec settings.

D.Create a private endpoint for the headquarters network.

E.Enable Microsoft peering on the virtual network gateway.

AnswersA, B, C

Azure VPN gateways must be deployed into the special GatewaySubnet within the VNet.

Why this answer

A virtual network gateway must be deployed in a dedicated subnet called GatewaySubnet to host the VPN gateway resources. This subnet is required for the gateway to function and must be named exactly 'GatewaySubnet' to be recognized by Azure when creating a site-to-site VPN connection.

Exam trap

The trap here is that candidates may confuse private endpoints (used for PaaS services) or ExpressRoute peering with the prerequisites for a classic site-to-site VPN, which strictly requires a GatewaySubnet, a public IP on the gateway, and a compatible on-premises VPN device.

Practice this question →

139

MCQmedium

A company wants to peer a new spoke virtual network with an existing hub VNet. The hub uses 10.20.0.0/16. The spoke was created with 10.20.1.0/24 because that range was still available in the IPAM spreadsheet. VNet peering creation fails. What should the administrator do first?

A.Enable gateway transit on the hub and retry the peering.

B.Add a route table to the spoke subnet so the networks can communicate.

C.Change the spoke VNet address space to a non-overlapping range, then recreate or update peering.

D.Configure a custom DNS server in the spoke to translate the overlapping range.

AnswerC

VNet peering requires the two virtual networks to have non-overlapping IP address spaces. Because the hub already uses 10.20.0.0/16, the spoke cannot use 10.20.1.0/24. The administrator must renumber the spoke to a different range, such as 10.21.0.0/16 or another approved block, before peering can succeed.

Why this answer

VNet peering in Azure requires that the address spaces of the peered virtual networks do not overlap. The hub uses 10.20.0.0/16, and the spoke uses 10.20.1.0/24, which is a subset of the hub's range. This overlap causes the peering creation to fail.

The administrator must first change the spoke's address space to a non-overlapping range (e.g., 10.21.0.0/24) and then recreate or update the peering.

Exam trap

The trap here is that candidates may think overlapping address spaces can be resolved by routing or DNS changes, but Azure explicitly prohibits peering with overlapping ranges, and no configuration workaround exists—the address space must be changed.

How to eliminate wrong answers

Option A is wrong because enabling gateway transit is used to allow a spoke VNet to use the hub's VPN/ExpressRoute gateway, but it does not resolve address space overlap, which is the root cause of the failure. Option B is wrong because adding a route table to the spoke subnet cannot fix overlapping IP ranges; route tables control traffic flow but cannot change the fact that Azure blocks peering with overlapping address spaces. Option D is wrong because configuring a custom DNS server does not address IP address overlap; DNS translates names to IPs, but the underlying conflict of overlapping ranges remains and prevents peering from being established.

Practice this question →

140

MCQmedium

A VM in a subnet has both a subnet-level NSG and a NIC-level NSG. The subnet NSG allows inbound TCP 22 from the VirtualNetwork service tag, but the NIC NSG denies inbound TCP 22 from the same source. An administrator says the subnet rule should be enough because it allows the traffic. What is the actual behavior?

A.The allow rule wins because subnet NSGs always override NIC NSGs.

B.The traffic is blocked because a deny in either NSG is effective.

C.The traffic is allowed because service tags bypass NIC-level rules.

D.The connection succeeds unless a route table sends the traffic elsewhere.

AnswerB

Azure evaluates both NIC and subnet NSGs. If either one denies the packet, the connection is blocked even if the other NSG has an allow rule.

Why this answer

When both a subnet-level NSG and a NIC-level NSG are applied to a virtual machine, network traffic is evaluated against both NSGs. The effective rule is the most restrictive: if either NSG contains a deny rule that matches the traffic, the traffic is blocked. In this scenario, the NIC-level NSG explicitly denies inbound TCP 22 from the VirtualNetwork service tag, so even though the subnet NSG allows it, the deny at the NIC level takes precedence and the traffic is blocked.

Exam trap

The trap here is that candidates often assume subnet-level NSGs take precedence over NIC-level NSGs, but Azure actually applies both and the most restrictive rule (any deny) wins, making it critical to check both NSGs for conflicting rules.

How to eliminate wrong answers

Option A is wrong because subnet NSGs do not override NIC-level NSGs; instead, both NSGs are evaluated and the most restrictive rule applies, so a deny in either NSG blocks the traffic. Option C is wrong because service tags do not bypass NIC-level rules; NSG rules are evaluated in priority order within each NSG, and a deny rule in the NIC NSG will still block traffic regardless of the service tag. Option D is wrong because route tables control the path traffic takes, not the firewall rules; even if a route table sends traffic to the VM, the NIC NSG's deny rule will still block the connection.

Practice this question →

141

MCQmedium

A Linux VM in a subnet must accept SSH only from the corporate admin subnet 10.8.4.0/24. The subnet NSG currently has an Allow-SSH rule for Any at priority 300 and a Deny-SSH rule for Any at priority 200. Administrators from 10.8.4.0/24 still cannot connect. What change should the administrator make?

A.Change the deny rule protocol from TCP to Any so the allow rule is evaluated first.

B.Add an Allow-SSH rule for 10.8.4.0/24 with a priority lower than 200.

C.Move the existing Allow-SSH rule to priority 400 so it applies later.

D.Add a route table to the subnet so the SSH packets follow a different path.

AnswerB

NSG rules are evaluated by priority, and the lowest number wins. A deny rule at 200 blocks SSH before the allow at 300 is considered. The fix is to add a more specific allow rule for the admin subnet with a higher priority, such as 100, so it is evaluated first. That keeps SSH restricted to approved administrators while preserving the existing deny for everyone else.

Why this answer

The subnet NSG has a Deny-SSH rule for Any at priority 200, which blocks all SSH traffic regardless of source. To allow SSH only from 10.8.4.0/24, an Allow-SSH rule for that specific subnet must be added with a priority lower (higher number) than 200, such as 210, so it is evaluated after the deny rule. Since NSG rules are processed in priority order (lowest number first), the deny at 200 will block traffic before the allow rule is reached unless the allow rule has a lower priority number, which is not possible here; instead, the allow rule must have a higher priority number (e.g., 210) to be evaluated after the deny, but the correct approach is to add an allow rule with a priority lower than 200 (i.e., a smaller number) to override the deny.

However, the correct answer states 'priority lower than 200' meaning a numerically smaller value (e.g., 100), which would be evaluated before the deny rule, allowing traffic from 10.8.4.0/24 before the deny rule blocks it. This is the standard NSG rule evaluation behavior: the highest priority (lowest number) rule wins.

Exam trap

The trap here is that candidates often confuse 'lower priority' with a higher numeric value, thinking a rule with priority 400 is 'lower' than 200, when in fact NSG rules use ascending numeric priority where lower numbers are evaluated first.

How to eliminate wrong answers

Option A is wrong because changing the deny rule protocol from TCP to Any does not affect rule evaluation order; NSG rules are evaluated by priority number, not protocol, and the deny rule at priority 200 will still block SSH before the allow rule at priority 300 is reached. Option C is wrong because moving the existing Allow-SSH rule to priority 400 (a higher number) would cause it to be evaluated even later, after the deny rule at 200, so it would never be applied and SSH would remain blocked. Option D is wrong because route tables control network traffic paths at Layer 3, not security filtering; adding a route table does not bypass NSG rules, and SSH packets would still be subject to NSG evaluation.

Practice this question →

142

MCQmedium

Based on the exhibit, what should the administrator do so VM-B resolves the storage account name to the private IP address?

A.Create a service endpoint on VNet-B and leave DNS unchanged.

B.Link the private DNS zone to VNet-B.

C.Assign a public IP address to the private endpoint.

D.Add a route table with a next hop to the storage account.

AnswerB

The DNS zone link lets workloads in VNet-B resolve the storage name to the private endpoint address.

Why this answer

The private DNS zone for the storage account must be linked to VNet-B so that VM-B can resolve the storage account's fully qualified domain name (FQDN) to the private IP address of the private endpoint. Without this link, the DNS resolution will fall back to the public endpoint, bypassing the private connectivity. Linking the zone ensures Azure's default DNS servers return the private IP for the storage account within VNet-B.

Exam trap

The trap here is that candidates often confuse network-level controls (like service endpoints or route tables) with DNS resolution, assuming that private connectivity alone will automatically change name resolution without explicitly linking the private DNS zone.

How to eliminate wrong answers

Option A is wrong because a service endpoint does not affect DNS resolution; it only provides direct connectivity to the Azure service over the Microsoft backbone, but the storage account name would still resolve to a public IP unless a private DNS zone is linked. Option C is wrong because assigning a public IP to the private endpoint defeats the purpose of private connectivity and does not change DNS resolution; private endpoints use private IPs from the virtual network, and a public IP would not be used for name resolution. Option D is wrong because a route table controls network traffic paths, not DNS resolution; adding a route with a next hop to the storage account would not change how the storage account name is resolved to an IP address.

Practice this question →

143

MCQmedium

A subnet uses a route table with gateway route propagation disabled so internet-bound traffic can be forced through a network virtual appliance. After the change, VMs in the subnet can no longer reach servers in the on-premises network 172.16.0.0/16 over the VPN gateway. What should the administrator add to the route table?

A.A user-defined route for 172.16.0.0/16 with next hop type Virtual network gateway.

B.A user-defined route for 172.16.0.0/16 with next hop type Internet.

C.An NSG allow rule for TCP 172.16.0.0/16.

D.A service endpoint for the on-premises network range.

AnswerA

When gateway route propagation is disabled, the subnet no longer learns on-premises routes automatically from the VPN gateway. Adding a specific route for the on-premises prefix with next hop Virtual network gateway restores reachability to that network while keeping the forced-tunneling design for other traffic.

Why this answer

When gateway route propagation is disabled on a route table, the subnet no longer receives the default system routes that include the VPN gateway route for on-premises networks. To restore connectivity to 172.16.0.0/16, you must add a user-defined route (UDR) with next hop type 'Virtual network gateway', which explicitly directs traffic for that prefix through the VPN gateway. This overrides the missing propagated route and forces the traffic to the on-premises network correctly.

Exam trap

The trap here is that candidates confuse routing (UDR) with filtering (NSG) or connectivity methods (service endpoints), assuming an NSG rule or service endpoint can fix a routing issue, when only a user-defined route with the correct next hop type can restore traffic flow to the on-premises network.

How to eliminate wrong answers

Option B is wrong because setting the next hop type to 'Internet' would send traffic to 172.16.0.0/16 out to the public internet, which cannot reach a private on-premises network and would fail. Option C is wrong because a Network Security Group (NSG) rule controls firewall filtering (allow/deny traffic), not routing; it does not define the path traffic takes to reach a destination. Option D is wrong because a service endpoint is used to extend a VNet's private address space to Azure PaaS services (e.g., Azure Storage, SQL Database) over the Azure backbone, not to route traffic to an on-premises network via VPN.

Practice this question →

144

MCQmedium

A subnet has a NAT gateway attached, but outbound internet traffic from the VMs is still leaving through a network virtual appliance. The subnet's route table includes a user-defined route for 0.0.0.0/0 with the next hop set to Virtual appliance. The business wants internet traffic to use the NAT gateway while keeping any required specific routes to on-premises networks. What should the administrator do?

A.Keep the default route and add a second NAT gateway to the subnet.

B.Remove the 0.0.0.0/0 user-defined route and keep only specific routes for private prefixes.

C.Disable network security groups on the subnet so the NAT gateway becomes active.

D.Set gateway route propagation to Disabled so the NAT gateway is preferred.

AnswerB

A subnet-level 0.0.0.0/0 UDR to a virtual appliance overrides the system route that would otherwise let the NAT gateway handle internet-bound traffic. Removing that default route restores normal outbound internet handling through the NAT gateway, while more specific routes for on-premises or private destinations can remain in place. This preserves both functionality and control.

Why this answer

Option B is correct because the user-defined route (UDR) for 0.0.0.0/0 with next hop Virtual appliance is overriding the NAT gateway's default route. NAT gateways require a default route (0.0.0.0/0) with next hop 'Internet' to direct outbound traffic through them. By removing the conflicting UDR and keeping only specific routes for on-premises prefixes, the subnet will use the NAT gateway for internet traffic while maintaining connectivity to on-premises networks via the remaining UDRs.

Exam trap

The trap here is that candidates mistakenly think NAT gateways can coexist with a default UDR to a virtual appliance, or that disabling gateway propagation or adding more NAT gateways will override the UDR, when in fact the UDR's higher priority always wins for the 0.0.0.0/0 prefix.

How to eliminate wrong answers

Option A is wrong because adding a second NAT gateway does not resolve the conflict; the existing UDR for 0.0.0.0/0 with next hop Virtual appliance will still take precedence over both NAT gateways, as UDRs have higher priority than system routes. Option C is wrong because network security groups (NSGs) do not affect routing decisions; they filter traffic at the subnet or NIC level but do not influence which next hop is used for outbound traffic. Option D is wrong because disabling gateway route propagation only affects routes learned from Azure VPN/ExpressRoute gateways, not user-defined routes; the UDR for 0.0.0.0/0 will still override the NAT gateway's default route.

Practice this question →

145

MCQmedium

A subnet has a route table with a 0.0.0.0/0 user-defined route to an on-premises virtual appliance. The business now wants Azure VM outbound internet traffic to use a NAT gateway so the public source IP stays consistent, and the firewall appliance is no longer required for internet egress. What should the administrator do?

A.Keep the default route to the virtual appliance and add the NAT gateway to the subnet.

B.Remove the 0.0.0.0/0 UDR and associate the NAT gateway with the subnet.

C.Change the route next hop to Virtual network gateway.

D.Create an NSG outbound rule that allows internet traffic from the subnet.

AnswerB

NAT gateway is used for outbound internet traffic when the subnet does not already force that traffic elsewhere. Because the 0.0.0.0/0 UDR sends all internet-bound packets to the virtual appliance, NAT gateway cannot provide the source IP. Removing the UDR allows the subnet to use the NAT gateway for outbound connectivity as intended.

Why this answer

Option B is correct because removing the 0.0.0.0/0 user-defined route (UDR) that points to the on-premises virtual appliance and associating a NAT gateway with the subnet ensures that all outbound internet traffic from Azure VMs uses the NAT gateway's public IP address. The NAT gateway automatically creates a default route (0.0.0.0/0) with a next hop type of 'Internet' for the subnet, overriding any conflicting UDRs. This provides a consistent source IP for internet egress without requiring the firewall appliance.

Exam trap

The trap here is that candidates may think a NAT gateway can coexist with a conflicting UDR (Option A) or that changing the next hop to a virtual network gateway (Option C) will provide internet egress, when in fact the UDR must be removed to allow the NAT gateway's default route to take effect.

How to eliminate wrong answers

Option A is wrong because keeping the 0.0.0.0/0 UDR to the virtual appliance would still route internet traffic through the firewall, bypassing the NAT gateway and failing to achieve the goal of using the NAT gateway for consistent source IP. Option C is wrong because changing the next hop to 'Virtual network gateway' would route traffic to a VPN or ExpressRoute gateway, which is not designed for NAT-based internet egress and would not provide a consistent public IP. Option D is wrong because an NSG outbound rule allowing internet traffic does not change the routing path; the subnet's route table still controls where traffic is forwarded, so without modifying the UDR, traffic would still go to the virtual appliance.

Practice this question →

146

MCQmedium

A storage account has public network access disabled. An app in a VNet must read and write blobs privately, and the team wants the blob endpoint name to resolve to a private IP without exposing the service publicly. What should the administrator configure?

A.A service endpoint on the subnet and a storage firewall allow rule.

B.A public IP address for the app and allow access from that IP in the storage firewall.

C.An NSG rule that allows outbound TCP 443 from the app subnet to storage.

D.A private endpoint for the storage account and a private DNS zone for blob name resolution.

AnswerD

Private endpoints give the storage service a private IP in the VNet, and DNS must resolve to it.

Why this answer

Option D is correct because a private endpoint assigns the storage account a private IP from the VNet, ensuring all traffic to the blob endpoint stays within Microsoft's backbone. A private DNS zone (e.g., `privatelink.blob.core.windows.net`) is required so that the blob endpoint name resolves to that private IP instead of the public IP, meeting the requirement for private name resolution without any public exposure.

Exam trap

The trap here is that candidates confuse service endpoints (which only provide source IP preservation and firewall rules) with private endpoints (which provide a true private IP and private DNS resolution), leading them to pick Option A thinking it achieves private connectivity when it does not change the public DNS resolution.

How to eliminate wrong answers

Option A is wrong because a service endpoint does not assign a private IP to the storage account; it only extends the VNet's identity to the service, and the blob endpoint still resolves to a public IP, which violates the requirement for private name resolution. Option B is wrong because assigning a public IP to the app and allowing that IP in the storage firewall still exposes the storage account to the public internet (the firewall rule only restricts access, but the endpoint remains publicly resolvable). Option C is wrong because an NSG rule controlling outbound TCP 443 does not change how the blob endpoint name resolves; it only permits traffic, but the name still resolves to a public IP, failing the private resolution requirement.

Practice this question →

147

MCQhard

Based on the exhibit, what should the administrator configure so the VM in the spoke VNet can resolve internal hostnames that are hosted on the DNS server in the hub VNet? The team has already verified that IP connectivity between the spoke VM and the hub VM works.

A.Set the SpokeVNet DNS server list to use 10.40.0.4 so the spoke queries the hub resolver directly.

B.Create a private endpoint for web01.corp.contoso.local in the spoke VNet so DNS resolves automatically.

C.Enable gateway transit on the peering so the spoke inherits the hub VNet DNS configuration.

D.Add inbound and outbound NSG rules allowing UDP and TCP port 53 between the two VNets.

AnswerA

The spoke already has network connectivity to the hub, so the remaining problem is name resolution. Azure VNet peering does not copy DNS settings from one VNet to another. By configuring the spoke to use the hub DNS server, queries for the internal zone are sent to the resolver that actually hosts or forwards that namespace.

Why this answer

Option A is correct because setting the SpokeVNet DNS server list to 10.40.0.4 (the IP of the DNS server in the hub VNet) configures the spoke VNet to forward all DNS queries to that custom DNS server. Since IP connectivity between the VNets is already verified, the spoke VM can resolve internal hostnames hosted on the hub DNS server. This is the standard method for cross-VNet DNS resolution when using a custom DNS server in a hub-and-spoke topology.

Exam trap

The trap here is that candidates often confuse VNet peering's gateway transit feature with DNS settings inheritance, but gateway transit only applies to network gateway routes, not DNS server configuration.

How to eliminate wrong answers

Option B is wrong because a private endpoint is used to connect privately to an Azure PaaS service (e.g., Azure SQL, Storage) and does not resolve custom internal hostnames hosted on a VM DNS server; it creates a network interface with a private IP for the PaaS resource, not a DNS resolution mechanism for arbitrary hostnames. Option C is wrong because gateway transit on VNet peering only allows the spoke VNet to use the hub's VPN/ExpressRoute gateway for outbound connectivity to on-premises networks; it does not inherit or propagate DNS server settings between VNets. Option D is wrong because while NSG rules allowing UDP/TCP port 53 are necessary for DNS traffic, the question states IP connectivity already works, implying the underlying network path is open; the core issue is DNS configuration, not firewall rules, and adding NSG rules alone does not configure the spoke to use the hub DNS server.

Practice this question →

148

MCQhard

After a user-defined route and VNet peering were added, a VM in a spoke subnet still does not reach 10.20.4.8 as expected. You need to confirm which route Azure will actually select on that VM's NIC, including any propagated routes and the route that wins. Which Network Watcher tool should you use?

A.Connection troubleshoot

B.Effective routes

C.IP flow verify

D.Packet capture

AnswerB

Effective routes shows the routes applied to the NIC and which next hop Azure will use for the destination.

Why this answer

Effective routes displays the actual routes applied to a network interface, including user-defined routes (UDRs), BGP-propagated routes, and VNet peering routes, along with the route priority (based on the longest prefix match and route source precedence). This allows you to see exactly which route wins for the destination 10.20.4.8, resolving why the VM cannot reach it despite the configured UDR and peering.

Exam trap

The trap here is that candidates confuse 'IP flow verify' (which checks NSG rules) with route verification, but IP flow verify does not show the routing table or the winning route for a destination IP.

How to eliminate wrong answers

Option A is wrong because Connection troubleshoot tests end-to-end connectivity between a source and destination, but it does not show the routing table or which specific route is selected on the NIC. Option C is wrong because IP flow verify checks whether traffic is allowed or denied by network security groups (NSGs) for a given 5-tuple, not which route is chosen from the routing table. Option D is wrong because Packet capture captures raw network traffic for analysis, but it does not provide the effective routing decision or the route selection logic.

Practice this question →

149

MCQmedium

You need to connect VNet-Hub and VNet-Spoke so that resources in both virtual networks can communicate privately over the Microsoft backbone. Both virtual networks are in the same region. What should you configure?

A.Virtual network peering

B.A site-to-site VPN

C.A network security group

D.An Azure Policy assignment

AnswerA

VNet peering is the correct solution for private, low-latency communication between Azure VNets.

Why this answer

Virtual network peering (A) is the correct solution because it enables direct, private connectivity between two virtual networks over the Microsoft backbone infrastructure. Since both VNets are in the same region, you can use standard VNet peering, which routes traffic between the peered networks using only private IP addresses, with no internet transit or gateway required. This meets the requirement for private communication without any additional VPN or gateway overhead.

Exam trap

Microsoft often tests the misconception that a site-to-site VPN is required for private connectivity between VNets, but VNet peering is the native, simpler solution for same-region private communication over the Microsoft backbone.

How to eliminate wrong answers

Option B is wrong because a site-to-site VPN requires a VPN gateway in each VNet and tunnels traffic over the internet or ExpressRoute, which adds latency, cost, and complexity compared to the simpler, lower-latency VNet peering for same-region connectivity. Option C is wrong because a network security group (NSG) is a stateful firewall that filters traffic at the subnet or NIC level; it does not establish connectivity between VNets and cannot enable routing or private communication between them. Option D is wrong because an Azure Policy assignment enforces compliance rules (e.g., tagging, allowed SKUs) but does not create network connectivity; it cannot route traffic between VNets or provide private communication.

Practice this question →

150

MCQmedium

An administrator is deploying a site-to-site VPN gateway in an existing VNet. The GatewaySubnet already exists, but deployment validation fails because the gateway has no public-facing IP resource. Which configuration is required?

A.Attach a Standard SKU public IP address with static allocation to the VPN gateway.

B.Attach a private IP address from the GatewaySubnet to the VPN gateway.

C.Place the gateway behind an internal load balancer in the GatewaySubnet.

D.Create a NAT gateway and associate it with the GatewaySubnet.

AnswerA

Azure VPN gateways require a public IP resource, and Standard static IPs are the supported choice.

Why this answer

A site-to-site VPN gateway in Azure requires a public IP address to establish connectivity with the on-premises VPN device. The Standard SKU public IP with static allocation is required because VPN gateways do not support Basic SKU public IPs and must have a static IP that does not change. Without this public IP resource, the gateway cannot be provisioned as it has no public endpoint for the VPN tunnel.

Exam trap

The trap here is that candidates may think a private IP from the GatewaySubnet is sufficient for a site-to-site VPN, overlooking that the VPN gateway must have a public IP to terminate the IPsec tunnel from the on-premises device.

How to eliminate wrong answers

Option B is wrong because a private IP from the GatewaySubnet is used for internal routing within the VNet, but the VPN gateway needs a public IP for the site-to-site tunnel endpoint. Option C is wrong because an internal load balancer operates within the VNet and cannot provide the public-facing endpoint required for a site-to-site VPN gateway; VPN gateways are not placed behind load balancers. Option D is wrong because a NAT gateway is used for outbound internet traffic from private subnets and does not provide a public IP for inbound VPN connections; the VPN gateway itself must have a directly attached public IP.

Practice this question →