Docker & Kubernetes Interview Prep

Docker interview questions cover the container runtime every backend engineer is expected to know — image layers and caching, Dockerfile best practices, multi-stage builds, the difference between ENTRYPOINT and CMD, networking modes, volumes and bind mounts, image security (non-root, distroless), and the Spring Boot-specific patterns (layered jars, jib). For orchestration, see the Kubernetes page.

Docker = process isolation via Linux namespaces + cgroups.

• Image = layered FS + manifest.
• Container = running instance + writable top layer.
• Multi-stage builds — separate build deps from runtime image.
• Non-root by default; distroless as the modern best practice.
• `ENTRYPOINT` vs `CMD` — entrypoint = executable, cmd = default args.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker compose — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker networking — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Docker security — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Multi stage builds — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Layer order matters — least-frequently-changed first.
• `.dockerignore` — both build speed and image-size win.
• `HEALTHCHECK` — declared in Dockerfile, surfaced by orchestrator.
• Spring Boot layered jars / jib — JVM-aware tooling.
• Don't run `latest` — pin tags, prefer immutable digest references.

"I'd build a multi-stage Dockerfile, base on distroless, run as non-root, declare a `HEALTHCHECK`, leverage Spring Boot layered jars for cache hits, and pin the digest in production manifests."

Kubernetes interview questions are now standard for any senior Java backend role — pods, deployments, services, ingress, ConfigMaps and Secrets, HPA and resource requests/limits, StatefulSets and persistent volumes, rolling updates and rollback, network policies, RBAC, and the production-debugging questions interviewers ask ("a pod is in CrashLoopBackOff — walk me through your debug"). Pair this page with the Docker, CI/CD and Cloud-Native pages for the full container-platform interview surface.

K8s = control loops over a desired-state spec.

• Pod is the atom; Deployment owns replica sets.
• Service = stable virtual IP; Ingress = HTTP routing.
• ConfigMap / Secret for config; PVC for storage.
• Probes — liveness restarts the pod, readiness gates traffic.
• HPA / VPA — scale on CPU / memory / custom metrics.

The interview surface for this module breaks into these focus areas:

• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Helm — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes configuration — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes networking — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes scaling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Kubernetes workloads — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• CrashLoopBackOff debug — kubectl describe for events, logs --previous for the prior crash.
• Resource requests + limits — requests reserve, limits cap; OOMKilled if you hit memory limit.
• StatefulSet vs Deployment — stable identity + ordered start; for databases, kafka.
• Network policies — deny by default, allow per-namespace.
• Helm vs Kustomize — templates vs overlays; both fine, pick one.

"I'd deploy stateless apps as a Deployment with readiness + liveness probes, set realistic requests/limits, expose via Service + Ingress, manage config in ConfigMap / Secrets, and scale with HPA on a metric that tracks user-perceived load."