Bind mounts versus named volumes
WHAT IT TESTS: Docker storage model. OUTLINE: a bind mount maps a host path into the container (great for live source in dev); a named volume is Docker-managed storage decoupled from the host layout (ideal for database data).
Compose image directive versus build directive
WHAT IT TESTS: Compose service definition. OUTLINE: image pulls a prebuilt image from a registry; build builds from a local Dockerfile and context; use build for your own custom application code.
Manage startup order and readiness in Compose
WHAT IT TESTS: dependency vs readiness distinction. OUTLINE: depends_on only orders start, not readiness; add a healthcheck to the DB and use depends_on with condition: service_healthy so the web app waits until the DB passes its health check.
Docker Compose default networking
WHAT IT TESTS: Compose networking internals. OUTLINE: Compose creates one default user-defined bridge network for the project; all services join it and reach each other by service name via embedded DNS, isolated from other projects.
How Compose services reach each other by name
WHAT IT TESTS: Compose service discovery. OUTLINE: services share a default network and the web app uses the database's service name as the hostname; Docker's embedded DNS resolves it to the container IP.
Persist PostgreSQL data across compose down
WHAT IT TESTS: volume persistence basics. OUTLINE: define a named volume and mount it at the database's data directory (/var/lib/postgresql/data); named volumes survive compose down.
Start Compose services detached and view one service's logs
WHAT IT TESTS: basic Compose CLI usage. OUTLINE: docker compose up -d starts everything detached; docker compose logs -f web follows only the web service's logs.
Distroless images: benefits and trade-offs
WHAT IT TESTS: minimal base image strategy. OUTLINE: distroless ships only the app and runtime deps, no shell or package manager; smaller and a smaller attack surface than Alpine; trade-off is harder debugging with no shell.
Pass build-time secrets securely with BuildKit
WHAT IT TESTS: secure build secret handling. OUTLINE: use BuildKit RUN --mount=type=secret (or type=ssh) so the secret is mounted only during that step and never written to a layer; pass it with --secret at build time.
Run a container as a non-root user
WHAT IT TESTS: container security hardening. OUTLINE: create a dedicated group and user, chown app files to them, then USER to drop privileges before the process runs.
What is a dangling image and how to prune it
WHAT IT TESTS: image lifecycle and cleanup. OUTLINE: a dangling image is an untagged layer (<none>:<none>) orphaned when a tag moves to a rebuilt image; list with docker images -f dangling=true, remove with docker image prune.
Debug a running container with the Docker CLI
WHAT IT TESTS: practical container debugging. OUTLINE: docker inspect for full state and config, docker logs -f to follow output live, docker exec -it <id> sh or bash for an interactive shell.
Multi-stage builds for compiled languages
WHAT IT TESTS: image slimming and build hygiene. OUTLINE: build in a stage with the full toolchain, then COPY --from only the artifact into a tiny final base, shrinking image size and attack surface.
Optimize Dockerfile layer caching for npm install
WHAT IT TESTS: layer caching mechanics. OUTLINE: copying all source first invalidates the npm install layer on any code change; instead copy package.json and lockfile, run npm install, then copy the rest.
Dockerfile CMD versus ENTRYPOINT
WHAT IT TESTS: container startup behavior. OUTLINE: ENTRYPOINT sets the fixed executable; CMD sets default args or the default command; run-time args override CMD but append to ENTRYPOINT. Use together to make a fixed binary with overridable defaults.
Dockerfile COPY versus ADD
WHAT IT TESTS: Dockerfile clarity and best practice. OUTLINE: COPY just copies local files; ADD also auto-extracts local tarballs and can fetch remote URLs; prefer COPY for predictability, use ADD for local archive extraction.
Build, tag, and run a container with port mapping
WHAT IT TESTS: core build and run CLI fluency. OUTLINE: docker build -t my-app:1.0 . to build and tag; docker run -d -p 8080:80 my-app:1.0 to run detached with host:container port mapping. RED FLAG: reversing the port order or forgetting the build context dot.
Trace a container process's syscalls from the host
WHAT IT TESTS: understanding that containers are host processes. OUTLINE: find the host PID via docker inspect or ps, then strace -p that PID from the host, since the container shares the host kernel.
What is the OCI and why do its specs matter?
WHAT IT TESTS: knowledge of container standards. OUTLINE: OCI defines vendor-neutral specs for image format and runtime so any compliant tool interoperates; runc implements the runtime spec; this prevents lock-in.
What is a container vs a VM?
WHAT IT TESTS: understanding of OS-level virtualization. OUTLINE: containers share the host kernel and isolate via namespaces and cgroups; VMs run a full guest OS on a hypervisor; containers are lighter and faster.