Virtualization, Containerization, and Serverless
What the Exam Is Really Testing
You will not need to configure a hypervisor or write a Dockerfile for the exam. What you do need to know is where the isolation boundaries are and what breaks when they fail.
Abstraction reduces hardware dependency but introduces new attack surfaces at the virtualization and orchestration layers.
Every question in this area comes down to: what new risks does this abstraction layer create, and how do you mitigate them?
Hypervisors: Type 1 vs Type 2
A hypervisor is software that creates and manages virtual machines (VMs). It allows multiple operating systems to run on a single physical host.
Type 1 (Bare-Metal)
Runs directly on hardware. No underlying operating system between the hypervisor and the hardware.
Examples: VMware ESXi, Microsoft Hyper-V, Xen.
Security advantage: smaller attack surface because there is no host OS to compromise. This is the standard for enterprise and data center environments.
Type 2 (Hosted)
Runs on top of a host operating system. The hypervisor is an application installed on the OS.
Examples: VMware Workstation, Oracle VirtualBox, Parallels.
Security disadvantage: the host OS is an additional attack surface. If the host is compromised, all VMs are at risk. Typically used for development and testing, not production.
Exam takeaway:
Type 1 is more secure because it eliminates the host OS layer. Type 2 inherits every vulnerability of the host OS.
VM-Specific Risks
Virtualization creates risks that do not exist in physical environments:
VM Escape
An attacker breaks out of a virtual machine and gains access to the hypervisor or other VMs on the same host. This is the most critical virtualization threat.
Mitigation: keep hypervisors patched, minimize the hypervisor attack surface, use hardware-assisted virtualization features.
VM Sprawl
The uncontrolled proliferation of virtual machines. VMs are easy to create and often forgotten. Unmanaged VMs become unpatched, unmonitored liabilities.
Mitigation: VM lifecycle management policies, automated inventory, decommissioning procedures.
Resource Reuse
When a VM is deleted, its memory and storage may retain sensitive data. If those resources are allocated to a new VM without proper sanitization, data leakage occurs.
Mitigation: secure data wiping before resource reallocation.
Containers vs Virtual Machines
Containers and VMs both provide isolation, but they work differently:
Virtual machines virtualize the hardware. Each VM runs its own operating system. Strong isolation because each VM has its own kernel.
Containers virtualize the operating system. Containers share the host OS kernel. Lighter weight, faster to start, but weaker isolation because of the shared kernel.
Security comparison:
- VMs provide stronger isolation (separate kernels)
- Containers have a larger shared attack surface (shared kernel)
- A kernel vulnerability in a container environment affects all containers on the host
- Containers start faster and use fewer resources, enabling rapid deployment
Container Security
Container-specific security concerns:
Image Security
Containers are built from images. If the base image contains vulnerabilities or malware, every container built from it inherits those problems.
- Image scanning — Scan images for known vulnerabilities before deployment
- Image signing — Cryptographically sign images to verify integrity and authenticity
- Trusted registries — Pull images only from verified, approved sources
- Minimal base images — Use stripped-down images to reduce attack surface
Runtime Security
- Least privilege — Run containers as non-root users
- Read-only filesystems — Prevent containers from modifying their own filesystem
- Network segmentation — Isolate container networks to limit lateral movement
- Resource limits — Prevent a single container from consuming all host resources
Orchestration Security
Container orchestration platforms like Kubernetes manage container deployment at scale. Security concerns include:
- API server authentication and authorization
- Secrets management (credentials, API keys)
- Network policies between pods
- Role-based access control for cluster management
Microservices Architecture
Microservices break applications into small, independently deployable services. Each service handles a specific function and communicates via APIs.
Security implications:
- Increased attack surface — More services means more endpoints, more APIs, more authentication points
- API security — Each service-to-service communication channel must be authenticated and encrypted
- Service mesh — Provides mutual TLS, traffic management, and observability between microservices
- Blast radius — If one microservice is compromised, proper segmentation limits the impact to that service
The exam tests whether you understand the tradeoff: microservices increase flexibility but also increase the number of components that need securing.
Serverless Computing
In serverless computing, the provider manages all infrastructure. The customer writes and deploys functions that execute in response to events.
Examples: AWS Lambda, Azure Functions, Google Cloud Functions.
Security considerations:
- Reduced infrastructure control — You cannot patch the OS or configure the runtime environment
- Function-level permissions — Each function needs precisely scoped IAM permissions (least privilege)
- Event injection — Untrusted event data can trigger functions with malicious input
- Cold start visibility — Functions spin up and down rapidly, making traditional monitoring difficult
- Dependency risks — Third-party libraries bundled with functions may contain vulnerabilities
The serverless model pushes even more responsibility to the provider but makes traditional security tools (agents, endpoint protection) difficult or impossible to deploy.
Infrastructure as Code Connection
Virtualization, containers, and serverless all benefit from Infrastructure as Code (IaC). Instead of manually configuring environments, you define them in version-controlled templates.
Security benefit: every deployment is consistent, auditable, and repeatable. Drift from the approved configuration is detectable.
This connection matters because the exam may present scenarios where misconfiguration is the root cause — and IaC is the corrective control.
Pattern Recognition
When you see virtualization or container scenarios on the exam:
- VM escape scenario — The answer involves hypervisor patching, isolation controls, or Type 1 vs Type 2 selection
- Unmanaged VMs — The answer involves lifecycle management, inventory, or VM sprawl prevention
- Container vulnerability — The answer involves image scanning, trusted registries, or minimal base images
- Serverless risk — The answer involves function permissions, input validation, or dependency management
Trap Patterns
Watch for these common traps:
- "Containers provide the same isolation as VMs" — False. Containers share the host kernel and provide weaker isolation than VMs.
- "Serverless eliminates security concerns" — False. It eliminates infrastructure management but introduces function-level permission and dependency risks.
- "Type 2 hypervisors are suitable for production" — They are typically used for development. The exam favors Type 1 for production and security-sensitive environments.
- Confusing image scanning with runtime monitoring — Image scanning catches vulnerabilities before deployment. Runtime monitoring detects threats during execution. Both are needed.
Scenario Practice
Question 1
A security analyst discovers that multiple virtual machines on the same host are running unpatched operating systems. The VMs were created six months ago for a project that has since ended.
What is this an example of?
A. VM escape
B. Resource exhaustion
C. VM sprawl
D. Hypervisor compromise
Answer & reasoning
Correct: C
VM sprawl occurs when virtual machines proliferate without proper lifecycle management. These forgotten, unpatched VMs represent an unmanaged attack surface.
The fix is VM lifecycle policies, automated inventory, and decommissioning procedures.
Question 2
An organization is deploying containers for a production application. A security review reveals that all containers are running as the root user and using images from an unverified public registry.
What should be addressed FIRST?
A. Implement a service mesh for traffic encryption
B. Run containers as non-root and use trusted image registries
C. Migrate the application to virtual machines instead
D. Add a host-based firewall to the container host
Answer & reasoning
Correct: B
Running as root and using unverified images are the two most fundamental container security failures. Fixing these addresses the highest-risk issues first.
A service mesh adds value but does not fix root-level execution or untrusted images.
Question 3
A development team wants to use a Type 2 hypervisor for a production environment because it is easier to set up on their existing workstations.
What is the PRIMARY security concern with this approach?
A. Type 2 hypervisors do not support virtual networking
B. The host operating system introduces an additional attack surface
C. Type 2 hypervisors cannot run multiple VMs simultaneously
D. Virtual machines on Type 2 hypervisors lack encryption support
Answer & reasoning
Correct: B
Type 2 hypervisors run on top of a host OS. If the host OS is compromised, the attacker gains access to the hypervisor and all VMs. This additional layer is the primary security concern for production use.
Key Takeaway
Remember this: every layer of abstraction trades direct control for flexibility, and each trade creates new security responsibilities. Before answering, ask yourself:
- What is the isolation boundary?
- What is shared between workloads?
- Who manages each layer?
- Where can an attacker move laterally?
Abstraction simplifies operations. It never simplifies security.