WORKDIR instruction for directory in Docker - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the Dockerfile line to set the working directory to /app.

Docker

WORKDIR [1]

Drag options to blanks, or click blank then click option'

A/home

B/app

C/var

D/usr

Attempts:

3 left

💡 Hint

Common Mistakes

Using a directory that does not exist or is unrelated to the app.

Forgetting the leading slash for absolute paths.

The WORKDIR instruction sets the working directory inside the container. Using /app sets it to the /app folder.

2fill in blank

medium

Complete the Dockerfile to set the working directory to a folder named 'src' inside /usr.

Docker

WORKDIR [1]

Drag options to blanks, or click blank then click option'

A/usr/src

B/usr/bin

C/usr/local

D/usr/lib

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing system folders like /usr/bin which are not for app source code.

Missing the 'src' folder in the path.

The WORKDIR /usr/src sets the working directory to the src folder inside /usr.

3fill in blank

hard

Fix the error in this Dockerfile line to set the working directory to /data.

Docker

WORKDIR [1]

Drag options to blanks, or click blank then click option'

AC:/data

Bdata

C/data

D./data

Attempts:

3 left

💡 Hint

Common Mistakes

Using relative paths like 'data' or './data'.

Using Windows-style paths like 'C:/data'.

The WORKDIR path must be absolute in Linux containers. /data is correct. data or ./data are relative and cause errors. C:/data is a Windows path and invalid here.

4fill in blank

hard

Fill both blanks to set the working directory to /var/www/html.

Docker

WORKDIR /[1]/[2]

Drag options to blanks, or click blank then click option'

Avar

Bwww

Chtml

Dusr

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'usr' instead of 'var' as the first folder.

Swapping 'www' and 'html' positions.

The path /var/www/html is built by joining var and www in the first two blanks. The last folder html is missing here because only two blanks are asked.

5fill in blank

hard

Fill all three blanks to set the working directory to /opt/project/src.

Docker

WORKDIR /[1]/[2]/[3]

Drag options to blanks, or click blank then click option'

Aopt

Bproject

Csrc

Dbin

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'bin' instead of 'src' as the last folder.

Mixing folder order.

The full path /opt/project/src is built by filling blanks with opt, project, and src respectively.

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