How do containers enforce CPU and memory limits via cgroups?

WHAT THIS TESTS: This question tests whether you understand the Linux kernel primitives that make container resource limits possible, specifically Control Groups (cgroups). Interviewers want to see that you distinguish between isolation mechanisms like namespaces and resource accounting mechanisms like cgroups. They also want to know if you understand the difference between configuration (Docker or the container runtime setting values) and enforcement (the kernel applying those values).

A GOOD ANSWER COVERS: A strong answer walks through the mechanics in four parts. First, state that cgroups are a Linux kernel subsystem that aggregates processes into hierarchies and tracks their resource usage. Second, for CPU, explain that Docker can set hard caps using CFS quota and period (for example, allowing 0.5 cores by setting a 50ms quota inside a 100ms period) or use CPU shares for relative weighting when the host is under contention. Third, for memory, explain that the runtime writes limits such as memory.limit_in_bytes in cgroups v1 or memory.max in cgroups v2; if a container exceeds its RAM limit and swap is not configured or also exhausted, the kernel Out-Of-Memory killer terminates processes in that cgroup. Fourth, clarify that the container runtime (like runC or crun) writes these parameters into the cgroup filesystem at start time, but the Linux scheduler and memory manager enforce them continuously, not the Docker daemon itself.

COMMON WRONG ANSWERS: A common red flag is confusing cgroups with namespaces, claiming namespaces limit resources when they only provide isolation. Another mistake is saying the Docker daemon actively monitors and throttles the container; in reality, the daemon only configures limits and the kernel enforces them. Candidates also err by describing CPU shares as guaranteed cores rather than relative weights, or by omitting OOM behavior entirely when discussing memory limits. Finally, failing to mention cgroups v2 or the distinction between v1 hierarchies and the v2 unified hierarchy can signal shallow knowledge.

LIKELY FOLLOW-UPS: Interviewers often ask what happens when a container exceeds its memory limit, expecting you to describe OOM kills and how swap limits modify that behavior. They may ask how CPU throttling appears in metrics or how requests differ from limits in Kubernetes, which maps requests to shares and limits to quota. You might also be asked about cgroups v2 improvements, such as the unified hierarchy and better delegation, or how systemd interacts with cgroup management.

ONE CONCRETE EXAMPLE: Imagine starting a container with Docker flags --memory=512m and --cpus=1.5. The runtime creates a cgroup for the container and writes memory.limit_in_bytes to 536870912 bytes. If the container's processes allocate more than 512 MB without sufficient swap, the kernel OOM killer targets them. For CPU, the runtime sets cpu.cfs_quota_us to 150000 and cpu.cfs_period_us to 100000, meaning the container can consume 1.5 cores worth of time every 100 milliseconds; if it tries to use more, the CFS scheduler throttles it until the next period.