CCNP Practice Question: Is deploying a new virtualized application on a…

Answer analysis

Option-by-option breakdown

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

• ✓

  Configure CPU affinity to pin the VM to specific physical cores.

  Why this is correct

  CPU affinity (often called core pinning) is the only mechanism that directly maps a VM's vCPUs to specific physical cores (pCPUs) in the hypervisor's CPU scheduler. By creating a 1:1 binding between each vCPU and a designated physical core, the hypervisor will not schedule any other vCPU or host process on those pinned cores, giving the VM exclusive, dedicated access. This is precisely what the network engineer needs for a latency-sensitive virtual network function, because it eliminates core-sharing contention and provides deterministic and consistent performance.

• ✗

  Set a CPU reservation equal to the number of vCPUs.

  Why it's wrong here

  A CPU reservation is a scheduling guarantee in the time domain: the hypervisor reserves a certain amount of CPU capacity (measured in MHz or clock cycles) for the VM, ensuring that it can always use that much CPU time when it needs it. However, this reservation does not bind the VM to any particular physical core, and other VMs or host workloads can still be scheduled on the same cores as long as the reserved CPU time is not exceeded by the combined usage. Therefore, a reservation prevents CPU starvation but does not provide exclusive ownership of physical cores, so other VMs can still interfere with the VM's performance through shared-core contention.

• ✗

  Enable NUMA node affinity for the VM.

  Why it's wrong here

  NUMA (Non-Uniform Memory Access) node affinity is a memory-locality optimization rather than a CPU-exclusivity control. When enabled, it instructs the hypervisor to run the VM's vCPUs and allocate its memory on the same NUMA node so that memory accesses avoid the slower cross-node interconnect. But NUMA affinity does not reserve the physical cores on that node for the VM alone; other VMs can still have vCPUs and memory on the same NUMA node and will share those cores with the VM. Thus, while this setting improves memory-access latency, it does nothing to guarantee that a VM gets dedicated physical cores as required in this scenario.

• ✗

  Configure a CPU limit equal to the number of vCPUs.

  Why it's wrong here

  A CPU limit sets an upper boundary on the amount of CPU time the VM is allowed to consume during a given interval, effectively throttling the VM when it exceeds the limit. This is the opposite of a reservation: it caps maximum usage, but it does not reserve any cores for exclusive use by the VM. In fact, other VMs can and will share the same physical cores with the VM, and the limit only restricts the VM's own consumption, not the hypervisor's ability to schedule other workloads on those cores. Consequently, a limit cannot deliver dedicated hardware resources, and it actually might degrade the VM's performance if the limit is set equal to its vCPU count.