Docker Fundamentals and Image Management Questions

Comprehensive understanding of Docker and container image lifecycle, including core concepts and practical tasks. Candidates should know containers versus virtual machines, image anatomy and layer caching, Dockerfile syntax and best practices such as multi stage builds and minimizing layer count and size, and strategies for building and optimizing images for performance and storage. Expect knowledge of image registries and workflows for tagging versioned images, pushing and pulling images, and image signing and vulnerability scanning for security. Candidates should be able to run and debug containers, configure networking and volumes for persistence, use Docker Compose for multi container development, and apply runtime considerations such as resource limits and running processes as non root. Familiarity with image cleanup, retention policies, and integration of image workflows into build and deployment pipelines is also assessed.

HardTechnical

83 practiced

You inherit a 2GB monolithic Docker image containing build tools, caches, and the runtime app. Propose a refactoring plan to reduce image size and runtime overhead. Describe concrete steps (multi-stage builds, remove build-time deps, split services), measurements/metrics to track (image size, startup time, memory), and trade-offs with splitting into multiple services.

Sample Answer

**Approach (summary)** As a DevOps Engineer I’d shrink the image by removing build-time artifacts, using multi-stage builds, switching to slim/base runtime images, pruning caches, and considering service-splitting where appropriate. Measure before/after and iterate.

**Concrete steps**- Baseline metrics (image size, startup latency, peak RSS, cold start time, CI build time).- Convert Dockerfile to multi-stage: build in a heavyweight image, copy only runtime artifacts to a minimal runtime image (e.g., distroless or alpine). Example:

dockerfile

# build stage
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o app ./...

# runtime stage
FROM gcr.io/distroless/base
COPY --from=builder /app/app /usr/local/bin/app
ENTRYPOINT ["/usr/local/bin/app"]

- Remove package manager caches, dev tool installations, unused locales, docs.- Use language-specific optimizations (pip wheel + --no-cache-dir, npm ci + prune, gradle --no-daemon).- Strip binaries, enable upx only if safe.- Use layered caching wisely: reorder Dockerfile so rarely-changing layers are above.- Split out large non-core components (e.g., background workers, cron jobs, asset builders) into separate services/sidecars with their own images.- Add CI gate: fail if image > X MB or startup time regresses.

**Metrics to track**- Image size (docker images / registry)- Build time and cache hit rate- Container startup (cold & warm)- Memory and CPU usage under load- Vulnerability scan count

**Trade-offs of splitting**- Pros: smaller images, faster deploys, independent scaling, improved fault isolation.- Cons: increased operational complexity (networking, service discovery), more releases to coordinate, possible latency from RPC. Mitigate via automation (Helm, k8s Deployments), observability, and contract/versioning.

**Result expectation**- Typical reductions: 50–90% image size cut depending on tools/caches removed; faster CI and reduced runtime memory.

HardSystem Design

76 practiced

Architect a scalable image registry deployment for a large organization storing billions of container images over years. Discuss storage backends (object storage vs block), deduplication/content-addressed storage, sharding/partitioning, lifecycle policies, garbage collection scheduling, cross-region replication, cost controls, and how CI integrates with automated cleanup and retention enforcement.

Sample Answer

**Clarify requirements & constraints**- Billions of images, multi-year retention, global teams, strong availability, cost-sensitive, integration with CI/CD.

**High-level architecture**- Content-addressable registry (SHA256) fronted by stateless API servers behind LB; metadata DB (sharded PostgreSQL/CockroachDB) for manifests/tags; object storage for blobs; index layer for fast lookup; background workers for GC/replication.

**Storage backend: object vs block**- Use object storage (S3/GCS/Azure Blob) for image layers: scalable, cost-effective, lifecycle policies, multi-region replication. Block storage only for DB/registry ephemeral volumes and cache nodes (SSD-backed), not for billions of blobs.

**Deduplication / CAS**- Store blobs by digest (content-addressed). Avoid duplicate uploads via upload session + conditional PUT. Maintain reference counts in metadata DB or via per-blob reference table to enable safe GC.

**Sharding / partitioning**- Partition metadata by namespace/org (hash namespace -> shard) and partition object storage with predictable prefixes (e.g., first 2 hex chars of digest) to avoid hotspotting. Use multiple metadata DB shards or a distributed DB (CockroachDB) for horizontal scale.

**Lifecycle policies & GC**- Define org-level policies (e.g., keep latest N tags, keep tags younger than X days, keep images used by prod). Implement policy engine that marks manifests/blobs for retention; GC runs in low-traffic windows via workers that: - Query unreferenced blobs via refcounts - Batch delete from object store with exponential backoff - Reconcile partial failures

**Cross-region replication**- Async, digest-based replication between regions: replicate manifests and blobs on-demand (first-pull fetch) and proactively for critical repos. Use replication queues, idempotent writes, and versioned manifests. Consider multi-master metadata only if strict cross-region write needed.

**Cost controls**- Tier storage: hot (frequently accessed) vs cold (archive) using lifecycle rules to transition older blobs to infrequent/Archive storage.- Chargeback per team, enforce quotas, per-org retention limits, and automated cold-move.- Monitor egress costs; use regional caches/proxies (pull-through cache) at edge.

**CI integration & automated cleanup**- CI annotates images with metadata (build-id, pipeline, expiration timestamp, environment, last-used). On successful deploy, CI calls registry API to mark images as pinned for prod. Periodic job (or webhook) from deployment systems updates last-used timestamp.- Automated cleanup pipeline: - Runs policy engine, marks candidates - Notifies owners (via Slack/email) with TTL before deletion - If no appeal, GC worker deletes- Enforce retention via pre-push hook checks (deny push if exceeding quota) and post-build lifecycle tagging.

**Reliability & monitoring**- Strong metrics (registry ops, GC progress, replica lag), alarms, end-to-end tests for replication and restore. Backups for metadata DB and object store versioning enabled.

Trade-offs:- CAS + object storage maximizes scale and cost-efficiency; eventual consistency for cross-region replication acceptable for most flows. For strict global write consistency, accept higher complexity/cost (distributed DB).

This design balances scalability, cost, and operational control while enabling CI-driven retention and safe automated cleanup.

HardTechnical

86 practiced

Compare using `scratch`, distroless, and minimal distributions (e.g., `alpine`, `debian-slim`) as base images for a compiled Go service. Discuss image size, security surface, debugging capability, library dependencies, and trade-offs. Recommend best practices for production and for debugging scenarios.

Sample Answer

**Approach summary**Compare scratch, distroless, and minimal distros for compiled Go services across size, security surface, debugging, library deps, and trade-offs, then give best-practice recommendations for production and debugging.

**Image size**- scratch: smallest (single binary) — often <10–20MB for a statically linked Go binary + layers. - distroless: minimal runtime files (ca certs, passwd) — slightly larger than scratch but still small (20–40MB). - alpine / debian-slim: larger (30–120+MB) depending on packages.

**Security surface**- scratch: minimal attack surface; no package manager or shells to exploit. Fewer CVEs, but you must ensure binary itself and build pipeline are secure. - distroless: low attack surface; includes only runtime artifacts needed (e.g., CA certs). - alpine/debian-slim: larger surface due to glibc/musl, shells, package managers — more CVEs and patching burden.

**Debugging capability**- scratch/distroless: poor — no shell, no strace, limited runtime introspection. Must build debug images or use ephemeral debug sidecars. - alpine/debian-slim: good — contains /bin/sh, common tools, easier to exec into container for live troubleshooting.

**Library dependencies and cgo**- scratch/distroless: best when Go binary is statically linked (CGO disabled). If your service uses cgo or native libraries, scratch may fail — you must include required .so files or use distroless/busybox-based images. Alpine uses musl which can cause subtle differences versus glibc; debian-slim has glibc compatibility.

**Trade-offs**- scratch: maximal minimalism and security, but lower observability and trickier startup (must bake certs, user files into image). - distroless: balanced — small and secure while providing minimal runtime files, still limited debugging. - minimal distros: easier troubleshooting and compatibility at cost of size and attack surface.

**Recommendations (DevOps perspective)**- Production: prefer distroless for Go services that are statically linked; use scratch only if you need absolute minimal size and have CI-trusted reproducible builds. Ensure multi-stage builds, vulnerability scans, and signed images. Disable CGO or vendor required native libs intentionally. - Debugging / staging: publish separate debug images based on alpine or debian-slim (same binary but linked/packaged with shells and tooling) or use ephemeral debug sidecars and init containers. Keep debug images out of production registries or tag clearly. - Pipeline best practices: use multi-stage builds, reproducible build flags (CGO_ENABLED=0, -trimpath, -ldflags="-s -w"), image vulnerability scanning, and automated rebuilds when base images are patched.

EasyTechnical

128 practiced

List the Docker commands you use to inspect, list, and remove containers and images, and the commands to safely clean up unused resources on a workstation or CI runner. Include `docker ps`, `docker images`, `docker rm`, `docker rmi`, `docker image prune`, and `docker system prune`, and explain common flags you would use.

Sample Answer

**Overview — goal:** common Docker CLI commands to inspect/list/remove containers/images and safe cleanup patterns for a workstation or CI runner.

**Inspect & list**- Containers (running / all)

bash

# running only
docker ps
# all containers (including exited)
docker ps -a
# show last N created
docker ps -n 5

- Images

bash

docker images
# include dangling images
docker images -a

**Remove containers & images**- Remove one or more containers

bash

docker rm <container_id>            # remove stopped container
docker rm -f <container_id>         # force remove running container (stops it first)

- Remove images

bash

docker rmi <image_id_or_repo:tag>   # remove image
docker rmi -f <image_id>            # force removal (used carefully)

**Safe cleanup / prune**- Remove dangling images

bash

docker image prune                   # removes dangling (<none>) images
docker image prune -a                # removes unused images (not referenced by any container)

- System-wide cleanup

bash

docker system prune                   # removes stopped containers, dangling images, networks
docker system prune -a                # also removes all unused images
# add -f to avoid interactive prompt
docker system prune -a -f --volumes   # also remove unused volumes

**Common flags & advice**- -a / --all: broader deletion (use with caution)- -f / --force: skip confirmation (use in CI scripts)- --volumes: include volumes (destructive)- In CI: run non-interactive prunes (use -f) and limit scope (e.g., docker image prune -a --filter "until=24h") to avoid removing images being built concurrently.- On workstation: prefer targeted rm/rmi and inspect before pruning (docker ps -a, docker images --filter "dangling=true").

EasyTechnical

82 practiced

Describe the anatomy of a Docker image and how image layers work. Explain what each layer contains (filesystem diffs, metadata), how the union/overlay filesystem composes them at runtime, how layers are cached and shared between images, and how image manifests and config relate to layers.

Unlock Full Question Bank

Get access to hundreds of Docker Fundamentals and Image Management interview questions and detailed answers.

Join thousands of developers preparing for their dream job.