Docker Interview Questions

containerd is a high-level container runtime (a CNCF graduated project) that Docker's daemon delegates container lifecycle management to via gRPC. It handles image pulls, snapshots, and supervising container processes, and itself delegates the low-level namespace/cgroup setup to runc. Kubernetes can also use containerd directly as a CRI runtime, without needing Docker at all.

runc is a CLI tool and library implementing the OCI (Open Container Initiative) runtime specification. It is the component that actually calls Linux kernel primitives — namespaces and cgroups — to create the isolated environment and exec the container's process. It is the lowest layer in the Docker/Kubernetes runtime stack.

By default over a Unix domain socket at /var/run/docker.sock, using a versioned REST API (e.g., /v1.46/containers/json). It can also be configured to use a TCP socket (optionally with TLS) or SSH for remote daemons, controlled via the DOCKER_HOST environment variable or `docker context`.

The CLI sends a create-container request to the daemon. The daemon checks for the image locally, pulling from the registry if missing. It asks containerd to create a container from the image's layered filesystem (via the storage driver) plus a new writable layer. containerd asks runc to set up namespaces and cgroups and exec the container's entrypoint. The daemon then configures networking (bridge attachment, NAT rules for any -p mappings) before returning control to the CLI.

No. A container is a regular host process with restricted visibility, achieved via Linux namespaces (isolation) and cgroups (resource limits) — there is no hypervisor and no separate kernel. This is why containers start in milliseconds and share the host kernel, unlike VMs which boot a full guest OS.

A registry is any server implementing the Docker Registry HTTP API v2 for storing and distributing images by name and digest. Docker Hub is Docker Inc.'s public hosted registry and the default one the CLI pulls from. Private alternatives include AWS ECR, GitHub Container Registry (GHCR), Google Artifact Registry, and self-hosted options like Harbor or Nexus.

The Open Container Initiative defines open specifications for container images (image-spec) and runtimes (runtime-spec). Because Docker images conform to OCI image-spec, they are portable: an image built by Docker can run unmodified under containerd, CRI-O, or Podman. This is why Kubernetes can drop Docker entirely yet still run 'Docker images'.

Kubernetes removed dockershim (the compatibility layer that let kubelet talk to dockerd) because it added an unnecessary extra layer; kubelet now talks to containerd or CRI-O directly via the CRI interface. Docker-built images are OCI-compliant, so they run completely unaffected — only the underlying runtime used to start them changed.

Never expose the daemon over plain TCP without TLS. Restrict the docker Unix group to trusted users (membership is equivalent to root). For remote access, use TLS client-certificate authentication or SSH-based contexts. For multi-tenant or CI environments, prefer rootless Docker or delegate orchestration to Kubernetes with proper RBAC instead of direct daemon access.

Your GitHub Actions self-hosted runner fails with 'Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?' Walk through your diagnosis. Expected reasoning: confirm dockerd is running (systemctl status docker), confirm the runner's user is in the docker group or has socket permissions, check DOCKER_HOST isn't pointing somewhere stale, and check the socket file actually exists (it may be in a container without the socket mounted, in which case the build needs docker-in-docker or socket-mounting with awareness of the security trade-off).

You discover a container running a public-facing API has `-v /var/run/docker.sock:/var/run/docker.sock`. Explain the risk and your remediation. Expected reasoning: this gives the container root-equivalent control of the host — any RCE in the app becomes a host compromise. Remediation: remove the mount; if Docker-control-from-a-container is genuinely required (e.g., a CI orchestrator), isolate it on a dedicated host/network, use a Docker socket proxy that whitelists API endpoints, or move to a rootless/Sysbox-based setup.

Each instruction's cache key depends on the previous layer's digest, the instruction text, and (for COPY/ADD) a hash of the referenced files. If all three match a previous build, Docker reuses the cached layer rather than re-executing the instruction. The moment one instruction misses the cache, every subsequent instruction also misses, since each layer builds on the previous one's digest.

Because cache invalidation cascades downward: instructions are cached based on everything before them. Placing rarely-changing steps (installing dependencies) before frequently-changing steps (copying application source) means a source code change only invalidates the layers after the dependency install, not the expensive dependency install itself.

It is permanently deleted. Any files written during the container's life that weren't stored in a volume or bind mount are lost. The underlying image layers are unaffected since they are shared, read-only, and owned by the image, not the container.

Created (filesystem and config prepared, not started) -> Running (process started) -> Paused (frozen via cgroups freezer, process suspended but not stopped) -> Stopped/Exited (PID 1 exited, container metadata retained) -> Removed (writable layer and metadata deleted). docker run combines create and start; docker rm -f combines stop and remove.

Copy-up is the overlay2 behavior where, the first time a container modifies a file that exists in a lower read-only layer, the entire file is copied into the writable layer before the modification is applied. For large files, this makes the first write unexpectedly slow, which is one reason write-heavy data (like a database's data directory) belongs in a volume, not the container's own filesystem.

Use a smaller/minimal base image (alpine, distroless), combine RUN instructions to avoid layer bloat, clean up package manager caches within the same RUN that installed them, use multi-stage builds to exclude build tools from the final image, and use .dockerignore to keep unrelated files out of the build context entirely.

docker commit snapshots a running container's current writable layer into a new image layer, producing a new image. It's useful for quick debugging snapshots, but discouraged for production because it's undocumented and unreproducible — there is no Dockerfile recording how that state was reached, so the build can't be version-controlled, reviewed, or rebuilt deterministically.

No. Docker tracks the lifecycle of PID 1 specifically. The moment PID 1 exits — regardless of any child or background processes it spawned — the container is considered Exited, and any remaining processes in that container's namespace are killed.

A Dockerfile does `RUN apt-get install -y build-essential` then later `RUN rm -rf /var/lib/apt/lists/*` in a separate RUN instruction, but the image size doesn't shrink. Explain why, and the fix. Expected reasoning: each RUN is its own layer; deleting a file in a later layer just adds a 'deletion marker' on top — the original layer with the large files is still part of the image and counted toward total size. Fix: combine the install and cleanup into a single RUN, or use a multi-stage build so build-essential never reaches the final image.

Every CI build re-runs `npm install` from scratch even when package.json is identical to the last commit. What would you check? Expected reasoning: confirm COPY package.json comes before COPY . . in the Dockerfile; check whether the CI uses --no-cache or a fresh build context each time (e.g., shallow clone changing file timestamps/hashes unexpectedly, or CI not persisting the Docker build cache between jobs — may need BuildKit's --cache-from/--cache-to or registry cache export).

COPY does a literal, predictable file/directory copy from the build context into the image. ADD does everything COPY does, plus two extra behaviors: it can download a file from a remote URL, and it automatically extracts recognized local archive formats (tar, gzip) into the destination. Best practice is to prefer COPY unless you specifically need one of ADD's extra behaviors.

ARG defines a variable available only during the image build process (docker build --build-arg) and is not present in the final running container by default. ENV defines a variable baked into the image and available to every process in every container started from it, both at build time (for subsequent instructions) and at runtime. You can promote an ARG into an ENV explicitly if you need its value available at container runtime.

No. EXPOSE is documentation/metadata recorded in the image — useful for tools and humans reading the Dockerfile, and used by docker run -P (publish all exposed ports to random host ports). Actually making a port reachable from outside the container requires -p hostPort:containerPort at docker run or a ports: entry in Docker Compose.

Shell form (CMD java -jar app.jar) runs the command via /bin/sh -c "...", making the shell PID 1 and your actual application a child process. Signals like SIGTERM sent by docker stop go to PID 1 (the shell), which often does not forward them to the child, so the app never gets a chance to shut down gracefully and Docker has to wait out the full grace period before SIGKILL. Exec form (CMD ["java","-jar","app.jar"]) runs the binary directly as PID 1, so it receives signals correctly.

ENTRYPOINT is treated as the executable; CMD's value (each array element) is appended as arguments to it. For example, ENTRYPOINT ["java","-jar","app.jar"] with CMD ["--server.port=9090"] results in the container running java -jar app.jar --server.port=9090. Running docker run image --server.port=8081 replaces only the CMD portion.

A multi-stage build uses multiple FROM instructions in one Dockerfile, each starting a new, independent build stage. Later stages can selectively COPY artifacts from earlier stages using COPY --from=<stage>. This lets you use a full SDK/build-toolchain image to compile your application, then discard that entire toolchain in the final stage, copying only the compiled artifact into a minimal runtime base image — dramatically shrinking final image size and attack surface.

Declare an ARG with a default, e.g., ARG JAR_FILE=target/*.jar, then reference it in COPY: COPY ${JAR_FILE} app.jar. At build time, override it with docker build --build-arg JAR_FILE=target/myapp-2.0.jar . — useful for CI pipelines that build multiple variants from one Dockerfile.

HEALTHCHECK defines a command Docker runs periodically inside the container (e.g., curl against an actuator/health endpoint). Based on the exit code, Docker marks the container's health status as starting, healthy, or unhealthy, visible via docker ps. Orchestrators and load balancers can use this status to avoid routing traffic to a container that is technically running but not actually ready to serve requests.

Each RUN instruction executes in its own subshell/layer; a cd inside one RUN does not persist to the next RUN instruction. WORKDIR, by contrast, is a Dockerfile-level setting that persists across all subsequent instructions (RUN, CMD, ENTRYPOINT, COPY, ADD) for the rest of that build stage, and it also creates the directory if it doesn't already exist.

A Spring Boot service has ENTRYPOINT java -jar app.jar (shell form). docker stop always hits the full grace period. Diagnose and fix. Expected reasoning: shell form makes /bin/sh PID 1; SIGTERM is sent to the shell, not forwarded to the java child process, so java never receives the signal and the timeout always expires before SIGKILL. Fix: switch to exec form, ENTRYPOINT ["java","-jar","app.jar"], so java itself is PID 1 and Spring Boot's shutdown hooks run on SIGTERM.

A single-stage Dockerfile does FROM maven:3.9-eclipse-temurin-21, builds the jar, then RUN rm -rf ~/.m2 to 'clean up'. The image is still 700MB+. Explain why and the correct fix. Expected reasoning: deleting files in a later RUN only adds a deletion marker layer — the earlier layer containing Maven, the JDK, and the dependency cache is still part of the image's layer history and still counted in size. The correct fix is a multi-stage build: build in the maven image, then COPY --from=builder only the resulting jar into a clean eclipse-temurin:21-jre-alpine final stage.

Volumes decouple the container from any specific host directory structure, making deployments portable across different hosts and environments. Docker also provides volume management tooling (create, inspect, prune, drivers for network storage) that bind mounts don't participate in. Bind mounts hard-code an exact host path, which becomes a liability when moving between dev, staging, and various production hosts.

tmpfs is an in-memory filesystem mount — data written there lives only in host RAM and is never persisted to disk, and disappears the moment the container stops. It's used for data that must never touch disk for security reasons (decrypted secrets, signing keys) or for write-heavy scratch space where durability is irrelevant and disk I/O would be a bottleneck.

Nothing — the volume is an independent Docker object with its own lifecycle, separate from any container. docker rm removes the container and its writable layer; the named volume and its data persist until explicitly removed with docker volume rm (and only if no other container references it).

An anonymous volume is created when you specify a container-side mount path with no source name (e.g., -v /data or a Dockerfile VOLUME instruction with no docker run mapping). Docker auto-generates a random name for it. Because it has no memorable name, these accumulate invisibly across container recreations and are easy to forget about, leading to silent disk usage growth until someone runs docker volume prune.

Run a temporary container that mounts the volume read-only alongside a host bind mount, then use a tool like tar to archive the volume's contents to the host (or directly to a backup target like S3). For databases specifically, prefer an application-level backup (pg_dump, mysqldump) over raw filesystem copies, since that produces a consistent, restorable backup rather than a potentially-corrupt snapshot of files mid-write.

Yes — multiple containers can mount the same named volume at the same time, which is a common pattern for sidecars (e.g., an app container writing logs to a volume that a log-shipping sidecar also mounts and reads). Applications must still handle any necessary file-level coordination/locking themselves; Docker does not provide automatic write coordination.

Both ultimately use the Linux bind mount mechanism to make a host directory visible inside the container's mount namespace. The difference is entirely at the Docker management layer: for a named volume, Docker controls and owns the source directory (under its volumes directory, potentially via a plugin driver); for a bind mount, the source directory is whatever pre-existing host path you specify, with no Docker-side bookkeeping.

A team upgraded their postgres:15 container to postgres:16 by stopping the old container, removing it, and starting a new one — all data was lost. Diagnose. Expected reasoning: the original container was likely run with no persistent storage at all (writable layer only), so docker rm destroyed the writable layer along with all data. Fix going forward: always run stateful services with an explicitly named volume (--mount type=volume,src=pgdata,...) so container replacement is decoupled from data lifecycle; verify with docker volume ls before any docker rm.

A developer bind-mounts their source folder into a container for hot-reload, but changes made in their IDE aren't reflected. What would you check? Expected reasoning: confirm the bind mount path is correct and the container process is actually watching the mounted path (not a copy made during image build that shadows the mount); on Docker Desktop for Mac/Windows, check whether file-change notifications are being properly forwarded across the VM boundary — some dev servers need polling mode enabled in this case.

The default bridge network (docker0) predates Docker's embedded DNS feature and does not run the embedded DNS server. Only user-defined bridge networks include automatic DNS resolution of container names and Compose service names. This is why best practice is to always create an explicit network rather than relying on the default one.

Publishing a port (-p hostPort:containerPort) causes Docker to install an iptables DNAT (destination NAT) rule on the host. Traffic arriving at the host's published port is rewritten to target the container's internal IP and port on its bridge network, then delivered across the virtual ethernet (veth) pair into the container's network namespace.

EXPOSE only documents which port the application listens on inside the image/container — it creates no actual network rule and has no effect on reachability. -p (or --publish) is what actually creates the iptables NAT rule making a container port reachable from outside, whether or not EXPOSE was declared.

An overlay network uses VXLAN encapsulation to create a virtual Layer 2 network spanning multiple physical or virtual hosts, so containers on different machines can communicate as if they were on the same LAN. This underlies Docker Swarm's multi-host service discovery and load balancing, and is conceptually the same problem that Kubernetes CNI plugins (Calico, Flannel, Cilium) solve for pod-to-pod networking across nodes.

The container shares the host's network namespace entirely — it sees the host's network interfaces directly, and any port the application binds to is immediately exposed on the host with no NAT, no isolation, and no port remapping. This maximizes network performance but removes Docker's networking isolation, and a port conflict on the host directly conflicts with the container.

Create a dedicated internal network (e.g., backend-net) and attach only the database and the services that legitimately need to talk to it. Public-facing services that should not have direct database access are simply never attached to that network, making the database unreachable from them at the network layer, independent of any application-level access controls.

Yes. A common pattern is an API gateway or BFF service attached to both a public-facing network and an internal backend network, acting as the only bridge between the two trust zones. `docker network connect <network> <container>` attaches an already-running container to an additional network without restarting it.

Two containers are started with plain `docker run` (no --network flag) and one tries to call the other by container name; it fails with a DNS resolution error. Diagnose. Expected reasoning: both containers landed on the default bridge network, which has no embedded DNS for container-name resolution. Fix: create a user-defined bridge network and run both containers attached to it (`--network app-net`), after which name-based resolution works automatically.

`docker run -p 8080:80 myapp` works via curl localhost:8080 on the host but a separate machine on the same LAN can't connect to host-ip:8080. Diagnose. Expected reasoning: check the port binding (was it bound to 127.0.0.1:8080:80 instead of 0.0.0.0:8080:80, restricting it to loopback only); check the host firewall/security group rules for port 8080; confirm the host's network interface is actually reachable from the other machine independent of Docker.

Not by default — depends_on only guarantees container start order, not application readiness. To wait for actual readiness, the dependency needs a healthcheck: block, and the dependent service must declare depends_on with condition: service_healthy, which makes Compose wait until that healthcheck reports healthy before starting the dependent service.

Compose automatically creates a dedicated user-defined bridge network for the project and attaches every service to it. Because user-defined bridge networks include embedded DNS, each service can resolve every other service by its service name (e.g., a JDBC URL of jdbc:postgresql://db:5432/appdb), with no manual network setup required.

docker compose up --scale app=3 -d runs three containers from the app service definition. The constraint is that you cannot use a fixed host port mapping (ports: "8080:8080") for a scaled service, since multiple containers can't bind the same host port; instead, use expose (internal-only) and put a load balancer (e.g., nginx) in front to distribute traffic across the replicas.

docker compose down stops and removes the containers and the project's network, but leaves named volumes (and their data) intact. Adding -v additionally removes the named volumes, which is destructive for any stateful service — useful for a genuinely clean slate, but it will permanently delete database data if used carelessly.

Common approaches: use a base compose.yaml plus a docker-compose.override.yml that Compose merges automatically, or explicitly chain multiple files with -f base.yml -f staging.yml. Environment-specific values (URLs, credentials, replica counts) are typically injected via .env files or shell-exported variables referenced as ${VAR} in the YAML.

It can run real production workloads on a single host, especially for small/simple deployments, with restart policies and healthchecks providing basic resilience. However, it has no native support for multi-host scheduling, rolling updates across nodes, or automatic failover if the host itself dies — for those needs, Kubernetes (or Docker Swarm, less commonly used today) is the appropriate next step.

compose.yaml has app depends_on: [db], but the app's first DB connection attempt fails because Postgres is still initializing. Fix this properly. Expected reasoning: depends_on alone only sequences container start, not readiness; add a healthcheck to the db service (e.g., pg_isready) and change app's dependency to depends_on: db: condition: service_healthy so Compose waits for Postgres to report healthy before starting the app. As a defense in depth, the app itself should also have connection retry logic, since this guarantee is Compose-specific and won't hold in environments without Compose's

A team runs docker compose up --scale app=3 -d on a service with ports: "8080:8080" and gets an error that the port is already allocated. Explain and fix. Expected reasoning: a fixed host port mapping can only be bound by one container; with 3 replicas, only the first succeeds. Fix: remove the explicit port mapping (or use expose: "8080" for internal-only visibility) and place a reverse proxy/load balancer container in front, publishing only the load balancer's port to the host, letting it distribute requests across the three app replicas via the project's internal DNS/network.

Secrets should be delivered as runtime-mounted files (Docker secrets, Kubernetes Secrets volumes) or fetched from an external vault at startup, not passed via plain environment variables or baked into the image. Environment variables are visible via docker inspect, are readable from /proc/<pid>/environ by anything with sufficient host access, and frequently leak into logs, crash dumps, and CI output — file-based or vault-based delivery avoids all of these exposure paths.

Image scanning tools (Trivy, Grype, Docker Scout, Snyk) enumerate every installed OS package and language-level dependency in an image's layers, building an effective Software Bill of Materials, then cross-reference that list against vulnerability databases (NVD, OSV, vendor advisories) to flag known CVEs by severity. It does not detect zero-day or custom application-logic vulnerabilities — only known, cataloged issues in the packages you've included.

A distroless image contains only the application and the minimal runtime libraries it needs to execute — no shell, no package manager, no general-purpose OS utilities. This both shrinks the image significantly and removes most of the tools an attacker would use post-compromise (no shell to get a foothold, no package manager to pull in additional tools), at the cost of making interactive debugging inside the container harder.

Setting USER in a Dockerfile makes the containerized process run as a non-root UID inside the container's own view, which is good practice but doesn't change how the Docker daemon itself runs on the host. Rootless Docker runs the entire Docker daemon as an unprivileged user, so there is no root daemon process on the host at all — a more thorough mitigation, since it removes daemon-level root risk, not just in-container process risk.

Add a scanning step immediately after the docker build step (before push to registry), running a tool like Trivy with a severity threshold and a non-zero exit code on matching findings (--severity CRITICAL,HIGH --exit-code 1), which fails the pipeline automatically. This should run on every commit/PR, not as a manual or periodic check, so vulnerabilities are caught before merge, not after deployment.

Drop all default Linux capabilities with --cap-drop=ALL, then add back only the specific capabilities the application genuinely requires (e.g., NET_BIND_SERVICE if it needs to bind a privileged port below 1024). Combine this with --security-opt=no-new-privileges to prevent setuid binaries from escalating privileges inside the container, even if such a binary exists in the image.

The app's compose.yaml passes DB_PASSWORD via `environment:`. Propose a remediation plan. Expected reasoning: migrate to file-based secret delivery — Docker secrets (Swarm) or, more realistically for most teams, an external secrets manager (Vault/AWS Secrets Manager) that the application fetches from at startup, or Kubernetes Secrets mounted as files if already on K8s. Update the application to read from a file path (or fetch at boot) rather than expecting an env var, then remove the plaintext password from compose.yaml and any committed .env files; rotate the exposed credential as part of rem

The Dockerfile and source code are unchanged, but a scheduled re-scan in CI now fails. Explain why and the correct response. Expected reasoning: the image's pinned base image and dependencies haven't changed, but the vulnerability database has — new CVEs are continuously discovered and published against existing software versions. The correct response is not to disable scanning, but to evaluate each finding (patch availability, exploitability, exposure), upgrade the affected base image/dependency where a fix exists, and document any accepted-risk exceptions with an expiry date for re-review.

Without rotation, the json-file driver appends to a single ever-growing log file per container, which can exhaust host disk space over time for long-running, chatty services. You configure max-size and max-file either globally in /etc/docker/daemon.json or per-container via --log-opt, capping both individual file size and the number of rotated files retained.

Prometheus pulls metrics by scraping each target's /metrics (or equivalent) HTTP endpoint on a configured interval, meaning the target just needs to expose current metric values; Prometheus controls timing and can detect a target going fully unreachable (a scrape failure is itself informative). Push-based systems (like StatsD) have applications actively send metrics to a collector, which can be simpler for ephemeral/batch jobs but doesn't give the same built-in 'is this target even alive' signal.

By adding the micrometer-registry-prometheus dependency and enabling the prometheus actuator endpoint (management.endpoints.web.exposure.include=prometheus), Spring Boot exposes JVM, HTTP request, and any custom Micrometer metrics in Prometheus's text exposition format at /actuator/prometheus, ready for a Prometheus scrape_config target.

Grafana is a visualization and alerting layer, not a metrics store itself. It connects to Prometheus (or other data sources) as a backend, executes PromQL queries to populate dashboard panels, and can evaluate threshold-based alerting rules that trigger notifications to channels like Slack or PagerDuty.

cAdvisor reads container resource usage statistics directly from the kernel's cgroup accounting (CPU, memory, network, disk I/O per container) and exposes them in Prometheus format. This gives infrastructure-level visibility — how much of its allocated resources a container is actually consuming — independent of and complementary to application-level metrics like request latency or error rate.

docker stats gives a live, point-in-time snapshot of CPU/memory/network/IO usage in the terminal, useful for quick ad hoc debugging, but it has no history, no alerting, no dashboards, and stops the moment you close the terminal. Production monitoring requires persistent storage of metrics over time (Prometheus's TSDB) plus visualization and alerting (Grafana) to detect trends and notify on anomalies.

Investigation shows /var/lib/docker/containers contains several multi-gigabyte -json.log files for a chatty service that's been running for months. Explain the root cause and the fix, including whether existing data needs cleanup. Expected reasoning: root cause is the default json-file driver with no rotation configured, so logs accumulated unbounded. Immediate fix: truncate or rotate the existing oversized log files (carefully, ideally restarting the container after setting rotation rather than truncating a file Docker has open); long-term fix: set max-size/max-file globally in daemon.json (o

Grafana dashboards show a clear upward memory trend with no plateau, ending in a container restart. What does this suggest, and how would you confirm it? Expected reasoning: this pattern is classic for a memory leak (unbounded cache growth, unclosed resources, accumulating objects) rather than a sudden traffic spike, which would show a sharper, traffic-correlated rise. Confirm by correlating the memory metric against request volume (flat/uncorrelated rise points to a leak, not load) and by taking heap dumps or profiling the JVM at different points in the climb to identify what's actually accum

Running directly on a developer machine, 'localhost' correctly refers to wherever Postgres happens to be running (often a local install or a port-forwarded container). Once the Spring Boot app itself is containerized, 'localhost' refers to the app's own container, not the database's — the connection string must use the database's service/container name (e.g., jdbc:postgresql://db:5432/appdb) so Docker's embedded DNS resolves it correctly.

A broker can be configured to advertise localhost:9092 as its address to clients. Within the broker's own container, that's technically true, but any other container trying to use that advertised address to connect will be pointed back at itself, not the broker — connections fail after an initially successful metadata request. The fix is setting KAFKA_ADVERTISED_LISTENERS to the broker's actual reachable network alias (its Compose/Kubernetes service name), not localhost.

Liveness should answer 'has this process fundamentally hung or deadlocked and needs to be restarted'; readiness should answer 'can this instance currently handle traffic' (e.g., is its database connection pool healthy right now). If you conflate them — using one health check for both — a temporary downstream dependency hiccup (database connection pool briefly exhausted) could trigger unnecessary container restarts (liveness failure) instead of just temporarily routing traffic away (readiness failure), worsening an incident instead of containing it.

Define one service per microservice plus their infrastructure dependencies (Postgres, Redis, Kafka) in a single compose.yaml, using service names for all inter-service and service-to-infrastructure connection strings, healthchecks on stateful dependencies with condition: service_healthy gating on dependents, and a gateway/reverse-proxy service as the single published entry point — mirroring the trust-boundary and service-discovery patterns the production cluster will actually use, even if production runs on Kubernetes rather than Compose.

By default, Redis is an in-memory store; without persistence configured, all data is lost on restart since nothing was ever written to disk. To survive restarts, you'd enable RDB snapshotting or AOF (append-only file) persistence and mount a named volume at Redis's data directory, so the persisted file survives container recreation — though for pure caching use cases, this loss-on-restart behavior is often acceptable and even desirable.

Testcontainers is a Java library that programmatically starts real Docker containers (Postgres, Kafka, Redis, etc.) for the duration of an integration test run, then tears them down automatically. It builds directly on Docker Engine's API — the same container lifecycle, networking, and volume concepts from this book — letting integration tests run against real dependency versions instead of mocks or embedded fakes, at the cost of requiring a Docker daemon available in the CI environment.

The Spring Boot app connects fine to Postgres when run from IntelliJ against a container started separately, but crash-loops with connection refused when the whole stack is started together via docker compose up. Diagnose. Expected reasoning: when run from the IDE, the developer likely has the connection string pointed at localhost:5432 (a port-mapped container), which is valid in that specific context. Inside Compose, the app container itself needs to resolve the database by service name (db), not localhost, since the app and database are now both containers on the same project network with n

Logs show the producer service successfully connects to Kafka and reports messages sent; the consumer service's logs show it joined the consumer group, but no messages ever arrive. Diagnose. Expected reasoning: this is the classic advertised-listener mismatch — check KAFKA_ADVERTISED_LISTENERS on the broker; if it's set to localhost or an unreachable address, clients can complete the initial bootstrap/metadata handshake (talking to the configured bootstrap-servers address) but then fail silently or with connection timeouts when redirected to the (wrong) advertised address for actual produce/co

'latest' is a floating, mutable pointer — it doesn't tell you which specific commit or build produced the image currently running in any environment, making rollbacks, audits, and incident investigation far harder. Production pipelines should tag images by an immutable identifier like the git commit SHA or a monotonically increasing build number, so every deployed artifact traces back unambiguously to its source.

Both build OCI-compliant images without requiring a running Docker daemon at all (daemonless), and without needing privileged container mode — Kaniko runs entirely inside a single container executing build steps directly against the filesystem, and Buildah similarly builds images using unprivileged user namespaces. This matters most on shared/multi-tenant CI infrastructure where granting Docker-in-Docker or socket access to every job would be an unacceptable security exposure.

Use multi-stage builds with deliberate instruction ordering (Chapter 3) so unchanged layers (dependencies) are cached; wire up CI-platform-native layer caching (GitHub Actions' type=gha cache, or a registry-based cache with --cache-from/--cache-to) so cache persists across separate job runs, since each CI job otherwise starts from a clean environment with no prior build cache available.

Immediately after the build step (and before push to a registry or deployment trigger), run an image scanner like Trivy with a severity threshold (--severity CRITICAL,HIGH) and a non-zero exit code on matching findings, so the pipeline fails automatically rather than proceeding with a vulnerable image. This should be a blocking step, not an informational report, with a documented exception process for cases that genuinely can't be remediated immediately.

CI (Continuous Integration) covers building and validating the image — compiling, testing, scanning, and pushing a trustworthy artifact to a registry. CD (Continuous Deployment/Delivery) covers getting that validated image running in target environments — whether via direct deploy scripts, Kubernetes rollouts, or a GitOps controller reconciling a manifest repository. Docker's immutable, registry-distributed image format is what makes a clean handoff between these two phases possible.

The build stage rebuilds the full Docker image from scratch on every run with no apparent caching. Diagnose the likely causes and propose fixes. Expected reasoning: check whether the CI runner is ephemeral (fresh VM/container per job) with no persisted build cache, in which case every run genuinely starts cold; introduce platform-native caching (GitHub Actions cache, or a registry-based --cache-from/--cache-to with BuildKit) so layers persist across runs. Also check Dockerfile instruction ordering for unnecessary cache invalidation (Chapter 2/3) and confirm .dockerignore is excluding unrelated

The deployment process pulls and runs an image tagged myapp:latest. Propose a remediation that addresses both the immediate question and the systemic gap. Expected reasoning: immediately, check the registry's image history/digest for what 'latest' currently points to and cross-reference push timestamps against commit history to reconstruct the answer. Systemically, switch the pipeline to tag and deploy by immutable identifier (git SHA or build number), updating deployment manifests/scripts to reference that specific tag/digest rather than a floating tag, so this question always has an immediat

A Pod is one or more containers that share a network namespace (same IP, can reach each other via localhost) and can share storage volumes, scheduled together onto the same node as an atomic unit. Multi-container Pods support sidecar patterns (e.g., a main application container plus a log-shipping or service-mesh proxy sidecar) that need tight co-location and shared networking, which is why Kubernetes schedules at the Pod level rather than scheduling individual containers independently.

A Deployment manages a ReplicaSet, which maintains a desired number of identical Pod replicas, automatically recreating any that fail or are deleted. It also manages rolling updates: when you change the Pod template (e.g., a new image tag), the Deployment controller incrementally replaces old Pods with new ones based on configurable maxSurge/maxUnavailable limits and readiness probe results, with built-in rollback support if the rollout fails.

A Kubernetes Service is assigned a stable virtual IP and DNS name (via CoreDNS) that load-balances across the current set of healthy Pods backing it, regardless of how often individual Pod IPs change as Pods are recreated. This is the direct cluster-scale analog of Compose's embedded DNS resolving service names to container IPs (Chapter 5/6) — the underlying problem (stable names over unstable individual instances) and the DNS-based solution are conceptually identical.

Liveness should detect a fundamentally hung/deadlocked process that needs a hard restart; readiness should detect whether the Pod can currently serve traffic, which can be temporarily false (e.g., a downstream dependency is briefly unavailable) without the process itself being broken. Using the same check for both means a transient downstream issue — which should only cause Kubernetes to stop routing traffic to that Pod (readiness) — would instead trigger unnecessary Pod restarts (liveness), which doesn't fix the underlying dependency issue and adds restart churn on top of it.

The Deployment controller incrementally creates new Pods with the updated spec (bounded by maxSurge, how many extra Pods can exist temporarily) and, once each new Pod passes its readiness probe, terminates a corresponding old Pod (bounded by maxUnavailable, how many can be down at once). This continues until all old Pods are replaced; if new Pods fail readiness checks, the rollout can be configured to halt or the operator can issue a rollback to the previous ReplicaSet.

Docker Engine (and the docker CLI) is how you build, test, and run individual containers/images, typically on a single machine during development. Kubernetes takes those same OCI images and orchestrates them across a cluster of machines — scheduling, scaling, networking, self-healing — solving problems (multi-host placement, automatic recovery, rolling updates with traffic shifting) that Docker Engine alone, or even Docker Compose, does not address.

Evaluate this claim and explain the actual situation to the team. Expected reasoning: this is a misunderstanding of the dockershim removal. The team's existing OCI-compliant images, built with docker build, will run unmodified on any current Kubernetes cluster, since the cluster's container runtime (containerd) directly understands the OCI image format — no rebuild or reformatting is needed. What would actually require attention is any tooling that assumed direct access to a Docker daemon on the node itself (e.g., some older CI/monitoring integrations), not the images themselves.

The Deployment uses default rolling update settings and a readinessProbe pointed at /actuator/health/readiness. Diagnose likely causes. Expected reasoning: check initialDelaySeconds on the readiness probe — if it's shorter than the application's actual startup/warm-up time, Kubernetes may start routing traffic to a Pod that reports ready prematurely (or worse, the probe path itself isn't accurately reflecting true readiness, e.g., a connection pool not yet warmed). Also verify maxUnavailable isn't set high enough to remove too many old Pods before enough new ones are confirmed ready, and confi

Alpine uses musl libc instead of glibc, and while musl is much smaller, it has subtle behavioral differences from glibc — particularly around certain DNS resolution behaviors and some native library interactions — that have caused real, hard-to-diagnose production bugs for specific applications, especially compiled languages or anything with native dependencies. The safe approach is to test thoroughly on the actual Alpine-based image rather than assume compatibility, and prefer vendor-published Alpine variants (like eclipse-temurin's Alpine tags) that have been explicitly tested against musl.

Regular layer caching reuses an entire previous layer if its instruction and inputs are unchanged. A BuildKit cache mount (--mount=type=cache,target=/root/.m2) instead persists a specific directory's contents (like a package manager's download cache) across builds without that directory ever becoming part of any image layer — useful because dependency download caches can be reused even when the layer that would have contained them does need to rebuild (e.g., because the source code COPY changed in the same RUN step).

Alpine generally produces the smallest raw image size and retains a shell and package manager (busybox-provided), which is convenient for interactive debugging but means more available tooling if an attacker gains code execution. Distroless removes the shell and package manager entirely, slightly increasing size relative to a minimal Alpine image in some cases but meaningfully reducing the post-compromise attack surface, at the cost of needing a separate debug-variant image (most distroless families publish a debug tag) for any interactive troubleshooting.

Multi-stage builds control what ends up in the final image, but within any single stage, Docker's layer cache still operates instruction-by-instruction. Even a builder stage benefits from ordering — copying dependency manifests and running dependency installation before copying full source code — so that stage's cache is reused across builds that only change application code, independent of whatever happens in the final stage.

The same code worked reliably on the previous Debian-based image. Diagnose the likely cause and recommend next steps. Expected reasoning: this is a known category of issue with musl libc's DNS resolution behavior differing from glibc's in certain edge cases (e.g., specific resolver configurations or response handling). Recommend testing DNS resolution behavior explicitly against the Alpine image under the same network conditions as production, checking whether the JDK/runtime in use has a musl-tested variant (rather than a generic JDK manually layered onto generic alpine), and if the issue per

Builds are still slow even though final images are smaller. Diagnose other likely bottlenecks. Expected reasoning: multi-stage builds primarily affect final image size/content, not build cache efficiency directly — check whether instruction ordering within the builder stage is still cache-unfriendly (e.g., copying full source before installing dependencies), whether the CI runners are ephemeral with no persisted Docker layer cache between runs (requiring registry-based or platform-native cache import/export, Chapter 10), and whether BuildKit cache mounts are being used for package manager down

RTO (Recovery Time Objective) is the maximum acceptable time to restore service after a disaster; RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured in time. A near-zero RPO requirement forces synchronous replication (with its latency cost), while a more relaxed RPO allows cheaper asynchronous replication or periodic backups. A tight RTO forces investment in automated failover and warm/hot standby infrastructure, while a relaxed RTO can tolerate a slower, more manual recovery process. Both numbers should come from a business conversation about acceptable ris

A restart policy only handles the case where the process crashes and the same host is available to restart it — it does not protect against the host itself failing, network partition to that host, or the restart taking long enough (cold start, cache warm-up, dependency timeouts) to cause real user-facing downtime. True HA requires multiple replicas across independent failure domains (hosts, ideally availability zones) behind a load balancer that can route around a failed instance immediately, with no restart-induced gap in service.

Backups are a necessary but insufficient component of disaster recovery. DR additionally requires: backups stored independently of the primary infrastructure's failure domain, a documented and tested restore procedure, a defined and validated RTO/RPO that the actual restore process can meet, and ideally periodic drills proving the whole chain works end to end. A backup that has never been restored, or that lives in the same region as the data it protects, gives a false sense of security.

A rolling deployment replaces instances incrementally (e.g., one at a time), which uses less extra capacity but means a bad release is live for some users during the rollout and rollback means re-rolling the old version back incrementally. Blue-green deployment runs the new version fully alongside the old version and switches traffic atomically once the new version is verified healthy, making rollback nearly instantaneous (switch traffic back) at the cost of requiring double the infrastructure capacity during the transition. Teams often choose rolling for cost efficiency and blue-green when ro

Infrastructure metrics can be noisy (CPU spikes during a GC pause or a batch job that don't affect users) and can also miss real problems (a service can have low CPU usage while still returning errors due to a downstream dependency failure). SLO-based alerts (error rate, latency percentiles, availability) directly measure what users experience, which both reduces false-positive alert fatigue and ensures the team is paged for things that actually matter to the business, with infrastructure metrics retained as supporting diagnostic context rather than the primary trigger.

It means examining every layer for a component whose failure alone would cause an outage: multiple application replicas behind a load balancer (not one app instance), a load balancer that itself is redundant (most managed cloud load balancers already are, but self-hosted ones need an HA pair), a database with a replica and automated or fast manual failover (not a single unreplicated instance), and even DNS/networking paths and the deployment pipeline itself (a CI/CD system that's down shouldn't prevent emergency rollbacks). The exercise is recursive — fixing the obvious app-tier SPOF often rev

With centralized logging, an engineer can query across all replicas and all hosts for a given time window, request ID, or error pattern in one place, which is essential when a service has multiple replicas (the relevant log line could be on any of them) or when the affected container has already been restarted/removed (its `docker logs` history is gone with it). Relying on per-host `docker logs` requires knowing which host to SSH into, doesn't survive container removal, and doesn't scale past a handful of instances — it works for local development but is operationally unworkable in production.

A game day is a deliberate, planned exercise where the team intentionally injects a failure (kills a replica, simulates a database failover, blocks a dependency) in a controlled way and observes whether the system's HA mechanisms, alerts, and runbooks actually work as designed. Monitoring tells you what is currently happening; it doesn't tell you whether your failover logic, your runbook's steps, or your team's response process actually work, because those are rarely exercised by real incidents often enough to build confidence. Game days convert untested assumptions about resilience into verif

Active-active (serving live traffic from multiple regions simultaneously) generally offers the best RTO since failover is just rerouting traffic, but it requires solving multi-region data consistency, conflict resolution, and roughly doubles steady-state infrastructure cost. Active-passive (a warm or cold standby region that isn't serving live traffic) is simpler to reason about and cheaper to run day-to-day, accepting a slower failover (spinning up or promoting the standby) as the trade-off. Companies choose active-passive when their RTO requirements can tolerate that slower failover and the

Identify the gaps in this design relative to a true HA architecture and propose a concrete remediation plan. Expected reasoning: identify that a single container is a host-level single point of failure regardless of its restart policy (a host failure, kernel panic, or maintenance reboot causes real downtime with no failover target); recommend running at least 2-3 replicas across separate hosts/AZs behind a load balancer with active health checks; check whether the service is stateless (if it holds local session state, that must be externalized first, e.g., to Redis, before horizontal scaling i

Diagnose why this went undetected and propose changes to prevent recurrence. Expected reasoning: the core gap is that backup success was never itself monitored/alerted on — the job's failure was invisible because nothing checked whether it actually completed. Recommend: alerting specifically on backup-job failure (not just on the cron running, but on a verified successful backup artifact existing with the expected size/recency), periodic automated restore-verification drills that would have caught the silent breakage by attempting to actually use a recent backup, and treating the backup pipeli

Assess whether the current architecture meets the requirement and propose what would need to change. Expected reasoning: recognize that asynchronous replication with any non-zero lag cannot meet a true zero-RPO requirement, since a primary failure during that lag window loses the unreplicated writes; a genuine zero-RPO requirement forces synchronous replication (acknowledging a write only after it's durably committed to the replica too), which increases write latency and may require the standby to be geographically closer (trading off some disaster-radius protection for write performance) or a

A VM virtualizes hardware and runs a full guest OS with its own kernel via a hypervisor, giving strong isolation but heavier resource overhead and slower startup. A container virtualizes at the OS level, sharing the host kernel and using namespaces/cgroups for isolation, making it far lighter weight and faster to start, at the cost of slightly weaker isolation than a full VM boundary.

Namespaces provide isolation — each container gets its own view of PIDs, network interfaces, mount points, hostname, and IPC, so it can't see or interact with the host's or other containers' resources. Cgroups (control groups) provide resource limiting and accounting — capping how much CPU, memory, or I/O a container can consume. Namespaces answer 'what can I see', cgroups answer 'how much can I use'.

containerd is a daemon that manages the container lifecycle (pulling images, managing storage, supervising execution) and sits between the Docker daemon (dockerd) and the low-level runtime. runc is the actual OCI-compliant low-level runtime that creates and runs containers using namespaces/cgroups directly. dockerd delegates to containerd, which delegates to runc for each container.

The Open Container Initiative defines open standards for container image formats (image-spec) and runtime behavior (runtime-spec), which lets different tools (Docker, Podman, containerd, CRI-O) interoperate — an image built by one OCI-compliant tool can run on any other compliant runtime.

Typically over a Unix socket (/var/run/docker.sock) on Linux, using a REST API; it can also be configured over TCP for remote access (with TLS strongly recommended in that case).

The client sends a request to the daemon, which checks if the image exists locally (pulling it from a registry if not), creates a new container filesystem from the image's layers plus a new writable layer, sets up namespaces/cgroups, and starts the specified process as PID 1 inside the container.

A registry is any server implementing the Docker/OCI Registry API for storing and distributing images. Docker Hub is one specific, popular public registry; private registries (Harbor, AWS ECR, GitHub Container Registry, self-hosted) implement the same API and can be used interchangeably by simply changing the image reference's hostname.

Kubernetes standardized on the Container Runtime Interface (CRI) so any compliant runtime (containerd, CRI-O) could be used directly without a Docker-specific compatibility shim; dockershim added maintenance burden and was deprecated then removed, meaning Kubernetes no longer talks to the Docker daemon directly — it talks to containerd or another CRI runtime.

Yes — Docker-built images remain fully OCI-compliant and run unchanged on Kubernetes via containerd; what changed is only that Kubernetes's runtime layer no longer routes through the Docker daemon specifically, not that Docker images or the Docker development workflow became obsolete.

Docker Engine is the core daemon/CLI/API that actually runs containers (available natively on Linux). Docker Desktop is a packaged application for macOS/Windows that runs Docker Engine inside a lightweight VM and adds a GUI, Kubernetes integration, and other developer conveniences on top.

Each instruction in a Dockerfile that modifies the filesystem produces a new, immutable, content-addressed layer; layers are stacked and shared across images. This matters because identical layers are cached and reused across builds and across different images sharing a base, saving disk space, transfer time, and build time.

Copy-on-write means a container doesn't copy the entire image filesystem at startup; instead it adds one thin writable layer on top of the shared read-only image layers, and only copies a file up to that writable layer the moment it's modified. This is why container startup is fast and many containers can share one image's layers efficiently.

`docker commit` snapshots a running container's current state into a new image, but the result is undocumented and non-reproducible (no record of how it got that way). A Dockerfile is a declarative, version-controllable, reproducible recipe; production images should always come from Dockerfiles, with `commit` reserved for quick ad hoc debugging snapshots.

created (filesystem and config set up, not started) → running → paused (optional, process frozen) → stopped/exited (process ended) → removed. A container can also go directly from running to removed if `--rm` or explicit `docker rm` is used after stopping.

`docker stop` sends SIGTERM and waits a grace period (default 10s) for graceful shutdown before sending SIGKILL if the process hasn't exited. `docker kill` sends SIGKILL (or another specified signal) immediately, with no grace period.

Most commonly because its main process (PID 1) completed and exited — a container's lifecycle is tied directly to its main process, so if that process isn't a long-running server/daemon (e.g., it was a one-shot script), the container stops as soon as it finishes.

A digest (sha256:...) is a cryptographic hash of the image manifest, uniquely and immutably identifying exact content. A tag (like `latest` or `1.2.0`) is a mutable, human-friendly pointer that can be reassigned to point at different digests over time — pulling by digest guarantees you get exactly the same bytes every time.

`latest` is just a regular mutable tag with no special versioning guarantee — it can be overwritten at any time, meaning the same `myapp:latest` reference can resolve to different actual content on different days, breaking reproducibility and making rollbacks and audits much harder.

Without `-a`, only dangling images (untagged, unreferenced layers left over from rebuilds) are removed. With `-a`, all images not currently used by any container are removed, including tagged ones not actively in use — a more aggressive cleanup.

`docker history <image>` shows the layer list with the command that created each and its size; for deeper inspection, tools like `dive` can interactively browse layer contents and what each layer added, modified, or deleted.

CMD provides a default command (and/or default arguments) that is entirely overridden if the user supplies a command at `docker run`. ENTRYPOINT defines the fixed executable that always runs; when both are present, CMD's value becomes ENTRYPOINT's default arguments rather than being replaced outright.

Exec form (`["java","-jar","app.jar"]`) runs the process directly as PID 1, so it receives signals like SIGTERM correctly for graceful shutdown. Shell form (`java -jar app.jar`) wraps the command in `/bin/sh -c`, making the shell PID 1 and the actual process a child that may not receive signals properly, breaking graceful shutdown.

ARG defines a build-time-only variable, available during the build but not present in the final running container unless explicitly assigned to an ENV variable. ENV sets a variable that's baked into the image and available both at build time and to the running container.

Docker's build cache invalidates a layer (and every layer after it) once any earlier instruction's inputs change. Placing rarely-changing instructions (installing dependencies) before frequently-changing ones (copying source code) means most builds only need to re-execute the last few steps rather than the whole build.

They let you use one stage with full build tooling (compilers, SDKs, build caches) to produce artifacts, then copy only the needed output into a separate, minimal final stage — so the shipped production image doesn't carry build-time tooling, dramatically reducing size and attack surface.

COPY simply copies files/directories from the build context into the image. ADD does the same but additionally auto-extracts local tar archives and can fetch remote URLs. Best practice is to default to COPY and use ADD only when you specifically need its extraction or URL-fetch behavior.

It defines a command Docker runs periodically inside the container to determine if it's `healthy`, `unhealthy`, or still `starting`; this status is visible via `docker ps`/`docker inspect` and can be used by orchestrators to make scheduling and load-balancing decisions, independent of whether the main process is merely still running.

EXPOSE is purely documentation/metadata about which port the application listens on inside the container — it does not publish or map that port to the host. Actual host accessibility requires `-p`/`--publish` at `docker run` time (or a `ports:` mapping in Compose).

BuildKit is Docker's modern build engine, enabled by default since Docker 23, offering features like parallel stage execution, better cache management (including cache mounts and remote cache import/export), and improved build secret handling — all meaningfully faster and more capable than the legacy sequential builder.

Use BuildKit's `--mount=type=secret` in a RUN instruction, which makes the secret available only during that specific RUN step's execution and never writes it into any image layer — unlike an ARG or ENV value, which would persist in the image history/metadata.

It excludes specified files/directories from being sent to the Docker build context, which both speeds up the build (less data transferred to the daemon) and prevents accidentally copying sensitive files (like `.env` or `.git`) into an image via a broad COPY instruction.

Running as root inside a container means that if an attacker achieves code execution, they have root privileges within that container's namespace, increasing the impact of any container-breakout vulnerability. Switching to a dedicated non-root user limits the blast radius of a compromise.

A named volume is fully managed by Docker (created, named, and stored in Docker's own managed area), portable across environments and host-path-agnostic. A bind mount maps a specific, explicit host filesystem path into the container, tying the setup to that host's directory structure — common in local development.

When data must never persist to disk at all — for example, temporary secrets or sensitive scratch data — since tmpfs is backed entirely by host RAM and disappears the moment the container stops, with nothing ever written to a physical disk.

Docker still creates an anonymous, randomly-named volume to satisfy the mount point, but because it has no memorable name or reference, it's easy to accumulate orphaned anonymous volumes over time unless explicitly cleaned up with `docker volume prune`.

The default bridge network predates Docker's embedded DNS server feature and was never upgraded with that capability for backward-compatibility reasons; only user-defined bridge networks (created via `docker network create` or implicitly by Compose) get automatic name-based service discovery.

In host mode, the container shares the host's network namespace entirely — no isolation, no virtual interface, no port mapping needed since the container's ports are the host's ports directly. In bridge mode, the container gets its own virtual interface and IP on an isolated virtual network, requiring explicit port mapping for host accessibility.

Multi-host networking in clustered/orchestrated deployments (Docker Swarm, and conceptually similar to what Kubernetes CNI plugins provide) — it lets containers on different physical/virtual hosts communicate as if on the same network, using VXLAN encapsulation to tunnel traffic between hosts.

Through iptables DNAT (Destination NAT) rules on Linux, which rewrite incoming traffic on the published host port to be forwarded to the container's internal IP and port on the bridge network.

Without `-d`, Compose runs in the foreground, streaming all services' logs to the terminal and stopping them on Ctrl+C. With `-d` (detached), services start in the background and the terminal returns immediately, with `docker compose logs` used separately to view output.

By default, `depends_on` only waits for the dependency's container to start, not for the application inside it to finish initializing (e.g., a database accepting connections). Use `depends_on: condition: service_healthy` paired with a proper HEALTHCHECK to actually wait for readiness.

Multiple replicas would all try to bind the same single host port, which isn't possible — only one process can listen on a given host port. To scale, omit the fixed host port mapping and put a load balancer in front of the replicas instead.

Plain `down` stops and removes containers and the project's network but leaves named volumes intact by default, preserving data. Adding `-v` additionally removes named volumes, permanently deleting any data stored in them.

It automatically creates one project-scoped, user-defined bridge network (named after the project/directory) and attaches all defined services to it by default, giving them automatic DNS resolution by service name without any explicit network configuration needed.

Both ultimately set environment variables inside the container; `environment:` lists them inline in the compose file, while `env_file:` loads them from an external file. Neither is a secrets mechanism — both result in variables visible via `docker inspect` or inside the container's environment.

Stateless services can be freely replicated since any instance can serve any request. A stateful service has data that must be consistent and coordinated across replicas, requiring a purpose-built clustering/replication mechanism (e.g., Postgres streaming replication, a managed clustered database) — you can't just run more containers and expect correctness.

Running internally on user-defined networks, it resolves container/service names to their current internal IP addresses automatically, enabling service discovery without hardcoded IPs — essential since container IPs are not guaranteed stable across restarts.

Mount a named volume to the container's data directory (`/var/lib/postgresql/data`) via the service's `volumes:` key and declare that volume in the top-level `volumes:` section — recreating the container (e.g., on image update) then reuses the same underlying data.

Performance can degrade significantly on non-Linux hosts (macOS/Windows) due to the overhead of the virtualized filesystem layer translating bind-mount file events, and node_modules/vendor directories mounted this way can cause severe slowdowns unless excluded via a separate anonymous volume or .dockerignore-equivalent exclusion.

Common causes: they're actually on different networks (default bridge vs. a user-defined one, or different Compose projects), a firewall/security-group rule is blocking the traffic, the target's application isn't listening on the expected interface (e.g., bound to 127.0.0.1 instead of 0.0.0.0 inside the container), or the wrong port is being used.

If an attacker exploits a vulnerability in the containerized application, running as root gives them root privileges within the container's namespace, which significantly raises the severity of any subsequent container-escape vulnerability versus the more limited blast radius of a non-root compromise.

It remaps the container's root user (UID 0) to an unprivileged UID on the host, so even if a process achieves what looks like root inside the container, it actually has only unprivileged host permissions — adding defense in depth against container-breakout scenarios.

Environment variables are visible via `docker inspect`, process listings, and often end up logged or in crash dumps. Docker secrets (in Swarm) are mounted as in-memory files only accessible to authorized services, not exposed via inspect or typical process introspection, providing meaningfully better protection for credentials.

Distroless removes the shell, package manager, and most other OS utilities, leaving essentially just the application and its runtime dependencies — Alpine retains a shell (via BusyBox) and a package manager, which is convenient for debugging but expands the attack surface available to anyone who achieves code execution.

It automatically detects known CVEs in OS packages and application dependencies baked into an image before it's deployed, allowing a pipeline to block releases with critical vulnerabilities rather than discovering them only after the image is already running in production.

It follows the principle of least privilege at the Linux capability level — instead of granting a container the default broad capability set, you drop everything and re-add only the specific capabilities the application actually needs, minimizing what a compromised process could do.

Logs written to stdout/stderr are captured by the configured log driver but tied to that specific container instance; once the container is removed, its log history (and any logs not shipped elsewhere) is gone. Production systems must ship logs to a centralized, off-host store to retain them beyond a container's lifecycle.

They cap how large any single log file grows and how many rotated files are retained per container, preventing unbounded disk usage from a chatty or long-running container's logs from filling up the host.

Prometheus actively scrapes (pulls) metrics from configured target endpoints at intervals, rather than targets pushing metrics to a central collector. This simplifies target-side implementation (just expose an HTTP endpoint) and gives Prometheus direct control over scrape timing and the ability to detect a target being unreachable.

Grafana is purely a visualization and dashboarding layer — it queries Prometheus (or other data sources) and renders the data, but stores no metrics itself. Prometheus is the time-series database and alerting engine; Grafana is the window into it.

Container-level resource usage metrics (CPU, memory, network, disk I/O) derived directly from cgroups, independent of whether the application itself exposes any custom metrics — useful for infrastructure-level visibility even into containers that don't instrument themselves.

Because confusing them is a common real production mistake: incorrectly treating a 'not ready yet' (e.g., still warming up) state as a liveness failure causes unnecessary restart loops, while treating a genuinely stuck process as merely 'not ready' leaves a broken instance receiving no remediation.

It effectively grants that container root-equivalent control over the entire host's Docker daemon — it can create, inspect, or remove any container, including privileged ones, making socket-mounting a significant privilege escalation risk if the container is compromised or runs untrusted code.

Run an image vulnerability scanner (Trivy, Grype, or a registry's built-in scanning like ECR/Docker Scout) against the built image as a CI pipeline step, and configure the pipeline to fail the build if critical/high-severity CVEs are found above an agreed threshold.

It only shows a live, point-in-time snapshot on the host you're directly connected to, with no historical retention, no alerting, and no aggregation across multiple hosts/replicas — adequate for ad hoc debugging but not for systematic production observability, which requires a proper metrics pipeline like Prometheus.

`-Djarmode=layertools` splits a fat jar into separate layers (dependencies, resources, application classes) by how frequently each changes; copying these as separate Docker layers means a rebuild after only an application code change reuses the cached dependency layer instead of re-copying the entire fat jar every time.

Buildpacks is a framework for building OCI-compliant images from source without writing a Dockerfile by hand; the Spring Boot Maven/Gradle plugin's `build-image` goal uses Paketo buildpacks under the hood to automatically produce an optimized, layered image directly from your project.

The classic cause is `KAFKA_ADVERTISED_LISTENERS` (or its older alias) being misconfigured — Kafka tells clients which address to reconnect to after the initial connection, and if that advertised address is only resolvable/reachable from inside the Docker network (e.g., the container's internal hostname), external clients can connect initially but fail on the follow-up metadata-driven reconnect.

Spring Boot Actuator exposes separate health groups/endpoints for liveness (`/actuator/health/liveness` — is the JVM/process fundamentally OK) and readiness (`/actuator/health/readiness` — are dependencies like the DB connection pool actually available); mapping each to the correct orchestrator probe type avoids restart loops during normal warm-up or transient dependency hiccups.

It spins up real, ephemeral instances of dependencies (Postgres, Kafka, Redis) as Docker containers during test execution, giving integration tests real behavior instead of mocks/in-memory fakes, while still being fully automated and disposable per test run.

DinD runs an isolated nested Docker daemon inside the CI job's container, avoiding shared-daemon risk but requiring privileged mode (a security concern) and losing host-level build cache by default. Socket-mounting shares the host's daemon (faster, cache-friendly) but means any container in that CI job has effective root access to the host's entire Docker environment — a bigger blast radius if the job's own dependencies are compromised.

They build OCI images without requiring a privileged Docker daemon or socket access at all, which is significantly safer in shared/multi-tenant CI environments (like Kubernetes-based CI runners) where granting any job privileged or daemon-level access is a major security concern.

Every build produces a uniquely and permanently identifiable image tag tied to an exact commit, eliminating the ambiguity of mutable tags like `latest` — you can always trace a running image back to the exact source code that produced it, and rollback means simply redeploying a previous known-good SHA tag.

An informational-only scan can be ignored under deadline pressure, so vulnerabilities accumulate silently; making it blocking (failing the build/deploy on critical findings above a threshold) enforces that security debt can't be deferred indefinitely without an explicit, visible decision to do so.

The Container Runtime Interface (CRI), implemented by runtimes like containerd and CRI-O directly, removing the need for a Docker-specific compatibility shim and the Docker daemon dependency in the node's runtime path.

A Pod is the smallest deployable unit — one or more tightly-coupled containers sharing network/storage. A Deployment is a higher-level controller that manages a desired number of Pod replicas, handling rollouts, rollbacks, and self-healing (recreating Pods that disappear) — you rarely create bare Pods directly in production.

Because Docker-built images are OCI-compliant artifacts; Kubernetes (via containerd/CRI-O) only needs an OCI-compatible image and runtime, completely independent of whether the image was originally built using the `docker build` command — the image format itself is the interoperable standard.

Hardcoding service addresses (IP:port) instead of relying on DNS-based service discovery (container/service names), which breaks the moment a container is recreated with a different IP — the fix is always referencing dependent services by their Docker/Compose/Kubernetes service name and letting the platform's embedded DNS resolve it.

Build one immutable image and inject environment-specific configuration externally at runtime via environment variables or Spring profiles activated by an environment variable (`SPRING_PROFILES_ACTIVE`), rather than baking environment-specific config into separate images per environment — this preserves the 'build once, deploy anywhere' principle.

If the Dockerfile copies the whole fat jar as a single COPY instruction, any code change invalidates that entire layer regardless of multi-stage build usage — the fix is using Spring Boot's layered jar feature to split dependencies (rarely change) from application classes (change often) into separate COPY instructions, so only the small, frequently-changing layer needs to rebuild.

Cache-friendly instruction ordering (stable instructions before frequently-changing ones), multi-stage builds (excluding build tooling from the final image), and minimal base image choice (Alpine or distroless instead of a full general-purpose distro) — they compound rather than substitute for each other.

Alpine uses musl libc instead of glibc, and musl's subtle behavioral differences (particularly around DNS resolution and certain native library interactions) have caused real production bugs that don't appear in testing on glibc-based images — switching requires actual testing on the Alpine image, not just an assumption of compatibility.

It persists a specific directory's contents (like a package manager's download cache) across builds without ever making that directory part of an image layer, so dependency downloads can be skipped on rebuild even when the layer that would have contained them must otherwise rebuild due to an earlier change in the same RUN step.

It only handles the case where the process crashes on the same host and that host remains available to restart it; it does nothing to protect against the host itself failing, and it doesn't eliminate the downtime gap that occurs during the restart (cold start, dependency reconnection, cache warm-up).

At least two, ideally three or more, spread across separate hosts or availability zones, so a single host or zone failure doesn't take the service fully offline — a single replica, regardless of restart policy, is always a single point of failure.

RTO (Recovery Time Objective) is the maximum acceptable downtime before service is restored after an incident. RPO (Recovery Point Objective) is the maximum acceptable data loss, measured in time. RTO drives failover/restoration speed requirements; RPO drives replication/backup frequency requirements — they're independent dimensions that both need explicit targets.

A backup file existing proves nothing about whether it can actually be restored successfully — corruption, format incompatibility, missing dependencies, or process errors can all silently make a backup unusable, which is only discovered (if ever) the first time someone actually tries to restore from it, ideally during a planned drill rather than a real emergency.

Rolling deployment replaces instances incrementally, using less extra capacity but leaving a mix of old and new versions live during the rollout. Blue-green runs the new version fully in parallel and switches traffic atomically once verified, enabling near-instant rollback (switch traffic back) at the cost of needing double capacity temporarily.

Infrastructure metrics can be noisy without indicating real user impact (a CPU spike during a benign batch job) and can also miss real problems (errors caused by a downstream dependency with low CPU usage locally) — SLO metrics directly reflect what users experience, reducing both false alerts and missed real incidents.

A deliberate, planned failure injection (killing a replica, simulating a database failover) used to verify that HA mechanisms, alerting, and runbooks actually work as designed — monitoring shows current state but doesn't prove your failover logic or team response process works until it's actually been exercised.

Active-active offers better RTO (failover is just traffic rerouting) but requires solving multi-region data consistency and roughly doubles steady-state cost; active-passive is simpler and cheaper day-to-day, trading off a slower failover (promoting/spinning up the standby) — the right choice depends on the business's actual RTO tolerance versus budget.

A region-wide or account-wide incident (the exact scenario disaster recovery exists to protect against) can destroy both the primary data and its backups simultaneously if they share the same failure domain — backups should be stored in an independent location/account/region.

Without it, diagnosing an issue requires knowing which specific host/replica to check, and any log history is lost the moment a container is removed or restarted — centralized logging lets you query across all replicas and survive container churn, which is essential once a service runs more than a single instance.

An error budget quantifies how much unreliability is acceptable against an SLO target over a period; teams can use remaining error budget to decide deployment risk tolerance — when the budget is healthy, ship faster and take more risk; when it's nearly exhausted, slow down and prioritize stability work, tying reliability and feature velocity together rather than treating them as unrelated concerns.

Multi-stage builds control what ends up in the final image, but the build cache within any single stage still operates instruction-by-instruction; copying dependency manifests and installing dependencies before copying full source code in the builder stage still lets unrelated source-only changes reuse the cached dependency-install layer.

Vertical scaling increases the resources (CPU/memory limits) given to existing container instances, which has a hard ceiling (the host's physical capacity) and usually requires a restart to apply. Horizontal scaling adds more replica instances behind a load balancer, which scales further, improves fault tolerance (more independent failure points), but requires the service to be stateless or to externalize its state first.

Without a memory limit (cgroup constraint), a container with a memory leak or unexpectedly high load can consume all available host memory, starving other containers on the same host and potentially triggering the kernel's OOM killer to terminate arbitrary processes rather than just the offending one in a controlled way.

Docker's `--memory` flag sets a hard cgroup memory cap directly for a standalone container. Kubernetes resource `requests` inform the scheduler how much capacity to reserve when placing a Pod, while `limits` set the hard cap (like Docker's flag) — the orchestration layer adds a scheduling dimension on top of the same underlying cgroup mechanism.

A good postmortem identifies not just the proximate technical cause but the contributing factors that let it reach production undetected or unmitigated (missing alerting, an untested assumption, a process gap) and produces concrete follow-up actions — fixing only the immediate bug without addressing those factors leaves the system equally exposed to the next, different incident with a similar root contributing cause.

Treating the container ecosystem as actively evolving rather than fixed — periodically re-checking whether a previously-adopted pattern (a builder, a base image strategy, a CI integration approach) still reflects current best practice, since several of the 'old way' patterns covered as historical context in this book (the original docker-compose binary, dockershim, unscanned images as the default) were themselves once the unquestioned standard.

This almost always indicates an architecture mismatch — the image was built for a different CPU architecture than the production host (e.g., built on Apple Silicon/ARM and deployed to an x86_64 host, or vice versa). Diagnose with `docker inspect --format='{{.Architecture}}'` on the image, and fix by building multi-architecture images (`docker buildx build --platform linux/amd64,linux/arm64`) or explicitly targeting the correct platform at build time.

This pattern (steady climb independent of load) points to a memory leak rather than a load-driven capacity issue. Diagnose with heap dumps/profiling tools appropriate to the runtime (e.g., JVM heap analysis for a Spring Boot app) taken at intervals, check for unbounded caches or connection pools that never release resources, and as a stopgap, consider whether a scheduled rolling restart masks the symptom while the actual leak is root-caused — but don't stop at the workaround.

Check whether the HEALTHCHECK's test command actually verifies the same thing the dependent service needs (e.g., the healthcheck might just check 'is Postgres accepting TCP connections' while the actual issue is a specific schema/migration not yet applied); also verify the healthcheck's `start_period`/`interval`/`retries` give enough time for true readiness, and consider adding application-level retry-with-backoff logic for the connection itself as defense in depth rather than relying solely on orchestration-level sequencing.

This is the classic default-bridge-network trap: the default bridge network does not provide embedded DNS, only IP-level connectivity. Fix by creating and using a user-defined bridge network (or, in Compose, simply relying on its auto-created project network) — both provide automatic name-based service discovery that the default bridge lacks.

Common causes: the final stage's base image itself is large (a full distro instead of Alpine/slim/distroless), unnecessary files were still copied from the builder stage (overly broad `COPY --from=builder /app /app` instead of copying only the specific built artifact), or build caches/temp files were generated inside the final stage itself rather than only in the builder stage. Inspect with `docker history` and tools like `dive` to identify which layer/instruction added the unexpected size.

This points to local Docker disk usage exhaustion (cache, old images, dangling layers accumulated over time) rather than a Dockerfile problem — diagnose with `docker system df` to see space breakdown, and resolve with `docker system prune -a --volumes` (after confirming nothing important would be lost), or by increasing the Docker Desktop VM's allocated disk size on macOS/Windows.

Likely cause: the application isn't handling SIGTERM gracefully — Kubernetes sends SIGTERM, the Pod is removed from Service endpoints, but in-flight requests already routed to the terminating Pod get dropped because the app exits immediately instead of finishing in-flight work first. Fix by implementing graceful shutdown (drain in-flight requests, delay actual exit) and ensuring `terminationGracePeriodSeconds` is long enough, combined with a `preStop` hook if needed to allow load balancer deregistration to propagate before the process actually exits.

Diagnose by checking accumulated container log file sizes on the host (`docker inspect` shows the log path; `du` on it directly) — the root cause is almost always missing log rotation configuration. Fix by setting `log-opts: max-size` and `max-file` on the daemon or per-container/Compose service, and ensure centralized logging is in place so on-host retention can be kept minimal.

Most likely cause: an instruction earlier in the Dockerfile was reordered or modified in a way that broke cache reuse for everything after it — for example, moving a `COPY . .` (full source) above the dependency-installation step, which now invalidates the dependency cache on every single source change. Diagnose by reviewing the diff of the Dockerfile specifically for instruction-order changes, and fix by restoring the least-to-most-frequently-changing ordering.

Check whether the compose.yaml is missing `environment:`/`env_file:` entries that were being passed manually via `-e` flags in the direct `docker run` command, or whether a `.env` file in the Compose project directory is silently overriding expected values — `docker compose config` is useful here to print the fully resolved configuration and spot the discrepancy directly.

The volume's host-side directory (or the data already inside a named volume) is likely owned by a UID that doesn't match the non-root user's UID inside the container. Fix by aligning UIDs explicitly (e.g., creating the container's user with a specific UID matching the host directory's ownership, or using an init container/entrypoint step that `chown`s the mount path to the correct UID before the main process starts).

Alpine uses musl libc and a minimal set of system libraries by default, so any dependency expecting glibc-specific shared libraries (common for some native extensions or pre-compiled binaries linked against glibc) will be missing them. Either install the specific needed libraries explicitly in the Alpine image, use a glibc-compatibility layer if available for that ecosystem, or revert to a slim glibc-based image if the dependency genuinely requires glibc.

Beyond the immediate fix (correct the scaling config), the deeper gap is that replica count itself wasn't monitored/alerted on — recommend adding an alert specifically for 'desired replica count' not matching 'actual ready replica count' over a sustained period, so a silent scaling failure is caught immediately rather than discovered only in a postmortem after an extended exposure window.

This indicates the health check isn't deep enough — a basic 'is the process alive' check passes while the actual dependency the service needs (an available DB connection) is exhausted. Fix by ensuring the health/readiness endpoint includes the database health indicator (Actuator does this automatically if the DB health indicator is enabled and not explicitly excluded) so pool exhaustion is correctly reflected as not-ready rather than falsely healthy.

If the HEALTHCHECK command itself is hanging or returning success incorrectly (e.g., checking a wrong/unrelated endpoint, or the check process itself getting stuck and timing out in a way that's misinterpreted), the orchestrator never sees a failure signal. Verify the HEALTHCHECK's test command actually exercises the specific failure mode in question, and check `timeout`/`retries` values are tuned so a truly hung check is correctly classified as unhealthy rather than perpetually 'still checking'.

This demonstrates exactly why periodic restore drills matter — a backup existing and a backup being restorable are different facts. The fix isn't just regenerating a compatible backup; it's establishing a recurring (e.g., quarterly) automated or semi-automated restore-drill process so a similar drift is caught proactively rather than only during an actual disaster, when it's too late to fix calmly.

Check whether the bind-mounted path is actually correct/existing on the second machine — a common cause is a relative path in a Compose file resolving differently depending on the working directory `docker compose` is invoked from, or environment-specific path differences (e.g., a Windows path format issue, or a symlinked directory that doesn't resolve the same way) silently mounting an empty or wrong directory rather than producing an explicit error.

Verify whether the Dockerfile uses exec-form CMD/ENTRYPOINT — if it's still in shell form, the shell (PID 1) may not be properly forwarding SIGTERM to the actual application process, so the app never receives the signal it was correctly designed to handle, and Docker eventually SIGKILLs after the grace period elapses regardless.

This usually indicates the service or its database wasn't actually built for multi-region writes — if both regions are accepting writes to a database that isn't properly multi-master/conflict-resolved, simultaneous writes to the same record in different regions can produce inconsistency. The fix requires either redesigning the data layer for proper multi-region consistency (conflict resolution strategy, or routing all writes to one primary region with read replicas elsewhere) rather than simply replicating the existing single-region architecture across regions.

If the secret was instead passed as a regular `ARG`/`ENV` (not actually via the BuildKit secret mount syntax) or if a RUN step explicitly echoed/logged it, it would persist in image layer history/metadata; verify the Dockerfile genuinely uses `RUN --mount=type=secret,id=token cat /run/secrets/token` syntax correctly scoped to a single RUN instruction, since a secret mount only protects the build if it's used as intended and the secret is never separately captured by another instruction.

This is typically a cold-start effect — connection pools, JIT warm-up (for JVM-based apps), or lazy-loaded caches/resources initializing on first real use rather than at startup. Diagnose by comparing cold vs. warm request timing directly, and mitigate with readiness probes that don't mark the service ready until a warm-up routine completes, or a startup-time warm-up request/script that pre-triggers the slow initialization before traffic is routed to the instance.

If `ports:` includes a fixed host port mapping, only the first replica can bind it successfully (the others fail to bind but might still report as running depending on configuration), so all traffic naturally lands on the one bound replica. Confirm by checking each replica's actual listening state, and fix by removing the fixed host port mapping and placing a load balancer or reverse proxy (e.g., nginx, Traefik) in front of the replicas to distribute traffic across all of them.

This usually indicates the scaling thresholds and stabilization window are too tight for the actual load variability — recommend widening the target CPU threshold's margin, increasing the HPA's stabilization window for scale-down decisions specifically (scale-up can be more aggressive, but rapid scale-down right after a brief lull causes flapping), and verifying the metric being scaled on (CPU) genuinely reflects the actual bottleneck rather than a noisy proxy for it.

This is a significant, likely unnecessary security exposure — `--privileged` grants nearly all host capabilities and device access, far beyond what almost any application legitimately needs. Investigate whether it was added to work around a specific narrower requirement (e.g., needing a particular capability or device access) that could instead be granted via a scoped `--cap-add` or specific `--device` flag, and remove the blanket privileged flag once the actual minimal requirement is identified and substituted.

This points to a failure in the logging pipeline itself rather than the application — check the log shipping agent/sidecar's own health and connectivity to the centralized store, disk space on the log-forwarding component, and whether a recent configuration or credential change (similar to the earlier backup-script scenario) silently broke shipping without an explicit alert on 'log pipeline health' itself.

Consider whether the health check's own timeout is too aggressive relative to the application's response time under genuine load — if the healthcheck request itself gets queued behind real traffic and occasionally exceeds its timeout, that's a load-induced false-negative rather than an actual health problem; verify by checking healthcheck response times specifically during load spikes, and consider giving the healthcheck endpoint a separate, lighter-weight code path or thread pool so it isn't starved by application traffic.

This usually indicates the application is caching the database connection/hostname resolution rather than re-resolving it, or the failover mechanism didn't update DNS/service discovery promptly enough for clients to pick up the change. Diagnose connection pool and DNS TTL/caching behavior in the application's database driver configuration, and ensure the failover process actively triggers reconnection (or that connection pools have a reasonably short max-lifetime forcing periodic reconnection) rather than assuming clients will detect the change passively.

Since the Dockerfile is unchanged, the most likely explanation is that the underlying base image tag was updated upstream (if not pinned to a digest) and now includes a newly disclosed CVE that didn't exist (or wasn't yet known) at the time of the previous scan — this highlights why pinning base images by digest gives reproducibility, while pinning by mutable tag means a 'passing' build today can fail tomorrow purely due to upstream changes, independent of anything the team did.

Even disciplined per-build container cleanup doesn't address accumulated images, build cache, and volumes left behind across many different builds over time — recommend a scheduled `docker system prune -a --volumes` (or equivalent CI-runner-level cleanup job) run periodically/between builds, separate from any in-build cleanup steps that only address that specific build's own resources.

This highlights the operational risk of coupling service availability to a specific, exact service/DNS name rather than a more stable abstraction — recommend introducing a stable virtual service name or a service mesh/registry layer that can be repointed independently of the underlying deployment's specific naming, and treating service renames as a coordinated, backward-compatible migration (e.g., temporarily supporting both old and new names) rather than an atomic cutover.

A strong answer covers: immutable image tagging by git SHA; layer-cache-friendly Dockerfiles with shared base images across services to maximize cross-service cache hits; a daemonless or carefully-scoped builder (Kaniko/Buildah, or socket-mounting with strict runner isolation) appropriate to the CI platform's multi-tenancy needs; a blocking vulnerability-scan gate with an agreed severity threshold; registry-based or platform-native build cache (since ephemeral runners lose local cache between runs); and a deployment stage using progressive rollout (canary or blue-green) with automated rollback

Cover: horizontal autoscaling (HPA or equivalent) tuned with appropriate scale-up aggressiveness and scale-down caution to avoid flapping; pre-warming capacity ahead of known sale start times rather than relying solely on reactive autoscaling (cold-start lag matters at 50x spikes); stateless service design so scaling is just adding replicas; a database/cache layer designed for the read-heavy spike pattern (read replicas, aggressive caching, possibly a queue to smooth write bursts for order processing); and explicit load-shedding/graceful-degradation behavior (e.g., disabling non-critical featu

Cover: active-active vs. active-passive trade-off discussion tied to the specific RTO/RPO targets; load balancing/traffic routing across regions (global load balancer or DNS-based failover); data layer strategy for cross-region consistency (this is usually the hardest part — discuss whether the data model can tolerate eventual consistency or requires a single-writer-region approach); independent per-region health monitoring with automated failover; and explicit acknowledgment that 99.99% (about 52 minutes of downtime/year) requires eliminating essentially every single point of failure, includi

Cover: signed and verified images (image signing/attestation) to ensure only verified artifacts are deployed; mandatory vulnerability scanning with no override path for critical CVEs; non-root, minimal/distroless runtime images; secrets management via a dedicated vault/secrets manager rather than environment variables; full audit trail from commit to deployed artifact (traceable via immutable SHA-based tagging); network policies restricting which services can communicate with which; and encrypted data at rest and in transit throughout, with these controls enforced as automated pipeline gates r

Cover: structured (JSON) logging with a consistent correlation/trace ID propagated across service calls for distributed tracing; centralized log aggregation (e.g., a Loki or ELK-style stack) with tiered retention (hot/warm/cold) to manage cost at this scale; Prometheus-style metrics with consistent labeling conventions across services so dashboards/alerts can be templated rather than built per-service; distributed tracing (e.g., OpenTelemetry) to follow a single request across many services; and SLO-based alerting per service feeding a unified on-call/escalation system, with dashboards organiz

Cover: StatefulSet usage for stable network identities and ordered, predictable pod management; PersistentVolumeClaims backed by a storage class appropriate to the performance/durability needs (e.g., provisioned IOPS for a database workload); a clustering/replication strategy native to the database itself (most databases shouldn't rely solely on Kubernetes-level mechanisms for data replication); pod anti-affinity rules ensuring replicas land on different physical nodes/zones; and a backup/restore strategy integrated with the storage layer (volume snapshots) in addition to logical (e.g., pg_dum

Cover: synchronous replication to a standby (accepting the latency cost) since asynchronous replication cannot meet near-zero RPO; an explicit, automated or rapid manual failover process with a clearly defined RTO; regular (not just initial) DR drills proving the failover actually works under realistic conditions; careful handling of in-flight transactions during failover (ensuring no double-processing or silent loss); and a clear escalation/communication plan for the business during an actual DR event, since technical recovery and business/customer communication need to happen in parallel, no

Cover: a clear network segmentation strategy (separate networks/namespaces for public-facing vs. internal-only services, with the gateway as the only ingress point to public services); rate limiting and authentication/authorization enforced at the gateway layer rather than duplicated per-service; TLS termination strategy (at the gateway vs. end-to-end); and how internal service-to-service calls bypass the gateway entirely (using internal service discovery/DNS) for lower latency, while still being subject to network policies restricting which services may call which.

Cover: right-sizing resource requests/limits based on actual observed utilization (Chapter 8/13 metrics) rather than initial guesses that were never revisited; identifying idle or over-provisioned replicas via utilization monitoring; using autoscaling to match capacity to actual demand curves instead of static peak-provisioned capacity; image size optimization (smaller images reduce registry storage and pull/transfer costs at scale); and evaluating spot/preemptible instances for appropriately fault-tolerant, stateless workloads — framed as a continuous practice (regular right-sizing reviews) r

Cover: backward-compatible schema migration patterns (additive changes first, deploy code that works with both old and new schema, then remove old schema elements in a later release) rather than a single atomic cutover; using a migration tool integrated into the deployment pipeline (e.g., Flyway/Liquibase for a Spring Boot service) run as a controlled step before the new application version is rolled out; feature-flagging risky migration-dependent behavior so it can be disabled instantly if an issue surfaces; and a clear rollback plan for both the application code and the schema change indepen

Cover: strict resource limits (CPU, memory, process count, execution time) per container to prevent resource-exhaustion attacks; running with `--cap-drop=ALL` and minimal added capabilities, non-root, and ideally a restrictive seccomp/AppArmor profile; network isolation (typically `--network none` or a tightly restricted network) since user code has no legitimate need for outbound network access in most such platforms; ephemeral, immediately-destroyed containers per execution (never reusing a container across different users' code); and considering a stronger isolation boundary than standard c

Cover: the core challenge that blue-green works cleanly for fully independent stateless services but becomes complex when blue and green versions of a service must share a single database schema simultaneously during the transition — address via backward/forward-compatible schema design (same principle as the migration question above) so both versions can safely operate against the same schema concurrently; database connection routing considerations; and acknowledging that pure blue-green may need to be scoped to the stateless application tier only, with the shared database treated as a separa

Cover: the isolation-model spectrum from shared containers with logical (application-level) tenant separation, to per-tenant namespaces/resource quotas in Kubernetes, to fully dedicated container/cluster-per-tenant for the highest-isolation tier customers — and the cost/complexity trade-off across that spectrum; resource limits/quotas to prevent one tenant's load spike from degrading others (the noisy-neighbor problem) regardless of which isolation model is chosen; and how this isolation choice typically maps to pricing tiers (e.g., dedicated infrastructure reserved for enterprise/premium tena

Cover: the staffing reality gap (24/7 coverage requirements vs. single-time-zone team) and how that's typically addressed — a rotating on-call schedule with explicit escalation tiers, automated alerting tied to SLO breaches (not infrastructure noise) to minimize unnecessary pages, a clear severity matrix defining what actually warrants waking someone up versus what can wait until business hours, and runbooks detailed enough that an on-call engineer outside their usual area of expertise can still execute a safe initial mitigation before deeper specialist involvement is needed.

Cover: per-service independent rollback capability (immutable, SHA-tagged images make 'redeploy the previous version' a known-good, fast operation) without requiring a coordinated multi-service rollback in the common case; automated rollback triggers tied to post-deploy health/SLO signals rather than relying solely on manual detection; careful handling of the cases where a rollback isn't safe in isolation (e.g., a schema migration already applied that the previous app version can't handle) by ensuring the backward-compatible migration pattern discussed earlier is the default practice; and feat