Implement and Manage Virtual Networking practice questions

Set-AzVpnGateway -LoggingConfiguration

Why it fails: 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 it fails: Incorrect. 'Set-AzVNetGateway' is used to configure virtual network gateway settings, but it does not have a -DiagnosticLogging parameter.

Add-AzLogAnalyticsSolution

Why it fails: 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 it fails: 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 it fails: 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 Microsoft Entra ID, 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 it fails: 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 it fails: Azure Monitor is used for centralized logging and metrics, not for name resolution or traffic visibility.

Azure Firewall

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

Azure DNS

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

Azure Network Watcher

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

Azure Traffic Manager

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

Azure Backup

Why it fails: 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 it fails: 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 it fails: 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 it fails: NSG flow logs show allowed and denied traffic flows, not the effective route table.

Azure Policy compliance

Why it fails: Policy compliance does not show routing information.

Activity log

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Add a network security group rule that allows traffic to 10.20.4.12.

Why it fails: A network security group rule permits or denies traffic but does not change routing, so packets to 10.20.4.12 would still follow the 0.0.0.0/0 user-defined route to the virtual appliance. It is tempting because NSGs control traffic flow, but they operate after routing decisions, not on path selection.

Increase the priority of the 0.0.0.0/0 route so it is preferred less often.

Why it fails: Route priority cannot be raised or lowered in Azure; the system selects the longest prefix match, so 0.0.0.0/0 always loses to a more specific range. Priority manipulation is tempting because route metrics work that way in traditional networking, but Azure UDRs have no such weighting mechanism.

Remove the VPN gateway association from the virtual network.

Why it fails: Removing the VPN gateway association breaks all gateway connectivity, including the traffic that must reach 10.20.4.12 directly, without altering how the 0.0.0.0/0 route is evaluated. It is tempting because the gateway appears involved, but the fix belongs in route selection, not in detaching the gateway from the virtual network.

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

Why it fails: 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 it fails: 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.

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

Why it fails: Peering is nontransitive, so one peering does not automatically connect other peerings together.

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

Why it fails: Resource group boundaries do not change the overlap restriction for virtual network address spaces.

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

Why it fails: A gateway alone does not make peering transitive or create spoke-to-spoke reachability by default.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Azure VNet peering

Why it fails: VNet peering connects two Azure virtual networks over the Microsoft backbone; it cannot terminate a branch office's IPsec tunnel from an on-premises static public IP. It tempts when linking Azure VNets, but a VPN gateway is needed for site-to-site connectivity.

Service endpoint

Why it fails: A service endpoint extends the virtual network identity to an Azure PaaS service over the Azure backbone; it does not encrypt branch-to-Azure traffic nor provide site-to-site connectivity to private VMs. It tempts for securing storage or SQL access from a subnet, but the branch office sits outside the virtual network.

Azure Front Door

Why it fails: Azure Front Door is a global HTTP/HTTPS content delivery and load-balancing service for public web endpoints; it provides no site-to-site IPsec tunnel and cannot give branch users private access to VMs. It tempts when publishing public web apps, but a VPN gateway is required here.

Delete the Deny-All-Inbound rule.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Create a private endpoint in AppSubnet.

Why it fails: 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 it fails: 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 it fails: 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.