Unit 13 · Self-check
Unit 13 Self-Check Quiz
Twenty-five questions covering virtual machines, hypervisors, container technologies, Docker, orchestration, cloud operating systems, and future trends. Each question can be expanded to reveal a model answer.
Questions
Multiple choice and short answer
Answer each question before expanding. These span all seven lessons of Unit 13.
Question 1
Define a virtual machine and a hypervisor. What is the difference between a Type 1 and a Type 2 hypervisor?
Show answer
A virtual machine (VM) is a software emulation of a complete computer — CPU, memory, disk, network — that can run its own operating system. The software that creates and runs VMs is the hypervisor (virtual machine monitor, VMM). It multiplexes the physical hardware among VMs and ensures that each VM is isolated from the others.
A Type 1 hypervisor runs directly on the hardware with no intervening host OS. Examples: KVM (where Linux is the host kernel), Xen, VMware ESXi, Microsoft Hyper-V. It has direct access to hardware and achieves low overhead. A Type 2 hypervisor runs as an application on a host OS. Examples: VirtualBox, VMware Workstation, QEMU in user-mode emulation. It is easier to install on a desktop but has more overhead because it goes through the host OS.
Question 2
Why is hardware-assisted CPU virtualisation (Intel VT-x, AMD-V) important? What did hypervisors do before it existed?
Show answer
Hardware-assisted virtualisation adds a new privilege level (root mode) in which the hypervisor runs, while guest kernels run in non-root mode. Privileged instructions executed by the guest trap to the hypervisor, which handles them and resumes the guest. The guest executes most instructions natively, so the overhead is small — typically a few percent for CPU-bound workloads.
Before hardware support, the hypervisor had to emulate privileged instructions in software. On x86, which was not originally designed to be virtualised (some privileged instructions fail silently in user mode rather than trapping), hypervisors used binary translation: they scanned the guest's code and replaced problematic instructions with traps to the hypervisor. This was complex and slow. Paravirtualisation — modifying the guest OS to cooperate with the hypervisor — was an alternative, but it required changing the guest kernel. Hardware support removed both the complexity and the need to modify the guest.
Question 3
How does nested paging (Intel EPT, AMD NPT) improve memory virtualisation?
Show answer
Without nested paging, the hypervisor had to maintain shadow page tables mapping guest-virtual to host-physical addresses. Every time the guest modified its page tables, the hypervisor had to intercept the modification and update the shadow tables — an expensive trap-and-emulate cycle. With nested paging, the CPU performs the two-level translation in hardware: it walks the guest's page tables (guest-virtual to guest-physical) and then the hypervisor's nested tables (guest-physical to host-physical). The guest's page tables are used directly, no shadow tables are needed, and the combined translation is cached in a nested TLB. The result is a large reduction in the memory-management overhead of VMs.
Question 4
What is virtio, and why is it faster than emulating a device?
Show answer
virtio is a standard interface for paravirtualised devices in Linux. It defines a shared-memory ring buffer between the guest driver and the hypervisor's device backend. The guest places requests in the ring and notifies the hypervisor; the hypervisor processes them and notifies the guest when done.
Emulating a real device — for example, an Intel e1000 network card — requires the guest to read and write device registers, each of which traps to the hypervisor, which emulates the register's behaviour. This is slow because every register access is a trap. With virtio, the guest and the hypervisor communicate through shared memory, and only the notifications (a few per batch of requests) trap. The result is much higher throughput and lower CPU overhead. virtio is not quite as fast as device passthrough, but it is portable across hypervisors and requires no modification to the guest beyond loading the standard virtio driver.
Question 5
What is a container? How does it differ from a virtual machine?
Show answer
A container is a group of processes on a host that are isolated from the rest of the system by kernel features: namespaces (mount, PID, network, UTS, IPC, user, cgroup) isolate the container's view of the system, cgroups limit its resource usage, and capabilities and LSM policies restrict what its processes can do. A container shares the host kernel.
A virtual machine, by contrast, runs its own kernel inside a hypervisor. A VM has stronger isolation — a bug in one VM's kernel cannot affect another VM — but it has more overhead (its own kernel, its own memory footprint) and starts more slowly (booting a guest OS takes seconds).
Containers start in milliseconds and have near-native performance, but their isolation is weaker: a kernel bug can allow a container escape. Modern platforms often run containers inside VMs for defence in depth.
Question 6
Which Linux namespaces are commonly used to isolate containers? Give a one-sentence description of each.
Show answer
- mount (mnt): isolates the file system — the container sees its own root and mount points.
- PID: isolates the process ID space — processes inside the container see only each other, and the first process sees itself as PID 1.
- network (net): isolates network interfaces, routing tables, and firewall rules — the container has its own network stack.
- UTS: isolates the hostname and domain name.
- IPC: isolates System V IPC and POSIX message queues.
- user: isolates UID and GID mappings — a process can be root inside the container without being root on the host.
- cgroup: isolates the cgroup view — the container sees its own cgroup hierarchy.
Question 7
What is a cgroup? Give two resources it can limit.
Show answer
A cgroup (control group) is a kernel mechanism that organises processes into hierarchical groups and applies resource limits and accounting to each group. It can limit:
- CPU: with
cpu.max(a quota in microseconds per period),cpu.weight(relative share), orcpuset.cpus(which CPUs the group may run on). - Memory: with
memory.max(a hard limit),memory.high(a soft limit that triggers reclaim), ormemory.swap.max(a swap limit).
io.max), the number of processes (pids.max), and device access (devices.allow). cgroups are the basis of container resource isolation and of systemd's resource controls.
Question 8
What is a Docker image? How does it differ from a Docker container?
Show answer
A Docker image is a read-only template: a layered file system containing the application, its dependencies, and the configuration needed to run it. Images are built from a
Dockerfile and stored in a registry. Each layer is a set of file changes (the base image, added packages, copied files, and so on), and layers are shared between images that use the same base.
A Docker container is a running instance of an image. It adds a writable layer on top of the image's read-only layers, and it has its own namespaces and cgroup limits. Multiple containers can be started from the same image, and they share the image's layers. The container's writable layer is discarded when the container is removed (unless a volume is used to persist data).
Question 9
Why does the order of commands in a Dockerfile affect build time?
Show answer
Docker caches the result of each build step (each layer). When a Dockerfile is rebuilt, Docker compares each step to the cached layers; if a step's inputs have not changed, Docker reuses the cached layer and does not re-execute the step. As soon as one step's inputs change, that step and all subsequent steps are re-executed — the cache is invalidated from that point on.
A well-ordered Dockerfile puts the steps that change least often first (base image, system packages) and the steps that change most often last (copying application source). This way, when the application source changes, only the last few layers are rebuilt, and the expensive package-installation steps are reused from cache. A poorly ordered Dockerfile that copies the source before installing packages forces the package installation to be re-executed on every source change.
Question 10
What is Docker Compose, and how does it relate to Kubernetes?
Show answer
Docker Compose is a tool for defining and running multi-container applications on a single host. The application is described in a YAML file (
docker-compose.yml) that specifies the services, their images or build contexts, their ports, volumes, environment variables, networks, and dependencies. The whole stack is started, stopped, and scaled with a single command.
Kubernetes generalises the same idea to a cluster of hosts. It defines resources declaratively (Pods, Deployments, Services, ConfigMaps, Secrets) and runs a control plane that reconciles the observed state with the desired state. Kubernetes handles scheduling, service discovery, load balancing, rolling updates, health checks, and autoscaling — concerns that Compose handles only in a minimal way (or not at all). The concepts are similar, but Kubernetes is designed for production-scale, multi-host deployments. Compose remains useful for local development and simple deployments.
Question 11
What does the Kubernetes control plane consist of, and what is the role of each component?
Show answer
The Kubernetes control plane consists of:
- API server (kube-apiserver): the front end of the cluster. All communication goes through it; it validates requests, persists them to etcd, and serves watch events to controllers and nodes.
- etcd: a distributed key-value store holding the entire cluster's desired and observed state. It is the single source of truth and must be backed up.
- Scheduler (kube-scheduler): watches for newly created Pods with no assigned node and selects a node for each, based on resource requirements, affinity rules, and other constraints.
- Controller manager (kube-controller-manager): runs the reconciliation loops that implement Kubernetes's declarative model — for example, the Deployment controller ensures the desired number of replicas is running, the Node controller detects and responds to node failures, and the ReplicaSet controller maintains the replica count.
- Cloud controller manager: integrates with the underlying cloud provider for load balancers, storage volumes, and node lifecycle.
Question 12
What is the declarative model in Kubernetes, and how does the reconciliation loop implement it?
Show answer
In the declarative model, the user specifies the desired state of the system (for example, "run three replicas of this container image with these resource limits") rather than the steps needed to achieve it. Kubernetes stores the desired state in etcd and continuously compares it to the observed state.
The reconciliation loop is the mechanism that closes the gap. Controllers watch the current state of the resources they own and, whenever the observed state differs from the desired state, take action to bring them into agreement. For example, the ReplicaSet controller ensures that the number of running Pods matches the specified replica count: if a Pod fails, the controller creates a replacement; if there are too many Pods, it deletes one. Because the loop runs continuously, Kubernetes is self-healing: it recovers automatically from node failures, Pod crashes, and configuration drift. This is a direct application of the control-loop concept from control theory.
Question 13
What is a microVM, and what problem does it solve?
Show answer
A microVM is a lightweight virtual machine that combines the fast startup of a container with the strong isolation of a VM. It uses a minimal virtual-machine monitor (such as AWS's Firecracker, or the KVM-based Kata Containers runtime) that boots a stripped-down guest kernel in a few milliseconds. The guest runs a single application or a small set of processes. Because the guest has its own kernel and its own memory, isolation is as strong as a VM's, but the boot time and memory footprint are close to a container's.
MicroVMs solve the tension between isolation and density. Standard VMs are too heavy for the high-density, fast-startup workloads of serverless platforms and container-based multi-tenant environments. Containers are fast and dense but share the host kernel, so a kernel vulnerability can allow an escape. MicroVMs give the best of both: strong isolation at container-like speed. They are used in AWS Lambda and Fargate, in Google Cloud Run, and in Kata Containers.
Question 14
What is live migration of a virtual machine? Describe the pre-copy approach.
Show answer
Live migration is the process of moving a running VM from one physical host to another without stopping it — the VM's execution continues, and the total downtime is typically tens to hundreds of milliseconds. It is used for load balancing, hardware maintenance, and power management in cloud environments.
In the pre-copy approach:
- The hypervisor copies the VM's memory pages to the destination host while the VM continues to run.
- Pages modified during the copy are tracked as dirty and re-copied in subsequent rounds. Each round copies a smaller set of pages because most pages have already been copied and the working set is finite.
- When the remaining dirty set is small enough, the VM is briefly paused, the last dirty pages and CPU state are copied, and the VM resumes on the destination. The source is then torn down.
Question 15
What is a cloud operating system? Name three challenges it addresses.
Show answer
A cloud operating system is the software layer that turns a data centre's worth of physical machines into a pool of virtual resources (compute, storage, network) that can be allocated to tenants on demand. Examples include OpenStack, VMware vCloud, and the proprietary control planes of AWS, Azure, and Google Cloud.
Three challenges it addresses:
- Multi-tenancy: many customers share the same physical hardware; the system must isolate their workloads so that one tenant cannot affect another's performance, security, or data.
- Elasticity: resources must scale up and down with demand. The system must provision new VMs or containers quickly, retire idle ones, and rebalance load across hosts.
- Fault tolerance: hardware fails; the system must detect failures, restart workloads on healthy hosts, and maintain availability. This includes live migration for planned maintenance, replication for data durability, and health checks for automatic recovery.
Question 16
What is the difference between a bind mount and a Docker volume? When is each appropriate?
Show answer
A bind mount maps a directory or file on the host into the container. The path is specified explicitly (for example,
-v /host/path:/container/path). The container sees the host's file system directly. Bind mounts are appropriate for development (mounting source code into a container so edits are visible immediately) and for accessing host resources that the container needs (a device, a configuration file).
A Docker volume is a named storage location managed by Docker. It lives in a Docker-managed directory (on Linux, usually /var/lib/docker/volumes/), and the container refers to it by name (for example, -v myvolume:/container/path). Volumes are appropriate for persistent application data (databases, logs, uploaded files) because they are portable across containers, can be backed up and restored with Docker commands, and work the same on any host. Volumes are also faster on Docker Desktop for Mac and Windows because they bypass the host file-system sharing layer.
In summary: bind mounts for development and host-specific resources; volumes for production data that must persist and be portable.
Question 17
What is a container registry, and how does it relate to the container image?
Show answer
A container registry is a service that stores and distributes container images. It supports pushing images (uploading a locally built image) and pulling images (downloading an image to run it). Docker Hub, GitHub Container Registry, Amazon ECR, and Google Artifact Registry are examples. A registry also supports tagging — multiple tags can point to the same image (for example,
myapp:1.0 and myapp:latest), and tags are used to identify versions.
The registry is where images live between build and run. A CI/CD pipeline builds an image, tags it, pushes it to a registry, and then a deployment tool (Docker Compose, Kubernetes) pulls it on the target host. Because images are layered and immutable, pulling an image only transfers the layers that are not already present on the host, which makes deployment fast and bandwidth-efficient. Private registries are used for proprietary images; public registries host open-source images and are used as the base for many applications.
Question 18
A cloud provider runs thousands of VMs on each physical host. Why is memory overcommitment used, and what risk does it introduce?
Show answer
Memory overcommitment is the practice of allocating more virtual memory to VMs than the physical memory available on the host. It relies on the observation that most VMs do not use all the memory they have been allocated, so the host can safely serve more VMs than the sum of their maximum sizes would suggest. It increases the density of VMs per host, reducing cost per VM.
The risk is that if the VMs collectively use more memory than is physically available, the host must either swap (which is very slow and can cause cascading failures) or reclaim memory from VMs (which slows them down). In the worst case, the host runs out of memory and the kernel's OOM killer terminates a VM. Cloud providers manage this risk with ballooning (a driver in the guest that releases memory when the host is under pressure), page sharing (deduplicating identical pages across VMs), and monitoring with rebalancing (migrating a VM to a host with more free memory). Overcommitment is a trade-off between cost efficiency and reliability; the right level depends on the workload's variability.
Question 19
What is the difference between a Pod and a container in Kubernetes?
Show answer
A container is the unit of packaging and execution: it contains a single application and its dependencies, and it runs as a process group in its own namespaces. A Pod is the unit of scheduling in Kubernetes: it is a group of one or more containers that share the same network namespace, IP address, and storage volumes, and that are scheduled together on the same node. Containers within a Pod can communicate with each other over
localhost and can share files through a common volume.
Most Pods contain a single container — the application. Multi-container Pods are used for sidecar patterns: a logging sidecar that tails the application's log files, a proxy sidecar that intercepts network traffic, or an init container that prepares the environment before the application starts. The Pod is the smallest deployable unit in Kubernetes; you do not schedule a container directly.
Question 20
A workload is highly variable — it needs many cores during peak hours and very few during off-peak hours. Would you deploy it on VMs or containers, and how would you manage the scaling?
Show answer
For a highly variable workload, containers are generally the better choice because they start in milliseconds and have a small memory footprint, so the system can scale the number of replicas up and down quickly without paying the cost of booting or shutting down a guest OS. A VM-based deployment would scale more slowly (seconds to tens of seconds per instance) and would consume more memory per instance.
The scaling would be managed with a horizontal pod autoscaler (HPA) that adjusts the number of replicas based on CPU utilisation, memory usage, or a custom metric. A cluster autoscaler would add or remove nodes when the workload does not fit on the current cluster. During off-peak hours, the autoscaler would reduce the replica count to the minimum specified, freeing resources for other workloads; during peak hours, it would add replicas, and (if needed) new nodes. This elasticity — scaling up and down smoothly in response to demand — is the core reason containers are preferred for cloud-native workloads. The trade-off is that container isolation is weaker than VM isolation, so if the workload is multi-tenant, a microVM or a container-in-VM approach may be preferable.
Question 21
What is a unikernel, and how does it differ from a traditional operating system?
Show answer
A unikernel is a specialised operating system image that is built by linking the application with only the operating-system libraries it needs, producing a single-address-space, single-process executable that runs directly on a hypervisor. It differs from a traditional OS in several ways:
- Single address space: there is no separation between kernel and user space, so there are no system calls and no context switches between privilege levels. The application calls library functions directly.
- Single purpose: the unikernel runs one application. It is not a general-purpose OS; it is a purpose-built image for that application.
- Minimal attack surface: only the code the application actually uses is included, so the attack surface is much smaller than a general-purpose OS's.
- Fast boot: a unikernel boots in milliseconds because there is no large kernel to initialise and no user-space to set up.
Question 22
What is WebAssembly, and why is it being considered as a lightweight alternative to containers?
Show answer
WebAssembly (Wasm) is a portable binary instruction format originally designed for the web, where it runs in a sandboxed environment inside the browser. A Wasm module is compiled ahead of time or at load time, and it runs in a memory-safe, sandboxed virtual machine. Its properties — small binary size, fast startup, strong sandboxing, portability across architectures — make it attractive outside the browser as well.
As a lightweight alternative to containers, Wasm offers:
- Startup time in microseconds versus milliseconds for containers, which matters for serverless and edge workloads.
- Smaller artifacts — a Wasm module is a few hundred kilobytes to a few megabytes, versus tens of megabytes for a container image.
- Strong sandboxing by default — Wasm modules cannot access the file system, the network, or other resources unless the host explicitly grants access through a capabilities-based interface (WASI).
- Portability — the same module runs on any host with a Wasm runtime, regardless of the underlying architecture.
Question 23
What is the role of an orchestrator in a container-based platform, and what does it do that a single-host runtime does not?
Show answer
An orchestrator manages containers across a cluster of hosts. It provides:
- Scheduling: deciding which host should run each container, based on resource requirements, affinity rules, and current load.
- Service discovery: giving each service a stable name and IP address, even as individual containers are created and destroyed.
- Load balancing: distributing traffic across the replicas of a service.
- Rolling updates and rollbacks: replacing old containers with new ones without downtime, and reverting if the new version fails.
- Health checks and self-healing: detecting failed containers and restarting or replacing them.
- Scaling: adjusting the number of replicas based on metrics or a schedule.
- Secret and configuration management: distributing sensitive data and configuration to containers securely.
Question 24
Why do many production environments run containers inside virtual machines rather than on bare metal?
Show answer
Running containers inside VMs — a pattern sometimes called "container-in-VM" or a "nested" deployment — is common for several reasons:
- Defence in depth: the VM provides a second layer of isolation. If a container escape occurs, the attacker is still confined to the VM and cannot reach the host or other tenants' VMs. This is important for multi-tenant environments where the tenants are not mutually trusted.
- Security boundaries: the VM is a well-understood and mature security boundary. The container's isolation mechanisms (namespaces, cgroups) are relatively new and have had more escapes. Layering them on a VM reduces the risk.
- Cluster management: many cloud platforms (AWS EKS, Google GKE, Azure AKS) run the Kubernetes nodes as VMs, so containers are naturally inside VMs. This simplifies node management, patching, and autoscaling.
- Resource isolation: the VM's hypervisor enforces CPU and memory limits more strictly than cgroups in some cases, and it provides the guest with its own kernel, so a kernel-level bug in one tenant's container cannot affect another tenant's kernel.
Question 25
In one or two sentences, state the central trade-off between virtual machines and containers, and how modern systems try to have both.
Show answer
Virtual machines provide strong isolation at the cost of higher overhead and slower startup; containers provide density and speed at the cost of weaker isolation because they share the host kernel. Modern systems try to have both by combining them — running containers inside VMs (for example, Kubernetes nodes as VMs) or by using microVMs (Firecracker, Kata Containers) that boot a stripped-down guest kernel in milliseconds, providing VM-grade isolation with container-like startup time and density.
Ready for the graded quiz?
Once you are comfortable with every question above, take the graded Unit 13 quiz in the LMS. It covers the same material with multiple-choice questions and short scenarios requiring a choice between VMs, containers, and microVMs for a given workload.