Test yourself

Docker for beginners

Final exam · 38 questions · answers explained as you pick

Docker basics

8 questions

01You are in the docker group, yet docker version prints the Client block and then, in place of the Server block, an error saying the client cannot connect to the daemon. Where do you look next?

ARun sudo usermod -aG docker $USER again and open a new login session

Incorrect — You are already in the group. A group problem shows up as permission denied on the socket; this error says nothing answered.

BReinstall the docker-ce-cli package, because the Client block is incomplete

Incorrect — The Client block printed in full, so the CLI works. What is missing is the daemon behind the socket.

Csudo systemctl status docker and sudo journalctl -u docker

Correct — The client reached no daemon, so check whether dockerd is running and read its journal for the reason it stopped or never started.

DRun docker run --rm hello-world so Docker pulls a fresh smoke-test image

Incorrect — Every docker run goes through the same daemon. With no daemon running it fails before any pull.

02Both run Docker 29, but docker info on an older production server reports Storage Driver: overlay2, while the lab VM reports overlayfs with driver-type: io.containerd.snapshotter.v1. What explains the difference?

AThe server was upgraded from an older Engine and kept its classic storage

Correct — Fresh Docker 29 installs use the containerd image store; a host upgraded from an older Engine keeps overlay2 until someone migrates it.

BThe server is an amd64 machine, and the overlayfs snapshotter exists only on arm64

Incorrect — The CPU architecture does not choose the image store. Fresh installs on amd64 use the containerd image store as well.

Coverlay2 means containerd is missing, so that server cannot start containers

Incorrect — containerd comes with every Docker Engine install. The storage line only says where images are kept.

DThe lab kit switched on an experimental image store for the course outputs

Incorrect — The kit changed nothing here. The containerd image store is the default for fresh installs since Docker Engine 29.

03On the lab VM, apt-mark showhold lists docker-ce, containerd.io and the plugins. Why is holding the Docker packages a sensible habit on a server too?

AHeld packages start faster, because apt skips their signature check at boot

Incorrect — A hold only stops apt from changing the installed version. It has no effect on how the daemon starts or runs.

BThe daemon refuses to start when the Engine is newer than the images on the host

Incorrect — Images do not tie the daemon to an Engine version like that. The reason is what an upgrade does to running containers.

CDocker's repository refuses to install a package that is not pinned and held

Incorrect — The repository accepts plain installs. The lab kit pins and holds by choice, so its versions match the lessons.

DAn Engine upgrade restarts the daemon and its containers, so you pick when

Correct — Upgrading restarts dockerd and with it every container; live restore keeps containers running only across patch upgrades. A hold stops a routine apt upgrade, by hand or by configuration management, from doing that at a moment you did not choose.

04On an arm64 lab VM, docker image ls --tree node:24-alpine shows 0B for the linux/amd64 and linux/s390x rows and 237MB for linux/arm64/v8. What do the 0B rows mean?

AThose two variants are damaged, and Docker will download them again on the next run

Incorrect — Nothing is damaged. The rows are 0B because nothing was downloaded for those platforms.

BThe index lists those platforms, but only the arm64 variant was pulled

Correct — An image index points to one variant per platform, and Docker pulled only the one that matches this CPU.

CDocker runs the amd64 and s390x variants through emulation that needs no disk

Incorrect — Nothing for those platforms is on disk, and the course sets up no emulation. Only the matching variant was pulled.

DThe amd64 and s390x variants are layers stored inside the arm64 variant

Incorrect — Compiled programs differ per CPU, so each variant is a separate image with its own ID, not a layer of another.

05A tool needs a kernel feature that only a newer Linux kernel than your host's provides. A colleague suggests running the tool from an image based on the newest distribution release. Will that work?

AYes, because the container boots the kernel that ships with the newer distribution

Incorrect — Containers boot nothing. A kernel package in an image is only files; the process runs on the host kernel.

BYes, provided the image is pulled for the same CPU architecture as the host

Incorrect — The right architecture lets the binaries run, but they still make system calls into the host kernel, which lacks the feature.

CNo; the image brings its own userland, but the kernel is still the host's

Correct — uname -sr inside any container prints the host kernel. Run the tool on a host or VM that has the newer kernel.

DNo, because a container must use the same distribution as its host

Incorrect — The lab runs Alpine containers on an Ubuntu VM. The distribution can differ; the kernel cannot.

06For a running container lab-idle, ps on the VM shows sleep 600 as PID 117155, owned by root, while docker exec lab-idle ps shows the same sleep 600 as PID 1. Why the two numbers?

AThe container has a PID namespace with its own numbering

Correct — The process is an ordinary host process; inside its PID namespace it is PID 1 and sees a much shorter process list.

BDocker started two copies of the command, one on the VM and one in the container

Incorrect — There is one process. The host PID came from docker inspect for the same container.

CThe container is a small VM, and PID 1 belongs to its guest kernel's process table

Incorrect — There is no guest kernel. Both views come from the same host kernel through different namespaces.

Ddocker exec shows a saved snapshot of the process list from when it started

Incorrect — ps inside the container reads the live list; it even showed itself as a new process.

07docker stats --no-stream lab-idle shows 584KiB / 5.76GiB under MEM USAGE / LIMIT. You never set a memory limit. What is the 5.76GiB?

AA default limit of about 6 GB that Docker applies to every container it starts

Incorrect — Docker sets no default memory limit. The figure follows the machine it runs on.

BMemory reserved for the container at start that other processes cannot use

Incorrect — Nothing is reserved. The container uses under 600 KiB and the rest stays free for everything else.

CThe size of the alpine image, unpacked into memory when the container started

Incorrect — The alpine image is 13.4 MB on disk, and images are not loaded into memory as a whole.

DAll of the VM's memory, because this container has no limit

Correct — Without a limit the container may use whatever the host has, so docker stats shows the host total.

08A security advisory names the OpenSSL version inside node:24-alpine, which your service has used for months. How does the fix reach the running service?

ADocker patches the libraries in running containers once the base image is updated

Incorrect — An image freezes its contents, and Docker never changes running containers. Nothing happens until you act.

BPull or rebuild on a newer image, then replace the container

Correct — Fixes arrive as a newer image, and only a new container started from it runs the fixed library.

CRun apk upgrade in the container with docker exec and leave it running

Incorrect — That change lives in the writable layer and is lost the next time the container is replaced from the image.

DUpgrade OpenSSL on the host, since containers load the host's libraries

Incorrect — Containers share the host kernel, not its libraries. The OpenSSL in the image is its own copy.

8 questions · explanations appear as you answer

Working with containers

11 questions

01Yesterday you stopped lab-web with docker stop. Today docker run -d --name lab-web nginx:1.30-alpine fails with Conflict. The container name "/lab-web" is already in use. You want the old container back, files and all. What do you run?

Adocker run -d --rm --name lab-web nginx:1.30-alpine, so the name is freed later

Incorrect — --rm does not touch the existing container, so the name is still taken, and a new container would start from a clean writable layer anyway.

Bdocker rm lab-web, then the same docker run command again

Incorrect — That frees the name, but docker rm deletes the writable layer, which holds the files you wanted to keep.

Cdocker start lab-web, which reuses the stopped container

Correct — docker start runs the existing container again from its own writable layer, as the marker file in the lab showed.

Ddocker pull nginx:1.30-alpine, so that the run can make a fresh copy

Incorrect — Pulling affects the image, not the container. The name clash stays exactly as it was.

02docker ps is empty, yet docker rmi nginx:1.30-alpine fails with container cc2929c71cc1 is using its referenced image. What is going on?

AA stopped container still uses the image; docker ps -a shows it

Correct — Docker will not delete an image that any container uses, running or stopped. Remove the containers first, then the image.

BThe image is still being pulled in the background and stays locked until it ends

Incorrect — No pull is running. The message names a container ID, not a download.

CA second tag points at the same image, so it can only be untagged, not deleted

Incorrect — A second tag makes rmi print Untagged and keep the content. It does not cause a container conflict.

DDocker keeps a copy of each removed container inside the image until a reboot

Incorrect — Containers are not stored inside images. The conflict is with a real container that still exists.

03You run docker tag nginx:1.30-alpine lab-nginx:mine, and later docker rmi lab-nginx:mine prints only Untagged: lab-nginx:mine. How much disk space did that free?

AAbout 92.9MB, the DISK USAGE that docker image ls showed for that tag

Incorrect — Those 92.9MB belong to content that nginx:1.30-alpine still references, so they stay.

BAbout 26.9MB, the compressed CONTENT SIZE of the copy docker tag made

Incorrect — docker tag made no copy. Both names showed the same image ID.

CHalf of the image, because the two tags were sharing its layers

Incorrect — Layers are not split between tags. The content stays whole while any name points to it.

DNone, because the other tag still points at the same content

Correct — Docker deletes content, and prints Deleted: sha256:..., only when the last reference goes.

04A CI step runs docker run --name migrate myapp:3 ./migrate.sh, and the shell reports exit status 125. Which part failed?

AThe script started and was then killed by a signal from the host

Incorrect — A kill by a signal gives 128 plus the signal number, such as 137 or 143.

BThe docker command itself, for example a name already in use

Correct — 125 is the code for a failure of docker itself, as with the name clash in the lab; the script never ran.

CThe script exists in the image but could not be executed

Incorrect — That is 126: the command exists but cannot be executed.

DThe script was not found in the image's filesystem or $PATH

Incorrect — That is 127. The container is created, but its process never starts.

05docker ps shows an nginx container as Up with 127.0.0.1:8083->8080/tcp, and curl http://127.0.0.1:8083/ fails with Recv failure: Connection reset by peer. What fixes it?

APublish on every address with -p 8083:8080, since loopback blocks the forward

Incorrect — Publishing on loopback works; the lab served nginx on 127.0.0.1:8080. The problem is the container side of the mapping.

BRestart the container, because nginx was still starting when curl connected

Incorrect — nginx starts in well under a second, and it never listens on 8080 however long you wait.

CRecreate it with -p 127.0.0.1:8083:80, the port nginx listens on

Correct — The right-hand number must be the port the program inside listens on, and nginx listens on 80.

DAllow host port 8083 in the host firewall so that the reply can get back

Incorrect — The connection to the host port succeeded. The reset came from the forward into the container, where nothing listened on 8080.

06A container runs sh -c 'echo started; exit 1' with --restart on-failure:3. A minute later, how many started lines does docker logs show?

AFour: the first run, then three restarts before it gives up

Correct — The daemon restarted it three times, then gave up and left it exited with status 1.

BThree, because the limit counts every run, the first one included

Incorrect — The limit counts restarts. The first start is not a restart, so there is one more line.

COne, because docker logs keeps only the output of the latest run

Incorrect — The log keeps the output of every run of the same container; the lab showed four lines.

DA growing number, as the daemon retries forever with a doubling delay

Incorrect — That describes always or unless-stopped. on-failure:3 stops after three restarts.

07docker logs web | grep -c error prints a pile of lines containing error straight to the terminal and then 0. What is happening?

Agrep counts only the lines that Docker stored with a timestamp

Incorrect — grep does not care about timestamps. It never received those lines.

Bdocker logs pages its output, so the pipe only gets the first page

Incorrect — docker logs does not page. It replays the whole log unless you use --tail.

CThe log was rotated, and grep is reading an empty older file

Incorrect — There is no rotation by default, and the lines did print, just not through grep.

DThey came from stderr, which skips the pipe; add 2>&1

Correct — docker logs keeps the container's stdout and stderr apart, and a plain pipe carries only stdout.

08A busy host keeps running out of disk. For its chattiest container, docker inspect -f '{{.HostConfig.LogConfig.Type}} {{.HostConfig.LogConfig.Config}}' app prints json-file map[]. What does that tell you?

ALogging is switched off, so the disk use must be coming from somewhere else

Incorrect — json-file is the default driver and it is on: every line the container prints is stored.

BIts log is one JSON file with no size limit and no rotation

Correct — With no options the file under /var/lib/docker/containers/<id>/ grows until the container is removed.

CLogs go to the systemd journal, which rotates them at its own size limit

Incorrect — That would be a different driver. json-file writes a file per container under Docker's data directory.

DThe container writes its log into its own writable layer under /var/log

Incorrect — Docker captures stdout and stderr outside the container, in a root-owned file on the host.

09A CI job runs docker run --rm -e API_URL myimg:2, but the job's environment never defines API_URL. What does the program in the container see?

AAPI_URL set to an empty string, because -e always creates the name

Incorrect — An empty value needs -e API_URL=. With a bare name and nothing to copy, Docker leaves the variable out.

BThe literal text API_URL as its value, taken from the command line

Incorrect — A bare name means "copy the value from my environment", not "use the name as the value".

CNo API_URL variable at all; the name is left out

Correct — -e NAME copies the value from the docker command's environment, and here there is nothing to copy.

DAn error from docker run with status 125 before anything starts

Incorrect — Docker accepts the flag. It has nothing to copy, so the container starts without the variable.

10You change LOG_LEVEL in app.env and run docker restart app, but the app still logs at the old level, and docker inspect -f '{{json .Config.Env}}' app shows the old value. What do you do?

ARemove the container and create a new one with the edited file

Correct — The environment is fixed when the container is created; restarting reuses it.

BRun docker restart --env-file app.env app so the restart reads the file

Incorrect — docker restart takes no env file. Changing a value means starting a new container.

CUse docker start app instead, which reads the env file again on start

Incorrect — docker start reuses the stored configuration just as restart does. Neither reads the file.

DRebuild the image, since env-file values are copied into it at run time

Incorrect — Run-time values never go into the image. They are stored in the container's configuration.

11Someone with access only to the Docker host, not to the application, recovers the production database password in a minute. The container was started with -e DB_PASSWORD=.... How, and what is the better pattern?

AFrom shell history; passing it through --env-file would have kept it hidden

Incorrect — History is one leak, but an env file ends up in the same container configuration that docker inspect prints.

BFrom the image layers; a build-time ENV line would have kept it out of sight

Incorrect — An ENV value in the image is readable by anyone who has the image, with docker image inspect.

CBy sniffing the bridge network; binding to 127.0.0.1 would have stopped it

Incorrect — No network access was needed. The value is stored in plain text in the container's configuration.

Ddocker inspect shows it; mount it as a file and use a _FILE variable

Correct — Environment variables are readable by anyone who can inspect the container. Images such as postgres read the secret from a file named in a _FILE variable.

11 questions · explanations appear as you answer

Building your own images

8 questions

01A Dockerfile ends with CMD ["node", "app.js"], but the file in the image is server.js. What happens when you build the image and run it?

AThe build stops at the CMD step with Cannot find module '/app/app.js'

Incorrect — Docker does not check what CMD refers to. The build only records it in the image configuration.

BThe build succeeds; the container exits with 1 and its log names the file

Correct — Node starts, fails to load /app/app.js and exits with status 1. docker ps -a and docker logs show it.

CThe build succeeds, and docker run fails with status 127 before Node starts

Incorrect — 127 would mean node itself is missing. It exists, so it starts and then fails on the missing module.

DThe container stays up and answers every HTTP request with a 404 page

Incorrect — Node never gets as far as listening; it exits as soon as it cannot load the module.

02The image lab-hello:2, already pushed to the team registry, turns out to contain .env with a real API token. You add .env to .dockerignore and push a rebuilt image. What else is needed?

ANothing, because the rebuilt image overwrites the old layers in the registry

Incorrect — The old image and its layers stay in the registry and on every host that pulled them.

BAdd a final RUN rm .env to the old Dockerfile and push that image as well

Incorrect — A later delete only hides the file. The layer that added it still holds it.

CRotate the token, because every copy of the old image still holds it

Correct — A secret that reached a layer is in the local store, the registry and every host that pulled the image. Rebuilding does not recall those copies. Also delete the old tag and manifest from the registry so no new host pulls it.

DRun docker builder prune so that the build cache forgets the token

Incorrect — That clears the local build cache only. The copies in the registry and on other hosts are untouched.

03docker image ls lab-hello shows DISK USAGE 249MB and CONTENT SIZE 64MB. Roughly how much does a push of this image to an empty registry transfer?

AAbout 64MB, the compressed size of its layers

Correct — CONTENT SIZE is the compressed size of the layers, close to what a push or pull transfers.

BAbout 249MB, since a registry stores images unpacked

Incorrect — Registries store compressed layers. DISK USAGE is the unpacked size on this host.

CAbout 185MB, the difference between the two numbers

Incorrect — The difference has no meaning of its own; no transfer sends it.

DOnly the layers from your own instructions, since the base is on Docker Hub

Incorrect — An empty registry has none of the layers, so the base layers are sent too.

04A Dockerfile has RUN apt-get update && apt-get install -y curl near the top. Months later a rebuild still installs the same old curl, although newer packages exist. Why?

Aapt-get writes a lockfile into the image that pins the first versions it saw

Incorrect — There is no such lockfile. The step did not run at all; its cached result was reused.

BThe base image blocks package updates until you pull a newer copy of it

Incorrect — The base image does not block apt. A fresh run of the step would fetch new package lists.

CBuildKit asked the package mirror and found no change in the version number

Incorrect — BuildKit never looks at what a RUN step would download.

DThe step's cache key is its command text, which has not changed

Correct — Nothing below it changed, so BuildKit reused the old result. Use --no-cache, and --pull for a newer base, when you want fresh packages.

05A Python service's Dockerfile runs COPY . . and then RUN pip install -r requirements.txt. Every code change reinstalls all packages. Which order keeps the install cached when only code changes?

ARUN pip install -r requirements.txt first, then COPY . .

Incorrect — The install needs requirements.txt, which is not in the image yet at that point.

BCOPY requirements.txt ., the install, then COPY . .

Correct — The install now depends only on requirements.txt, so a code change reruns just the last copy.

CCOPY . . twice in a row, so that the second copy hits the cache

Incorrect — The first copy still changes with every edit, so every step after it runs again.

DKeep the order and build with --no-cache so pip skips what it has

Incorrect — --no-cache makes BuildKit rerun every step, which is the opposite of what you want.

06docker history lab-layers:1 shows <missing> in the IMAGE column for every row except the top one. Should you worry?

AYes, the base image was only partly downloaded and should be pulled again

Incorrect — The image runs and every row has a size. The column is about IDs, not content.

BYes, garbage collection removed those layers and the image is now broken

Incorrect — Removed layers would make the image unusable. These are present; their sizes are listed.

CNo, those intermediate layers simply have no image ID of their own

Correct — <missing> is not an error. Only the top row is an image with its own ID.

DNo, it means those layers are kept on Docker Hub and fetched when needed

Incorrect — All the layers are stored locally. <missing> says nothing about where they came from.

07An image has ENTRYPOINT ["echo", "greeting:"] and CMD ["hello", "world"]. docker run --rm --entrypoint echo myimg prints an empty line. Why not hello world?

A--entrypoint needs the program and its arguments together inside quotes

Incorrect — --entrypoint takes the program only; its arguments go after the image name.

BBusyBox echo ignores arguments that come from the image configuration

Incorrect — echo prints whatever arguments it receives. It received none.

CThe CMD values were appended to the old entrypoint, which did not run

Incorrect — Nothing is appended to a replaced entrypoint. The new program runs alone.

DReplacing the entrypoint also drops the image's CMD

Correct — Only arguments you pass after the image name reach the new entrypoint; new args would have printed.

08Your start script writes a config file and then starts the server. Why should its last line be exec my-server "$@" and not just my-server "$@"?

Aexec replaces the shell, so the server becomes PID 1 and gets SIGTERM

Correct — Without exec the shell usually stays PID 1 (it depends on the shell), and a shell without a handler ignores the stop signal, so the server never sees it. exec makes the server PID 1 with every shell.

BWithout exec the shell does not pass the arguments on, so "$@" is empty

Incorrect — "$@" expands the same way with or without exec. The difference is which process ends up as PID 1.

Cexec makes Docker check at build time that the server binary exists

Incorrect — Docker checks nothing about the programs a container will run at build time.

Dexec runs the server in the background so the script can exit and free memory

Incorrect — exec runs nothing in the background. The server takes over the script's process.

8 questions · explanations appear as you answer

Data, networking & Compose

11 questions

01A container writes reports into a bind-mounted ./out directory. On the host, ls -ln out shows the new files owned by 0 0, and your account cannot edit them. Why?

ABind mounts give every file to root, whichever user writes it

Incorrect — Files keep the numeric IDs of the writing process. In the lab, a container run with --user "$(id -u):$(id -g)" produced a file owned by 1000.

BThe process ran as root, and files keep the writer's numeric IDs

Correct — Run the container with --user "$(id -u):$(id -g)", or compare docker exec <name> id with ls -ln when permissions go wrong.

CThe daemon copies the files out of the container as root when it exits

Incorrect — Nothing is copied. A bind mount is the host directory itself, written directly.

DThe host does not know the user names in the image, so it falls back to root

Incorrect — The host shows numbers, not a fallback. A process running as 1000 produces files owned by 1000.

02A batch container writes large temporary files to /scratch, and they should never land in its writable layer or in any volume. Which option fits, and what is its catch?

A-v scratch:/scratch; Docker deletes that volume when the job exits

Incorrect — That creates a named volume, which stays until you remove it explicitly.

B--mount type=bind,src=/tmp,dst=/scratch; the files go when the job ends

Incorrect — A bind mount writes into a host directory. The files land on disk and stay there.

C--tmpfs /scratch; its contents count toward the container's memory

Correct — A tmpfs is memory-backed and empty on each start. Under memory pressure the kernel can still swap it to disk.

D-v "$PWD/scratch":/scratch:ro, which keeps every write in memory

Incorrect — Read-only refuses writes with Read-only file system; it does not redirect them anywhere.

03After docker rm -f on every container that used it, docker volume ls still lists lab-notes. Why?

AVolumes outlive containers and need an explicit command to remove

Correct — docker volume rm (or docker volume prune) removes a volume; removing containers never does.

BDocker keeps a volume for 24 hours in case its container is recreated

Incorrect — There is no timer. The volume stays until you remove it.

C-f stopped the containers but left them on disk, so it is still in use

Incorrect — docker rm -f removes the containers; it only kills them first if they are running.

DThe volume belongs to the alpine image and stays as long as the image does

Incorrect — Volumes are separate from images. lab-notes was created with docker volume create.

04docker run -d --network host -p 8082:80 myweb prints WARNING: Published ports are discarded when using host network mode. What does that mean for the server inside?

AIt stays unreachable from outside until you switch to --network none

Incorrect — none leaves only a loopback interface, which makes it less reachable, not more.

BDocker picked a random host port in place of 8082, and docker port shows it

Incorrect — In host mode no port is mapped at all, random or otherwise.

CIt listens on 8082 in its own namespace and needs a bridge to reach the host

Incorrect — With host networking there is no separate network stack; the container uses the host's interfaces.

DIt listens on the host's own interfaces, on the port it opens itself

Correct — The container's ports are already the host's ports, so -p has nothing to do. Port clashes with other host programs become possible.

05On one laptop, a container cannot reach a company server at 172.18.4.20 while the VPN is connected, although the laptop itself can. Other machines are fine. What is the usual cause?

AThe VPN client is missing from the image and has to be installed in it

Incorrect — The host already reaches the server. The trouble is that the same address range exists on both sides.

BA Docker network uses the same 172.18 range, so the traffic stays in Docker

Correct — Docker takes subnets from its default pools. Give it other ranges with default-address-pools.

CThe embedded DNS server at 127.0.0.11 cannot answer queries for IP addresses

Incorrect — No name is involved; the address is used directly.

DThe company server must publish its port with -p before a container connects

Incorrect — Publishing is for traffic into containers. The company server is not a container.

06A container on the user-defined network lab-net has nameserver 127.0.0.11 in its /etc/resolv.conf. How does it resolve a public name such as a package mirror?

AIt cannot; on a user-defined network only container names can be resolved

Incorrect — Containers on such networks resolve public names fine. Names that are not containers are passed on.

BDocker copies the public DNS records it needs into the container's /etc/hosts

Incorrect — Nothing is copied. Queries go to 127.0.0.11 and are answered or forwarded as they come.

CThe embedded DNS forwards it to the host's resolver, shown as ExtServers

Correct — Container names are answered locally; everything else goes to the resolver listed in the generated file.

D127.0.0.11 is a public DNS service run by Docker that answers every name

Incorrect — 127.0.0.11 is a loopback address inside the container, served by the local engine.

07On a new server without a .env file, docker compose up -d stops with required variable POSTGRES_PASSWORD is missing a value: set POSTGRES_PASSWORD in .env. What has Compose created so far?

AThe network and the volume but no containers, so the next up reuses them

Incorrect — Interpolation fails while the file is read, before any resource exists.

BThe db container with an empty password, which it then stopped again

Incorrect — Compose never got that far. A blank value is what plain ${POSTGRES_PASSWORD} would have given.

CEvery service, with the password set to the text of the error message

Incorrect — The text after :? is the error message, never a value.

DNothing; the :? form fails before Compose creates anything

Correct — ${POSTGRES_PASSWORD:?...} marks the variable as required, and Compose exits with the message from the file.

08A project's .env file contains DEBUG=true, but compose.yaml never mentions DEBUG. The app in the container reports that DEBUG is unset. Why?

A.env only feeds ${...} interpolation inside the Compose file

Correct — Reference it in the file, or list it under environment: or env_file:, and it reaches the service.

BThe value has no quotes, and Compose passes only quoted values to containers

Incorrect — Compose accepts unquoted values and even strips quotes. The variable was never referenced.

CThe shell environment wins over .env, and the shell has DEBUG unset

Incorrect — An unset shell variable overrides nothing. Compose looks in the shell first, then in .env.

DVariables in .env are passed only to the first service in the file

Incorrect — There is no per-service rule. .env reaches no container unless the file references it.

09A team's Postgres health check is pg_isready -U app -d app, with no -h. On a fresh volume, db turns healthy, yet web still fails once with ECONNREFUSED. What explains it?

AThe check needs start_period: 0s so that it runs right after the start

Incorrect — The start period changes when failures count, not what the check tests.

BFirst init runs a socket-only server, and a check without -h passes on it

Correct — The temporary init server has TCP off, so a socket check can pass early. Check over TCP with -h 127.0.0.1.

CHealth checks run on the host, so they cannot see the database in the container

Incorrect — Docker runs the health check command inside the container.

Dservice_healthy waits for the first check to run, not for one to pass

Incorrect — Compose waits for the healthy state, which needs a passing check. The check itself was too weak.

10A teammate runs docker push acme/api:1.0, expecting it to go to the company registry at registry.example.com. Where does Docker send it?

ATo registry.example.com, the registry saved in the teammate's config.json

Incorrect — config.json records logins per registry. It does not change where a name without a registry part points.

BTo localhost:5000, the default for names that have no registry address

Incorrect — A local registry has to be named in the reference, as in localhost:5000/lab-notes:1.0.

CTo Docker Hub, as docker.io/acme/api:1.0, since acme is not a host name

Correct — A first component without a dot, colon or localhost is a namespace on Docker Hub. Tag it registry.example.com/acme/api:1.0.

DTo whichever registry the base image of acme/api was originally pulled from

Incorrect — The base image plays no part. The name alone decides where a push goes.

11You are logged in to the company registry, and docker push ends with denied rather than no basic auth credentials. What does that point to?

AThe registry knows who you are but refuses that repository

Correct — Usually a wrong namespace, or an account without push rights on it.

BYour credentials were never sent, so log in again with --password-stdin

Incorrect — Missing credentials give no basic auth credentials. denied means you were recognised and the action was refused.

CDocker Hub's pull limit was reached, so every further request is refused

Incorrect — The pull limit answers 429 Too Many Requests, and this is a push to another registry.

DThe image is larger than the registry accepts and must be pushed in parts

Incorrect — The message is an authorization answer; size has nothing to do with it.

11 questions · explanations appear as you answer