What is a container vs a VM?

WHAT THIS TESTS This probes whether you understand that containers solve the dependency and consistency problem through OS-level virtualization, distinct from hardware virtualization.

A GOOD ANSWER COVERS A container bundles an application together with its libraries and config so it runs the same everywhere. It executes as an isolated process on the host, sharing the host kernel rather than booting its own. Isolation comes from Linux namespaces, which give each container its own view of process IDs, network, mounts and users, while cgroups cap CPU, memory and IO. A VM instead virtualizes hardware: a hypervisor runs full guest operating systems, each with its own kernel. The payoff is that containers start in milliseconds, use far less memory and disk, and pack densely on a host, while still solving works-on-my-machine drift.

COMMON WRONG ANSWERS Describing a container as a lightweight VM, or claiming each container has its own kernel. Confusing the image (the packaged artifact) with the container (the running instance). Implying containers provide the same strong security boundary as a VM.

LIKELY FOLLOW-UPS How do namespaces and cgroups actually differ? Are containers as secure as VMs, and when would you still pick a VM? What is the difference between an image and a container?

ONE CONCRETE EXAMPLE A Python web app needs Python 3.12 and a specific OpenSSL version. On a shared host that conflicts with another app. Packaged as a container image, it carries exactly those dependencies and starts in under a second; ten such containers share one kernel where ten VMs would each waste gigabytes booting a guest OS.