CCNA Virtual Network Questions — Page 4 of 4

226

MCQhard

An administrator is deploying a route-based site-to-site VPN gateway. The GatewaySubnet already exists, but validation fails because the public IP configuration is incompatible with the chosen gateway. Which public IP setup is required for the gateway?

A.A Basic SKU public IP with dynamic allocation.

B.A Basic SKU public IP with static allocation.

C.A Standard SKU public IP with static allocation.

D.A private IP address assigned directly from GatewaySubnet.

AnswerC

Azure VPN gateways require a Standard public IP configuration, and the address must be statically allocated. This is part of the gateway's external-facing connectivity requirement and is validated during deployment. If a Basic or dynamically assigned public IP is selected, gateway creation can fail even when GatewaySubnet already exists and is sized correctly.

Why this answer

For a route-based site-to-site VPN gateway in Azure, the gateway must use a Standard SKU public IP address with static allocation. This is because route-based VPN gateways require the public IP to be statically assigned and the Standard SKU provides the necessary features like availability zones and zone resiliency, which are not supported by the Basic SKU. The Basic SKU public IP is incompatible with route-based VPN gateways, and a private IP from the GatewaySubnet cannot serve as the public endpoint for the VPN connection.

Exam trap

The trap here is that candidates often assume any static public IP will work, overlooking the SKU requirement—Azure specifically mandates Standard SKU for route-based VPN gateways, and Basic SKU is only valid for policy-based gateways or other services like basic load balancers.

Why the other options are wrong

Route-based VPN gateways require a Standard SKU public IP with static allocation. Basic SKU public IPs do not support the necessary features like BGP and active-active mode for route-based VPNs.

For a route-based VPN gateway, Azure requires a Standard SKU public IP with static allocation. Basic SKU public IPs are not supported for route-based VPN gateways.

A route-based site-to-site VPN gateway requires a public IP address for internet-facing communication; a private IP from GatewaySubnet cannot be used for external connectivity.

Practice this question →

227

MCQmedium

A public web application runs on two Windows Server VMs in Azure. Users connect through a single public IP on TCP 443, and the solution must distribute traffic only to healthy VMs without requiring Layer 7 features such as URL-based routing. Which Azure service should the administrator deploy?

A.Azure Application Gateway.

B.Azure Load Balancer Standard.

C.Azure Traffic Manager.

D.Azure Front Door.

AnswerB

A Standard Load Balancer is the right fit for distributing TCP 443 traffic to healthy backend VMs using a single public IP at Layer 4. It supports health probes and works well for internet-facing workloads that do not need application-level routing. Because the scenario specifically excludes Layer 7 features, the load balancer provides the simplest and most cost-effective design while still meeting availability and traffic distribution requirements.

Why this answer

Azure Load Balancer Standard is the correct choice because it operates at Layer 4 (TCP/UDP) and distributes incoming traffic across healthy VM instances based on a single public IP address and port (TCP 443). It performs health probes to ensure traffic is only sent to healthy backend VMs, and it does not require any Layer 7 features like URL-based routing, making it ideal for this scenario.

Exam trap

The trap here is that candidates often confuse Azure Application Gateway with Azure Load Balancer, assuming that any web traffic requires Layer 7 features, but the question explicitly states no Layer 7 features are needed, making the Layer 4 Load Balancer the correct and simpler choice.

Why the other options are wrong

Azure Application Gateway is a Layer 7 load balancer that provides URL-based routing and other HTTP/S features, which are not required here. The question specifies no Layer 7 features are needed, and only TCP 443 traffic distribution is required, making a Layer 4 load balancer (Azure Load Balancer) the correct choice.

Azure Traffic Manager operates at the DNS level, routing traffic based on DNS resolution, not on the health of individual VMs or ports. It cannot distribute traffic to healthy VMs on TCP 443 without Layer 7 features.

Azure Front Door operates at Layer 7 and provides global load balancing with HTTP/HTTPS features like URL-based routing, which are not required. The question specifies no Layer 7 features and a single public IP, making Front Door overkill and incorrect.

Practice this question →

228

MCQmedium

A company plans a new spoke virtual network that must be peered to an existing hub VNet using 10.0.0.0/16. The spoke will need two subnets: one sized for about 120 VMs and another for about 40 VMs. The new address space must not overlap the hub or the on-premises range 10.1.0.0/16. Which VNet address space is the best choice?

A.10.0.1.0/24

B.10.1.0.0/22

C.10.2.0.0/22

D.10.0.0.0/24

AnswerC

This address space does not overlap the hub or on-premises ranges and is large enough to carve out two usable subnets for the workload. A /22 gives room for multiple subnets and future growth, which is important when planning a spoke that needs to host dozens or hundreds of VMs. It is a practical choice for peering compatibility and capacity.

Why this answer

(10.2.0.0/22) is correct because it provides a non-overlapping address space with the hub VNet (10.0.0.0/16) and on-premises (10.1.0.0/16). The /22 prefix offers 1024 IP addresses, which is sufficient for subnets supporting 120 VMs and 40 VMs, while avoiding any overlap with the existing ranges.

Exam trap

The trap here is that candidates often overlook the hub VNet's address space (10.0.0.0/16) and incorrectly assume a smaller subnet like 10.0.1.0/24 is safe, not realizing it falls within the hub's larger CIDR range.

Why the other options are wrong

Option A (10.0.1.0/24) overlaps with the hub VNet address space 10.0.0.0/16, which is not allowed for peering.

Option B (10.1.0.0/22) overlaps with the on-premises range 10.1.0.0/16, which is explicitly prohibited in the question.

Option D (10.0.0.0/24) overlaps with the hub VNet address space 10.0.0.0/16, which violates the requirement that the new address space must not overlap the hub.

Practice this question →

229

MCQmedium

A storage account has a private endpoint in VNet A. A VM in peered VNet B can reach the storage account by private IP, but when the VM resolves the storage account name it still gets the public IP address. What should be configured so the name resolves to the private IP from VNet B?

A.Create a new storage account in VNet B.

B.Link the private DNS zone for the storage service to VNet B.

C.Add an inbound NSG rule allowing DNS traffic from VNet B.

D.Replace the private endpoint with a service endpoint.

AnswerB

A private endpoint assigns the storage account a private IP address in VNet A, but name resolution from VNet B must still map the storage service FQDN to that private IP. Linking the private DNS zone to VNet B enables DNS resolution across the peered network, so clients in VNet B can resolve the storage account to its private endpoint. This is the standard approach for enabling private connectivity to a PaaS service over VNet peering.

Why this answer

When a private endpoint is created in VNet A, a private DNS zone (e.g., `privatelink.blob.core.windows.net`) is automatically linked to VNet A, enabling name resolution to the private IP within that VNet. However, VNet B is peered but not linked to that private DNS zone, so VMs in VNet B continue to resolve the storage account name via public DNS, returning the public IP. By linking the private DNS zone to VNet B, the VM will resolve the storage account name to the private IP address of the private endpoint.

Exam trap

The trap here is that candidates assume peering automatically extends DNS resolution for private endpoints, but peering only provides network connectivity—DNS zone linking is a separate, required configuration step.

Why the other options are wrong

Creating a new storage account in VNet B does not resolve the DNS issue for the existing storage account; it only provides a separate storage endpoint that would still require proper DNS configuration.

The issue is DNS resolution, not network traffic filtering. An NSG rule allowing DNS traffic from VNet B does not configure the private DNS zone to be accessible or linked to VNet B, so the storage account name still resolves to the public IP.

Service endpoints do not provide private DNS resolution; they only ensure traffic stays on the Microsoft backbone. The VM in VNet B would still resolve the storage account name to its public IP address, not the private IP.

Practice this question →

230

MCQmedium

A contractor working from home needs temporary access to internal Azure resources. There is no on-premises network to connect, and you do not want to expose the resources publicly. Which connectivity option should you deploy?

A.Site-to-site VPN, because it is the standard option for any remote access.

B.Point-to-site VPN, because it connects an individual client to the virtual network.

C.VNet peering, because it can securely connect any remote device to Azure.

D.ExpressRoute, because it is the simplest option for temporary contractor access.

AnswerB

Point-to-site VPN is the correct solution because it establishes a secure, encrypted tunnel from an individual client computer to an Azure virtual network over the public internet. It uses protocols such as IKEv2, SSTP, or OpenVPN and authenticates the user or device before granting access to private resources inside the VNet. This makes it ideal for a single remote user needing temporary access without exposing workloads publicly.

Why this answer

A Point-to-Site (P2S) VPN is the correct choice because it allows an individual client computer to establish a secure, encrypted connection to an Azure virtual network over the public internet using SSTP, IKEv2, or OpenVPN protocols. This meets the requirement of temporary remote access without exposing resources publicly, as the connection is initiated from the client and authenticated via certificates or Azure AD.

Exam trap

The trap here is that candidates often confuse Point-to-Site VPN with Site-to-Site VPN, assuming any VPN requires a physical device on-premises, or they overcomplicate the solution by choosing ExpressRoute for its perceived security, ignoring the temporary and individual nature of the access requirement.

Why the other options are wrong

Site-to-site VPN requires a VPN device on-premises to establish a connection between entire networks, but the contractor has no on-premises network to connect, making it unsuitable for individual remote access.

VNet peering connects two Azure virtual networks, not a remote client device. It does not provide remote access for an individual contractor working from home.

ExpressRoute is a dedicated private connection to Azure, requiring on-premises infrastructure and long-term contracts, making it unsuitable for temporary contractor access without an on-premises network.

Practice this question →

231

MCQmedium

Why is centralized logging valuable during security incident response?

A.It makes related events from many devices easier to collect and correlate.

B.It guarantees that attacks cannot succeed.

C.It replaces access control mechanisms.

D.It forces all systems to use one VLAN.

AnswerA

Centralized logging aggregates events from firewalls, endpoints, servers, and cloud services into a single time-indexed repository, allowing analysts to reconstruct a full attack chain by correlating related activities across devices. Instead of examining isolated logs, investigators can query for indicators of compromise that span an entire network, significantly reducing the time to detect and respond to incidents.

Why this answer

Centralized logging aggregates logs from multiple sources (e.g., Azure VMs, network security groups, Azure Firewall) into a single repository like Azure Log Analytics or Azure Sentinel. This correlation enables security analysts to identify patterns across devices, such as a chain of events from an initial breach to lateral movement, which is critical for incident response. Without centralization, manually correlating timestamps and log formats from disparate systems would be impractical during an active attack.

Exam trap

The trap here is that candidates may think centralized logging is a security control that prevents attacks (like a firewall or IDS), rather than recognizing it as a detective control that aids in post-incident analysis and correlation.

Why the other options are wrong

This option is wrong because centralized logging does not prevent attacks; it merely helps in detecting and analyzing them after they occur. Security measures must be implemented to actually prevent attacks from succeeding.

This option is wrong because centralized logging does not replace access control mechanisms; rather, it complements them by providing visibility into access attempts and security events. Access control mechanisms are essential for determining who can access what resources, independent of logging.

Option D is incorrect because centralized logging does not dictate network architecture or enforce VLAN configurations; it focuses on aggregating log data for analysis. Centralized logging can operate across different VLANs without forcing all systems into a single VLAN.

Practice this question →

232

Multi-Selecthard

A storage account already has a private endpoint for Blob service in a VNet. Virtual machines in AppSubnet still resolve the account name to the public endpoint, so traffic never reaches the private IP. Which two actions should the administrator take? Select two.

Select 2 answers

A.Create a private DNS zone for privatelink.blob.core.windows.net.

B.Link the private DNS zone to the VNet used by AppSubnet.

C.Enable a service endpoint for Microsoft.Storage on the subnet.

D.Set the storage account firewall to Selected networks without a private endpoint.

E.Assign a static public IP to the private endpoint.

AnswersA, B

A private DNS zone named privatelink.blob.core.windows.net is a mandatory component of the private endpoint deployment. When a client resolves the storage account's blob endpoint, the private DNS zone overrides the public CNAME record, returning the private IP address assigned to the private endpoint's NIC. Without this zone, DNS queries for the blob service FQDN continue to resolve to the public endpoint, so traffic never traverses the private link.

Why this answer

A private DNS zone for `privatelink.blob.core.windows.net` is required to override the default public DNS resolution for the storage account. When a private endpoint is created, the storage account's FQDN (e.g., `mystorageaccount.blob.core.windows.net`) must resolve to the private IP address of the endpoint within the VNet. Without this DNS zone, the VM in AppSubnet will continue to resolve the name to the public IP via Azure's public DNS servers, bypassing the private endpoint.

Exam trap

The trap here is that candidates often confuse service endpoints with private endpoints, assuming that enabling a service endpoint alone will redirect traffic to the private IP, when in fact DNS resolution must be explicitly configured via a private DNS zone.

Why the other options are wrong

Enabling a service endpoint for Microsoft.Storage on the subnet does not change DNS resolution; VMs would still resolve the storage account to its public IP address, not the private endpoint's IP.

Setting the storage account firewall to Selected networks without a private endpoint would block all traffic except from allowed IPs, but VMs in AppSubnet still resolve to the public IP, so traffic would be blocked or still go over the internet, not fixing the private endpoint resolution issue.

Assigning a static public IP to the private endpoint does not affect DNS resolution; the VM still resolves the storage account name to the public IP, so traffic bypasses the private endpoint.

Practice this question →

233

MCQmedium

You have two virtual networks named VNet-Hub and VNet-Spoke1 in the same Azure region. Resources in the two VNets must communicate privately over the Microsoft backbone without using a VPN gateway. What should you configure?

A.VNet peering

B.A site-to-site VPN

C.A public load balancer

D.An NSG outbound deny rule

AnswerA

VNet peering connects VNet-Hub and VNet-Spoke1 directly over the Microsoft backbone, satisfying the requirement for private communication without a VPN gateway. Traffic between peered virtual networks stays on Microsoft's private network, with low latency and no gateway needed, unlike site-to-site or VNet-to-VNet VPN configurations.

Why this answer

VNet peering enables direct, private connectivity between two virtual networks in the same Azure region using the Microsoft backbone infrastructure. It does not require a VPN gateway, public IP addresses, or any internet transit, making it the correct choice for private communication between VNet-Hub and VNet-Spoke1.

Exam trap

The trap here is that candidates often confuse VNet peering with VPN gateway-based solutions, assuming a VPN is required for private connectivity, but VNet peering directly meets the requirement without any gateway or public internet exposure.

Why the other options are wrong

A site-to-site VPN requires a VPN gateway and uses encrypted tunnels over the public internet, not the Microsoft backbone. The question specifies private communication over the Microsoft backbone without a VPN gateway, so this option does not meet the requirements.

A public load balancer distributes incoming internet traffic to backend resources and does not enable private communication between virtual networks over the Microsoft backbone.

An NSG outbound deny rule blocks traffic but does not enable private connectivity between VNets; it cannot establish communication over the Microsoft backbone.

Practice this question →

234

MCQmedium

You need to allow or deny traffic to and from resources in an Azure subnet based on source IP address, destination 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

A network security group (NSG) is the Azure resource that acts as a distributed virtual firewall for inbound and outbound traffic. It contains security rules that apply a priority, source/destination address, port, and protocol to explicitly allow or deny traffic at a subnet or network interface (NIC) level. By default, NSGs include built-in rules like allowing virtual network traffic and denying all internet-inbound traffic, but you can override these with custom rules. Associating an NSG with a subnet is the standard method for controlling traffic to and from resources inside that subnet.

Why this answer

A network security group (NSG) is the correct Azure feature because it acts as a stateful, distributed firewall that filters traffic to and from Azure resources in a virtual network. NSGs contain security rules that allow or deny inbound and outbound traffic based on source/destination IP address, port, and protocol (TCP, UDP, or ICMP). This directly matches the requirement to control traffic based on source IP, destination port, and protocol.

Exam trap

The trap here is that candidates often confuse route tables (which control traffic paths) with NSGs (which control traffic permissions), especially when the question mentions 'allow or deny traffic'—route tables never deny traffic, they only redirect it.

Why the other options are wrong

Route tables control network traffic routing paths, not allow/deny rules based on source IP, destination port, or protocol. They determine where traffic goes, not whether it is permitted.

A private DNS zone is used for custom domain name resolution within a virtual network, not for filtering traffic based on source IP, port, or protocol.

Azure Advisor provides recommendations for best practices in cost, security, reliability, and performance, but it does not allow or deny traffic based on source IP, port, or protocol.

Practice this question →

235

MCQmedium

An on-premises datacenter must reach private IP addresses in Azure over an encrypted site-to-site tunnel. The Azure VMs must not have public IP addresses, and the connection should use the company's existing edge device. Which Azure component should be deployed?

A.Azure Bastion

B.Azure VPN Gateway

C.Azure Route Server

D.A network security group with inbound allow rules

AnswerB

VPN Gateway terminates the encrypted site-to-site tunnel and enables private connectivity from on-premises to Azure VNets. It works with the on-premises edge device and allows access to Azure private IPs without assigning public IPs to the target VMs.

Why this answer

Azure VPN Gateway is the correct component because it provides an encrypted site-to-site IPsec/IKE tunnel between an on-premises network and Azure virtual networks. It supports policy-based or route-based VPNs, works with existing edge devices, and allows Azure VMs to remain without public IP addresses by routing traffic through the gateway's private IP space.

Exam trap

The trap here is confusing Azure Bastion (a secure access service) with a VPN gateway, because both involve 'secure connections' to Azure, but Bastion does not extend the on-premises network or support site-to-site tunneling.

Why the other options are wrong

Azure Bastion provides secure RDP/SSH access to VMs without public IPs, but it does not create an encrypted site-to-site tunnel from on-premises to Azure private IPs.

Azure Route Server is used for dynamic routing between network virtual appliances (NVAs) and Azure virtual networks, not for creating encrypted site-to-site tunnels to on-premises datacenters.

A network security group (NSG) filters traffic but does not provide encrypted site-to-site connectivity or routing between on-premises and Azure private IPs.

Practice this question →

236

MCQmedium

An administrator added an NSG rule named Allow-Admin-HTTPS with priority 250 to permit inbound TCP 443 from a single public IP. The NSG also contains a Deny-All-Inbound rule with priority 200. The administrator still cannot connect to the VM over HTTPS from the allowed IP. What should be changed to resolve the issue?

A.Change the allow rule priority to a number lower than 200.

B.Change the deny rule priority to 65000 so it is evaluated first.

C.Convert the allow rule to an outbound rule instead of inbound.

D.Replace the NSG with a route table so HTTPS can pass through the subnet.

AnswerA

NSG rules are evaluated in ascending priority order, so the lower number is processed first. Because Deny-All-Inbound at 200 is taking effect before the allow rule at 250, the connection is blocked. Moving the allow rule to a priority such as 150 ensures the specific HTTPS exception is matched before the broad deny rule.

Why this answer

The Deny-All-Inbound rule with priority 200 is evaluated before the Allow-Admin-HTTPS rule with priority 250 because NSG rules are processed in order of ascending priority (lower numbers are evaluated first). Since the deny rule matches all inbound traffic, it blocks the HTTPS connection before the allow rule can be evaluated. To resolve this, the allow rule must have a priority lower than 200 (e.g., 150) so it is evaluated first and permits the traffic from the specified public IP.

Exam trap

The trap here is that candidates often assume higher priority numbers mean higher precedence, but in Azure NSGs, lower priority numbers are evaluated first, so a deny rule with a lower number will block traffic before a higher-numbered allow rule can permit it.

Why the other options are wrong

In Azure, NSG rules are evaluated in priority order, with lower numbers evaluated first. A deny rule with priority 200 is evaluated before an allow rule with priority 250, so changing the deny rule priority to 65000 (a higher number) would cause it to be evaluated later, but the allow rule still has a higher priority number (250) than the deny rule (200), so the deny rule would still be evaluated first. The correct fix is to lower the allow rule priority below 200.

The issue is that the Deny-All-Inbound rule with priority 200 is evaluated before the Allow-Admin-HTTPS rule with priority 250, blocking the traffic. Changing the allow rule to outbound would not affect inbound HTTPS traffic, which is the problem.

Route tables control traffic routing between subnets and on-premises networks, not traffic filtering. They cannot permit or deny specific ports like HTTPS; NSGs are required for that.

Practice this question →

237

Multi-Selecteasy

Which two statements about network security group processing are correct? Select two.

Select 2 answers

A.NSG rules are evaluated starting with the lowest priority number.

B.An NSG can be linked only to a subnet, not to a network interface card.

C.A deny rule with a lower number can block traffic even if an allow rule exists later.

D.Azure ignores NSG rules whenever a route table is attached to the subnet.

E.Security rules are processed alphabetically by name.

AnswersA, C

Azure Network Security Group rules are evaluated in ascending priority-number order, so the rule with the smallest numeric value (for example, 100) is processed before rules numbered 200 or 1000. The first rule whose source, destination, port, and protocol match the traffic is applied, and no later rules are evaluated. This numeric priority design ensures deterministic, predictable filtering regardless of rule order in the portal or ARM template.

Why this answer

NSG rules are processed in order of increasing priority number, meaning the rule with the lowest priority number (e.g., 100) is evaluated first. This ensures that more specific or critical rules can be applied before broader rules with higher priority numbers.

Exam trap

The trap here is that candidates often confuse NSG rule processing order with alphabetical or sequential naming, or mistakenly believe NSGs cannot be applied to NICs, leading them to select options B or E instead of the correct priority-based evaluation logic.

Why the other options are wrong

An NSG can be linked to both a subnet and a network interface card (NIC), not just a subnet. This is a fundamental capability of NSGs in Azure.

Azure does not ignore NSG rules when a route table is attached. NSGs and route tables operate independently: NSGs filter traffic, while route tables control traffic routing. Both can be applied to the same subnet without conflict.

NSG rules are processed in priority order (lowest number first), not alphabetically by name. Rule names are for identification only and have no effect on evaluation order.

Practice this question →

238

MCQmedium

Based on the exhibit, which Network Watcher tool should you use to determine whether an NSG allows or denies TCP 1433 traffic and which rule is responsible?

A.IP flow verify

B.Connection troubleshoot

C.Packet capture

D.Next hop

AnswerA

IP flow verify is the correct choice because it evaluates a specific 5-tuple (source IP, destination IP, protocol, and source/destination ports) against the effective NSG rules applied to a virtual machine's NIC or subnet. It returns an explicit allow/deny result along with the rule ID that permitted or blocked the traffic, making it purpose-built for answering 'does this NSG allow this TCP flow?' Unlike broader connectivity tests, it isolates NSG rule evaluation as the sole decision factor, so you know exactly which rule is responsible.

Why this answer

IP flow verify tests a specific source/destination IP, port, and protocol (TCP 1433) against the effective NSG rules to report whether traffic is allowed or denied, and it identifies the exact NSG rule (name and priority) responsible for that decision. This makes it the correct tool for determining NSG rule impact on a specific traffic flow.

Exam trap

The trap here is that candidates confuse 'Connection troubleshoot' (which tests end-to-end connectivity) with 'IP flow verify' (which specifically tests NSG rule evaluation), leading them to pick B because they think connectivity checks include rule analysis.

Why the other options are wrong

Connection troubleshoot tests connectivity from a source VM to a destination, but it does not identify which specific NSG rule is allowing or denying traffic; it only reports overall reachability.

Packet capture captures network traffic for analysis but does not evaluate NSG rules against a specific traffic flow to determine if traffic is allowed or denied and which rule is responsible.

Next hop is used to determine the next hop type and IP address for a specific destination, not to check if NSG rules allow or deny traffic. It does not evaluate NSG rules.

Practice this question →

239

MCQmedium

A storage account must be reachable only from resources in a specific Azure subnet, and connections must not use the public endpoint. Which option should the administrator configure?

A.A service endpoint on the subnet, because it keeps traffic on the Azure backbone.

B.A private endpoint for the storage account in the subnet.

C.A NAT gateway attached to the subnet.

D.A storage firewall rule that allows all Azure services.

AnswerB

A private endpoint assigns the storage service a private IP address inside the selected virtual network subnet. Traffic then stays on private addressing instead of using the public endpoint, which is exactly what the requirement asks for. This also allows the administrator to restrict access to approved network locations while improving the security posture of the storage account.

Why this answer

A private endpoint assigns the storage account a private IP address from the subnet, effectively bringing the service into the virtual network. This ensures all traffic to the storage account stays within the Microsoft Azure backbone and never traverses the public internet, meeting the requirement that connections must not use the public endpoint.

Exam trap

The trap here is that candidates confuse service endpoints with private endpoints, assuming both provide the same level of isolation, but service endpoints still expose the public endpoint and do not give a private IP address.

Why the other options are wrong

A service endpoint does not prevent public endpoint access; it only ensures traffic from the subnet to the storage account stays on the Azure backbone, but the storage account still has a public endpoint that could be accessed from elsewhere.

A NAT gateway enables outbound internet connectivity for private subnets but does not restrict inbound access to the storage account from a specific subnet, nor does it eliminate the public endpoint.

A storage firewall rule allowing all Azure services permits connections from any Azure service, not just from the specific subnet, and still uses the public endpoint, failing to meet the requirement of no public endpoint access.

Practice this question →

240

MCQmedium

You need to allow SSH access to only one Linux VM in a subnet that contains several application servers. The other VMs in the subnet must remain inaccessible from the internet. What is the best configuration?

A.Add an inbound allow rule on the subnet NSG for TCP 22 from your admin IP address.

B.Associate an NSG with the target VM's NIC and add an inbound allow rule for TCP 22 from your admin IP.

C.Create a public load balancer in front of the subnet and forward port 22 to the VM.

D.Enable a service endpoint on the subnet so SSH traffic is limited to that VM.

AnswerB

An NSG associated directly with the target VM's network interface (NIC) applies its rules only to that NIC, so adding an inbound allow rule for TCP 22 from your admin IP explicitly permits SSH for that single VM while leaving every other NIC in the subnet unaffected. Because Azure's default rules deny all other inbound internet traffic, this NIC-level NSG creates the narrowest possible exposure: only the specified source IP can reach only the specified port on only the target VM. This is the proper least-privilege approach when you need to administer one specific Linux VM within a shared subnet.

Why this answer

Network Security Groups (NSGs) can be associated at the subnet or NIC level. By associating an NSG directly with the target VM's NIC and adding an inbound allow rule for TCP port 22 from your admin IP address, you restrict SSH access exclusively to that VM while leaving the other VMs in the subnet unaffected by the rule. This provides granular, host-level security without impacting the broader subnet traffic.

Exam trap

The trap here is that candidates often assume subnet-level NSG rules are sufficient for granular control, but they fail to recognize that a subnet NSG applies to all VMs in that subnet, whereas a NIC-level NSG provides per-VM isolation.

Why the other options are wrong

Applying the rule at the subnet NSG level would allow SSH access to all VMs in the subnet, not just the target VM, violating the requirement that other VMs remain inaccessible from the internet.

A public load balancer distributes traffic across multiple VMs, not restrict access to a single VM. It would expose all VMs behind it to SSH traffic if configured, and it adds unnecessary complexity and cost for a simple access control requirement.

Service endpoints secure Azure service traffic (e.g., to Storage or SQL) to a virtual network, not SSH access to a specific VM. They do not filter inbound internet traffic to VMs.

Practice this question →

241

MCQmedium

An administrator is deploying an Azure VPN gateway for a site-to-site connection. The deployment fails because required network resources are missing. Which configuration is required before the gateway can be created?

A.A subnet named GatewaySubnet and a public IP address for the VPN gateway.

B.A subnet named AzureBastionSubnet and a static private IP address.

C.A network security group attached directly to the virtual network gateway.

D.A load balancer with a public frontend to terminate the VPN connection.

AnswerA

Azure VPN gateways require a dedicated GatewaySubnet, which must be created within the virtual network with a name exactly 'GatewaySubnet', and at least one public IP address for the VPN gateway that serves as the endpoint for on-premises VPN devices. This public IP is assigned to the gateway and provides the external IP that the on-premises VPN device connects to. Without these, the gateway cannot be deployed or establish site-to-site tunnels. Also note that the public IP should be in the Basic or Standard SKU depending on gateway SKU, and it must be a dynamic allocation for Basic gateways.

Why this answer

A VPN gateway in Azure requires a dedicated subnet named 'GatewaySubnet' to host the gateway instances, and a public IP address resource must be allocated to the gateway to establish the site-to-site VPN tunnel over the internet. Without these two prerequisites, the deployment will fail because the gateway cannot be provisioned or addressed externally.

Exam trap

The trap here is that candidates often confuse the required subnet name 'GatewaySubnet' with other special subnets like 'AzureBastionSubnet' or 'AzureFirewallSubnet', leading them to select an incorrect option that seems plausible but serves a different purpose.

Why the other options are wrong

AzureBastionSubnet is required for Azure Bastion, not for a VPN gateway. A VPN gateway requires a subnet named GatewaySubnet and a public IP address, not a static private IP.

A network security group (NSG) cannot be attached directly to a virtual network gateway; NSGs are associated with subnets or network interfaces, not the gateway resource itself. The gateway requires a dedicated GatewaySubnet, not an NSG.

A load balancer is not required for a site-to-site VPN gateway; the gateway uses a public IP address for termination, not a load balancer. The missing resources are a dedicated GatewaySubnet and a public IP address.

Practice this question →

242

MCQhard

A VM named VM1 cannot establish TCP 1433 connectivity to VM2. The administrator wants to test the exact flow, confirm whether an NSG allows or denies it, and identify the rule that applies if the flow is blocked. Which Network Watcher tool should be used?

A.Effective routes, because it shows the exact NSG rule name for blocked traffic.

B.IP flow verify, because it evaluates the 5-tuple and reports the matching allow or deny rule.

C.Packet capture, because it automatically tells you which NSG rule denied the traffic.

D.Connection troubleshoot, because it only checks DNS name resolution.

AnswerB

IP flow verify is designed to test a specific source, destination, protocol, and port combination against NSG rules. It returns whether the flow is allowed or denied and identifies the rule that matched, which makes it the right tool when you need to prove whether TCP 1433 is blocked and why.

Why this answer

IP flow verify is the correct tool because it evaluates the 5-tuple (source IP, destination IP, source port, destination port, and protocol) against the effective Network Security Group (NSG) rules for a given virtual machine network interface. It explicitly reports whether the traffic is allowed or denied and, if denied, identifies the exact NSG rule (name and priority) that caused the denial. This directly meets the administrator's requirement to test the exact flow and identify the blocking rule.

Exam trap

The trap here is that candidates often confuse 'Connection troubleshoot' (which tests end-to-end connectivity and can indicate a block) with 'IP flow verify' (which explicitly identifies the exact NSG rule name that caused the denial), leading them to choose the less precise tool.

Why the other options are wrong

Effective routes show the effective route table for a VM, not NSG rules. They cannot identify the specific NSG rule that allows or denies traffic based on a 5-tuple.

Packet capture does not automatically identify which NSG rule denied traffic; it only captures raw network packets, requiring manual analysis to infer blocking.

Practice this question →

243

MCQhard

A VM in VNet B can reach a blob storage account through a private endpoint that was created in peered VNet A. The storage FQDN still resolves to the public IP when queried from VNet B, so the VM does not use the private path. What should the administrator change?

A.Add a service endpoint for Microsoft.Storage to VNet B

B.Link the private DNS zone used by the private endpoint to VNet B

C.Disable the storage account firewall completely

D.Move the storage account into VNet B

AnswerB

Private endpoint connectivity depends on DNS resolution returning the private IP address. In a peered virtual network, the DNS zone for the private endpoint must be linked so clients in VNet B resolve the storage name to the private address instead of the public one. Once that DNS path is corrected, traffic follows the private endpoint.

Why this answer

The private endpoint in VNet A creates a private IP for the storage account, but DNS resolution in VNet B still returns the public IP because the private DNS zone (privatelink.blob.core.windows.net) is not linked to VNet B. By linking the private DNS zone to VNet B, the VM will resolve the storage FQDN to the private IP, ensuring traffic uses the private endpoint path through the VNet peering.

Exam trap

The trap here is that candidates assume VNet peering automatically extends DNS resolution for private endpoints, but in reality, private DNS zones must be explicitly linked to each peered VNet to enable private IP resolution.

Why the other options are wrong

A service endpoint for Microsoft.Storage would route traffic to the public IP of the storage account, not to the private endpoint. The VM in VNet B already needs to resolve the storage FQDN to the private IP, which requires DNS resolution through the private DNS zone linked to VNet B.

Disabling the storage account firewall would not change DNS resolution; the VM in VNet B would still resolve the FQDN to the public IP because the private DNS zone is not linked to VNet B.

Moving the storage account into VNet B does not resolve the DNS resolution issue; the private endpoint's DNS zone must be linked to VNet B for the FQDN to resolve to the private IP.

Practice this question →

244

MCQmedium

Your company has an on-premises office network that needs encrypted connectivity to an Azure virtual network. In addition, traveling users need secure access from their laptops when they are away from the office. Which Azure design best meets both requirements?

A.Deploy a VPN gateway and configure both site-to-site and point-to-site connections.

B.Use VNet peering between the office network and Azure, then share the same connection with remote users.

C.Create a service endpoint to the virtual network and enable private access for laptops.

D.Deploy a NAT gateway and use it for secure office and laptop connectivity.

AnswerA

A VPN gateway supports both site-to-site tunnels for the office network and point-to-site access for individual users. This single design meets the hybrid branch requirement and the remote-user requirement without exposing the VNet directly to the internet. It is the standard Azure networking choice when you need encrypted connectivity from both networks and individual clients.

Why this answer

A VPN gateway supports both site-to-site (S2S) connections for the on-premises office network and point-to-site (P2S) connections for individual traveling users. The S2S connection uses IPsec/IKE to establish encrypted tunnels between the on-premises VPN device and the Azure VPN gateway, while the P2S connection uses SSTP, OpenVPN, or IKEv2 to allow remote laptops to connect securely from anywhere. This single gateway resource can handle both connection types simultaneously, meeting both requirements efficiently.

Exam trap

The trap here is that candidates confuse VNet peering (which only works between Azure VNets) with hybrid connectivity, or assume a single-purpose service like NAT gateway or service endpoint can replace a VPN gateway for encrypted remote access.

Why the other options are wrong

VNet peering connects two Azure virtual networks, not an on-premises network to Azure. It does not provide encrypted site-to-site or point-to-site connectivity, so it fails to meet both requirements.

Service endpoints provide private connectivity from a virtual network to Azure PaaS services, not from on-premises or remote laptops to the virtual network. They do not support site-to-site or point-to-site VPN connectivity.

A NAT gateway provides outbound internet connectivity for virtual networks but does not support encrypted site-to-site or point-to-site VPN connections. It cannot establish encrypted tunnels from on-premises offices or remote laptops to Azure.

Practice this question →

245

MCQmedium

VNet-Hub and VNet-Spoke1 are in the same region and subscription. Resources in the two VNets must communicate over the Microsoft backbone without using a VPN gateway. What should you configure?

A.VNet peering

B.A site-to-site VPN gateway in each VNet

C.A private endpoint

D.A service endpoint

AnswerA

VNet peering is the native Azure connectivity mechanism that links two virtual networks through the Microsoft backbone infrastructure, providing low-latency, private, and high-bandwidth communication without traversing the public internet. Because both VNets reside in the same region and subscription, you can simply enable peering between them, and the existing routing automatically allows resources in vnet spoke1 to reach resources in vnet hub with no additional gateway or encryption overhead.

Why this answer

VNet peering enables direct connectivity between two virtual networks in the same region and subscription over the Microsoft backbone, without requiring a VPN gateway or public internet. This is the correct solution because it provides low-latency, private communication using the Azure infrastructure, and it supports resources in both VNets to communicate as if they were on the same network.

Exam trap

The trap here is that candidates often confuse VNet peering with VPN gateways or service endpoints, mistakenly thinking a VPN gateway is required for cross-VNet communication or that service endpoints can connect VNets, when in fact VNet peering is the native, gateway-free solution for direct VNet-to-VNet connectivity within the same region.

Why the other options are wrong

A site-to-site VPN gateway requires traffic to traverse the public internet or a VPN tunnel, not the Microsoft backbone, and incurs additional cost and complexity. The question explicitly requires communication over the Microsoft backbone without a VPN gateway.

A private endpoint enables secure access to a specific Azure service (e.g., Azure SQL) from a VNet via a private IP, but it does not connect two VNets together. The question requires inter-VNet communication, which private endpoints cannot provide.

Service endpoints allow access to Azure PaaS services from a VNet over the Microsoft backbone, but they do not enable communication between two VNets. VNet peering is required for direct VNet-to-VNet connectivity.

Practice this question →

246

Matchingmedium

A team is troubleshooting inbound access to Azure VMs. Match each NSG concept on the left with the most accurate behavior or troubleshooting implication on the right.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

The priority 100 rule is evaluated first, so it wins if both rules match the same traffic.

It controls traffic entering the subnet or NIC from another network location.

It filters traffic for a single VM and can be used in addition to a subnet NSG.

It matches any ephemeral source port and does not limit the sender's port selection.

It allows only HTTPS traffic that uses TCP and the specified destination port.

Why these pairings

NSG is a distributed firewall; default inbound rule denies all; UDR overrides routes; ASG groups VMs; flow logs record traffic; service tags represent Azure IPs.

Practice this question →

247

MCQhard

You have an Azure load balancer in front of two virtual machines. The load balancer reports both instances as unavailable even though the VMs are running. What is the most likely cause?

A.The health probe is failing.

B.The VMs are in an availability set.

C.The storage account uses the Cool tier.

D.The subscription has a budget alert.

AnswerA

The health probe is failing. Azure Load Balancer continuously sends HTTP, TCP, or HTTPS probes to the configured backend pool endpoints. If the probe does not receive the expected response within the timeout interval, the load balancer marks that backend instance as unhealthy and stops routing new traffic to it, directly causing the symptom of unavailable virtual machines.

Why this answer

The health probe is the mechanism by which the Azure Load Balancer determines the availability of backend instances. If the probe is misconfigured (e.g., wrong port, protocol, path, or interval) or the backend VMs are not responding to the probe requests (e.g., firewall blocking the probe traffic or the application not listening on the specified port), the load balancer marks both instances as 'Unavailable' even though the VMs are running. This is the most common cause of backend pool unavailability.

Exam trap

The trap here is that candidates often assume 'VM is running' means it is automatically available to the load balancer, overlooking the critical role of the health probe configuration and the need for the probe traffic to be allowed by network security rules.

Why the other options are wrong

An availability set ensures high availability by distributing VMs across fault domains, but it does not affect load balancer health probe status. The load balancer reports instances unavailable due to health probe failures, not availability set membership.

The storage account tier (Cool vs. Hot) affects access cost and latency for blob storage, not the health of VMs behind a load balancer. The load balancer's health probe failure is unrelated to storage account configuration.

A budget alert does not affect load balancer health probe status; it only triggers cost-related notifications. The load balancer reports VMs as unavailable due to health probe failures, not subscription billing settings.

Practice this question →