Docker Practice Questions: Build, Inspect, Explain

This page contains original technical exercises, not a set of reported Docker interview questions and not a hiring or salary guide. The Docker documentation is the public technical source to consult when a command or behaviour matters. Read the documentation version that matches the tool you are using, because a local configuration can change the result of an example. The prompts below do not claim how often a question appears, what an employer tests, or what a role pays.

Explain the image and container boundary

Start with a plain-language explanation of the difference between an image and a running container. Then choose a tiny program with one dependency and write down what belongs in the build instructions, what belongs in configuration, and what should not be placed in the image at all.

Your answer should include a way to test the result. For example, describe how you would confirm which files reached the build context and how you would see the program's output. Do not assume a tag refers to the same bytes forever; identify the version or digest you intended to use when reproducibility matters.

Trace a failed build from evidence

Imagine a build fails because a file expected by a copy instruction is unavailable. Before changing the instruction, inspect the build context and any ignore rules. State the observation that would confirm the file is excluded, and the narrow change that would restore it without adding unrelated files.

This is a useful debugging pattern: locate the boundary, observe it, change one thing, and test again. It is stronger than responding to a build error by widening the context blindly.

Design configuration without leaking a secret

Take a service that needs a database address and an access value. Describe how you would keep non-sensitive configuration visible while avoiding hard-coding a secret into an image, a repository, or a command history. Explain the difference between a local convenience setting and a production-safe secret-handling method.

When you write a sample configuration, use placeholders. A real credential should be supplied through an approved runtime mechanism and should never be copied into a tutorial, a source tree, or a screen recording.

Investigate a networking question

Suppose a process works inside a container but cannot be reached from a browser. List the checks in order: whether the process is listening, what address it binds to, how the port is published, and whether the request reaches the expected host. For each check, say what result would move you to the next one.

The prompt teaches a diagnostic chain, not a memorised command. A clear explanation will also mention what information is unknown, such as an external firewall rule or the runtime environment.

Review a Dockerfile as a change set

Read a Dockerfile and ask which instruction invalidates later build layers, which files are copied earlier than necessary, and whether the final image contains development material that is not needed to run the program. Suggest one change, state its expected effect, and describe how you would verify that effect.

Avoid promising a speed improvement or image-size reduction without measurement. If you measure it, record the command, environment, and before-and-after values so another person can reproduce the claim.