WORKDIR instruction for directory in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Effect of WORKDIR on RUN command

Given the Dockerfile snippet below, what will be the current directory when the RUN command executes?

Docker

FROM alpine
WORKDIR /app
RUN pwd

A /app

B /

C /root

D /usr/local/bin

💡 Hint

WORKDIR sets the working directory for following instructions.

The WORKDIR instruction sets the working directory for all subsequent commands in the Dockerfile. So, when the RUN command executes, the current directory is /app.

🧠 Conceptual

intermediate

WORKDIR creates directories if missing

What happens if the directory specified in WORKDIR does not exist in the image?

A Docker creates the directory automatically

B Docker throws an error and stops building

C Docker uses the root directory instead

D Docker ignores the WORKDIR instruction

💡 Hint

Think about how Docker handles paths that don't exist.

If the directory does not exist, Docker creates it automatically during the build process.

❓ Configuration

advanced

Multiple WORKDIR instructions effect

Consider this Dockerfile snippet:

FROM ubuntu
WORKDIR /app
WORKDIR logs
RUN pwd

What is the output of the RUN pwd command?

A /logs

B /app/logs

C /app

D /

💡 Hint

Each WORKDIR is relative to the previous one if not absolute.

The second WORKDIR 'logs' is relative to the first '/app', so the final directory is '/app/logs'.

❓ Troubleshoot

advanced

Unexpected directory in container

A developer writes this Dockerfile:

FROM node:18
WORKDIR /usr/src/app
COPY . .
RUN npm install
CMD ["node", "server.js"]

But when running the container, files are missing in /usr/src/app. What could cause this?

A COPY command copies files relative to the current WORKDIR

B CMD command changes the working directory

C WORKDIR must be set after COPY to affect file locations

D COPY command copies files relative to the build context root

💡 Hint

COPY uses the build context root, not WORKDIR, as source.

The COPY command copies files from the build context root to the destination path. The destination '.' is relative to WORKDIR, but the source '.' is always relative to the build context root.

✅ Best Practice

expert

Optimizing Dockerfile with WORKDIR

Which Dockerfile snippet best follows best practices for setting WORKDIR and copying files to reduce image layers and improve readability?

A

FROM python:3.12
RUN mkdir /app
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt

B

FROM python:3.12
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt

C

FROM python:3.12
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

D

FROM python:3.12
COPY requirements.txt /app/
RUN pip install -r /app/requirements.txt
WORKDIR /app
COPY . .

💡 Hint

Consider layer caching and clarity of commands.

Option C sets WORKDIR early, copies only requirements.txt first to leverage caching, installs dependencies, then copies the rest. This reduces rebuild time and improves readability.

Practice

1. What does the WORKDIR instruction do in a Dockerfile?

easy

A. Runs a command when the container starts

B. Deletes files in the container

C. Sets the working directory for commands inside the container

D. Specifies the base image for the container

Solution

1. Step 1: Understand the purpose of WORKDIR

   The WORKDIR instruction sets the folder where subsequent commands run inside the container.

2. Step 2: Compare with other options

   Options A, B, and C describe other Dockerfile instructions or actions, not WORKDIR.

3. Final Answer:

   Sets the working directory for commands inside the container -> Option C

4. Quick Check:

   WORKDIR sets folder for commands [OK]

Hint: WORKDIR sets folder for commands inside container [OK]

Common Mistakes:

• Confusing WORKDIR with CMD or ENTRYPOINT
• Thinking WORKDIR deletes files
• Assuming WORKDIR sets base image

2. Which of the following is the correct syntax to set the working directory to /app in a Dockerfile?

easy

A. WORKDIR /app

B. WORKDIR: /app

C. WORKDIR = /app

D. WORKDIR(/app)

Solution

1. Step 1: Recall Dockerfile syntax for WORKDIR

   The correct syntax is WORKDIR /path without any symbols like colon, equals, or parentheses.

2. Step 2: Check each option

   Options A, B, and D use invalid syntax for Dockerfile instructions.

3. Final Answer:

   WORKDIR /app -> Option A

4. Quick Check:

   WORKDIR uses space, no symbols [OK]

Hint: WORKDIR uses space before path, no symbols [OK]

Common Mistakes:

• Adding colon or equals sign after WORKDIR
• Using parentheses around path
• Forgetting the space between WORKDIR and path

3. Given this Dockerfile snippet:

FROM alpine
WORKDIR /app
RUN touch file.txt
WORKDIR /app/data
RUN echo "hello" > message.txt

Where will the file message.txt be created inside the container?

medium

A. /app/data/file.txt

B. /app/message.txt

C. /message.txt

D. /app/data/message.txt

Solution

1. Step 1: Follow WORKDIR changes

   The first WORKDIR sets directory to /app. The second WORKDIR changes it to /app/data.

2. Step 2: Locate where message.txt is created

   The command RUN echo "hello" > message.txt runs in /app/data, so the file is created there.

3. Final Answer:

   /app/data/message.txt -> Option D

4. Quick Check:

   Last WORKDIR sets folder for commands [OK]

Hint: Last WORKDIR sets current folder for commands [OK]

Common Mistakes:

• Assuming files created in first WORKDIR folder
• Confusing file paths with root directory
• Ignoring multiple WORKDIR instructions

4. You wrote this Dockerfile snippet:

WORKDIR /app
RUN ls
WORKDIR app/data
RUN ls

Why does the second WORKDIR cause an unexpected result?

medium

A. Because WORKDIR cannot be used twice

B. Because relative path 'app/data' resolves to /app/app/data instead of /app/data

C. Because RUN ls is invalid syntax

D. Because /app directory is not created automatically

Solution

1. Step 1: Understand relative paths in WORKDIR

   The second WORKDIR uses a relative path app/data, which is relative to the current directory /app. So it tries to set /app/app/data.

2. Step 2: Understand relative path resolution

   Docker creates /app/app/data automatically if needed, but this nested path is usually unintended if /app/data was desired.

3. Step 3: Identify actual issue

   Relative path app/data is a mistake; use data or absolute /app/data instead.

4. Final Answer:

   Because relative path 'app/data' resolves to /app/app/data instead of /app/data -> Option B

5. Quick Check:

   Relative WORKDIR paths resolve from current dir [OK]

Hint: Relative WORKDIR paths are inside current folder [OK]

Common Mistakes:

• Thinking WORKDIR cannot be used multiple times
• Assuming RUN ls is invalid
• Believing /app is not auto-created

5. You want to create a Dockerfile that:
- Sets working directory to /app
- Creates a subfolder logs
- Changes working directory to logs
- Creates a file app.log

Which Dockerfile snippet correctly does this?

hard

A. WORKDIR /app
RUN mkdir logs
WORKDIR logs
RUN touch app.log

B. WORKDIR /app/logs
RUN mkdir logs
WORKDIR /app
RUN touch app.log

C. RUN mkdir /app/logs
WORKDIR /app/logs
RUN touch app.log

D. WORKDIR /app
RUN touch app.log
WORKDIR logs
RUN mkdir logs

Solution

1. Step 1: Set working directory to /app and create logs folder

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log sets WORKDIR to /app and runs mkdir logs to create the subfolder.

2. Step 2: Change WORKDIR to logs and create app.log

   Then it changes WORKDIR to logs (relative to /app) and creates app.log inside it.

3. Step 3: Verify other options

   WORKDIR /app/logs RUN mkdir logs WORKDIR /app RUN touch app.log sets WORKDIR incorrectly and creates logs folder in wrong place. RUN mkdir /app/logs WORKDIR /app/logs RUN touch app.log creates logs folder but misses initial WORKDIR. WORKDIR /app RUN touch app.log WORKDIR logs RUN mkdir logs creates app.log before logs folder and changes WORKDIR before folder exists.

4. Final Answer:

   WORKDIR /app RUN mkdir logs WORKDIR logs RUN touch app.log -> Option A

5. Quick Check:

   Create folder before changing WORKDIR [OK]

Hint: Create folder before changing WORKDIR into it [OK]

Common Mistakes:

• Changing WORKDIR before folder exists
• Creating files in wrong directory
• Using absolute path incorrectly