Docker Quiz

docker stop is the polite way to shut a container down: it sends a SIGTERM asking the main process to wrap up gracefully, and only force-kills it after waiting a grace period, unlike docker kill which skips straight to force-terminating.

Plain `depends_on` guarantees Compose starts the `db` container before the `app` container, but a database process can take several seconds to initialize after its container starts, so `app` can easily start before `db` is actually ready to accept connections. The fix is `depends_on: db: condition: service_healthy` paired with a `HEALTHCHECK` on the db service, so Compose waits for db to report healthy before starting app. Option D is a trap: a HEALTHCHECK isn't required for basic `depends_on` to work at all, it's only needed if you want the smarter `service_healthy` condition.

Docker doesn't emulate a separate machine or run a whole second operating system for each container, that's what a full VM does. Instead it isolates processes using the host kernel's own namespaces (controlling what a process can see) and cgroups (controlling what it can use), which is why containers start almost instantly compared to VMs.

A volume isn't part of the container that created it, it's a separate storage area the Docker daemon itself manages, sitting outside any single container's own writable layer. That separation is exactly why the data in a volume survives even after the container that wrote to it gets removed entirely.

HEALTHCHECK's job is narrow and specific: run a command on a schedule and use its result to report whether the container is healthy, unhealthy, or still starting up. It doesn't scan for vulnerabilities, auto-restart anything on its own, or configure Kubernetes probes, those are separate, unrelated concerns.

free reads /proc/meminfo, which isn't aware of cgroups at all, it just reports the HOST's total physical memory regardless of any per-container limit. To see the ACTUAL memory ceiling a container is bound by, an application needs to read the cgroup's own limit file directly instead of relying on tools like free.

There's no info here about images or networks, so those two are already off-topic. Stopped containers do exist, but `docker ps` alone won't show them, that requires the `-a` flag. Left with its default, unflagged behavior, `docker ps` lists exactly the containers that are running right now.

-Xmx only caps the JVM's HEAP, it says nothing about all the other memory a JVM process actually uses, metaspace, thread stacks, native buffers, which adds real overhead on top of the heap limit. And older JVMs (before JDK 10) didn't even look at the container's cgroup memory limit at all, both factors together mean actual memory usage can blow right past what -Xmx alone would suggest.

Normally, anything you copy or reference during a build risks ending up baked into a layer forever, even if you try to delete it afterward. The --secret flag instead makes a file's contents available ONLY for the duration of a single RUN --mount=type=secret step, entirely in memory, so the secret is usable during the build but never actually written into any image layer.

A Dockerfile is the actual recipe Docker follows to build an image: a plain text file listing instructions like FROM, RUN, and COPY, executed in order, each one adding a new layer to the resulting image.