An AHV cluster needs two application VLANs, 100 and 200, to reach VMs over the same physical NIC. What should the administrator do so both VLANs can traverse that interface?
Select an answer to reveal the explanation.
Short Explanation
Think of a single cable like a shared hallway: VLAN tags are name badges. You don't build two hallways just because two teams share the door; you let the bridge accept both VLAN IDs. The trap is thinking a bond or Flow does VLAN trunking — it doesn't.
Full Explanation
A single physical interface can carry traffic for several VLANs when the AHV bridge is configured to accept the relevant VLAN IDs. In that model, frames arrive tagged, the bridge forwards them according to their VLAN membership, and virtual machines attached to the bridge can communicate on each permitted VLAN without requiring a separate physical path. This is the normal way to support trunked VLAN traffic across one NIC while preserving logical separation. Creating a separate bridge for each VLAN is unnecessary when the bridge can carry multiple VLAN IDs; it adds configuration overhead and does not solve the need for tagged traffic on one interface. Using a bond instead of a bridge confuses link aggregation or redundancy with VLAN trunking, because bonding only combines physical NICs and still requires VLAN-aware bridging for multiple VLANs. Enabling Flow policy addresses microsegmentation and traffic control, not the underlying network requirement to transport multiple VLANs across the same interface. Exam caveat: answer the mechanism asked, not a nearby feature that also belongs to AHV networking. Operational check: confirm the bridge permits both VLAN IDs and that the upstream switch port is trunked or otherwise configured to carry those VLANs.