The municipal virtualization cluster hosts many VMs on each physical host to save cost. Which security consideration is most relevant?
Select an answer to reveal the explanation.
Short Explanation
Packing apartments into one building saves money—and means one bad wall affects more neighbors. Dense VMs raise the stakes on isolation and shared-host resources. Shared passwords and soft hosts are not freebies of virtualization.
Full Explanation
When a municipal virtualization cluster packs many VMs onto each physical host to save cost, resource sharing and isolation between co-resident VMs become critical. Density increases the impact of hypervisor misconfiguration, VM escape research, shared storage/network mistakes, and noisy-neighbor contention across departments that may host different sensitivity tiers on the same iron. Security architecture must harden the hypervisor and management plane, enforce separation where policy requires, and monitor abnormal inter-VM activity—cost savings do not retire isolation work.
Asserting that high density removes isolation concerns because hypervisors never fail or misconfigure is wishful; hypervisors are software with patch needs and admin-error modes. Allowing guest VMs to share one admin password across departments collapses accountability and least privilege regardless of virtualization boundaries. Claiming physical hosts no longer need hardening once any guest OS is installed ignores that host firmware, hypervisor, and management interfaces remain high-value targets whose compromise affects every guest.
Exam caveat: density questions emphasize co-residency and isolation, not "hypervisor perfection" or shared passwords. Operationally, patch and restrict hypervisor admins, segment management networks, separate high-sensitivity workloads when required, apply resource controls, and treat templates/snapshots as sensitive artifacts that can leak credentials or malware across many VMs.