Security
Security
Container security is layered: host hardening, daemon access, image provenance, runtime isolation, and secrets handling. Candidates must understand that containers share the host kernel, so isolation is weaker than virtual machines. Key mechanisms include Linux namespaces (isolation of PID, network, mount, user), cgroups (resource limits), capabilities, seccomp profiles, and AppArmor/SELinux mandatory access control.
Best practices: run as a non-root USER in the image; drop capabilities (--cap-drop=ALL then add only what is needed); use --read-only with tmpfs mounts for writable paths; avoid --privileged, which disables nearly all isolation; set no-new-privileges to block setuid escalation; and mount the Docker socket into a container only with extreme caution, since it grants control of the daemon. Image security means scanning for vulnerabilities, using minimal trusted base images, pinning by digest, and never baking secrets into layers - anyone who can pull the image can read them.
Secrets: Docker Swarm secrets are mounted as files under /run/secrets and are encrypted at rest in the Raft log; they are not environment variables by default. BuildKit supports build secrets so credentials are not persisted in layers.
Traps: thinking deleting a secret in a later layer removes it (it does not); believing --privileged is required for most workloads (it almost never is); and assuming a non-root user inside the container is safe if the container still has broad capabilities or a writable host mount.
Rule of thumb: apply least privilege at every layer - non-root user, dropped capabilities, read-only root filesystem, and secrets mounted as files rather than environment variables.
Storage and Volumes
Storage and Volumes
Candidates must distinguish the three ways data enters a container: volumes (managed by Docker, stored under the data root, best for persistence), bind mounts (a host path mapped into the container, dependent on host layout), and tmpfs mounts (memory-only, disappear on stop). The key decision is persistence and portability: volumes are the recommended mechanism for stateful data because Docker manages their lifecycle and they work across platforms.
Understand lifecycle commands: docker volume create, ls, inspect, rm, and prune. A volume persists after a container is removed unless --rm with -v or an explicit docker volume rm is used. Named volumes can be shared between containers, and anonymous volumes are harder to track. In Swarm, volume-backed services are node-local unless a volume driver provides shared storage, so a task rescheduled to another node may not see its data.
Storage drivers (overlay2 and others) manage image layers and the container's writable layer; they are separate from volumes. The writable layer is ephemeral - data written there is lost when the container is removed. Bind mounts are useful for development and configuration injection but create coupling and permission pitfalls, especially with SELinux labeling (:z/:Z) and read-only flags (:ro).
Traps: assuming data in the container's writable layer survives removal; confusing docker volume prune with image pruning; expecting a named volume to be automatically shared across Swarm nodes; and forgetting that a bind mount hides whatever existed at that path in the image.
Rule of thumb: if data must outlive the container, use a named volume; if it must be shared across hosts, use a volume driver backed by network storage.