Technical interviews are tough. You’re expected to know the answer to any question asked at any time. Provide a wrong answer and you’ll get the standard, “Thanks for coming in, we’ll get back to you.”

The experience can be even more trying when the interview is about a complex technology. Docker is one such technology.

Thus, to help you to move forward in the interview process and avoid being shown the door, here are some questions about Docker and containers that are typically asked of a developer in a technical interview. This is not a comprehensive list; there will surely be others asked of you. But, if you answer these correctly, you will demonstrate that you have a basic understanding of containers and Docker and how to use them.

What is the difference between a container and a container image?

A container image is a template from which a running container is created. It is defined in a text file that is named by default Dockerfile. (You can use another name and reference it with the Docker build command to create the container image.)

The following code snippet is a sample Dockerfile that defines a container image for a Node.JS web server application:

# get the base node image
FROM node:10.13.0

#create a working directory
WORKDIR /usr/src/app

#copy all the source code files in the container’s working directory
COPY . /usr/src/app

#execute npm install to get all the application dependency packages off the internet
RUN npm install

#make is to sthe container will expose port 4000 for access tho the application
EXPOSE 4000

#start the application in the container by using the CMD command
CMD ["node", "server.js"]

To build the container image, execute the following Docker command:

docker build -t mycontainerimage .

Let’s break down that code snippet:

  • docker is the general command executable
  • build is the subcommand to create a container image
  • -t is the option that indicates the (tag) name of the container image
  • mycontainerimage is the arbitrary (tag) name of the container image
  • . (period) tells docker build to look for the container description in the default file named Dockerfile. (If the text file with the description of the container image has a different name, define it here. For example, if the textfile is named mydockerfile you would execute the command: docker build -t mycontainerimage mydockerfile )

To create a container based on the container image created above, run the following command:

docker run --name mycontainer mycontainerimage

Within that code snip:

  • docker is the general command executable
  • run is the subcommand to create a container 
  • --name is the option that indicates the name of the container
  • mycontainer is the arbitrary name of the container
  • mycontainerimage is the arbitrary (tag) name of the container image
  • . (period) tells the docker build command to look for the container description in the default file named Dockerfile. (If the text file containing the description of the container image has a different name, define it here. For example, if the text file is named mydockerfile execute the command: docker build -t mycontainerimage mydockerfile ) 

What is the result if you run the following command?

sudo docker container run -it busybox /bin/sh

This command creates a container using the busybox container image, and once the container is up and running exposes a command-line prompt from within the container:

sudo docker container run -it busybox /bin/sh

This is similar to logging into a virtual machine and then having access to a command terminal from within the virtual machine.

How do you create a container image that denies root access to its file system?

The way to deny root access is to create a special user as part of the container image defined in the Dockerfile, and then allow that user access to only the parts of the internal file system needed to do the work at hand.

The code snippet below shows the technique to create a container image that defines a default non-root user:

# declare the base container image using the alpine version of the Linux
FROM alpine

# create anew user named, mickey_mouse
RUN adduser -D -g '' micky_mouse

# make the micky_mouse the default user within the container
USER micky_mouse

# make the HOME directory for the new user, mickey_mouse the default working directory
WORKDIR /home/micky_mouse

What does the following command do?

docker run -d --name=webby --net=host nginx

This command creates a container named webby based on the container image nginx, and runs it as part of the localhost network as declared by using the option --net=host: 

docker run -d --name=webby --net=host nginx

In this case, the container is an nginx web server that runs by default on port 80. Thus, once the container is up and running, to access nginx you execute the following command from the host:

curl localhost:80

The container is created using the -d option. This means it will run as a background process.

What is the difference between docker and dockerd?

The executable docker is the client through which users interact with the daemon dockerd. dockerd is the software that actually interacts with the host operating system to create, run and destroy docker containers on a host system.

Thus, in the following command, the executable docker is the intermediary between you and dockerd:

docker run -d --name myserver nginx

In other words, you are telling docker to contact dockerd, which must create a container based on the container image nginx. So, dockerd will name the container myserver and run it as a background process.

How do you give a container access to a directory on the local file system?

You can give a container access to a directory on the local file system by using the -v option when executing the docker run command set. The -v option maps a directory in the local file system into a container’s internal file system.

The following code snippet illustrates the technique:

# Create a directory
mkdir happydir

# create a text file with some content in the newly created directory
echo hi there > ./happydir/message.txt

# create a docker container mapping the host directory, happydir to a
# directory anmed, hostfs within the container
docker run -d -p 80:80 --name myserver -v `pwd`/happydir:/hostfs nginx

# access a command prompt within the container
docker exec -it myserver /bin/sh

# confirm that you can access file, message.txt that was created on the host
cat hostfs/message.txt

Is it possible to store a container image in a local repository? If so, how?

Yes you can store a container image using a local repository. Create a repository based on the container image, registry. which acts as a local Docker container image repository. The example below shows how you create the local registry and then add a container image to it:

# Create the local repository
docker run -d -p 5000:5000 --restart=always --name registry registry:2

# Build a container image using a local Dockerfile
docker build -t my_container_image .

# Tag the container image for adding to the local repository
docker tag my_container_image localhost:5000/my_container_image

# Push the tagged image to the local repository
docker push localhost:5000/my_container_image

Docker interview questions: How far should you go in the stack?

Containers are a game-changer. Being able to use them effectively is an important skill for anybody working in today’s software development environment.

The depth of your knowledge that will help you ace a technical interview depends on the position for which you interview. The questions asked above are general to any job that requires a working knowledge of container technology. This includes developers as well as engineers who work in CI/CD pipelines that use containers as part of the general deployment process.

The lower you go in the technology stack, the more complex things become. Interviewers will ask more difficult questions for jobs that require an in-depth understanding of containers at the operating system level. You’ll also need to answer the questions listed above just to get through the door.

No matter the position you’re interviewing for, if you can answer the questions posed above, that’s a good start to a successful career using containers in your day-to-day activities.