Quiz: Container Runtimes

← Back to quiz index

15 questions

L1 (8 questions)

1. What is the relationship between containerd, runc, and the shim?

Show answer

containerd is the high-level runtime (image management, container lifecycle). runc is the low-level runtime that creates the actual container (sets up namespaces, cgroups). The shim (containerd-shim) sits between them — it parents the container process so containerd can restart without killing containers.

2. What Linux kernel features do containers rely on?

Show answer

Namespaces (isolation: PID, network, mount, UTS, IPC, user) and cgroups (resource limits: CPU, memory, I/O). Namespaces make the container think it's alone; cgroups prevent it from consuming all host resources. Containers are NOT VMs — they share the host kernel.

3. What happens when you docker exec into a running container?

Show answer

A new process is started inside the container's existing namespaces (PID, network, mount, etc.). It joins the same cgroup. The exec'd process sees the same filesystem and network as the main process. It does NOT create a new container — it adds a process to an existing one.

4. Where do container stdout/stderr logs go?

Show answer

The container runtime captures stdout/stderr from PID 1 and writes to a log file (e.g., /var/log/containers/ on Kubernetes nodes). The logging driver determines format and destination. In Kubernetes, kubectl logs reads these files. Applications should log to stdout/stderr, not to files inside the container.

5. What is the OCI specification?

Show answer

Open Container Initiative defines standards for container images (image-spec) and runtimes (runtime-spec). Ensures images built with any tool (Docker, Buildah, kaniko) run on any OCI-compliant runtime (runc, crun, gVisor). It's what makes the container ecosystem interoperable.

6. Why should containers run as non-root?

Show answer

Root in a container is UID 0 on the host. A container breakout as root gives host-level root access. Run as non-root (USER directive in Dockerfile) to limit blast radius. Kubernetes can enforce this with runAsNonRoot: true and pod security standards.

7. What are common causes of container runtime failures?

Show answer

1. Disk full on the node (image storage, container logs).
2. containerd/dockerd is down or unresponsive.
3. Image pull failures (auth, network, missing tag).
4. Resource exhaustion (too many containers, PID limits).
5. Corrupted image layers.
6. Socket permission issues (/var/run/containerd/containerd.sock).

8. What is the difference between a container image and a running container?

Show answer

Image: read-only template with filesystem layers, metadata, and default commands. Container: a running instance of an image with a writable layer, network, PID namespace, and state. Multiple containers can run from the same image. Images are stored in registries; containers exist on hosts.

L2 (7 questions)

1. A container is killed with OOMKilled but the application reports using less memory than the limit. Why?

Show answer

1. The limit applies to the entire cgroup, not just the app heap — includes page cache, tmpfs, kernel buffers.
2. Child processes in the same cgroup count toward the limit.
3. Memory accounting includes RSS + cache. Check /sys/fs/cgroup/memory.current vs memory.max inside the container.

2. How do container image layers work and why do they matter for image size?

Show answer

Each Dockerfile instruction creates a layer (read-only). Layers are stacked using overlay filesystems (overlayfs). Shared base layers are pulled only once. A writable layer is added at runtime. Large layers (installing then deleting packages in separate RUN instructions) waste space — combine in a single RUN to keep images small.

3. A container image pull fails with 'manifest unknown' or 'not found'. What do you check?

Show answer

1. Image tag exists in the registry (tags are mutable — it may have been overwritten or deleted).
2. Correct registry URL and repository path.
3. Architecture mismatch (amd64 vs arm64 manifest).
4. Registry authentication (private repo, expired token).
5. Image was built but never pushed.

4. What is seccomp in the context of containers?

Show answer

Seccomp (Secure Computing Mode) filters which syscalls a process can make. Docker's default seccomp profile blocks ~44 dangerous syscalls (e.g., reboot, mount, kernel module loading). Custom profiles can be stricter. In Kubernetes, set via securityContext.seccompProfile. Running without seccomp (Unconfined) increases attack surface.

5. How does container networking work at a low level?

Show answer

Each container gets its own network namespace with a virtual ethernet pair (veth). One end is in the container namespace, the other is on the host bridge (e.g., docker0, cbr0). NAT/iptables rules handle port mapping and inter-container routing. In Kubernetes, the CNI plugin manages this (Calico, Cilium, Flannel).

6. What is the difference between ENTRYPOINT and PID 1 signal handling in containers?

Show answer

PID 1 in Linux has special signal behavior — it ignores signals unless it explicitly handles them. If your app runs as PID 1 (ENTRYPOINT), SIGTERM may be ignored and the container gets killed after the grace period. Fix: use tini or dumb-init as PID 1 to properly forward signals, or handle signals in your app.

7. How do you debug a container that exits immediately after starting?

Show answer

1. Check logs: docker logs / kubectl logs (may be empty if crash is instant).
2. Check exit code: 0 = normal exit (CMD finished), 1 = app error, 137 = OOMKilled/SIGKILL, 139 = segfault.
3. Run interactively: docker run -it --entrypoint /bin/sh image.
4. Check if CMD/ENTRYPOINT is correct.
5. Check for missing env vars or config files.