Implement and manage virtual networking practice questions

Answer: A) Global VNet peering

• AGlobal peering connects VNets in different regions over the Microsoft backbone.
• BThat exposes VMs to the internet.
• CDNS doesn't create connectivity.
• DAvailability sets apply to VMs.

Answer: A) Enable the option to use the remote virtual network's gateway (Use remote gateways)

In a hub-and-spoke design, the hub peering allows gateway transit and the spoke peering is set to use remote gateways, so the spoke shares the hub's VPN gateway instead of deploying its own.

• ACorrect. The spoke side of the peering must be set to use the peered (hub) VNet's remote gateway; together with gateway transit on the hub side, this lets the spoke share the hub's VPN gateway and learn on-premises routes.
• BIncorrect. Allow gateway transit is configured on the peering of the VNet that owns the gateway (the hub). The spoke has no gateway to offer, so this setting on the spoke side doesn't let it use the hub's gateway.
• CIncorrect. This is a route table setting, not a peering setting, and it prevents routes learned from the VPN gateway from being distributed to those subnets, which would work against reaching on-premises.
• DIncorrect. Virtual network access must stay enabled for traffic to flow across the peering; turning it off blocks communication with the hub and therefore with the gateway.

Answer: A) Virtual appliance with that IP

• AA user-defined route with next hop type VirtualAppliance points to the appliance's IP.
• BThat sends traffic straight to the internet.
• CNone drops the traffic; that doesn't meet this requirement.
• DThat sends traffic to a VPN or ExpressRoute gateway.

Answer: A) On the hub-to-spoke peering, allow gateway transit; on the spoke-to-hub peering, use remote gateways

• AGateway transit lets the hub share its VPN/ExpressRoute gateway with peered spokes; each spoke must be set to use the hub's remote gateway (and can't have its own gateway).
• BThere is no 'internet gateway' object in Azure VNets, and spokes should route through the hub, not out directly.
• CThat defeats the hub-and-spoke design and multiplies cost; the point is to share the hub's gateway.
• DThat removes private connectivity entirely.

Answer: A) Azure Traffic Manager

• ATraffic Manager uses DNS to route client requests to the most appropriate endpoint based on a chosen routing method, such as performance (closest) or priority, across regions.
• BLoad Balancer operates at the regional/network layer for resources within a region, not global DNS-based routing across regions.
• CNSGs filter traffic by rule; they don't perform DNS-based global routing.
• DExpressRoute provides a private, dedicated connection from on-premises to Azure; it isn't a global traffic-routing service.

Answer: A) HA ports

• AHA ports load-balance all TCP and UDP flows on all ports, which suits NVAs.
• BPersistence keeps clients on the same backend; it doesn't cover all ports.
• CThat's unrelated to internal all-port balancing.
• DTraffic Manager routes by DNS.

Answer: A) The `Storage` service tag (optionally regionalized, e.g. Storage.WestEurope)

• AService tags represent Microsoft-managed groups of IP prefixes for a service and are updated automatically, so you reference `Storage` instead of hard-coding ranges.
• BThat would allow all outbound internet traffic, far broader than intended.
• CThat's exactly the manual upkeep service tags exist to remove, and it drifts out of date.
• DThat covers traffic within the VNet and peered networks, not the Azure Storage service.

Answer: A) Peering isn't transitive, so the A–B and B–C peerings don't connect A to C

VNet peering isn't transitive: A peered to B and B peered to C doesn't connect A to C. Either peer A and C directly, or route traffic through an NVA in the hub using UDRs and 'allow forwarded traffic'.

• AA peering connects only the two VNets in it. To let A and C communicate, either peer A with C directly, or send the traffic through an NVA in hub B. The NVA option needs user-defined routes pointing to the NVA, plus 'allow forwarded traffic' on the peerings.
• BGlobal VNet peering connects VNets across regions, and region isn't the problem here. Even with all three VNets in one region, A still couldn't reach C through B.
• CWhen peering allows virtual network access, the VirtualNetwork service tag includes the peered VNet. So the default AllowVnetInBound rule permits that traffic, as A-to-B connectivity already shows.
• D'Use remote gateways' lets a VNet use a VPN/ExpressRoute gateway or Route Server in the peered VNet. It doesn't make peering transitive, and the hub's own peerings can't be set to use a spoke's gateway this way.

Answer: A) Associate an Azure NAT Gateway with the subnet to provide a large, scalable pool of outbound SNAT ports

• ANAT Gateway gives predictable, high-scale outbound connectivity with far more SNAT ports than default outbound or a load balancer, eliminating port exhaustion for chatty egress workloads.
• BInbound rules don't affect outbound SNAT capacity.
• CThis works but is costly, hard to manage, and expands the attack surface; NAT Gateway is the recommended pattern.
• DSubnet size doesn't change SNAT port allocation.

Answer: A) Azure DNS Private Resolver

• AIts inbound endpoint lets on-premises DNS forward queries to Azure private DNS zones.
• BPublic zones are visible on the internet.
• COpening a port doesn't provide resolution.
• DTraffic Manager routes traffic by DNS, not private name resolution.