Docker Interview Questions & Answers

--userns-remap works by mapping container UIDs, including what LOOKS like root inside the container, to a completely unprivileged UID range on the actual host. That means even if an attacker somehow breaks out of container isolation entirely, they land as an unprivileged host user, not real root, which is exactly the containment this setting buys you.

By default, docker stop sends SIGTERM to a container's main process to ask it to shut down gracefully. STOPSIGNAL lets you override WHICH signal gets sent instead, useful for apps that expect a different signal (like SIGINT) to trigger their own graceful shutdown logic.

free reads /proc/meminfo, which isn't aware of cgroups at all, it just reports the HOST's total physical memory regardless of any per-container limit. To see the ACTUAL memory ceiling a container is bound by, an application needs to read the cgroup's own limit file directly instead of relying on tools like free.

The `none` network driver still creates a separate network namespace for the container, so it isn't the same as the host's network, but it attaches no interfaces besides loopback, leaving it with no external connectivity at all. This is useful for containers doing offline or batch work that should never make network calls. Option B describes the DEFAULT bridge driver, and option C describes the `host` driver, which is the opposite of `none`: it removes network isolation entirely instead of maximizing it.

It doesn't kill networking, meaningfully slow startup, or block writes, none of those describe what `--privileged` actually changes. What it does is strip away most of the isolation Docker normally enforces, handing the container almost the same level of access to the host's devices and kernel that a process running directly on the host would have, which is a serious risk if that container is ever compromised.

--userns-remap is configured on the Docker DAEMON itself, but Kubernetes never actually calls docker run directly, it enforces its own equivalent protections (dropped capabilities, read-only filesystems, non-root users) directly through each pod's securityContext instead. So while the other three options still apply meaningfully in Kubernetes, this particular Docker-engine-level setting simply never comes into play.

Uploading is `docker push`, upgrading Docker is a system-level install/update task, and Compose doesn't generate Dockerfiles for you. `docker-compose up` reads the services listed in your docker-compose.yml and starts all of them together, which is the entire reason Compose exists: running multi-container apps with one command.

Host networking removes isolation entirely, and --link is deprecated and clunky. A user-defined bridge network is the modern, recommended answer here: it gives connected containers automatic DNS-based discovery by name, while still keeping them isolated from any unrelated containers that aren't on that same network.

--cpus=2 is implemented as a CFS quota and period pair, roughly 200ms of runtime per 100ms period, and the kernel enforces it per period: if the container's threads burn through that period's quota in a burst, they're throttled, effectively paused, until the next period starts. This shows up as periodic latency spikes rather than a smooth, evenly-distributed slowdown, and is a well-known cause of tail-latency issues in containerized services even when average CPU usage looks comfortably under the configured limit. Option D is a trap: the mismatch reflects a real kernel enforcement mechanism, not a monitoring bug.

`docker login` exchanges credentials for a token that Docker stores, by default in `~/.docker/config.json`, which is what lets later `docker pull` and `docker push` commands access private repositories without re-entering a password every time. It has nothing to do with starting the daemon itself or creating in-container users. Image signing is a separate feature, Docker Content Trust, and is not what `login` does.