350-401 Practice Question: An enterprise is deploying a virtualized network…

Answer analysis

Option-by-option breakdown

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

• ✗

  Enable CPU overcommitment to allow the VNF to use any available CPU cycles.

  Why it's wrong here

  Enabling CPU overcommitment lets the hypervisor schedule multiple vCPUs on shared physical cores, which can cause unpredictable latency and throughput because a VNF's packets may stall behind other tenants' workloads. High-throughput SD-WAN VNFs require deterministic, line-rate processing, so this lack of guaranteed CPU capacity directly violates the strict performance SLA. Additionally, overcommitment can disrupt NUMA locality and cache residency, degrading forwarding performance further. Therefore, while overcommitment maximizes host utilization, it is an inappropriate performance strategy for production VNFs.

• ✓

  Configure NUMA pinning and CPU pinning to dedicate physical cores to the VNF's virtual CPUs.

  Why this is correct

  Configuring NUMA pinning and CPU pinning dedicates physical CPU cores and ensures their memory is allocated on the same NUMA node, giving the VNF exclusive, non-overlapping access to compute resources. In KVM, NUMA pinning binds each virtual CPU to a specific host core and the VM’s memory to a local NUMA node, avoiding expensive remote memory accesses and eliminating hypervisor scheduler contention. This deterministic resource allocation is essential for high-throughput SD-WAN VNFs, which need stable forward rates and low jitter under load. It is the recommended NFV performance practice over any other tuning option.

• ✗

  Use VMware vSphere instead of KVM for better VNF performance.

  Why it's wrong here

  Switching from KVM to VMware vSphere would not address the underlying issue because the question specifically asks how to optimise a KVM-based VNF, and both hypervisors support CPU and NUMA pinning techniques. The real bottleneck is the lack of dedicated, non-overcommitted CPU resources, not the hypervisor vendor; without pinning, even vSphere would expose the VNF to scheduler contention and remote memory latency. In an SD-WAN edge NFV platform, the chosen hypervisor is often fixed by the vendor, and replacing it introduces operational complexity without guaranteeing performance gains. Therefore, the correct action is to tune KVM’s pinning features rather than change hypervisors.

• ✗

  Increase the number of virtual CPUs assigned to the VNF to improve throughput.

  Why it's wrong here

  Simply increasing the number of virtual CPUs assigned to a VNF usually fails to improve throughput because packet-processing workloads are often pinned to specific queue/interrupt cores, and extra vCPUs may all contend for the same physical cores unless pinning is configured. Adding vCPUs without pinning increases scheduler activity, cache thrashing, and context switching, which can actually degrade forwarding performance and introduce jitter. Throughput in NFV depends more on deterministic core allocation, memory locality, and I/O efficiency than on raw vCPU count. So merely enlarging the vCPU pool ignores the real cause of poor performance and can make things worse.

Go deeper

Related to this question