All 75 Docker quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 22 subtopics, so you can revise one part at a time. Choose Try Docker quiz above to take a scored run and review the questions you got wrong.
What the Docker quiz covers
Compose9
Dockerfile9
Containers & Lifecycle7
Build Optimization6
Networking6
Volumes & Data6
CLI5
Images & Layers4
Registry & Tags4
Security4
Resources & Limits3
Configuration2
Build1
Image1
Logging1
Maintenance1
Mechanism1
Network1
Registry1
Design1
Operations1
Volume1
Beginner level — 20 Docker questions
Question 1·Images & Layers
What is the core difference between a Docker image and a container?
A.An image is an immutable template of read-only layers; a container is a running instance with an added writable layer
B.Image and container are two names for the same thing, differing only in that the image lives in a registry and the container on the local machine
C.A container is a frozen snapshot of an image used for backup and cannot run any process
D.Each image can create exactly one container; to run several copies you must build the image again
Answer: A
An image is an immutable template made of read-only layers. A container is a running instance created from an image, with an added writable layer and its own namespace/process. One image can run as many containers. Changes in the writable layer are lost when the container is deleted unless a volume is used.
What is the difference between COPY and ADD in a Dockerfile, and which should you prefer?
A.Both copy files; ADD additionally extracts tar archives and downloads URLs
B.COPY can copy only a single file, while ADD can copy whole subdirectories
C.COPY and ADD are identical, ADD is just the old alias for COPY
D.ADD is faster than COPY because it compresses the data before writing it into the layer
Answer: A
Both copy files/directories from the build context into the image. ADD adds behavior: it auto-extracts local tar archives and supports URLs in some cases. Since these implicit behaviors are surprising, production should prefer COPY for clarity, using ADD only when you deliberately need tar extraction.
What is the core difference between a container and a virtual machine?
A.A container shares the host kernel; a VM virtualizes hardware and runs its own guest OS
B.A container is an optimized VM; each container still boots its own kernel, just a lighter one
C.VMs and containers are alike in size and startup speed, differing only in image file format
D.Containers isolate more strongly than VMs because each container has its own hypervisor
Answer: A
A VM virtualizes hardware: each VM runs a full guest OS with its own kernel on a hypervisor. Containers virtualize at the OS layer: many containers share the host kernel, each packaging only the app plus its own userspace. The consequence: containers are lightweight (MB) and start in milliseconds with higher density; VMs are heavier but isolate more strongly thanks to their own kernel boundary.
A.Both bind mounts and volumes store data in the container's writable layer, so it is lost when the container is deleted
B.A volume stores data inside the image, so pushing the image to a registry carries the data along
C.A bind mount is read-only while a volume is write-only
D.A bind mount maps a host path; a volume is managed by Docker in its own area
Answer: D
A bind mount maps a host path directly into the container — host file edits show up immediately in the container, good for local development but tied to the host's directory structure. A volume is managed by Docker in its own storage area, more portable and suited to persistent data like database data. Both live outside the writable layer, so data isn't lost when the container is deleted.
A..dockerignore only takes effect while the container runs, hiding files from the processes inside
B.It prevents any image layer from being cached so each build starts clean
C.It permanently deletes the listed files from the host machine after the build
D.It excludes files and directories from the build context before the context is sent to the builder
Answer: D
.dockerignore excludes files/directories from the build context before the context is sent to the Docker builder. Benefits: faster builds (less data sent), more stable cache (COPY . . is less disturbed by unrelated files), and it avoids accidentally baking secrets, .git, local node_modules, or large artifacts into the image. It applies at build time and does not delete files on the host.
A.Both send the same signal, differing only in that stop also deletes the container afterwards
B.stop merely freezes the process and keeps its state in RAM; you resume it with docker unpause
C.stop sends SIGTERM and waits a 10-second grace period before SIGKILL; kill sends SIGKILL straight away
D.kill sends SIGTERM while stop sends SIGKILL — the names are the reverse of the behaviour
Answer: C
docker stop sends SIGTERM, waits out the default 10-second grace period, then sends SIGKILL — giving the app time to close connections and finish in-flight work. docker kill sends SIGKILL directly, so the process dies immediately. Change the wait with docker stop -t <seconds>.
The Dockerfile has EXPOSE 3000 but the container runs as docker run myapp with no -p. Can the host reach localhost:3000?
A.Yes — EXPOSE publishes the port to the host automatically under the same number
B.Yes, but only when the container runs on the default bridge network
C.No, and there is no way to reach it because EXPOSE has blocked the port from outside
D.No — EXPOSE is documentation metadata only and publishes nothing
Answer: D
No. EXPOSE only records "this container serves on which port" as documentation for humans and for docker run -P. It does not create a port mapping to the host. To reach it from the host you must publish explicitly with -p 3000:3000.
Which directory does the Dockerfile below copy package.json into?
dockerfile
FROM node:22-alpine
RUN mkdir /app
RUN cd /app
COPY package.json .
A.The build fails because WORKDIR must be declared before COPY
B.Into /app, because RUN cd /app set the working directory for every following instruction
C.Into / — each RUN runs in its own shell, so cd does not carry over to the next instruction
D.Into /app, because COPY always uses the most recently mkdired directory
Answer: C
Into /. Each RUN is a layer with its own shell, so cd /app no longer applies to the next instruction. The correct fix is WORKDIR /app — it sets the working directory for all subsequent instructions and creates the directory if it doesn't exist.
How does running a container with --network host differ from the default bridge network?
A.The container gets its own IP address from the LAN's router
B.It differs only in performance; you still have to publish ports with -p as on the default bridge
C.It shares the host's network namespace: no -p needed, and network isolation is lost
D.Host mode enables a dedicated firewall for the container so it is safer than bridge
Answer: C
--network host drops the separate network namespace: the container uses the host's network stack directly. A port opened in the container is open on the host, so -p is neither needed nor used. In exchange you lose isolation and risk port clashes with other processes. Fully functional on Linux.
Running docker pull nginx with no tag — which image does it fetch?
A.It fetches the latest tag — merely a conventional label, not a promise of recency
B.Docker fetches the image with the highest semver version available in the registry
C.Docker compares build dates and fetches the most recently pushed image
D.The command errors out because a tag is mandatory
Answer: A
It pulls nginx:latest. latest is just the default tag when none is given, assigned entirely by whoever published it — it does not guarantee the newest version. In production, pin a specific version tag, or even better, pin the digest.
Why add a USER instruction to a Dockerfile rather than running as root?
A.So it can write to volumes without extra configuration
B.So the image is smaller when pushed to a registry
C.So the container starts faster by skipping permission checks
D.So that someone escaping the container does not immediately have root on the host
Answer: D
Because user identity is shared with the OS kernel: root inside the container maps to root outside on the host. If a vulnerability allows escaping the container, the attacker immediately has the highest privileges on the server.
A.The first runs a new process; the second attaches to the already-running main process
B.The first can only read output while the second can send input
C.The first is for Linux containers and the second for Windows containers
D.The first works on a stopped container while the second does not
Answer: A
The former starts a new process inside the container — usually a shell for inspection. The latter attaches to the standard streams of the existing main process. So detaching from the attached session can kill the container.
A.Stopped containers, unused networks and images, and the build cache
B.Every image and container, including running ones
C.Only layers duplicated between images
D.All Docker data including volumes
Answer: A
Stopped containers, unused networks, untagged images, and build cache. It does not remove volumes unless the corresponding flag is added — a deliberate design choice to avoid accidental data loss.
A.One shows a condensed view, the other shows full details
B.One lists only running containers, the other lists stopped ones too
C.One only covers containers created by the current user
D.One lists containers, the other lists the available images
Answer: B
The default command lists only running containers, while the other option lists stopped ones as well. An exited container still exists along with its logs and exit code, so that option is the first step when diagnosing an incident.
What does the trailing dot mean in docker build -t app .?
A.The directory sent to the builder as the build context
B.Where the image is saved once the build completes
C.The default working directory inside the resulting image
D.The location of the Dockerfile to use for the build
Answer: A
It is the directory sent to the build tool as the context. The entire contents of the directory are packaged and sent, so copy commands in the Dockerfile can only pick up files within that scope.
A.It limits the container's access to that directory
B.It copies the source code from the host into that directory
C.It creates a volume mounted at the named directory
D.It sets the working directory for the following instructions
Answer: D
It sets the working directory for subsequent instructions and creates the directory if it does not exist. Relative paths in copy and run commands are resolved from there.
A.Docker's own event log about the container's lifecycle
B.The standard output and error streams of the main process
C.Every log file inside the container's filesystem
D.The history of commands run inside the container
Answer: B
It shows the standard output and error stream of the main process. Logs the application writes to a file inside the container do not appear here — which is why applications running in containers should log to standard output.
A.A database recording the containers currently running
B.Where Docker's network and volume configuration is stored
C.A store that holds and distributes images
D.The component that orchestrates containers across several hosts
Answer: C
It is the place that stores and distributes images. Pull and push commands both work with it. A registry can be a public service, a cloud provider's service, or a system you run yourself on an internal network.
How does docker run -d differ from running without it?
A.The container runs in the background and the terminal is returned immediately
B.The container is restarted automatically when it fails
C.The container runs with more restricted privileges than usual
D.The container is removed automatically once its process ends
Answer: A
The container runs in the background and the terminal is returned immediately. Without this option the output is attached to the terminal, and closing that window can stop the container along with it.
A.A separate partition isolating the container's data
B.The filesystem change produced by one instruction
C.A different version of the same image
D.A full copy of the filesystem at each step
Answer: B
It is the file system change produced by a single instruction. Layers stack on top of each other, are cached individually, and are shared between multiple images — so two images with the same base only cost storage for the differing parts.
Given the Dockerfile below, what command does docker run img --port 9000 execute inside the container?
dockerfile
FROM python:3.12-slim
ENTRYPOINT ["python", "-m", "app"]
CMD ["--port", "8000"]
A.CMD and ENTRYPOINT are the same, so only the last line counts and the container runs python -m app --port 8000
B.python -m app --port 8000 --port 9000 — command-line arguments are appended to CMD rather than replacing it
C.python -m app --port 9000 — ENTRYPOINT fixes the executable and arguments after the image name replace CMD
D.--port 9000 — docker run arguments override both ENTRYPOINT and CMD
Answer: C
It runs python -m app --port 9000. ENTRYPOINT fixes the main executable (python -m app); CMD only supplies default arguments (--port 8000). Arguments passed after the image name in docker run replace the entire CMD, then get appended after ENTRYPOINT. To replace ENTRYPOINT itself you must use the --entrypoint flag.
Which statement about Docker restart policies is FALSE?
bash
docker run --restart on-failure:3 myapp
docker run --restart unless-stopped myapp
A.always and unless-stopped differ only in name, their behaviour is identical
B.no is the default and never restarts a container automatically
C.on-failure restarts only on a non-zero exit code, with the attempt count capped by :N
D.A restart policy cannot be combined with --rm, since the container is deleted as soon as it exits
E.unless-stopped is like always but respects a manual docker stop
Answer: A
The restart policy decides whether Docker automatically restarts a container when it exits or when the daemon restarts, set via --restart. no (the default) never restarts. on-failure[:N] restarts only on error exit (non-zero exit), with an optional limit on attempts. always always restarts. unless-stopped is like always but respects your manual stop. It can't be combined with --rm — Docker reports a "conflicting options" error.
Which statement about container storage and data persistence is correct?
A.The VOLUME instruction in a Dockerfile stores data inside the image so it ships with the image
B.docker commit on a running container saves the volume's data into the new image as well
C.A volume can be attached to only one container at a time
D.Data written to the writable layer survives after the container is deleted
E.A volume exists independently of the container lifecycle: deleting the container does not delete the volume
Answer: E
Data written to the writable layer is lost when the container is deleted unless a volume/bind mount is used. A volume exists independently of the container (deleting the container doesn't delete the volume) and can be mounted by multiple containers. Two misconceptions to avoid: the VOLUME instruction doesn't put data into the image, and docker commit doesn't save volume contents into the new image.
With the command below, which port does a client on the host use to reach the API, and how does the mapping work?
bash
docker run -d -p 8080:8000 my-api
# the my-api process listens on port 8000 inside the container
A.Both 8080 and 8000 are opened on the host and both point at the process in the container
B.Through port 8080; -p follows the host:container format
C.The host reaches it on port 8000; the first number is the container port and the second the host port
D.No publishing is needed, the container exposes port 8000 to the host automatically since they share one machine
Answer: B
The host reaches it via port 8080. The -p syntax is host:container, so -p 8080:8000 forwards host port 8080 to container port 8000. The container has its own network namespace: the port the process listens on inside (8000) is not exposed to the host unless published. To let the host reach it, you must publish that port.
In Docker Compose, when service api connects to service db (Postgres), which address should it use?
A.Use localhost:5432 because the services run on the same host machine
B.Use the service name: host db port 5432 — services on the same network resolve through internal DNS
C.Use 127.0.0.1 inside the api container because Compose merges every service into one network namespace
D.You must publish db's port to the host and have api connect to the host's IP
Answer: B
Use the service name as the hostname: host db, port 5432. Docker Compose creates a default network and provides internal DNS, so services on the same network resolve each other by service name. Don't use localhost — each service has its own network namespace, so localhost points back to that same container. There is no need to publish db's port for api to call it internally.
What is the difference between an image tag and an image digest?
A.Tags and digests are both immutable, differing only in display format
B.A digest is an incrementing serial number Docker assigns on each image push
C.latest is a special digest that always points at the newest tested stable build
D.A tag is a label that can be repointed at another image; a digest is a content hash and is immutable
Answer: D
A tag is a human-readable reference like app:1.2.0 or app:latest, and it can be re-pushed to point at a different image. A digest is a content-hash reference (sha256:...), which is immutable — the same digest always means exactly that one image. In production, avoid depending on latest; use explicit version tags and pin the digest when you need high reproducibility.
What is Docker Compose for, and where does it fit relative to Kubernetes?
A.Compose fully replaces the Dockerfile: declaring services in Compose means you no longer build images
B.Compose runs several containers from one file, suited to development and small environments
C.Compose is a miniature Kubernetes, handling scaling, self-healing and rolling updates across a multi-node cluster
D.Compose can run only one container at a time; several services require several separate Compose files
Answer: B
Docker Compose describes and runs multiple containers from a single config file, usually for local development, integration tests, and small environments — letting the app, database, cache, and broker run together on one network with consistent configuration. Compose does not replace Kubernetes for large-scale production orchestration (scaling, self-healing, multi-node rolling updates), but it is very useful for developer onboarding and simulating dependencies.
A.ENV only applies at build time, while ARG is the runtime environment variable
B.ARG exists only at build time; ENV is written into the image so it is readable at runtime
C.ARG and ENV are identical, ARG is just the deprecated old name
D.Both are stripped from the image after the build so neither can configure runtime
Answer: B
ARG is a build-time variable: passed via --build-arg, not present in the running container. ENV is baked into the image, readable by processes at runtime, and overridable with docker run -e. Neither should be used to hold secrets, since both leak through docker history / docker inspect.
What does a HEALTHCHECK declared in a Dockerfile actually do?
A.HEALTHCHECK fully replaces liveness/readiness probes when deploying to Kubernetes
B.Docker runs the check command periodically and marks the container healthy/unhealthy
C.HEALTHCHECK runs exactly once at startup to confirm the application is ready
D.Docker restarts the container automatically the first time the health check fails
Answer: B
HEALTHCHECK tells Docker how to automatically check whether the app inside the container is still serving. The result is a starting/healthy/unhealthy status, visible in docker ps and docker inspect. Compose uses it for condition: service_healthy. The Engine does not restart unhealthy containers on its own.
Why is splitting apt-get update and apt-get install into two RUN instructions, as below, an anti-pattern?
dockerfile
FROM debian:12
RUN apt-getupdate
RUN apt-get install -y curl
A.Because each RUN creates a new container so the DEBIAN_FRONTEND variable is lost
B.They are two different layers: editing the install line still reuses the stale update layer from cache
C.Because apt-get cannot run across consecutive RUN instructions, you must switch to apt
D.Because Docker allows only one package-install command per Dockerfile
Answer: B
Because the cache is tracked per layer. If you change the install line, the update layer above still hits the cache, so packages get installed from a stale mirror list — prone to 404 errors or outdated packages. Combine them into one RUN joined with && so both steps always run together.
The image already contains data at /app/node_modules. Running docker run -v mydata:/app/node_modules img with an empty named volume mydata — what is in that directory?
A.Image content and volume are synchronized both ways each time the container starts
B.An empty directory — a volume always completely masks the image's existing content
C.You still see the image's content — an empty named volume is pre-populated
D.The container fails to start because you cannot mount a volume over a directory that already has data
Answer: C
You still see the image's content. An empty named volume is pre-populated by Docker with the destination directory's content from the image on first mount. From then on the volume already has data, so it stays as-is. A bind mount is the opposite — it always masks the image content.
Switching the base image from node:22 to node:22-alpine to cut size — what is the most common real-world risk?
A.Alpine cannot run Node.js, it only suits applications written in Go or Rust
B.Alpine only ships for ARM so the image will not run on x86 servers
C.Alpine uses musl instead of glibc, so native modules must be rebuilt from source
D.Alpine does not support layer caching so builds are always slower
Answer: C
Alpine uses musl libc, not glibc. Native modules are usually only built for glibc, so they must be recompiled (needing an extra build toolchain and longer builds), and some libc-level behavior like DNS or locale differs. The -slim variant (Debian, glibc) is the middle-ground choice when you don't want to switch libc.
B.137 is the standard code for an image with a missing layer, so re-pull it
C.The container stopped because the restart policy expired, unrelated to memory
D.137 means the health check failed 137 times in a row
Answer: A
Exit 137 = 128 + 9, meaning the process was SIGKILLed. In a container with --memory, the culprit is almost always the kernel OOM killer after exceeding the limit. Confirm with docker inspect --format "{{.State.OOMKilled}}" <container>.
A.No — depends_on only guarantees container start order
B.Yes — Compose always waits for the dependency's port to open before starting the other service
C.Yes, as long as both services are on the same network
D.No, and Compose has no mechanism to wait — you must write a wait-for-it style script
Answer: A
No. The list form of depends_on only orders container startup. Postgres still takes a few more seconds to accept connections, while api is already running and calls it immediately. The right way: add a healthcheck to db and use condition: service_healthy — and the app should still retry on its own.
What problem does CMD npm start (shell form) cause versus CMD ["npm","start"]?
A.The process runs under a shell, so it never receives the stop signal
B.Environment variables are not passed to the child process
C.The command is not found because the image has no shell
D.The image grows because a shell has to be embedded
Answer: A
The shell form runs the command under /bin/sh -c; with npm start there's also an extra npm process in front of the app. When the runtime sends SIGTERM to PID 1, the app may not receive the signal directly, so graceful shutdown is unreliable.
What does the container storage layer's copy-on-write mean?
A.Data is recompressed each time the container writes to the filesystem
B.Files are backed up automatically before each write so they can be restored
C.Modifying a file from the image copies that file up into the container's writable layer
D.Every change is written straight into the original image on disk
Answer: C
The image layers are read-only and shared across all containers. When a container modifies a file, that file is copied up to its own writable layer before being modified. That way many containers run the same image without duplicating data.
A.When the binary is self-contained and you want the smallest possible attack surface
B.When the application needs to run several processes in parallel
C.When you need to install many system packages that ordinary base images lack
D.When the application needs direct access to the host's hardware
Answer: A
When the executable is self-contained — typically a statically compiled Go program — and you want to minimize the attack surface. No shell, no package manager, so an intruder has almost no tools available.
Why is docker commit from a running container an anti-pattern?
A.The command stops the running container
B.The resulting image is not reproducible and nobody knows what is inside it
C.The resulting image cannot be pushed to a registry
D.The resulting image is always far larger than one built from a Dockerfile
Answer: B
Because the resulting image is not reproducible: there is no record of what was installed or changed. Six months later, nobody can rebuild that image and nobody knows what is inside it.
How does BuildKit differ from Docker's legacy builder?
A.It abandons the concept of layers in images entirely
B.It builds independent stages in parallel and offers cache mounts and secret mounts
C.It produces images in a proprietary format incompatible with older registries
D.It runs only on Linux
Answer: B
It builds a dependency graph and builds independent stages in parallel, skipping stages that aren't needed for the final result. It also adds cache mounts, secret mounts, and multi-platform builds. Since Docker it is the default builder.
What risk does mounting /var/run/docker.sock into a container carry?
A.The container can no longer be stopped with the ordinary stop command
B.It is effectively granting that container root on the host
C.Other containers on the same host become noticeably slower
D.That container's image can no longer be pushed to a registry
Answer: B
It is equivalent to granting root on the host. With that socket, the container can create a new container that mounts the entire host file system with the highest privileges — so every isolation boundary becomes meaningless.
What else does running a container with --read-only need for the application to work?
A.Mounting tmpfs for the directories the application needs to write temporarily
B.Turning off the application's logging
C.Running the container as root to bypass the restriction
D.Switching to a base image that supports read-only mode
Answer: A
Mount an in-memory file system for the directories the app needs to write to temporarily — the temp directory, the directory holding the process lock file. Many programs still need to write somewhere even if they store no data.
What do image vulnerability scanners (Trivy, Grype) detect and not detect?
A.They detect known CVEs in packages; they do not detect logic flaws in your own code
B.They detect runtime misconfiguration such as excessive privileges
C.They detect every kind of vulnerability including ones in application code
D.They only detect vulnerabilities in the base OS, not in language libraries
Answer: A
They list the packages in the image and match them against vulnerability databases. They do not analyze your code — logic flaws, injection, and broken authorization go undetected. That is the job of static analysis tools.
Why should a containerised application log to stdout rather than to a file?
A.So the infrastructure collects the logs, separating storage from the application
B.Because log output to stdout is standardized automatically
C.Because writing to stdout is significantly faster than writing to disk
D.Because containers are never allowed to write files
Answer: A
So the platform handles collection and storage while the app just emits a stream of events. Writing to a file inside the container means the logs are lost when the container is recreated, and nobody outside can read them.
How is a container running with --cpus=0.5 limited?
A.It is stopped when it uses more than 50% CPU for a period of time
B.It gets lower priority under contention but has no hard cap
C.It is throttled to 50% of CPU time, not killed
D.It may only run on half of the machine's physical cores
Answer: C
It's throttled to half of one core's CPU time — the process is slowed down but not killed. This is an important difference from a memory limit, which kills the process when exceeded.
A container reports "too many open files". What is the cause and fix?
A.The host's disk is full so no more files can be opened
B.The file descriptor limit was exceeded; raise the ulimit or fix the leak
C.The image has too many layers, exceeding a filesystem limit
D.The container lacks permission to open files in that directory
Answer: B
Remember that every network socket is also a file descriptor, so a process with many connections hits the limit. Fix it by raising the limit, and check for a leak.
How does -p 127.0.0.1:8080:8080 differ from -p 8080:8080?
A.The two are equivalent, just written differently
B.The first encrypts the traffic while the second does not
C.The first listens only on loopback and is not exposed to the outside network
D.The first allows connections only from other containers
Answer: C
The first form only listens on the loopback address, so it's only reachable from that server itself. The second listens on every interface — if the server has a public address, the service is exposed directly to the Internet.
Why create a user-defined bridge network rather than using the default bridge?
A.A user-defined network gives higher bandwidth between containers
B.A user-defined network encrypts traffic between containers
C.The default network does not let containers reach the Internet
D.A user-defined network has internal DNS so containers reach each other by name
Answer: D
A user-defined network has built-in name resolution: containers reach each other by service name. On the default network you have to use IP addresses, which change every time a container is recreated. It also gives better isolation.
Bind mounting a host directory into a container causes permission denied. Why?
A.The container is not allowed to write outside its own filesystem
B.The host directory must be on a list Docker permits
C.The container user's UID does not match the file owner on the host
D.Bind mounts are always mounted read-only
Answer: C
Because permissions are checked by the user's numeric identity, not by name. The user inside the container has a different number than the file owner on the host, so the kernel denies access even though the names look the same.
B.Run a temporary container mounting that volume and archive it out to a host directory
C.Push the volume to a registry the way you push an image
D.Copy Docker's data directory on the host directly
Answer: B
Run a temporary container that mounts that volume together with a host directory, then archive the data out. The volume lives in an internal directory managed by Docker — reading it directly from the host is unreliable because that's an implementation detail.
How does depends_on with condition: service_healthy differ from plain depends_on?
A.It runs health checks periodically throughout the runtime
B.It restarts the dependent service when the other one fails
C.It waits for the healthcheck to report healthy, not merely for the container to start
D.It merges the two services into one container
Answer: C
The plain form only waits for the container to be started, not for the service inside to be ready. With a health condition, Compose waits until the health check reports healthy — which is what you actually want.
A.It is merged automatically over the main file, overriding matching values
B.It replaces the main file entirely when present
C.It is only for declaring extra environment variables
D.It is only read when passed explicitly with the file flag
Answer: A
It's merged automatically on top of the base file, overriding matching values. This lets you keep a shared base and add per-environment overrides — bind-mounting source, exposing debug ports, setting environment variables.
How do env_file and environment differ in Compose?
A.The latter only accepts string values
B.The former encrypts the values while the latter leaves them plain
C.The former reads from a file, the latter is declared inline and takes higher precedence
D.The former is only for build time while the latter is only for runtime
Answer: C
The first reads variables from a file; the second declares them inline in the Compose file and takes precedence on conflicts. Both set environment variables for the container.
A.Declaring which users may run the corresponding services
B.Choosing the CPU architecture the image will be built for
C.Assigning services to groups that only start when that profile is enabled
D.Setting different resource configuration tiers per service
Answer: C
Assign services to named groups, and they only start when that group is enabled. This keeps auxiliary services — monitoring tools, sample data loaders, database admin tools — in the same file without starting by default.
CI needs to pull an image from a private registry. Which approach fits best?
A.Copy the login configuration file from a personal machine onto the runner
B.Make the registry public so no authentication is needed
C.A short-lived token or a dedicated CI credential, never a personal account
D.Embed the username and password in the Dockerfile so it logs in by itself
Answer: C
A short-lived access token or a dedicated CI account with minimal permissions. A personal account belongs to one person — revoking it when they leave the company breaks the whole pipeline with nobody understanding why.
A.A complete list of the components and versions present in the image
B.A digital signature proving the image's origin
C.A description of the ports and volumes the image needs at runtime
D.A record of the commands run during the build
Answer: A
A complete list of the components in the image with versions — OS packages, language libraries, and transitive dependencies. It is the software bill of materials, used to look things up when a new vulnerability appears.
A container shows UTC while the application needs Vietnam time. What is the right handling?
A.Keep UTC in the container and convert to local time in the presentation layer
B.Add the offset in hours to every timestamp when storing it
C.Set the timezone variable and install the timezone data package into the image
D.Bind mount the host's timezone file into the container
Answer: A
Keep the container on UTC and convert to local time at the display layer. Setting the server to local time feels convenient but makes data inconsistent once the system spans multiple regions, and causes bugs when timezone rules change.
Why use the same image for staging and production?
A.To make CI builds run faster
B.Because Docker does not allow building the same Dockerfile more than once
C.So that what was tested is exactly what runs, with only configuration differing
D.To save storage space in the registry
Answer: C
So that what was tested is what runs. Rebuilding per environment can produce different contents because dependencies and cache change over time — so the artifact running in production is no longer the one that was tested.
A.All three are competing products doing the same job
B.OCI is the standard, containerd is the runtime, and Docker Engine uses containerd underneath
C.OCI is a command-line tool replacing the docker command
D.containerd is the image format while Docker Engine is the runtime
Answer: B
The first organisation standardises and defines specifications for image format and for runtime. The second component is a runtime that implements that specification. Docker Engine uses it underneath and adds tooling, networking and build layers.
How does --tmpfs /tmp differ from mounting a volume at /tmp?
A.The data lives in RAM and disappears when the container stops
B.The data is compressed to save space
C.The data is backed up automatically before the container stops
D.The data is shared between every container on the same host
Answer: A
Data lives in memory and vanishes completely when the container stops. It's faster than disk writes and leaves no trace, so it suits temp files and sensitive data you don't want touching disk.
What is the benefit of combining commands into one RUN with &&?
A.Fewer layers, and temporary files deleted in the same layer never enter the image
B.The commands run in parallel so the build is faster
C.The later command still runs even if the earlier one fails
D.The commands' output is written into a single log file
Answer: A
Two benefits: fewer layers, and more importantly temp files are removed in the same layer so they never enter the image. Deleting in a separate command leaves the files in the earlier layer and the size doesn't shrink at all.
A.When the container needs to send signals to other containers
B.When you need to set the wait time before the container is killed
C.When the application needs to ignore every stop signal
D.When the application uses a signal other than SIGTERM for a graceful shutdown
Answer: D
When the application uses a signal other than the default one to shut down gracefully. Some web servers use their own signal for that, while the default signal makes them shut down immediately — cutting off in-flight requests.
What problem does an oversized build context cause?
A.The builder refuses to build once the context exceeds a threshold
B.The entire context is sent to the builder before the build even starts
C.The final image always contains the whole context
D.The layers lose their cache validity on every build
Answer: B
The entire context is sent to the builder before the first command runs. With a dependency folder of hundreds of megabytes or a large Git history folder, this step takes tens of seconds on every build.
After editing environment in compose and running docker compose up, what happens?
A.Nothing happens until you run the restart command
B.The container is recreated because its configuration changed
C.The running container has its variables updated without being recreated
D.Compose errors out and asks you to delete the old container first
Answer: B
The container is recreated. Environment variables can only be set at container creation, so they can't be changed on an existing container. Compose compares the desired config with the current state and replaces whatever has drifted.
A container restarts repeatedly. What is the first diagnostic step?
A.Change the restart policy to no-restart
B.Delete the container and rebuild the image from scratch
C.Raise the memory limit and run it again to see whether it helps
D.Read the container's logs and check the previous run's exit code
Answer: D
Read the container's logs and check the exit code of the previous run. The logs usually contain the direct cause, and the exit code tells you whether the process exited on its own due to an error or was killed by the kernel for running out of memory.
How do docker-compose (v1) and docker compose (v2) differ?
A.V2 uses a completely different configuration file format
B.V2 cannot build images, it only runs existing ones
C.V2 only runs on a container orchestration platform
D.V2 is a Go plugin integrated into the CLI
Answer: D
Version two is a Go plugin integrated directly into the main CLI tool, while version one is a standalone Python script that is no longer supported. The config file format is compatible, so migrating requires almost no changes.
A.Declaring default environment variables for the container
B.Naming and tagging the image instead of using the build command's parameter
C.Marking which layers to keep during image cleanup
D.Attaching metadata to the image so tools and people can look it up
Answer: D
Attaches metadata to the image as key-value pairs. There's a set of conventional keys for things like source code, version, build time and license — so tools and other people can look them up consistently.
In CI, the Docker build cache is often not reused. Why, and how is it fixed?
A.The cache works only when the Dockerfile has not changed at all
B.The runner is a clean machine each time; fix it by exporting the cache to a registry
C.Registries do not allow storing cache data
D.CI always disables the cache to guarantee clean builds; re-enable it with a flag
Answer: B
Because CI runners are usually a clean environment each time, there is no local cache to reuse. The fix is to export the cache to a registry on the previous build and import it on the next one, via the builder's cache options.
Does docker compose down delete data in named volumes?
A.Yes, every volume belonging to the project is removed with it
B.It depends on whether the volume is declared at service or project level
C.No, unless you add the option to remove volumes
D.Yes, but the data is backed up automatically before removal
Answer: C
No, unless you add the volume deletion option. Data is intentionally kept so restarting doesn't lose the database. Adding that option is an irreversible operation, so it requires great care.
A container must call a service running on the host. Which address?
A.The container name set in the configuration file
B.The local loopback address, as when running on the host
C.The host's public address on the internet
D.The special hostname Docker provides that points at the host
Answer: D
Use the special domain name Docker provides that points to the host. The loopback address inside the container points to the container itself rather than the server — this is the most common mistake for beginners.
The host disk fills with one container log files. Which setting prevents this?
A.Setting a memory limit on the container that logs heavily
B.Restarting the container on a schedule to clear old logs
C.Changing the application to log into its own file
D.A limit on the size and number of retained log files
Answer: D
Limit the size and number of log files kept in the logging driver configuration. By default there is no limit, so a chatty application will fill the disk and drag down every other container on the server.
A.Statistics on how many times a container has been restarted
B.The resource history over the past seven days
C.Real-time CPU, memory and network usage
D.How much disk space each image occupies
Answer: C
It shows CPU, memory, and network usage in real time. The memory column shows both the amount in use and the configured limit, so this is the first step when you suspect a container is about to be killed for running out of memory.
Copying a result file from a running container to the host — what do you use?
A.Enter the container and send the file out over the network
B.The command for copying files between a container and the host
C.Attach an extra volume to the running container
D.Create a new image from the container and extract the file
Answer: B
Use the file copy command between container and host. It works with both running and stopped containers, so you can retrieve diagnostic files even after the container has exited due to an error.
Packing a web server, app, and cron into one container — what is wrong?
A.Docker does not allow more than one process to run
B.The processes cannot communicate with one another inside
C.The resulting image would exceed the maximum allowed size
D.You cannot scale or restart the parts independently
Answer: D
It does not scale, and each part cannot be restarted independently. The three components have different resource needs and release cadences, so combining them forces them to change together and one part's failure brings down the whole container.
Editing a Dockerfile then running docker compose up has no effect. Why?
A.The old image is reused because no rebuild was requested
B.The build cache retains every old layer
C.Dockerfile changes only take effect after the machine restarts
D.The configuration file must declare the new image version
Answer: A
The old image is reused because no rebuild is requested. The command uses an existing image if one is found, so when the Dockerfile changes you must add an explicit rebuild option.
Bind-mounting source code on macOS slows the app noticeably. Why?
A.Docker has to copy the whole directory into the container
B.Files pass through a sharing layer between the virtual machine and the host
C.The macOS filesystem does not handle permissions correctly
D.The container is limited to resource defaults that are too low
Answer: B
Because files go through a sharing layer between the VM and the host system. Docker runs in a Linux VM on this platform, so every file operation costs much more than running directly on Linux.
