City hall runs all election applications as virtual machines on a single hypervisor host. What risk awareness should the campus team emphasize about that design?
Select an answer to reveal the explanation.
Short Explanation
If every election app lives in one civic attic, a roof leak soaks them all. Shared hardware is a shared failure domain—when the hypervisor host dies, every VM on it feels it. Virtualization packs denser, but it does not invent magic immunity.
Full Explanation
Running every city-hall election application as a VM on a single hypervisor concentrates risk: if that physical host fails—power, motherboard, storage controller, or hypervisor crash—every guest that shares the hardware is impacted at once. Virtualization improves density and operational agility, but it enlarges the blast radius of host failure compared with one-app-per-server designs unless the campus team plans redundancy (additional hosts, clustering/HA, backups, and tested recovery). Risk awareness for municipal election systems must therefore emphasize shared failure domains, not assume consolidation removes operational resilience work. Density without host-level recovery planning is a brittle design. Claiming VMs never need backups because the hypervisor mirrors disks forever overstates platform features; snapshots and storage redundancy are not a substitute for backup and restore policy. IPv6 unique-local addressing is an addressing choice and does not remove the need for host redundancy planning. EtherChannel on the host NIC can harden a network uplink path but cannot guarantee the hypervisor CPU, memory, or local storage will not fail. Exam caveat: questions often pair the benefit of consolidation with the risk of a common failure domain—recognize both sides. Operational check: map which election VMs share each host, validate backup/restore and failover procedures before election windows, and ensure critical VMs are spread or protected so a single hypervisor outage cannot take down the entire civic application set.