Configure and Manage vSphere Networking →mediumMultiple Choice

VCP-DCV Distributed Port Group Practice Question

An administrator is configuring a distributed switch for a cluster of ESXi hosts. The requirements are: VLAN 100 for production, VLAN 200 for management, and a separate VLAN 300 for vMotion. The management network should be isolated from production traffic. What is the best practice for configuring these networks on the distributed switch?

⚠ Common exam trap

VCP-DCV often tests the misconception that guest OS VLAN tagging or trunk port groups can substitute for properly segmented distributed port groups — candidates must remember VMkernel traffic cannot be VLAN-tagged at the guest level.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create three separate distributed port groups, each with the appropriate VLAN ID, and assign each VM kernel adapter or VM to the correct port group.

Best practice on a vSphere Distributed Switch is to create one distributed port group per VLAN/network function, each with its own VLAN ID, and attach the appropriate VMkernel adapters (management, vMotion) or VM vNICs to the correct port group. This provides clean traffic isolation, simplifies troubleshooting, and aligns with VMware's recommended design for separating management, vMotion, and production traffic.

Answer analysis

Option-by-option breakdown

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

✓
Create three separate distributed port groups, each with the appropriate VLAN ID, and assign each VM kernel adapter or VM to the correct port group.
Why this is correct
Three distributed port groups with VLAN IDs 100, 200 and 300 keep production, management and vMotion traffic logically separated at layer 2, isolating management from production while letting each VMkernel adapter or VM attach to its correct segment.
✗
Create one distributed port group with VLAN 100, and use VLAN tagging on the VMs for management and vMotion.
Why it's wrong here
Tagging inside guest VMs leaves the management and vMotion traffic sharing the production port group's broadcast domain, so isolation is not achieved. Guest tagging suits environments where a single uplink must carry many VLANs to external switches, not host-level traffic separation.
✗
Use standard switches for management and vMotion to avoid complexity.
Why it's wrong here
Standard switches cannot be centrally managed across the cluster, so per-host VLAN configuration must be replicated manually and the distributed switch's requirements go unmet. They suit single-host or small environments where centralised management and consistent policy across many hosts are not required.
✗
Create one distributed port group with VLAN trunk (4095) and use port-based VLAN filtering on the VMs.
Why it's wrong here
A single trunk port group with port-based VLAN filtering pushes VLAN separation onto guest OS tagging, so management and production traffic share one uplink and isolation is not enforced at the virtual switch. Trunking suits physical appliances or nested virtualisation needing many VLANs.
✗
Create two port groups: one for production (VLAN 100) and one for management+vMotion (VLAN 200) because vMotion can share VLAN with management.
Why it's wrong here
Incorrect: Management and vMotion should be on separate VLANs to avoid resource contention and security risks; sharing a VLAN is not a recommended best practice.

Visual reference

Go deeper

VCP-DCV Distributed Port Group Practice Question

Why each option matters

Option-by-option breakdown

Related to this question