All jobs / DevOps / SRE / cloud

Containers interview questions

Containers questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. What is the difference between an image and a container?

    The strongest answer: An image is the immutable recipe; a container is a running instance of that recipe — I do not “SSH into the image to fix prod”

    Why it works: Exactly. Recipe versus process. You ship images; you run containers.

    • Image = immutable artifact.
    • Container = running instance.
    • Fix the image, do not pet the container.
    • Do not call it a small VM and stop thinking.

  2. A Dockerfile says `FROM node:latest`. What is wrong?

    The strongest answer: latest moves; builds become unreproducible — I pin a digest or a version I can explain

    Why it works: Exactly. Pin what you run. Patches come from a version you choose, not from a moving word.

    • Pin versions or digests.
    • latest is not a version.
    • Patches are a choice, not a tag.
    • Same pin in CI and prod.

  3. A container can take all the memory on the node. What do you set?

    The strongest answer: Requests and limits (or the platform equivalent) so a leak kills the one container, not the neighbours

    Why it works: Exactly. Isolate the blast. Restart-always on a leak is a flap.

    • Set requests and limits.
    • A leak should evict one container.
    • Do not “fix” with swap.
    • Do not rely on always-restart.

  4. In the team’s Docker Compose stack, Postgres loses all its data every time the container is recreated.

    Why, and what is the fix?

    The strongest answer: The data lives in the container’s writable layer, which goes away with the container; declare a named volume (or bind mount) on the data directory in the compose file so it outlives recreation

    Why it works: Right — containers are disposable, volumes are where state lives. And remember `down -v` deletes named volumes too.

    • Container layer is disposable.
    • State goes in a volume.
    • Declare it in compose.
    • down -v removes volumes.

  5. CI rebuilds a 12-minute Docker image on every commit. What do you change first?

    The strongest answer: Order the Dockerfile so dependency layers stay cached, and cache those layers in CI — I do not start with a bigger runner

    Why it works: Exactly. Cache-friendly layers, then CI cache. Hardware is later.

    • Stable layers first in the Dockerfile.
    • CI cache on those layers.
    • Do not git the image.
    • Do not skip to a bigger runner.

  6. A production image is 1.8 GB and includes a compiler. What do you do?

    The strongest answer: Multi-stage: build in one stage, copy the runtime bits into a slim image — I do not ship the toolchain to prod

    Why it works: Exactly. Slim runtime. A compiler in prod is attack surface and minutes on every pull.

    • Multi-stage builds.
    • Runtime-only final image.
    • No compiler in prod.
    • Smaller pull, smaller surface.

  7. The app container connects to `localhost:5432` and gets connection refused, though the database container is running. Why?

    The strongest answer: Each container has its own network namespace, so localhost is the app container itself; on a Compose or user-defined network the containers resolve each other by service name — connect to `db:5432`

    Why it works: Exactly — container networking gives each container its own loopback and embedded DNS by service name.

    • localhost is this container.
    • Own namespace per container.
    • Use the service name.
    • Do not host-network your way out.

  8. The Dockerfile has no USER line, so the app runs as root. Does that matter inside a container?

    The strongest answer: Yes — containers share the host kernel, so a breakout or a mounted host path is root on the host; set a non-root USER, read-only root filesystem, drop capabilities and never run privileged

    Why it works: Right — container isolation is namespaces and cgroups, not a hypervisor. Least privilege applies inside the box too.

    • Shared kernel, not a VM.
    • USER non-root in the Dockerfile.
    • Read-only fs, drop capabilities.
    • Never --privileged for an app.

  9. The container registry has grown to terabytes, pulls from the cluster are slow, and a public registry started rate-limiting your nodes.

    What do you change?

    The strongest answer: Retention that garbage-collects untagged and old images but keeps anything deployed, immutable tags, and a pull-through cache or mirror near the cluster so production never pulls straight from a public registry

    Why it works: Right — retention keyed to what is deployed, immutability so a tag cannot change under you, and a local cache for speed and independence.

    • Retain by what is deployed.
    • Immutable tags.
    • Garbage-collect the rest.
    • Mirror or cache near the cluster.