What is the difference between a container and a virtual machine, and when would you still choose a VM?
Quick Answer
A VM virtualizes hardware and runs a full guest OS on a hypervisor; a container virtualizes the OS and shares the host kernel, packaging just the app and its userspace. Containers are lighter and start in milliseconds; VMs give stronger isolation and can run a different kernel.
Detailed Answer
A virtual machine boots its own kernel on top of a hypervisor, so each VM carries a full operating system — gigabytes of image, seconds to boot, and a fixed slice of RAM/CPU. A container is just a set of processes on the host, isolated by kernel features (namespaces for what a process can see, cgroups for how much it can use, and often seccomp/AppArmor for what it can do). Because containers share the host kernel, images are tens of megabytes, they start almost instantly, and you can pack far more of them per node. The trade-off is the shared kernel: a container cannot run a different OS kernel than the host, and a kernel-level exploit has a larger blast radius than a hypervisor escape. You still reach for VMs when you need hard multi-tenant isolation, a different kernel/OS, or to run untrusted workloads — which is also why sandboxed runtimes like Kata or gVisor exist to give containers VM-like boundaries.
Code Example
# Container: shares host kernel, MBs, ms to start docker run --rm alpine uname -r # prints the HOST kernel version # cgroup limit a container the way K8s does under the hood docker run --memory=256m --cpus=0.5 nginx
Interview Tip
Lead with the one-line distinction (kernel shared vs kernel virtualized), then name the concrete kernel primitives — namespaces + cgroups. Mentioning Kata/gVisor for untrusted workloads signals you know where the line actually is.