Docker vs Virtual Machines MCQ 60 Tests With Answers (2026)

Incorrect·B: By leveraging Linux Kernel Namespaces.

Linux namespaces are kernel features that partition global system resources, creating isolated views. PID namespaces isolate processes (container's PID 1 is invisible outside), network namespaces isolate networking, mount namespaces isolate filesystems (including /proc, /sys, /dev). Namespaces are the technical foundation of container isolation.

Incorrect·A: Control Groups (cgroups)

Control Groups (cgroups) are kernel mechanisms that enforce resource limits and quota. You can restrict a container to 2 CPUs, 512 MB RAM, or 100 MB/s disk I/O using cgroups. Cgroups also monitor resource usage in real-time. Namespaces provide isolation; cgroups provide resource enforcement—both are essential for container management.

Incorrect·B: Type 1 runs directly on the bare-metal hardware; Type 2 runs as an application on top of a host operating system.

Type 1 (bare-metal) hypervisors like ESXi, Hyper-V, and KVM boot directly on physical hardware and manage VMs without a host OS. Type 2 hypervisors like VirtualBox, VMware Fusion, and Parallels run as applications on a host OS (Windows, macOS). Type 1 is for data centers; Type 2 is for desktops.

Incorrect·A: Routing traffic between the host's physical network adapter and the virtual network adapters of the VMs.

A vSwitch is a virtual network switch managed by the hypervisor. It bridges the physical network interface to virtual network interfaces assigned to VMs. vSwitches can be in "Bridged" mode (VMs get real network access) or "NAT" mode (VMs share the host's IP). Network policies, VLANs, and port mirroring can be configured on vSwitches.

Incorrect·B: Data is strictly written to the container's writable layer and is lost permanently when the container is deleted, unless external Volumes or Bind Mounts are used.

By default, container data is ephemeral—the writable layer is deleted with the container. To persist data, you must use Docker Volumes (managed by Docker, stored in /var/lib/docker/volumes/) or Bind Mounts (host filesystem directories mounted into the container). Without these, data loss occurs on container deletion.

Incorrect·C: Union File Systems (e.g., OverlayFS)

Union File Systems (UnionFS, AUFS, OverlayFS) allow multiple read-only layers to be stacked and presented as a single filesystem. Each Dockerfile instruction creates a layer; at runtime, all layers are merged. The container gets a thin writable layer on top. This enables sharing of base layers and rapid image distribution.

Incorrect·A: A kernel panic or severe vulnerability exploited in one container can potentially compromise the host and all other containers running on it.

Container isolation relies on kernel security. A kernel vulnerability (like CVE-2021-22555, Dirty Pipe) exploited within a container can escalate to host root, compromising all containers and the host. This is why kernel security updates are critical for container environments. VMs avoid this risk because a guest OS exploit cannot directly hit the hypervisor.

Incorrect·D: Docker Containers

A single server might run 5–10 VMs (limited by RAM and hypervisor overhead) but hundreds or thousands of lightweight containers. Each container overhead is minimal (a few MB plus namespace/cgroup bookkeeping). A microservices architecture with containers achieves 10–100x higher application density than VMs on identical hardware.

Incorrect·B: Bridge Network Mode

Bridge mode is the default: Docker creates a bridge interface (docker0) on the host. Containers attach to this bridge with internal IPs (e.g., 172.17.0.2). NAT rules (iptables) map container ports to host ports. A container's port 8080 might map to host:8080, making it accessible externally. Host mode bypasses this; overlay mode supports multi-host networking.

Incorrect·A: The admin cannot see processes running inside VMs, but can view processes running inside containers using standard commands like `top` or `ps`.

VM processes are hidden—the hypervisor emulates separate process spaces, making VM processes invisible to the host. Container processes are visible on the host because they run natively on the host kernel. An administrator can `ps aux` and see all container processes. This makes container debugging easier but also means the host can see and manage container internals.

Incorrect·B: It is an industry-standard core container runtime responsible for managing the complete container lifecycle (image transfer, execution, and storage) beneath the Docker engine.

Containerd is an abstraction layer between Docker CLI and the kernel. Docker delegates container management to containerd, which handles image pulling, filesystem setup, and delegation to `runc` for execution. Kubernetes uses containerd directly, bypassing Docker entirely. This separation allows container runtimes to evolve independently of the Docker daemon.

Incorrect·B: They must be trapped and translated by the hypervisor before being passed to the physical CPU, introducing computational overhead.

VMs are not true "pass-through" execution. Privileged instructions (changing memory mappings, enabling interrupts, etc.) from the guest are trapped by the hypervisor and translated to equivalent operations. This interception is called "VM exit." Modern CPUs provide hardware-assisted virtualization (like Intel VT-x) that accelerates this, but overhead still exists.

Incorrect·B: It provides the rapid deployment benefits of containers while leveraging the strong, hardware-level security boundaries and mature management tools of VMs.

A common production architecture is "Containers in VMs": run Docker on Linux VMs managed by a hypervisor (ESXi, Hyper-V, etc.). This combines container agility (inner layer) with VM isolation and compliance benefits (outer layer). If a container escapes, it's confined to the VM. If a kernel exploit hits the host, the VM boundary provides defense-in-depth.

Incorrect·A: Containers are ephemeral and can be built, spun up, tested, and destroyed in seconds, whereas deploying full VMs for every minor code test is vastly too slow and resource-heavy.

CI/CD pipelines need rapid iteration: build → test → deploy → destroy. Containers excel here: Docker images are built in seconds, spun up in milliseconds, run integration tests, then are discarded. VMs take minutes to boot and consume significant resources, making per-commit VM deployment economically infeasible. Containers enable test parallelization.

Incorrect·A: A VM boots a full init system (like systemd) to start multiple background services, whereas a container typically runs the application executable directly as PID 1 without background OS services.

A VM boots systemd or init, which spawns background services (sshd, syslog, cron, etc.)—a full OS environment. A container's PID 1 is usually the application (e.g., `java -jar app.jar`). If the application exits, the container stops. This design principle—one process per container—aligns with the Unix philosophy and microservices patterns.

Incorrect·B: Live Migration (e.g., vMotion)

Live migration (vMotion, KVM live migration) pauses a running VM, copies its memory to a target host, and resumes it there—downtime is sub-second. Containers don't support true live migration because they're process-based, not OS-based. Orchestrators like Kubernetes instead recreate containers on new hosts (rolling updates, minimal disruption).

Incorrect·A: VMs are typically patched in-place while running, whereas vulnerable containers are destroyed and replaced entirely with a newly built, patched image.

VMs are mutable: you SSH in and run `apt update && apt upgrade`. Containers follow an immutable paradigm: rebuild the image with updated packages, push the new image, and orchestrate replacement of old containers. This "immutable infrastructure" approach improves reliability and auditability over in-place patching.

Incorrect·C: A Dockerfile

A Dockerfile is a text file containing instructions (FROM, RUN, COPY, EXPOSE, CMD) that Docker uses to build images layer-by-layer. Each instruction creates a layer; `docker build` executes them sequentially. Dockerfiles enable version control, reproducible builds, and Infrastructure-as-Code for containerized applications.

Incorrect·B: It is a tool for defining and running multi-container Docker applications using a single YAML file to configure application services.

Docker Compose is a multi-container orchestrator for single hosts. A `docker-compose.yml` file defines services (web, database, cache, etc.), their images, ports, volumes, environment variables, and dependencies. `docker-compose up` launches the entire stack. It's ideal for local development and CI environments; Kubernetes handles production multi-host orchestration.

Incorrect·C: A Virtual Machine

Docker containers run on the host kernel; you cannot choose a different kernel. If the application requires Windows Server 2008 kernel features (like specific APIs or driver compatibility), you must use a VM with Windows Server 2008 Guest OS. Containers' kernel-sharing model prevents this flexibility.

Incorrect·B: An attack where a malicious user breaks out of the container's isolated namespaces to gain root access to the underlying host operating system.

A container escape is a security breach where an attacker exploits a kernel vulnerability or misconfiguration to break out of the container's namespace isolation and gain access to the host. Famous examples include dirty cow, runc race conditions, and runC breakouts. Escaped containers can compromise all sibling containers and the host itself.

Incorrect·C: Intel Virtualization Technology (Intel VT-x)

Intel VT-x (AMD SVM for AMD) provides hardware-level virtualization support: CPU modes (VMX root/non-root), extended page tables, and direct I/O access. Without hardware assistance, hypervisors must emulate privileged instructions in software (binary translation), which is slow. Modern hypervisors require hardware virtualization extensions.

Incorrect·B: It spawns and runs containers strictly according to the OCI specification by interfacing directly with kernel namespaces and cgroups, independent of the higher-level Docker daemon.

Runc is the OCI-compliant low-level container runtime. It reads an OCI runtime specification (json file describing namespaces, cgroups, mount points), then calls kernel APIs (clone(), unshare(), setns()) to create isolated processes. Docker and Kubernetes use runc (via containerd) to actually execute containers. Runc is the bridge between high-level container orchestrators and the kernel.

Incorrect·A: Docker bridge networks utilizing iptables NAT can introduce noticeable CPU overhead and latency in high-throughput microservice environments, whereas VM vSwitches often utilize SR-IOV for direct hardware access.

iptables-based NAT in Docker (DNAT/SNAT) adds CPU overhead per packet. vSwitches can offload to SR-IOV NICs, bypassing the host kernel for VM traffic. In high-throughput scenarios (>10 Gbps), Docker bridge networking is slower than VM vSwitches. Overlay networking, host networking, or socket-based approaches reduce this gap.

Incorrect·A: Kata Containers (or Firecracker microVMs)

Kata Containers and Firecracker run application containers inside minimal, purpose-built VMs instead of relying on kernel namespace isolation. Each container gets its own lightweight VM (boots in milliseconds, uses minimal RAM). This provides VM-level security isolation while maintaining container speed. Popular with untrusted workload isolation (e.g., AWS Lambda).

Incorrect·C: Storage I/O abstraction layers, UnionFS overhead, and host kernel caching conflicts can introduce unpredictable latencies compared to direct block storage access in VMs or bare metal.

Containerized databases face latency issues: UnionFS layers add overhead, bind mount caching interactions with host page cache can cause unexpected stalls, and iptables NAT adds latency to network I/O. Bare metal or VM with direct storage access (no layering) offers predictable, low-latency I/O—critical for databases. High-performance applications often use VMs or bare metal.

Incorrect·A: On Windows, Docker utilizes a lightweight utility VM (often via WSL 2 or Hyper-V) to host the necessary Linux kernel, whereas on native Linux, it utilizes the host kernel directly.

Docker requires a Linux kernel (for namespaces, cgroups). On Linux, it uses the native kernel. On Windows 10/11, Docker Desktop runs a lightweight Linux VM (WSL 2 or Hyper-V) and communicates with it. On macOS, Docker also runs a hidden Linux VM. This explains why Docker on Windows is slightly slower than native Linux.

Incorrect·B: The Kubelet and the Kubernetes Control Plane

Kubernetes is a container orchestrator that manages containers across multiple host nodes. The Kubelet (node agent) communicates with the Control Plane (API server, scheduler, controller manager). Kubernetes abstracts away individual hosts, scheduling containers/pods based on resource requests, tolerations, and affinity rules. Docker is a runtime; Kubernetes is the orchestrator above it.

Incorrect·C: It disables namespace and cgroup restrictions, granting the container near-total root capabilities over the host system, making container escape trivial.

Privileged mode (`--privileged`) removes namespace and cgroup restrictions, giving the container access to host device nodes, full CPU/memory/network capabilities, and capability to mount the host filesystem. A privileged container can easily gain host root access—it's essentially unrestricted access. Only use for legitimate low-level tasks (like container runtimes themselves).

Incorrect·A: Hypervisors utilize complex ballooning and page-sharing drivers to overcommit memory safely, whereas Docker relies entirely on the Linux kernel's OOM (Out Of Memory) killer to terminate greedy container processes if the host exhausts its RAM.

Hypervisors implement memory ballooning: guests negotiate, swell, and shrink virtual balloons to elastically balance memory. Containers use kernel OOM-killer: when memory is exhausted, the OOM killer selects and terminates the most memory-hungry process. Hypervisors are more graceful; container approach is harsher but simpler.

Incorrect·B: The ability to run a hypervisor (and VMs) inside another virtual machine, which requires the underlying host hypervisor to expose hardware virtualization extensions (like VT-x) to the guest VM.

Nested virtualization (e.g., running KVM VMs inside Hyper-V VMs) requires the host hypervisor to expose CPU virtualization flags to the guest. Most cloud providers disable this for performance and security reasons. However, modern processors and cloud platforms are improving support. Deeply nested architectures suffer severe performance degradation.

Incorrect·D: AppArmor or SELinux

AppArmor and SELinux are Linux MAC modules that define which capabilities processes can exercise. Docker can enforce AppArmor profiles per container, restricting privileged syscalls (mount, ptrace, etc.). Seccomp (also used by Docker) achieves similar goals by filtering syscalls. Together, they reduce the kernel attack surface containers expose.

Incorrect·C: Deploying distinct Virtual Machines on isolated, dedicated bare-metal hosts (Type 1 Hypervisor) for each tenant.

Regulatory frameworks like HIPAA, PCI-DSS, and others mandate physical/hardware isolation for multi-tenant environments. Containers share the kernel, so namespace isolation is perceived as insufficient. VMs on isolated bare-metal hosts provide hardware-level segregation and audit trails separating each tenant completely. More expensive but legally necessary.

Incorrect·B: It filters and restricts the specific Linux system calls a containerized process is permitted to execute, minimizing the kernel attack surface.

Seccomp (secure computing mode) is a Linux kernel feature that restricts which syscalls a process can call. A container can run with a seccomp profile that whitelists only necessary syscalls (e.g., read, write, mmap) and blocks everything else (e.g., ptrace, mount, reboot). This dramatically reduces the kernel attack surface a container can exploit.

Incorrect·C: They utilize a minimalist, heavily stripped-down hypervisor and incredibly thin guest kernels to boot in milliseconds while maintaining rigid hardware-level isolation.

Firecracker is a KVM-based microVM hypervisor specifically designed for serverless. It boots a minimal Linux kernel in ~125ms and consumes ~5MB RAM per VM. This bridges containers (fast, dense) and VMs (secure). Each Lambda invocation gets its own microVM, providing isolation at container density.

Incorrect·A: When a container attempts to modify an existing file from a read-only image layer, the file is copied up to the container's writable layer before the modification occurs, preserving the underlying image.

CoW is an optimization technique used by UnionFS. Image layers are read-only and shared across containers. When a container modifies a file, only that modification is copied to the writable layer, not the entire file. This reduces disk I/O and storage space—multiple containers can safely modify the same "file" (each gets its own copy in the writable layer).

Incorrect·B: VM Exits occur when the hypervisor must intervene to handle privileged instructions or hardware interrupts generated by the Guest OS, causing a context switch. Containers share the host kernel, executing system calls directly without hypervisor intervention.

A VM Exit is when the hypervisor must intercept and handle a privileged instruction issued by guest OS code. Examples: memory mapped I/O, I/O port access, MSR writes. Each exit involves a context switch (guest→hypervisor→guest), adding latency. Containers avoid this: syscalls are handled directly by the host kernel in the container's privilege level.

Incorrect·D: Macvlan Networking

Macvlan allows a container to have its own virtual MAC address on the host's physical network. The container appears as a separate physical device to the switch, receiving its own DHCP lease and IP. No NAT is involved. Useful for legacy applications expecting direct network presence, but incompatible with containers needing inter-container communication.

Incorrect·C: Creating a virtual disk that only consumes host storage space as data is actually written, risking a host storage outage if multiple VMs suddenly expand and overcommit the physical hardware.

Thin provisioning allocates disk space on-demand: a 100GB thin-provisioned VM initially consumes 0 bytes; as data is written, the file grows up to 100GB. If multiple VMs fail to monitor growth, the shared storage pool can become exhausted, causing VM crash. Monitoring and enforcement of quotas are critical. Thick provisioning pre-allocates space, avoiding this risk but wasting storage.

Incorrect·B: It allows the Docker daemon and containers to run entirely within an unprivileged user namespace, mitigating the risk of an attacker gaining host root access if they manage a container escape.

Rootless Docker runs the Docker daemon and containers under an unprivileged user account, using user namespaces to map container root (UID 0) to a non-root host UID. If a container escapes, the attacker gains an unprivileged user shell, not host root. This dramatically reduces the blast radius of container escapes. Trade-off: some features (device access, privileged network ports) require workarounds.