Scenario-Based Docker Interview Questions

“My laptop keeps its layer cache between builds, but a CI runner is usually brand new every job, so it has nothing to reuse and runs every step from scratch. First I'd check the Dockerfile order, because if the code is copied before the dependency install, even a warm cache gets thrown away on every commit. If the order is fine, I'd give CI a cache it can carry between jobs. With BuildKit I can push the cache to the registry with cache-to and pull it back with cache-from, using mode max so the intermediate stages are kept too. Most CI systems also have their own cache store that BuildKit can use. I'd compare build times before and after on a commit that changes only code. If it's still slow, I'd look at whether the lockfile changes on every commit.”

“COPY can only see files inside the build context, so I'd start there. I'd check the last argument of the build command. If CI runs the build with the docker folder as the context but the file lives at the repo root, it's simply not in what Docker was sent. Next I'd open .dockerignore, because a broad pattern like a wildcard that excludes everything, or one that ignores a whole config folder, silently removes the file. Then I'd check whether the path climbs out with dot-dot, which COPY never allows. The sneaky one is letter case: my Mac's file system usually ignores case, so Config.json and config.json look the same locally, but the Linux CI runner treats them as different files. If it only fails in CI, that's where I'd look first.”

“When the script is clearly there, the missing file is almost always the interpreter named on its first line. I'd run the image with a shell and look. If the first line says bin bash and the base is Alpine, there's no bash, so exec fails with exactly this message. The other classic cause is Windows line endings. If someone edited the script on Windows or git converted it, the first line ends with a carriage return, and the kernel goes looking for a program called sh with that invisible character stuck on the end. Printing the first line through od -c shows a backslash r just before the newline. I'd fix it by converting the file to LF, and add a gitattributes rule so shell scripts always check out with LF, which stops it coming back on the next Windows laptop.”

“Alpine is small because it uses musl instead of glibc. For Python that matters, because many packages with native code publish ready-made wheels built against glibc. If there's no musl wheel for a package, pip downloads the source and compiles it, so I suddenly need compilers in the image and the build crawls. The runtime crash fits too: native libraries built or tuned for glibc can behave differently on musl, and some only get tested on glibc. I'd check the pip log to see which packages built from source. Then I'd usually switch to the slim Python image. It's a bit bigger than Alpine but installs the normal wheels in seconds, and with a multi-stage build the final image often ends up about the same size. I'd judge the switch by final size and build time together.”

“If the repo didn't change, something outside it did, so I'd list the inputs that come from the network. First the base image: a tag isn't fixed, and it may have moved to a new patch release or a newer OS overnight. I'd compare the digest yesterday's build resolved with today's, from the build logs or by inspecting both images. Next, unpinned package installs. An apt-get install without versions, or pip and npm without a lockfile, can quietly pull a newer library. I'd diff the installed package lists from the two images. Then anything downloaded by URL. Once I find the change, I'd pin it. The base goes by digest with a tool that opens a pull request to bump it, so updates still arrive but they're tested and reviewed instead of landing by surprise.”

“First I'd get the space back without breaking anything, then stop it happening again. I'd run docker system df to see the split between images, containers, volumes and build cache. On servers the surprise is often logs. The default json-file driver keeps every line forever unless you set rotation, so I'd check the log files under the containers folder and find the chatty one. Stopped containers, dangling images and old build cache are usually safe to prune. I'd not prune volumes on a whim, because that's where databases keep their data. For the lasting fix I'd set max-size and max-file for logs in the daemon config, knowing it applies only to containers created after the change, so running ones need recreating. I'd also add a disk alert that fires well before the disk is full.”

“The container's health state records the last few checks with their output, so I'd read that before guessing. docker inspect on the container shows the Health section. Very often the output says curl isn't found. The check was copied from an example, but our slim or distroless image doesn't include curl, so the check fails every time even though the app is fine. Other things I'd look for: a timeout shorter than the endpoint needs, no start period for an app that takes a while to warm up, or the check hitting a different port than the app listens on inside the container. The fix depends on the cause. For the missing tool, I'd rather add a tiny health command built into the app than install curl just for the check, especially on a distroless image with no shell.”

“Averages hide this. A CPU limit isn't a smooth speed cap. The kernel gives the container a quota of CPU time per short period, usually 100 milliseconds. If the service has eight busy threads, a limit of one CPU is used up in about twelve milliseconds, and then every thread waits for the rest of the period. Requests caught in that wait get slow, even though the average over a minute looks low. Some runtimes also size their thread pools from the host's core count, not the limit, which makes it worse. I'd confirm by reading cpu.stat in the container's cgroup: rising throttled counts and time line up with the spikes. Then I'd size the thread pools to the limit, raise the limit, or for latency-sensitive services remove the hard limit and use CPU shares so they can burst when the host has room.”

“I like that the job reuses our image, but I'd not put cron inside the web container. First, scaling: the moment we run three copies of the app, the cleanup runs three times a night, which might be harmless or might double-delete things. Second, the container now has two processes, so something has to supervise them. If cron dies, the web server keeps the container looking healthy and no one notices. Third, cron itself is awkward in containers. Jobs start with a very small environment, so they may not see our config variables, and their output often goes nowhere. Instead I'd run the same image with a different command, like a cleanup script, as its own container started on a schedule. That could be a scheduled job in our cluster, or a timer on the host. It then logs and fails visibly.”

“A bind mount shares the real host folder, and permissions are checked by numeric user ID, not by name. So if my app runs as user 1000 inside the container but the host folder belongs to user 1001, it's a stranger to that folder. A common twist is that the host path didn't exist, so Docker created it, and it's owned by root. I'd compare the output of id inside the container with ls -ln on the host folder. In development I'd usually run the container with my own user and group IDs so files come out owned by me. On a server I'd change the folder's owner to the container's user, or switch to a named volume, which Docker creates for me. If the IDs match and it still fails on a Fedora or RHEL host, I'd suspect SELinux and try the z label.”

“The image did install node_modules into /app during the build. But when I mount my project folder over /app, the mount hides everything the image had there, and my laptop's folder either has no node_modules or has ones built for macOS, which breaks native modules on Linux. So the app starts and can't find its packages. The usual fix in Compose is to add a second volume just for /app/node_modules. That path then isn't covered by my source mount, and it gets filled from the image. The catch is that this volume sticks around, so after I add a package and rebuild, the container can still see the old modules. I'd rebuild with the option that renews anonymous volumes, or remove that volume. Another option is installing packages outside /app entirely.”

“The Postgres image does its setup once. When the container starts, it checks whether the data folder is empty. Only then does it create the database, set the password from the environment and run the scripts in the init folder. My data lives in a volume that survived the restart, so the image saw an existing database and skipped all of that. The password variable is ignored after the first run, which is why the new one fails. On my laptop with throwaway data, I'd bring the stack down with its volumes and start again. On a shared environment I'd never do that. I'd change the password with an ALTER USER statement and run schema changes through a proper migration tool, so they apply to databases that already exist.”

“First, get the app back. The new container refused to start, so it shouldn't have touched the data. I'd put the old image tag back and start it, then check the app works. Then I'd explain the cause: a new major Postgres version can't open the old version's data files, so swapping the image is never enough. For the real upgrade I'd take a backup, then pick a method. For a small database, dumping from the old version and restoring into a new one on a fresh volume is simple and safe. For a large one, pg_upgrade is much faster but needs both versions' binaries. If downtime has to be tiny, logical replication to the new version and a quick switch works. Whatever I choose, I'd rehearse it on a copy of the volume and keep the old volume until the new one is proven.”

“The fact that it works from inside the container tells me the app runs fine, so it's about where it listens. Each container has its own network stack, and localhost inside it means only that container. When I publish a port, Docker forwards traffic to the container's own network interface, not to its loopback. If the app bound to 127.0.0.1, that forwarded traffic finds nothing listening and the connection gets reset. I'd confirm with ss -ltn inside the container: if it shows 127.0.0.1:8080 instead of 0.0.0.0:8080, that's it. The fix is to make the app listen on 0.0.0.0, usually a host flag or setting. Flask's dev server and several front-end dev servers default to localhost, so this bites a lot of people. I'd also double-check the mapping points at the port the app really uses.”

“Docker writes its own iptables rules. When a port is published, traffic to it is redirected and forwarded to the container, so it never passes through the input rules that tools like ufw manage. The firewall looks closed but the port is open. I'd treat it as an incident. First I'd stop the exposure by removing the port mapping or binding it to 127.0.0.1 only, then check Redis for a password, strange keys or changed config, since an open Redis gets found fast. The better design is not to publish it at all. The app reaches Redis by service name over a private Docker network. If I really need host-level filtering for published ports, it goes in the DOCKER-USER chain, which Docker leaves alone. Then I'd scan from outside to prove it's closed, and add that scan to our checks.”

“The timing is the clue. Docker's default bridge network takes 172.17.0.0/16, and the service lives in that same range. Once Docker starts, the host has a route saying everything in 172.17 lives on the docker0 bridge, so packets for the internal service go into Docker instead of out to the real network. I'd confirm with ip route, and ip route get on the service's address would show docker0. The fix is to give Docker ranges nobody on the company network uses. In the daemon config I'd set bip for the default bridge and default-address-pools for the networks Compose and users create, then restart Docker and recreate the networks. I'd check with the network team which ranges are free, and put the same config on every Docker host so it doesn't happen elsewhere.”

“Something already listens on host port 5432, so I'd find out what. First docker ps, filtered by the published port, to see if a container holds it. Often it's a leftover from another project, or the same project cloned into a second folder. Compose names projects after the folder by default, so the two copies don't see each other's containers. If no container shows up, I'd run ss -ltnp or lsof on the port, because a Postgres installed straight on my machine is a common culprit. Then I decide. If it's something I don't need, I stop it. If I need both, I change our mapping to 5433:5432, since only the host side has to be unique, and point my local tools at 5433. Inside the Compose network the app still uses 5432.”

“A container's environment is fixed when the container is created. docker compose restart just stops and starts that same container, so it keeps the old values. I'd run docker compose up -d instead. Compose compares the current config with what the container was created from, sees the change and recreates it. To be sure, I'd check two places. docker compose config shows what Compose resolves from the .env file, which catches typos or a shell variable overriding the file. Then docker exec with env shows what the running container actually has. If both look right and the app still shows the old value, the value may be baked into the image through ARG or ENV in the Dockerfile, or the app caches its config, and that needs a rebuild or an app restart of its own.”

“The token has been public for a month, so I'd assume someone has it. Step one is to revoke it and issue a new one, before any cleanup, because deleting the image doesn't un-leak anything. Anyone who pulled it can read build args from the image history. Next I'd check the package registry's logs for that token to see if anyone else used it, and tell the security team. Then I'd remove the image tags from the public registry, and make the repo private if it was never meant to be public. Finally I'd fix the build. With BuildKit I'd pass the token as a secret mount on the one RUN step that needs it. It's available during that step and never written into a layer or the history. I'd also add secret scanning on images in CI.”

“I'd agree with the review. The Docker socket is the full Docker API. Anything that can send requests to it can start a new container with privileged mode and the host's root folder mounted, which is root on the host. The read-only flag on the mount doesn't help, because it only stops changes to the socket file itself. Requests through it still work. So if that agent or its image were ever compromised, the whole server goes with it. I'd first ask what the agent needs. Usually it's listing containers and reading stats. A small socket proxy that allows only those read endpoints cuts the risk a lot. Some agents can read metrics from the cgroup files instead. If we truly must keep the socket, I'd pin the agent image by digest and write the risk down with an owner.”

“I'd not just say no, because they have a deadline. I'd explain the cost in one line: privileged mode gives the container nearly everything the host's root user has, including every device, so a bug in it becomes a problem for the whole machine. Then I'd sit with them and run it without the flag to see what actually fails. Most of the time it's one thing. A VPN or network tool needs the NET_ADMIN capability, or something needs a single device like a USB serial port. I'd add just that capability or device and test again. That usually takes less than an hour. If it truly can't be narrowed today, I'd agree to ship on isolated hosts only, with a ticket and a date to fix it, rather than letting privileged mode quietly become normal.”

“The tag moved, but the old image may still exist under its digest, so I'd hunt for that first. Our deploy or CI logs often print the digest that was pushed. If not, a server that ran the old version may still have it locally, and docker images with the digests option shows it. Many registries also keep the untagged manifest until garbage collection runs. Once I have the digest, I deploy by digest, which points at exactly that image whatever happens to tags. If nothing turns up, I'd rebuild from the last good commit. That gets us close, but base images and packages may have moved, so I'd watch it closely. Afterwards I'd push for every build getting a unique tag like the commit hash, turn on tag immutability in the registry, and have deploys record the digest.”

“That error is Docker Hub's pull rate limit. Anonymous pulls are counted per IP address, and our CI runners probably share one outbound address, so in busy hours they use up the allowance together and the unlucky jobs fail. That explains why it looks random. The quick fix is to log in to Docker Hub in CI so pulls count against an account, which has a higher limit. The better fix is to stop pulling from the public hub on every job. I'd set up a pull-through cache or mirror, or copy the base images we use into our own registry and point our Dockerfiles at those. That also helps if the hub is down, and we control when a base image changes. I'd make the job log which registry each image came from, so it's clear in future.”