Type 1 vs Type 2 Hypervisors
The most tested virtualization concept on the A+ Core 2 exam is the distinction between Type 1 and Type 2 hypervisors. They differ in where they run relative to the host operating system:
Performance: Best — no host OS overhead.
Use case: Enterprise data centres, production servers, cloud infrastructure.
Security: Smaller attack surface — no underlying OS to compromise.
Performance: Lower — two OS layers add overhead.
Use case: Developer workstations, home labs, testing environments.
Security: Larger attack surface — host OS vulnerabilities affect all VMs.
Type 1 = no host OS underneath (bare metal). Type 2 = runs on top of a host OS (hosted). The exam gives you a scenario — "A company wants maximum performance for production VMs running 24/7 in a data centre." → Type 1. "A developer wants to test software in different OS environments on their laptop." → Type 2.
Remember: VMware ESXi = Type 1. VMware Workstation = Type 2. Both are VMware products but fundamentally different architectures.
Key Virtualization Concepts
| Concept | What It Is | Exam Relevance |
|---|---|---|
| Guest OS | The operating system running inside a VM — it believes it's running on real hardware but is actually running in a virtualised environment | Each VM runs its own guest OS — a single physical host can run Windows Server, Ubuntu, and Windows 10 simultaneously |
| Host OS | The operating system the Type 2 hypervisor runs on — the base OS of the physical machine (e.g. Windows 10 running VirtualBox) | Type 1 has no host OS. Type 2 requires one. |
| Snapshot | A point-in-time copy of a VM's state — disk contents, memory, and configuration captured at that moment. Can be restored to roll the VM back to that exact state. | A+ Core 2 — used for safe testing (take snapshot, test, revert if needed) and backup. Not a substitute for full backups. |
| VM Template | A pre-configured VM image used as a master copy to rapidly deploy identical VMs — avoids reinstalling OS and software for every new VM | Enterprise provisioning — deploy 50 identical VMs in minutes from one template |
| vCPU | Virtual CPU — a portion of a physical CPU's capacity allocated to a VM. Multiple VMs can share physical CPU cores. | Over-provisioning vCPUs causes performance issues — common troubleshooting scenario |
| VM Sprawl | The uncontrolled proliferation of VMs — too many VMs created and never decommissioned, consuming resources and creating security risks | Security+ — abandoned VMs may not receive patches, creating vulnerabilities. Requires VM lifecycle management. |
| Live Migration | Moving a running VM from one physical host to another with no downtime — the VM keeps running during the move (VMware vMotion, Hyper-V Live Migration) | Network+ / Security+ — enables maintenance without downtime; requires shared storage |
| Nested Virtualisation | Running a hypervisor inside a VM — a VM running its own VMs. Supported by some hypervisors; used in labs and cloud training environments. | Lab environments — your home lab may use nested virtualisation |
VMs vs Containers
Containers are a lighter-weight alternative to full VMs. Both isolate workloads, but they do it differently:
| Feature | Virtual Machine | Container |
|---|---|---|
| What's isolated | Full OS + application — each VM has its own kernel, OS libraries, and processes | Application + dependencies only — shares the host OS kernel |
| Size | Gigabytes — full OS image per VM | Megabytes — just the application and its libraries |
| Startup time | Minutes — full OS boot sequence | Seconds or milliseconds — no OS boot needed |
| Isolation | Strong — each VM has its own kernel, hardware-enforced separation | Weaker — all containers share the host kernel; a kernel vulnerability affects all |
| Portability | Heavy — VM images are large and tied to hypervisor format | High — containers run identically on any system with the container runtime |
| Technology | VMware, Hyper-V, VirtualBox | Docker, Podman, Kubernetes (orchestration) |
| Use case | Running different OS types, strong isolation requirements, legacy apps | Microservices, DevOps pipelines, cloud-native applications |
Cloud Service Models — IaaS, PaaS, SaaS
Cloud computing is virtualisation at scale — providers like AWS, Azure, and Google Cloud run massive hypervisor farms and rent virtual resources. The A+ Core 2 and Network+ exams test the three cloud service models:
| Model | What the Provider Manages | What You Manage | Examples |
|---|---|---|---|
| IaaS Infrastructure as a Service | Physical hardware, networking, virtualisation layer, storage | OS, middleware, applications, data — you install and manage everything above the hypervisor | AWS EC2, Azure VMs, Google Compute Engine |
| PaaS Platform as a Service | Everything in IaaS plus the OS, runtime, middleware, and development tools | Your application code and data only — the platform handles everything beneath | AWS Elastic Beanstalk, Azure App Service, Google App Engine, Heroku |
| SaaS Software as a Service | Everything — hardware through application | Your data and user configuration only — you just use the software | Microsoft 365, Google Workspace, Salesforce, Dropbox |
Public cloud: Resources shared among multiple customers on provider infrastructure (AWS, Azure, GCP). Most cost-effective, least control.
Private cloud: Cloud infrastructure dedicated to a single organisation — either on-premises or hosted. Full control, higher cost.
Hybrid cloud: Combination of public and private — workloads move between them based on need. Common enterprise model.
Community cloud: Shared infrastructure for organisations with similar requirements (government agencies, healthcare providers). Less common on the exam but present.
Virtualisation Security Concerns
| Concern | Description | Defence |
|---|---|---|
| VM Escape | An attacker exploits a hypervisor vulnerability to break out of a VM and access the host system or other VMs — the most severe virtualisation attack | Keep hypervisors patched, use Type 1 for isolation, monitor for anomalous inter-VM communication |
| VM Sprawl | Uncontrolled creation of VMs leads to unpatched, forgotten systems that become attack vectors | VM lifecycle management policies, automated patch compliance, regular audits of running VMs |
| Snapshot Risks | Old snapshots may contain unpatched OS states — restoring a snapshot rolls back security patches | Limit snapshot retention, delete snapshots after testing, never restore old snapshots to production |
| Shared Resources | VMs on the same host share physical CPU and memory — side-channel attacks (like Spectre/Meltdown) can potentially leak data between VMs | CPU microcode patches, hypervisor isolation features, separate sensitive workloads to dedicated hosts |
Exam Scenarios
Studying for A+ Core 2?
See the best study guides and practice exams for the 220-1202 exam.
Virtualisation in the Enterprise — Why It Matters
Before virtualisation, each physical server ran one operating system and one primary application. A web server, database server, and email server each needed dedicated hardware — which sat idle most of the time, wasting power, cooling, and rack space. Virtualisation solved this by running multiple VMs on a single physical host, each VM believing it has exclusive access to hardware resources that are actually shared. Modern enterprise datacentres routinely run dozens of VMs per physical host, with hardware utilisation rates of 60–80% instead of the 5–15% common with dedicated physical servers.
For the exam: understand that virtualisation provides hardware consolidation (fewer physical servers for the same workload), improved disaster recovery (VMs can be backed up as single files and restored to different hardware), rapid provisioning (a new server can be deployed in minutes from a template), and isolation (a compromised VM doesn't directly affect the hypervisor or other VMs — though VM escape vulnerabilities can break this boundary).
VM Components — What Makes Up a Virtual Machine
A virtual machine consists of: a virtual CPU (vCPU) mapped to physical CPU cores, virtual RAM allocated from the host's physical RAM, a virtual disk (typically a .vmdk or .vhd file on the host's storage that the VM treats as a real hard drive), a virtual network adapter (the hypervisor creates a virtual switch that connects VMs to each other and to the physical network), and virtual I/O devices (graphics, USB controllers, etc.). The hypervisor manages resource allocation and prevents VMs from accessing each other's memory or storage without explicit configuration.
Snapshots capture the exact state of a VM at a point in time — memory contents, disk state, and configuration. They allow you to roll a VM back to a known-good state if something goes wrong. On the exam: snapshots are not the same as backups. Snapshots depend on the VM remaining on the same storage — if the host fails, snapshots fail too. Proper backup exports the VM to a separate location. Snapshots are ideal for testing changes (take a snapshot, apply a patch, roll back if something breaks) but should not be the sole protection mechanism.
Containers vs Virtual Machines
Containers (Docker, Kubernetes pods) are a lighter-weight alternative to VMs. Where a VM runs a full guest OS on top of the hypervisor, a container shares the host OS kernel and runs only the application and its dependencies. This makes containers significantly faster to start (seconds vs minutes), much smaller (megabytes vs gigabytes), and more portable — a container that runs on a developer's laptop runs identically in production. The trade-off is weaker isolation: containers share the kernel, so a kernel vulnerability can potentially affect all containers on a host. VMs provide stronger isolation because each has its own kernel.
On the exam: the key distinction is isolation level. VMs = stronger isolation, higher overhead. Containers = lighter weight, weaker isolation, better for microservices and CI/CD pipelines. Security+ specifically tests container security risks: image vulnerabilities (a vulnerable base image affects every container built from it), container escape (breaking out of container isolation to the host), and the importance of running containers as non-root users.
Cloud and Virtualisation — The Connection
Cloud computing is built on virtualisation. When you provision an EC2 instance on AWS or a VM on Azure, you're getting a virtual machine running on Amazon's or Microsoft's physical hypervisor infrastructure. The cloud provider manages the physical hardware and hypervisor (Type 1); you manage the guest OS and everything above it. This is exactly the IaaS shared responsibility model — the provider owns the virtualisation layer, the customer owns the OS.
Understanding this connection makes cloud concepts on the exam easier to reason through. Questions about what a customer is responsible for in IaaS become intuitive when you understand that the customer is essentially renting a VM — they control the guest OS and above, just like a Type 2 hypervisor user controls their VM but not the underlying host OS or hardware.