Docker & Kubernetes for Java Engineers — Interview Questions

How to use this lesson

Show that you understand what containers are (Linux primitives, not tiny VMs), and how Kubernetes objects map to operational concerns: rollout, discovery, configuration, health and scaling. Tie everything back to running a JVM service well in a container.

Q1. How does Docker work?

Short answer: A container is a normal Linux process isolated by kernel features:

• namespaces give each container its own view of PIDs, network, mounts, users, hostname and IPC;
• cgroups limit and account for its CPU, memory and I/O;
• plus capabilities, seccomp, AppArmor or SELinux, for security.

The image is a stack of read-only layers (a union filesystem, overlayfs), each produced by a Dockerfile instruction. A container adds a thin writable layer on top. The Docker Engine (dockerd → containerd → runc, following the OCI runtime specification) pulls images from registries, and creates and manages containers, networks and volumes. On macOS and Windows, Docker Desktop runs a Linux VM, and the containers run inside it.

Learn it in depth → Docker Fundamentals

Q2. How does a Docker container differ from a VM?

Short answer:

Hybrids (Firecracker microVMs, Kata Containers, gVisor) give container-like speed with stronger isolation. They're used for multi-tenant and serverless workloads.

Q3. How do you pass environment variables and secrets into Docker containers?

Short answer:

• Environment variables: docker run -e SPRING_PROFILES_ACTIVE=prod, --env-file prod.env, the Compose environment:/env_file:, and Kubernetes env/envFrom (ConfigMaps). Never bake environment-specific values into the image.
• Secrets:
  • don't use ENV in the Dockerfile, or build args: they're persisted in the image layers and history;
  • at runtime: Docker/Compose secrets (mounted at /run/secrets/… as files), Kubernetes Secrets mounted as files (preferred over environment variables), or injected from Vault or cloud secret managers (the CSI driver, External Secrets Operator, sidecars);
  • at build time: BuildKit --mount=type=secret (for private repository tokens during the build, never stored in the layers).
• Spring Boot reads mounted files with spring.config.import=configtree:/run/secrets/, or through environment variable binding.

Q4. What's the difference between COPY and ADD in a Dockerfile?

Short answer:

• COPY copies files and directories from the build context into the image. It's simple and predictable, so prefer it.
• ADD does the same, plus it auto-extracts local tar archives, and can fetch remote URLs. That's "magic" behaviour, which surprises readers, and remote fetches aren't cached well or verified (use curl/wget with checksums instead, or ADD --checksum= in newer BuildKit).

Use ADD only when you specifically need tar extraction. Use COPY --chown=app:app, and COPY --from=build in multi-stage builds.

Q5. What's the difference between ENTRYPOINT and CMD?

Short answer:

• ENTRYPOINT: the executable that always runs (the container's "command"), for example ["java", "-jar", "/app/app.jar"].
• CMD: default arguments for the entrypoint (or the default command if there's no entrypoint). It's easily overridden by docker run image <args>.
• Combined: ENTRYPOINT ["java","-jar","/app/app.jar"] plus CMD ["--spring.profiles.active=default"] means the arguments can be swapped at run time.
• Use the exec form (the JSON array), not the shell form. In the shell form, the process runs under /bin/sh -c, so SIGTERM doesn't reach the JVM, and graceful shutdown breaks. With shell scripts as the entrypoint, use exec java …, so the JVM becomes PID 1 (or use --init/tini for signal forwarding and zombie reaping).

Q6. How do Docker volumes work? Named vs anonymous volumes?

Short answer: Volumes store data outside the container's writable layer, so it survives container removal, and performs better than the overlay filesystem:

• Named volumes (-v pgdata:/var/lib/postgresql/data): managed by Docker, referenced by name, persist until explicitly removed, and are reusable across containers. Use them for databases in development and Compose.
• Anonymous volumes (-v /data, or a VOLUME in a Dockerfile): get a random name, are easy to lose track of, and are removed with docker rm -v.
• Bind mounts (-v ./src:/app/src): map host paths, for development hot-reload and configuration files. They depend on the host layout.
• tmpfs mounts: in memory, for sensitive or scratch data.

In Kubernetes, the equivalents are PersistentVolumes/PersistentVolumeClaims (with StorageClasses), emptyDir, and ConfigMap or Secret volumes.

Q7. What is docker-compose for? How do you connect several containers (application + database) in a network?

Short answer: Docker Compose defines multi-container applications in compose.yaml (services, networks, volumes, environment, health checks, depends_on with conditions), and runs them with docker compose up. It's used for local development environments, integration and e2e testing, demos, and small single-host deployments. (Spring Boot 3.1+ can start the Compose services automatically, with spring-boot-docker-compose.)

Networking:

• Compose creates a user-defined bridge network per project. Services reach each other by service name, through Docker's embedded DNS (for example jdbc:postgresql://db:5432/shop).
• Only publish ports (ports:) for the host-facing services.
• Custom networks isolate tiers.
• With depends_on: condition: service_healthy, the application waits for the database's health check.

services:
  db:
    image: postgres:16-alpine
    environment: { POSTGRES_DB: shop, POSTGRES_PASSWORD: example }
    volumes: [ "pgdata:/var/lib/postgresql/data" ]
    healthcheck: { test: ["CMD-SHELL", "pg_isready -U postgres"], interval: 5s, retries: 10 }
  app:
    build: .
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/shop
      SPRING_DATASOURCE_PASSWORD: example
    depends_on: { db: { condition: service_healthy } }
    ports: [ "8080:8080" ]
volumes: { pgdata: {} }

Learn it in depth → docker-compose for Local Development

Q8. How do you reduce Docker image size, for faster deployment?

Short answer:

• Multi-stage builds: build with the JDK and Maven in one stage, and copy only the artifact into the runtime stage.
• A minimal runtime base: a JRE (not a JDK), distroless, or slim Debian or UBI-minimal. Alpine is possible, with musl-based JDK builds.
• A custom runtime with jlink: only the JDK modules you use (jdeps --print-module-deps).
• Layered Spring Boot JARs: dependencies in a layer separate from the application code, so pushes and pulls transfer only the changed layers.
• Order the instructions from rarely changing to frequently changing (cache efficiency), and combine RUN steps, cleaning the package caches in the same layer.
• .dockerignore, to keep .git, target and IDE files out of the context.
• GraalVM native images, for the smallest images (tens of MB), where they're suitable.

Measure it: docker history, dive.

Learn it in depth → Multi-Stage Builds

Q9. How do you test or scan Docker images for vulnerabilities?

Short answer:

• Scanners: Trivy, Grype, Docker Scout, Snyk Container, and registry-native scanning (ECR, Artifact Registry, Harbor, Artifactory Xray). They check the OS packages and application dependencies (JARs) against CVE databases. They can also detect secrets and misconfigurations.
• Put them in CI: scan every build, and fail on critical or high CVEs with a fix available (with a documented exception or allow-list process). Also rescan deployed images continuously, because new CVEs appear after the build.
• Supply-chain hardening:
  • generate an SBOM (Syft or CycloneDX);
  • sign images (cosign or Sigstore), and verify the signatures at admission (Kyverno or Gatekeeper policies);
  • pin base images by digest;
  • rebuild regularly for base-image patches (Renovate or Dependabot).
• Config checks: Hadolint (Dockerfile lint), and Dockle/Checkov (non-root user, no secrets, health checks).
• Runtime: Falco, and admission policies (no root, read-only filesystem, no privileged containers).

Q10. What's the difference between a Kubernetes Pod, a Deployment and a Service?

Short answer:

• Pod: the smallest deployable unit: one or more co-located containers (the application, plus optional sidecars or init containers), sharing a network namespace (one IP) and volumes. Pods are ephemeral and replaceable, so you rarely create them directly.
• Deployment: declarative management of stateless Pods. It keeps the desired replica count (through ReplicaSets), and performs rolling updates and rollbacks of the Pod template. It's the default for Spring Boot services.
• Service: a stable virtual IP and DNS name (orders.shop.svc.cluster.local) that load-balances across the ready Pods selected by labels. Types:
  • ClusterIP (internal);
  • NodePort;
  • LoadBalancer (a cloud load balancer);
  • Headless (no VIP; DNS returns the pod IPs, for StatefulSets and client-side balancing).

Learn it in depth → Core Objects

Q11. How do ConfigMaps and Secrets work in Kubernetes?

Short answer:

• ConfigMap: non-confidential key-value or file configuration. It's consumed as environment variables (envFrom) or mounted files. Mounted files update automatically when the ConfigMap changes (after a delay); environment variables need a pod restart.
• Secret: the same mechanics, for sensitive data. But by default, Secrets are only base64-encoded, not encrypted. You must:
  • enable encryption at rest in etcd (a KMS provider);
  • restrict RBAC access;
  • avoid putting them in Git in plain text (use Sealed Secrets, SOPS, or the External Secrets Operator syncing from Vault or AWS Secrets Manager);
  • prefer mounting as files over environment variables (env vars leak through process listings, crash dumps and child processes).
• Spring Boot: spring.config.import=configtree:/etc/secrets/, environment variable binding, or Spring Cloud Kubernetes (reload on change).

Learn it in depth → Config & Secrets

Q12. What's the difference between readiness and liveness probes? (And startup probes?)

Short answer:

• Readiness probe: "can this pod serve traffic right now?" If it fails, the pod is removed from Service endpoints (it gets no traffic), but it isn't restarted. Use it for startup warm-up, temporary overload, and dependencies the pod truly can't work without, and during graceful shutdown.
• Liveness probe: "is this process stuck, or broken beyond recovery?" If it fails, Kubernetes restarts the container. Check internal health only (deadlocked event loops, broken state). Never check external dependencies (a database outage would restart every pod, and make things worse).
• Startup probe: holds off the liveness and readiness checks until a slow-starting application (JVM warm-up, migrations) has started, which avoids restart loops.
• Spring Boot: management.endpoint.health.probes.enabled=true exposes /actuator/health/liveness and /readiness, backed by ApplicationAvailability (readiness goes to REFUSING_TRAFFIC during shutdown).
• Tune them: initialDelaySeconds, periodSeconds, failureThreshold and timeoutSeconds. Keep the endpoints cheap.

Learn it in depth → Probes & Autoscaling

Q13. How do you autoscale pods on CPU or memory?

Short answer:

• The Horizontal Pod Autoscaler (HPA) adjusts the replicas to keep a target utilisation (for example CPU at 65% of requests). It needs resource requests to be set, and the metrics-server. It supports memory (awkward for the JVM, whose heap doesn't shrink quickly), custom metrics (request rate or latency through the Prometheus Adapter), and external metrics. KEDA handles event-driven scaling (Kafka lag, queue depth, cron), including scaling to zero.
• The Vertical Pod Autoscaler (VPA) recommends or sets the requests and limits (don't combine it with the HPA on the same metric).
• Cluster Autoscaler or Karpenter add nodes when pods are unschedulable.
• For JVM services:
  • scale on CPU or request rate, not heap usage;
  • set stabilisation windows, to avoid flapping;
  • account for warm-up (new pods are slow at first; use CDS or AOT caches, and readiness only after warm-up);
  • set minReplicas for availability, and pre-scale for known peaks.

Q14. How do Helm charts work, and why use them?

Short answer: Helm is Kubernetes' package manager. A chart is a set of templated manifests (Go templates) plus values.yaml defaults, and metadata (Chart.yaml, dependencies). helm install/upgrade renders the templates with the environment-specific values, and applies them as a versioned release, with helm rollback support and hooks (pre-upgrade jobs for migrations). Why use it:

• one parameterised definition for many environments and services (a shared library chart for all Spring Boot microservices: Deployment, Service, HPA, PDB, probes, ServiceMonitor);
• versioning;
• easy installation of third-party software (Kafka, Prometheus, ingress controllers).

The alternatives: Kustomize (patch-based overlays, with no templating), and CDK8s. Often both are combined with GitOps (Argo CD renders Helm charts).

Q15. What's the difference between a StatefulSet and a Deployment?

Short answer:

• Deployment: for stateless pods. They're interchangeable (random names), created and replaced in any order, and typically share a volume, or none.
• StatefulSet: for stateful workloads (databases, Kafka, ZooKeeper, Elasticsearch):
  • stable, unique identities (kafka-0, kafka-1) and stable DNS through a headless Service;
  • a PersistentVolumeClaim per pod (volumeClaimTemplates) that follows the pod identity across rescheduling;
  • ordered deployment, scaling and rolling updates (0, 1, 2…), with partitioned updates.

Running databases in Kubernetes is possible with operators (CloudNativePG, Strimzi for Kafka), but many teams use managed cloud databases, and keep Kubernetes for stateless services.

Q16. What is Kubernetes Ingress for?

Short answer: Ingress defines HTTP(S) routing from outside the cluster to Services: host and path rules, TLS termination (certificates through cert-manager), and features configured through annotations. An Ingress controller (NGINX, Traefik, HAProxy, a cloud load balancer controller like the AWS Load Balancer Controller) implements it, usually behind a cloud load balancer. It lets one external entry point serve many services, instead of a LoadBalancer Service each. The newer Gateway API (Gateway, HTTPRoute) is the more expressive, role-oriented successor, with traffic splitting, header matching, and cross-namespace delegation.

Learn it in depth → Services & Ingress

Q17. How do you manage secret rotation in Kubernetes?

Short answer:

• The source of truth is an external secret manager (Vault, AWS Secrets Manager, GCP Secret Manager), with automatic rotation (for example, rotated database credentials, or Vault dynamic secrets: short-lived credentials generated per lease).
• Sync into the cluster:
  • External Secrets Operator (a refresh interval, updating the Kubernetes Secrets);
  • or the Secrets Store CSI Driver (mounted files, with rotation polling);
  • or the Vault Agent injector, or Vault Secrets Operator.
• Application pickup:
  • mounted files update in place, and applications re-read them (Spring Cloud Vault or Spring Cloud Kubernetes reload, or HikariCP credential refresh on new connections);
  • environment variables require a restart: trigger a rolling restart on change (Reloader, or a hash annotation in the pod template);
  • dual-credential overlap: the old and new secrets are both valid during the rotation window, so connections don't break.
• Automate it, and audit it: RBAC on Secrets, encryption at rest, and alerts on rotation failures.

Follow-up questions this topic invites — and their answers

Q: Why do JVMs in containers get OOMKilled, and how do you prevent it? A: The container memory limit covers heap plus non-heap memory (metaspace, threads, code cache, direct buffers, GC). Set -XX:MaxRAMPercentage around 70–75, cap metaspace and direct memory, set memory requests equal to limits, and use Native Memory Tracking to size them.

Q: What is a PodDisruptionBudget? A: A policy limiting how many pods of an application can be voluntarily evicted at once (node drains, upgrades), for example minAvailable: 2, so maintenance doesn't take the service below capacity.

Q: How do you do graceful shutdown in Kubernetes for Spring Boot? A: server.shutdown=graceful plus spring.lifecycle.timeout-per-shutdown-phase, a preStop hook with a short sleep (so endpoints deregister before SIGTERM processing), and a terminationGracePeriodSeconds longer than the drain time.

Q: What are resource requests vs limits? A: Requests reserve capacity for scheduling, and define the QoS. Limits cap usage: exceeding a memory limit gets the container killed, and CPU limits throttle it. For JVM services, set memory requests equal to limits, and be cautious with tight CPU limits (throttling hurts latency and GC).