350-401 Virtualization Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the same VLAN for all tenants and rely on VLAN ACLs.

  Why it's wrong here

  VLAN ACLs operate at Layer 2 and filter traffic within a broadcast domain; they cannot maintain separate routing tables or forwarding decisions per tenant. If all tenants share the same VLAN, their IP subnets and MAC addresses are visible to one another at the data-link layer, and VACLs cannot prevent ARP spoofing or other L2 attacks. Moreover, VACLs cannot resolve overlapping IP address spaces because they rely on a single L3 forwarding context, so the isolation required for multi-tenancy is fundamentally unavailable.

• ✓

  Create trunk links with 802.1Q subinterfaces on each switch and assign each subinterface to the appropriate VRF.

  Why this is correct

  Creating an 802.1Q trunk with subinterfaces lets each switch or router terminate multiple VLANs on a single physical link, and each subinterface can be explicitly bound to a tenant's VRF. This gives each tenant an isolated routing table; the switch will route packets received on a subinterface using only the routes in that subinterface's assigned VRF. The trunk carries tagged frames for all tenants, but the VRF association ensures that traffic from tenant A's VLAN never enters tenant B's routing path, even though they share the same physical ports and trunk. This is a standard VRF-lite design for inter-switch VRF connectivity.

• ✗

  Configure static routes on each switch pointing to the next-hop IP in the global routing table.

  Why it's wrong here

  Static routes placed in the global routing table are unaware of VRFs and cannot direct traffic that arrives on a VRF-aware interface. Even if the route points to a valid next hop in the global table, packets from a VRF will be dropped because the VRF's routing table has no corresponding route or because the next hop is not reachable from that VRF's context. Additionally, with overlapping subscriber addresses, a single global route is ambiguous and cannot select the correct egress interface. The fix would be to define separate static routes inside each VRF, not in the global table.

• ✗

  Enable OSPF with a single area on all switches and redistribute between VRFs.

  Why it's wrong here

  OSPF running in a single area without VRF-aware configuration builds one LSDB and one SPF tree for the entire device, so it cannot distinguish tenant A's routes from tenant B's routes. Redistribution between VRFs is not a native OSPF feature; it requires route leaking between VRFs, which violates the isolation VRFs are meant to enforce and can cause routing loops if not carefully filtered. Furthermore, OSPF's router ID and neighbor relationships are global by default, so you cannot run multiple independent OSPF instances for each tenant without enabling VRF-lite (per-VRF OSPF process). Therefore, a single-area OSPF approach cannot provide the per-tenant segregation this multi-tenant network demands.

Go deeper

Related to this question