hardMultiple Choice
350-401 Practice Question: Deploying a virtualized firewall on a VMware ESXi…
A company is deploying a virtualized firewall on a VMware ESXi host. The firewall VM requires high network throughput and low latency. The engineer decides to use SR-IOV to assign a virtual function (VF) from a physical NIC to the VM. After configuration, the VM can communicate, but the host's management network becomes unreachable. What is the most likely cause?
⚠ Common exam trap
Cisco often tests the misconception that SR-IOV requires a dedicated management NIC, but the real issue is that the same PF cannot serve both management and SR-IOV VFs without disruption.
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
✓
The physical NIC's PF is also used for the host management network, and SR-IOV configuration disrupted it.
When SR-IOV is enabled on a physical NIC, the Physical Function (PF) is shared between the host management network and the Virtual Functions (VFs). If the PF is used for the host management network, enabling SR-IOV can disrupt the PF's driver or configuration, causing the management network to become unreachable. This is a common misconfiguration where the same NIC is used for both management and SR-IOV VFs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The physical NIC's PF is also used for the host management network, and SR-IOV configuration disrupted it.
Why this is correct
The host's management network is typically bound to a VMkernel adapter placed on a virtual switch whose uplink is the physical NIC's Physical Function (PF). When SR-IOV is enabled on that same NIC, the system often needs to reset or reconfigure the PF driver, which can temporarily remove the uplink from the vSwitch or change its queue and ring settings. That disruption makes the VMkernel adapter lose link and renders the ESXi host unreachable via the management IP. This is not a VM forwarding issue but a loss of the PF's own network capability.
- ✗
The VM's VF is using the same MAC address as the host management interface.
Why it's wrong here
Under SR-IOV, each Virtual Function is assigned a unique MAC address by the physical NIC's hardware, and this address is typically a variation of the PF's MAC with a distinct offset; hence, a collision with the host management interface is impossible. The VFs are PCIe functions presenting their own MAC in the VM, and the host's VMkernel adapter also uses its own MAC, so there is no reason they would share an address. A mismatch or duplicate MAC in SR-IOV would also be a configuration error outside normal operation, and even then it would produce an IP conflict, not the sudden loss of management that stems from PF disruption.
- ✗
The ESXi host requires a dedicated physical NIC for management when using SR-IOV.
Why it's wrong here
ESXi does not mandate a separate physical NIC for management when SR-IOV is enabled; the management VMkernel adapter can remain on a standard or distributed virtual switch that uses the PF as its uplink, provided the PF's link remains intact. Many administrators do dedicate a NIC for management as a best practice, but this is a design choice, not an SR-IOV requirement. Since the issue is specifically that the PF was disrupted by enabling SR-IOV, the remedy is to fix the PF configuration or move management to another port, not to assume a dedicated NIC is always needed.
- ✗
The VM's VF is consuming all available bandwidth on the NIC.
Why it's wrong here
A VF can never 'consume all available bandwidth' on a physical NIC to the point of killing the PF's management traffic because each VF has its own transmit and receive queues and is subject to NIC-level traffic shaping; even a fully saturated VF will only degrade performance on the link, not sever the PF's Layer 2 connectivity. Management traffic from the host is sent through the PF's own queue, which is separate from VF queues, so the VM's bandwidth usage does not directly shut off management. If the management address became unreachable, that is a sign of a link-level or PF driver failure, not mere congestion.
Go deeper
Related to this question
About these practice questions
One of 1,923 original 350-401 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.