What makes a process a container to the kernel

WHAT THIS TESTS Whether you can go past the textbook namespaces-and-cgroups answer to the full set of kernel features that constrain a containerized process, and whether you know it shares the host kernel.

A GOOD ANSWER COVERS From the kernel's view a container is a normal process; nothing about its scheduling or execution is fundamentally new. What differs is the bundle of constraints applied. Namespaces give it isolated views of PIDs, network, mounts, users, IPC, UTS and cgroups so it sees its own slice of the system. Cgroups cap and account its CPU, memory, IO and pids. Beyond those, the process runs with a reduced Linux capability set, dropping privileges like raw networking or mounting unless explicitly granted. A seccomp profile filters which syscalls it may invoke, shrinking the attack surface. Its root filesystem is swapped via a mount namespace plus pivot_root or chroot so it sees the image's rootfs, not the host's. Mandatory access control through SELinux or AppArmor labels confines what files and operations it can touch. The no_new_privs flag often prevents privilege escalation. All of this runs on the single shared host kernel; there is no separate guest kernel as in a virtual machine.

COMMON WRONG ANSWERS Stopping at namespaces and cgroups, which the question explicitly asks you to exceed. Saying a container has its own kernel or boots an OS; it does not, which is the key distinction from VMs. Forgetting security layers like capabilities, seccomp and MAC that are central to container isolation.

LIKELY FOLLOW-UPS Why is sharing the kernel both efficient and a weaker isolation boundary than a VM? What does a privileged container actually relax? How do gVisor or Kata change the model by adding a kernel boundary? How does rootless containerization use user namespaces?

ONE CONCRETE EXAMPLE Running nginx in a container, ps on the host shows an ordinary nginx process. Yet it lives in its own PID and network namespaces, is capped to half a CPU and 256 MiB by cgroups, has dropped CAP_SYS_ADMIN, runs under a seccomp profile blocking dangerous syscalls, sees the image rootfs via pivot_root, and is labeled by SELinux, all while executing on the same kernel as the host.