Docker Fundamentals
Fast recall
Quick revision
Core answer
Whether you understand a container image as a portable runtime contract (app + filesystem + config) and can name what it solves (env drift) vs. what it costs.
Saying 'Docker is a lightweight VM' without explaining the shared kernel model or naming the problem (environment drift) it solves and the new problems (JVM/container memory, image size) it introduces.
Frame a container image as a portable runtime contract that ends environment drift, then name what it changes for a JVM app — the JVM now runs inside a cgroup with memory limits, so heap and container memory interact and can OOM-kill — and the cost side: image size, layer caching, build reproducibility.
Interview-ready guide
Interview answer
Docker is a tool that packages an application together with its entire runtime — the OS libraries, the JVM, the app jar, and config — into one portable artifact called a container image, which then runs as an isolated process on any host with a compatible runtime.
The reason it exists is that environment drift — 'it works on my machine' — was the dominant cause of deployment failure, and a container captures the whole runtime contract so the same immutable image runs identically on a laptop, CI, and production.
The thing that's specific to a Java app is that the JVM now runs inside a cgroup with a memory limit, so its heap and the container limit interact and the container can get OOM-killed; you handle that with -XX:MaxRAMPercentage. And I keep images small with multi-stage builds — build with Maven in one stage, then copy only the JRE and the jar to the final image.
The caveat I always flag is that a shared kernel means a container is a weaker security boundary than a VM.
Docker Fundamentals
Direct Answer
Docker is a tool that packages an application together with its runtime, libraries, and configuration into a single portable artifact called a container image, which runs as an isolated process on any host that has a Docker-compatible runtime. It exists because 'it works on my machine' was the dominant deployment failure: differences in OS, JVM version, dependencies, and config between dev and prod caused outages, and a container captures the entire runtime contract so the same image runs identically on a laptop, a CI runner, and a production cluster.
Common Mistakes & Pitfalls
Saying 'Docker is a lightweight VM' without explaining the shared kernel model or naming the problem (environment drift) it solves and the new problems (JVM/container memory, image size) it introduces.
Check your understanding
Answer these without looking back at the article.
- Why can a JVM inside a container get OOM-killed even when -Xmx is set, and how is it fixed?
- What is the difference between a container and a VM in terms of isolation and security boundary?
- How does a multi-stage build reduce image size, and which layers should you cache separately?
- What is a Docker layer, and why does ordering COPY before RUN speed up builds?
- When is a container not a sufficient security boundary, and what would you use instead?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.