A library catalog microservice currently ships on a full general-purpose OS base image with shells and package managers the runtime never uses. Why should the team switch to a slim or distroless runtime base?
Select an answer to reveal the explanation.
Short Explanation
A full OS base is a moving van full of furniture you never unpack. Slim or distroless keeps the libraries the process needs and little else—faster pulls, less to attack.
Full Explanation
A library catalog microservice only needs the runtime libraries and binaries it actually executes. Switching from a full general-purpose OS base to a slim or distroless runtime base removes shells, package managers, and unused packages that inflate pull size and expand the CVE surface. Smaller images pull faster onto build agents and cluster nodes, and fewer unused tools mean fewer packages to scan, patch, and exploit if an attacker lands in the container. That is a deliberate packaging choice aligned with cloud-native immutability: ship what the process needs, not an entire workstation OS.
Running multiple unrelated OS init systems side by side is not a goal of slim bases and fights the one-main-process container model. OCI billing is not structured as “full OS images are charged, slim bases are free”—image choice is about size and risk, not a mythical billing exemption. Using docker commit to capture every apt upgrade without rebuilding recreates snowflake layers and hides drift from the Dockerfile that should be the source of truth; it does not justify keeping a fat base.
Exam caveat: distroless images often lack a shell, so debug workflows must use ephemeral debug sidecars or rebuild with a debug variant rather than docker exec bash. Operational check: compare image sizes and vulnerability scan counts for the full OS base versus the slim/distroless candidate for the same catalog binary, and confirm the runtime still starts and serves health checks before promoting the smaller base.