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.