Implement and Manage Virtual Networking practice questions

Set-AzVpnGateway -LoggingConfiguration

Why wrong: Incorrect. 'Set-AzVpnGateway' is used to modify VPN gateway properties like SKU or connections, but it does not have a -LoggingConfiguration parameter for sending logs to Log Analytics.

Set-AzVNetGateway -DiagnosticLogging

Why wrong: Incorrect. 'Set-AzVNetGateway' is used to configure virtual network gateway settings, but it does not have a -DiagnosticLogging parameter.

Add-AzLogAnalyticsSolution

Why wrong: Incorrect. 'Add-AzLogAnalyticsSolution' installs a management solution (e.g., 'Azure VPN Gateway' solution) into a Log Analytics workspace, but it does not configure diagnostic settings for individual resources; diagnostic settings must be created separately.

Both features do the exact same job, so using both is redundant.

Why wrong: Access controls are proactive—they enforce who can perform which actions through policies like least privilege and Conditional Access—whereas centralized logging is reactive, collecting telemetry to detect, investigate, and respond to events after they occur. These controls address different phases of the security lifecycle: prevention versus detection/investigation. Because they target distinct risks and provide separate layers of defense, using both is complementary, not redundant, and is a fundamental practice in Azure security.

NSG flow logs remove the need for authentication.

Why wrong: Logs are detective controls that record events, but they do not verify identity or authorize actions—that is the role of authentication and authorization mechanisms like Azure AD, managed identities, and service principals. Removing authentication would allow unrestricted access to resources, and although logging would capture the resulting activity, it would be too late to prevent destructive changes, data exfiltration, or configuration tampering. Centralized logging must therefore be paired with preventive access controls to be effective.

Azure RBAC makes log timestamps irrelevant.

Why wrong: Even with strong access controls, logs remain essential for compliance audits, incident response, and detecting anomalous usage patterns such as impossible travel or unusual resource access. Timestamps are critical for correlating events across resources and reconstructing the precise sequence of a security incident, regardless of how effective authentication is. Logs also capture insider threats, misconfigurations, and compromised accounts that bypass access controls, so timestamped logging is never irrelevant in a well-governed Azure environment.

Azure Monitor

Why wrong: Azure Monitor is used for centralized logging and metrics, not for name resolution or traffic visibility.

Azure Firewall

Why wrong: Azure Firewall filters traffic based on rules but does not provide traffic pattern visibility.

Azure DNS

Why wrong: Azure DNS provides name resolution and is not used for log collection.

Azure Network Watcher

Why wrong: Azure Network Watcher provides network diagnostics and monitoring tools but does not centralize VM performance and activity logs for querying.

Azure Traffic Manager

Why wrong: Azure Traffic Manager is a DNS-based traffic load balancer and is not used for log collection.

Azure Backup

Why wrong: Incorrect: Azure Backup is designed for data protection and recovery, not for streaming operational updates. It operates on a schedule or on-demand basis, not as a subscription for real-time changes.

Azure Network Watcher

Why wrong: Incorrect: Azure Network Watcher provides tools for monitoring, diagnosing, and analyzing network traffic, but it does not offer a subscription-based push mechanism for configuration changes. It typically requires active polling or manual triggers.

Azure Virtual Network peering

Why wrong: Incorrect: Azure Virtual Network peering is used to connect virtual networks, enabling traffic between them. It does not provide subscription-based streaming of operational updates.

NSG flow logs

Why wrong: NSG flow logs show allowed and denied traffic flows, not the effective route table.

Azure Policy compliance

Why wrong: Policy compliance does not show routing information.

Activity log

Why wrong: The activity log shows control-plane events, not active route entries on a NIC.

The NIC allow rule can override a deny decision already made by the subnet NSG.

Why wrong: NSG evaluation is not 'first match wins' across scopes in a way that a NIC allow can override a subnet deny. Once a rule in the effective NSG set (combined from both NSGs) denies a packet, that deny is final and no later allow rule is considered. Because both NSGs are combined and processed as one ordered set, a subnet-level deny with a lower priority number will block the packet before the NIC allow rule with a higher priority number is reached.

Both the subnet NSG and the NIC NSG are evaluated, and a deny in either one blocks the packet.

Why wrong: When a subnet and a NIC each have an NSG, Azure aggregates all rules from both NSGs into the effective NSG rule list, sorted by priority. A denied packet from either NSG will be blocked because both NSGs must allow the traffic; if any matching deny rule exists, the packet is dropped. This is why the effective security result is the intersection of allows, and a deny at either scope is sufficient to block.

The allow rule must use a private IP source range because public source ranges are not valid in NSG rules.

Why wrong: NSG source and destination fields accept any valid IPv4 or IPv6 CIDR, including public IP ranges, private RFC 1918 addresses, specific service tags (like Internet), and application security groups. There is no restriction preventing public source ranges in an NSG rule. The traffic from the internet can be matched with a public IP prefix; the issue in the scenario is about priority and deny behavior, not the type of source range.

A user-defined route with next hop Internet would bypass the NSG deny and restore access.

Why wrong: A user-defined route (UDR) influences the next hop for traffic, such as sending it to the Internet via a virtual appliance or the default Internet route, but it does not affect NSG filtering. NSG rules evaluate traffic after routing decisions are made; the deny rule still applies to the packet regardless of its next hop. You cannot use a UDR to get around an NSG deny; instead, you would need to adjust the NSG rules themselves.

A service endpoint on the subnet and a public firewall rule on the SQL server.

Why wrong: Service endpoints keep traffic on the Microsoft backbone, but they do not give the service a private IP in your VNet. A public firewall rule also conflicts with the requirement to avoid the public endpoint.

A network security group rule that denies all public internet traffic to the subnet.

Why wrong: An NSG rule that denies public internet traffic to the subnet filters packets at the network interface or subnet layer, but it cannot turn the Azure SQL Database public endpoint into a private endpoint. The workload would not be able to reach the SQL server's public IP at all, and even if it could, the traffic would still traverse the public endpoint rather than a VNet-private IP. No private IP is assigned to the SQL resource, and no private DNS zone is created, so name resolution still returns the public address.

A NAT gateway on the subnet so the SQL connection uses a private source address.

Why wrong: A NAT gateway only performs outbound source network address translation for subnets that lack public IPs, translating private source addresses to the NAT gateway's public IP. It does not assign Azure SQL Database a private IP inside the VNet, nor does it change DNS resolution so that the server name maps to a private address. Connections from the workload would still target the SQL public endpoint, so this does not meet the requirement for private connectivity.

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

Why wrong: A service endpoint for Microsoft.Storage on the subnet does not place the storage service on a private IP inside the VNet; it only optimizes routing so the subnet's traffic to the public storage endpoint remains on the Azure backbone. The storage account continues to expose a public endpoint, and the VM would still resolve the file FQDN to a public IP unless separate DNS is also forced. This fails the requirement of a private address and does not meet the same isolation, data-exfiltration protection, or flat private-path guarantee that a private endpoint provides.

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

Why wrong: The Storage File Data SMB Share Reader role grants the VM's managed identity permission to read the file share over SMB once a valid authenticated session is established, but it has no effect on network connectivity. The role cannot create a private endpoint, assign a private DNS zone, or cause the storage account to resolve to a private IP. Authorization and network path are separate layers; without the private connectivity configured, the identity would still be reaching the share via the public endpoint.

Enable a service endpoint for Microsoft.Sql on the subnet instead of using a private endpoint.

Why wrong: A service endpoint for Microsoft.Sql adds the VNet subnet to the SQL service's routing table but does not create any private IP; it still sends traffic to the public endpoint of the logical server. This reduces routing over the internet but does not satisfy the requirement for a private endpoint address and does not protect against data exfiltration to other SQL servers that accept the service endpoint.

Leave public network access enabled and add the VNet as an allowed firewall rule.

Why wrong: Enabling public network access and adding the VNet as a firewall rule keeps the SQL server reachable through its public address; the firewall rule simply permits traffic sourced from the VNet's IP ranges. This conflicts with the private-IP-only stipulation, because connections are still handled by the public endpoint and the server remains publicly discoverable and potentially exposed if the rule is misconfigured.

A public Standard Load Balancer with outbound rules for the backend pool.

Why wrong: Outbound rules can provide SNAT, but this is not the simplest or most direct option when you want a single static outbound IP for a subnet. Load balancers are usually chosen for inbound distribution as well.

A public IP address on each virtual machine so all outbound traffic is traceable.

Why wrong: Assigning a public IP to each backend VM makes every instance directly reachable from the internet, exposing management ports and services to inbound traffic and contradicting the backend tier's isolation requirement. Even if network security groups restrict inbound traffic, the VMs will still perform source NAT to multiple distinct public IPs instead of a single static outbound address. This destroys the predictability needed for a single SNAT address and forces per-VM IP management for allow-lists and monitoring, so it does not meet the outbound-only, single-egress-IP design.

An internal load balancer with a private frontend IP.

Why wrong: An internal load balancer has a private frontend IP that only routes inbound traffic inside the virtual network, such as front-end to back-end communication. It has no public-facing frontend and cannot perform source NAT to the internet, so backend VMs would still need a separate outbound path. Thus, this option would not provide the required outbound internet access, let alone a single static public outbound address, and would be worse than doing nothing for egress.

User-defined routes never apply to peered networks.

Why wrong: User-defined routes do apply to traffic in a subnet, but they can lose to a more specific route for the destination prefix.

NSG rules always override any route table entry.

Why wrong: NSGs filter traffic after routing decisions and do not determine the next hop. They cannot replace route selection behavior.

Peering only works when both VNets are in the same region.

Why wrong: VNet peering can be global, so the region does not explain the route selection result shown by Network Watcher.

Add a route table to VNet-B so traffic can bypass the overlap.

Why wrong: A user-defined route table changes the next hop for packets within a single VNet by overriding the system routes, but it cannot alter the address space advertised by the VNet or the peering validation logic. If VNet-B's CIDR overlaps VNet-A's, packets destined for that range are inherently ambiguous: Azure cannot decide whether to deliver them locally or across the peer. Creating a route table in VNet-B only affects that VNet's local routing decisions; it does not change the overlapping prefix or make the peering creation success.

Create a network security group rule to allow all traffic between the VNets.

Why wrong: A Network Security Group (NSG) filters traffic by IP address, port, and protocol at the subnet or network interface level, but it has no role in peering provisioning or routing table construction. Azure VNet peering validates the full defined address spaces of both VNets and will return a hard failure if they overlap, because the platform must create unambiguous routes between them. An NSG rule permitting all traffic cannot resolve an overlapping CIDR conflict; the peering connection itself will still be rejected before any traffic can flow.

Enable gateway transit on VNet-A so the address conflict is ignored.

Why wrong: Gateway transit is a peering property that allows a peered VNet to route traffic through the virtual network gateway of the hub VNet to reach on-premises or other networks. However, it is only usable after a peering relationship has been successfully established, and it does not exempt either VNet from the address space uniqueness requirement. The overlapping CIDR conflict is a validation error at peering creation time, not a routing behavior that gateway transit can override; enabling gateway transit on VNet-A would have no effect until the underlying overlap is resolved.

Delete the Deny-All-Inbound rule.

Why wrong: Deleting the Deny-All-Inbound rule eliminates the catch-all block that prevents any unsolicited inbound traffic, exposing the VM to potentially malicious connections from the internet. The security goal is to allow only specific admin HTTPS access, and that can be achieved by reordering the existing rules so the allow rule is evaluated first. Removing the deny rule would require adding another restrictive rule to maintain the same level of protection, making it a broader change than necessary.

Change Allow-HTTPS-Admin protocol from TCP to Any.

Why wrong: The HTTPS test traffic is already TCP 443, so broadening the protocol to Any changes nothing about which rule is evaluated first. NSG rules are processed in priority order from lowest number to highest, and the Deny-All-Inbound rule at priority 200 is checked before Allow-HTTPS-Admin at priority 250. Even with a protocol of Any, the deny rule still matches and blocks the connection, so the true fix is to lower the allow rule's priority number.

Move the allow rule to outbound traffic.

Why wrong: Inbound and outbound NSG rules are separate rule sets, and the admin's HTTPS connection enters the VM through the inbound path. Moving the allow rule to outbound means it only applies to traffic originating from the VM, so the inbound packets from the workstation are still subject to the inbound Deny-All-Inbound rule at priority 200. Furthermore, the deny rule is explicitly inbound, so an outbound allow rule cannot influence that evaluation.

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

Why wrong: A rule based on the current Web subnet address range is static and overly broad: it covers every VM in the subnet, not just the web-tier workload, and it does not adapt automatically as the scale set scales out or if address ranges change. Even though new instances may inherit IPs from that range, the rule also permits traffic from unrelated VMs sharing the subnet, violating least-privilege. An application security group instead ties membership to the VM's network interface, so the rule follows the workload's actual instances automatically without relying on CIDR bookkeeping.

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

Why wrong: A load balancer NAT rule translates inbound internet traffic to a specific port on an individual VM, which is unrelated to authorizing internal communication from the web tier to the app tier. It would expose the app tier directly from the internet—exactly what the existing deny rule is meant to prevent—and it does not reference the source web tier at all. Because NAT rules are processed before NSG rules and do not themselves permit internal traffic, they cannot replace an inbound ASG-based allow rule for TCP 8443 within the virtual network.

A service endpoint for Microsoft.Web on both subnets.

Why wrong: Service endpoints such as Microsoft.Web are designed to secure outbound traffic from a virtual network to Azure PaaS services, not to govern or filter east-west traffic between VMs inside the same VNet. Adding that endpoint to the web and app subnets would only affect routing/access to App Service instances or similar services, and it does not create any allow rule for TCP 8443 between the two application tiers. The allow decision remains entirely in the network security group, so this option has no bearing on the requirement.

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

Why wrong: Adding a 0.0.0.0/0 UDR with the VPN gateway as next hop and disabling gateway propagation would blackhole or tunnel all egress traffic, including internet-bound traffic, through the on-premises VPN. This directly violates the stated requirement that only on-premises traffic should traverse the VPN while internet traffic stays direct; it also risks asymmetric routing because the VPN gateway may not be configured to forward arbitrary internet traffic back to the subnet. Disabling gateway propagation further removes any BGP-learned routes, which can break the very VPN connectivity you rely on.

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

Why wrong: A service endpoint does not function as a routing next hop for arbitrary prefixes; it creates a direct, optimized path from the subnet to a specific Azure PaaS service using its service tag. The next hop for a service endpoint is not a VPN gateway, and the endpoint applies only to addressed Azure service traffic, not to general on-premises or internet destinations. Therefore, this option cannot force on-premises traffic through the VPN and would leave the standard internet route in place.

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

Why wrong: Network Security Group rules operate as a stateful firewall at the subnet or NIC level; they evaluate allowed source/destination IPs, ports, and protocols, but they never influence the routing table. The decision of whether traffic goes to a VPN gateway is made by the effective route table based on the destination IP prefix, not by an NSG allow/deny rule. Even if an NSG blocks all internet traffic, it cannot cause on-premises traffic to be sent through the VPN; the route table is the only mechanism that selects the next hop.

/28

Why wrong: A /28 subnet provides too few usable addresses after Azure reservations. It cannot support about 30 VM NICs.

/27

Why wrong: A /27 subnet has 32 total addresses, but Azure reserves 5 of them, leaving only 27 usable addresses. That is still short of the requirement for about 30 VM NICs.

/25

Why wrong: A /25 subnet would also work, but it uses more address space than necessary. For an easy planning question, the smallest prefix that meets the need is the better answer.

Create a private endpoint in AppSubnet.

Why wrong: Creating a private endpoint in AppSubnet gives the storage account a private IP address inside the subnet and redirects all connections to that address over the Microsoft backbone, which is exactly the private-IP approach the administrator said they do not want. This changes the network path from the public endpoint to a private one and requires additional configurations such as a private DNS zone and endpoint approval on the storage account. It is a valid isolation option, but it contradicts the explicit constraint in the scenario.

Disable public network access on the storage account.

Why wrong: Disabling public network access on the storage account enforces the 'Disabled' network access setting, which drops all traffic through the storage account's public endpoint, including traffic from AppSubnet that would otherwise be permitted by a service endpoint and firewall rule. The scenario explicitly requires the application to access storage over the public endpoint path, so this setting would satisfy isolation but break the required connectivity. It is meant for private-endpoint-only architectures, not for service-endpoint-based designs that still use the public endpoint.

Assign a public IP address to the storage account.

Why wrong: A storage account is an Azure platform-as-a-service resource exposed through a shared public endpoint DNS name such as 'accountname.blob.core.windows.net'; it is not a virtual machine or network interface, so a public IP address cannot be assigned to it. The storage account already has a public endpoint that resolves to Microsoft-managed infrastructure, and access control is performed via firewall rules, service endpoints, or private endpoints, not by attaching an IP resource. Attempting to assign a public IP would fail at the Azure control plane because this resource type does not support that property.

A service endpoint on the subnet

Why wrong: Service endpoints still use the storage account's public endpoint, so the traffic is not private IP based.

A shared access signature scoped to the subnet

Why wrong: A SAS controls authorization only; it cannot restrict access to a subnet by itself.

Allow trusted Microsoft services on the storage firewall

Why wrong: This opens access to many Microsoft services and does not limit access to one specific subnet.

Detach the subnet from the NAT gateway.

Why wrong: The NAT gateway is the intended outbound mechanism for the subnet; detaching it would remove the public IP-based egress path and leave only the virtual appliance route or Azure's default outbound behavior. Doing so would not resolve the override caused by the 0.0.0.0/0 UDR—it would actually remove the valid alternative to the appliance, making outbound connectivity less reliable. The problem is the route table, not the NAT gateway's association, so detaching is counterproductive.

Change the route table source address to 10.1.0.4.

Why wrong: Route tables in Azure do not use a 'source address' field; they contain route entries defined by an address prefix (destination) and a next-hop type, such as virtual appliance, virtual network, or internet. Modifying a nonexistent source-address property is invalid and cannot change how the subnet selects an outbound path. Furthermore, even if you intended to adjust the routing table, the correct action would be to remove or replace the 0.0.0.0/0 route, not to alter a source attribute, since the virtual appliance route still takes precedence for internet traffic.

Enable a service endpoint on the subnet.

Why wrong: Service endpoints provide private, direct connectivity to supported Azure PaaS services (such as Storage or SQL) over the Azure backbone, but they do not alter the subnet's routing for general internet traffic. They also do not influence how the NAT gateway selects outbound paths, as service endpoints operate at the application layer for specific service resources rather than at the IP routing layer. Enabling a service endpoint therefore has no effect on the default route conflict caused by the 0.0.0.0/0 UDR to the virtual appliance.