Name three Linux namespaces and explain what each one isolates.
Kernel primitives behind container isolation.
Name three of PID, Network, Mount, UTS, IPC, User, Cgroup, Time; say what each hides; cite CLONE_NEW* or /proc/pid/ns.
What's really being asked
This question probes whether you know how containers actually work at the kernel level. Anyone can run Docker commands; senior engineers should understand that containers are not magic but rather a composition of specific Linux kernel features. Namespaces are the isolation primitive, and the interviewer wants to see that you can name concrete types, describe exactly what global resource each one virtualizes, and ideally reference the system-call API or procfs entries that expose them.
The full answer
A strong response names three or more namespaces from the eight available types and precisely states what each isolates. For example, the PID namespace isolates process IDs so that init inside the container is PID 1 and host PIDs are invisible. The Network namespace isolates network devices, routing tables, firewall rules, and port numbers so the container can have its own loopback and IP stack. The Mount namespace isolates filesystem mount points so that a container's rootfs does not leak to the host. Other valid choices include UTS for hostname and NIS domain, IPC for System V and POSIX message queues, User for UID and GID mappings, Cgroup for the cgroup root directory view, and Time for boot and monotonic clocks. Mentioning the CLONE_NEW* flags used with clone, unshare, or setns, or noting that /proc/pid/ns/ exposes stable namespace file descriptors, signals that you have worked with the API directly rather than just reading docs.
The mistakes people make
The biggest red flag is conflating namespaces with cgroups. Namespaces isolate what a process can see; cgroups limit what a process can use. Saying that namespaces throttle CPU or memory is a fundamental misunderstanding. Another weak pattern is answering with Docker abstractions like overlay networks or volumes instead of kernel namespaces. Listing a namespace without explaining the specific global resource it wraps also scores poorly because it suggests memorization without comprehension.
What usually comes next
An interviewer may ask what happens if you share a namespace between containers, how you enter an existing namespace with nsenter or setns, or why user namespaces are special because unprivileged users can create them since Linux 3.8. They might also ask how PID namespaces interact with signal delivery or how mount propagation flags affect shared mount namespaces.
A concrete example
If you run a container and it binds to port 80, that works without host conflict because the container is in its own Network namespace created with CLONE_NEWNET. Inside that namespace the process sees its own eth0 and loopback, while on the host the veth pair end is attached to a bridge. The process also believes it is PID 1 because of CLONE_NEWPID, and its filesystem root is isolated by CLONE_NEWNS, all orchestrated by the runtime before execing the container payload.
Interview question
A container needs its own eth0 and routing table while its init process appears as PID 1. Which clone flags are required to create it?
- a.CLONE_NEWPID and CLONE_NEWNS
- b.CLONE_NEWNS and CLONE_NEWCGROUP
- c.CLONE_NEWNET and CLONE_NEWPIDCorrect
- d.CLONE_NEWUSER and CLONE_NEWIPC
Why? this is the answer
CLONE_NEWNET creates a new Network namespace for isolated interfaces and routing tables, while CLONE_NEWPID creates a new PID namespace so the container's init becomes PID 1. Option A is tempting because it includes the correct PID flag, but CLONE_NEWNS isolates mount points rather than network devices.
Just read this? Test yourself on what you have been reading.
Read the original → man7.org
- #linux
- #namespaces
- #containers
- #docker
- #kernel
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles