350-401 Practice Question: Is troubleshooting a performance issue with 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.

• ✗

  The vFW is CPU-bound, but the monitoring is inaccurate.

  Why it's wrong here

  This is incorrect because the vFW's CPU utilization is actually low in the scenario, not high. A CPU-bound condition would generate sustained high usage on the vFW vCPU and typically produce visible processing delays or drops directly tied to CPU saturation. Inaccurate monitoring could obscure the metric, but it cannot hide the pattern of heavy CPU demand; instead, the observed low CPU usage points away from a CPU bottleneck and toward the host's memory issue as the real cause.

• ✗

  The host's CPU is oversubscribed, causing vCPU starvation.

  Why it's wrong here

  This is wrong because the host is not oversubscribed on CPU; the symptom of high host memory usage is unrelated to CPU allocation. If vCPU starvation were occurring, the vFW would exhibit high 'ready' time or steal time, and the guest would likely show high CPU wait rather than low CPU usage. Furthermore, CPU starvation would affect all VMs on the host broadly, while the packet loss reported here is specific to the vFW, aligning far more closely with a memory-reclamation event.

• ✓

  The host is under memory pressure, causing the hypervisor to swap or balloon memory from the vFW.

  Why this is correct

  This is correct because high host memory usage triggers the hypervisor's memory-reclaim mechanisms, such as ballooning or swapping out guest pages, to free memory for other workloads. When the vFW's memory is inflated or its pages are swapped, the guest OS may have to fault pages back in, adding significant latency to its data-plane processing. This increased latency can cause the vFW to drop packets because it cannot process traffic fast enough, even though the vFW's own memory usage appears normal from inside the guest.

• ✗

  The vFW's packet buffer is exhausted, but the monitoring does not show it.

  Why it's wrong here

  This is incorrect because packet buffer exhaustion would be a guest-level condition that typically appears as ingress drops or queue discards in the vFW's interface counters and logging; monitoring rarely fails to show such drops entirely. Additionally, packet buffer exhaustion would not explain the host's high memory usage, which is the distinguishing symptom in this scenario. The host's memory pressure and the hypervisor's subsequent reclamation of vFW memory is a more direct and observable cause of the packet loss.

Go deeper

Related to this question