TL;DR: A VM runs a full guest kernel on virtualised hardware. A container is an ordinary Linux process whose view is narrowed by namespaces and whose resources are capped by cgroups, sharing the host kernel. Sharing avoids booting a guest kernel, but startup still includes image pulls and application initialization. The shared kernel also shapes the security boundary.
How to approach it
Answer with the mechanism rather than the diagram. Most people draw the two stacks and say containers are lighter, which is the observation rather than the reason. Naming namespaces and cgroups specifically, and then drawing the security conclusion from the shared kernel, is what makes this sound like knowledge rather than a slide.
A strong answer
A virtual machine is created by a hypervisor that presents virtual hardware: a CPU, disks, network cards. On top of that you install a full operating system with its own kernel. Booting includes guest-kernel initialization. Its time and image size depend on the guest and virtualization implementation; lightweight VMs can boot quickly.
A container is not a machine at all. It is a process running directly on the host kernel, with two Linux features applied to it.
Namespaces restrict what the process can see. A PID namespace means it sees its own process tree starting at PID 1 and cannot see the host's processes. A mount namespace gives it its own filesystem view, which is how the container image becomes its root directory. A network namespace gives it its own interfaces and routing table, so it has its own IP. There are others for hostname, users and inter-process communication. Each one narrows a dimension of what the process perceives.
cgroups restrict what it can consume: a CPU quota, a memory limit, IO bandwidth. Exceed the memory limit and the kernel's OOM killer terminates the process, which is what an OOMKilled pod actually is.
That is the whole mechanism. ps on the host shows the container's processes as ordinary processes, because they are. There is no guest kernel, no virtual hardware, no boot.
The consequences worth stating:
A container avoids per-VM guest-kernel overhead. Its image contains application and userland dependencies; image size, pull time and application initialization can still dominate startup. Measure density and recovery time for the actual workload.
And the security consequence, which is what the shared kernel actually costs you. All containers on a host share one kernel. A successful kernel escape can compromise the host and neighboring workloads. VM isolation introduces a guest/hypervisor boundary, which also has an attack surface and needs patching. So containers are an excellent isolation boundary between your own cooperating workloads and a weak one for anything untrusted. If you run code a customer supplied, you want a sandboxed runtime like gVisor or Kata (which puts a lightweight VM back underneath) or a separate machine.
The practical point about portability: a container image carries your dependencies but not a kernel, so it depends on the host kernel's ABI and on the architecture. An arm64 image does not run on an amd64 host without emulation, which is why multi-architecture images exist.
Apply the distinction to a build service
Suppose a platform runs trusted application builds and also accepts build scripts uploaded by external customers. Both can use container images, but the trust boundary differs. A customer script can deliberately exercise kernel interfaces, mount behavior or resource exhaustion. Restrict capabilities, system calls and host access, then choose a sandbox or VM boundary appropriate to that untrusted workload.
Resource isolation needs its own test. A memory limit can contain one process's allocation while disk writes or excessive processes still damage neighboring work if those resources have no effective limit. Check the configured controls and measure a representative noisy workload in an isolated environment.
For trusted services, shared-kernel containers can be a useful density and deployment choice. For external code, explain the additional boundary and how you patch it. “It runs in Docker” does not describe the permission set, runtime or threat model.
What interviewers probe next
"Why does a container image need a base like Debian or Alpine then?" For userland: libc, shell, certificates, package tooling. Not for a kernel. A suitable statically linked binary can run in scratch, though it may still need data such as CA certificates. Distroless images include selected runtime files while omitting tools such as a shell and package manager.
"Can a container run a different OS from the host?" A different distribution, yes, because that is userland. A different kernel, no. Linux containers on macOS or Windows commonly run inside a Linux VM. Windows containers are a separate mode with Windows kernel compatibility requirements.
"What does --privileged do?" Removes most of the restrictions: all capabilities, access to host devices. It reduces the container to roughly a process with root on the host, and it is worth being able to say that plainly because it is requested far more often than it is needed.
Common mistakes
Saying containers are "lightweight VMs", which gets the mechanism backwards and leads to wrong conclusions about isolation.
Claiming containers are more secure than VMs. They isolate differently and the shared kernel is a larger attack surface.
Forgetting that the host kernel is shared, then running untrusted code in a plain container.
Believing an image is portable everywhere, when it is tied to a kernel ABI and a CPU architecture.