Why debugging containers matters in Docker - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to list all running Docker containers.

Docker

docker [1]

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

Aps

Bbuild

Cstart

Drun

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'docker run' instead of 'docker ps' to list containers.

The docker ps command lists all running containers. This helps you see which containers are active and may need debugging.

2fill in blank

medium

Complete the code to start an interactive shell inside a running container named 'webapp'.

Docker

docker exec -it webapp [1]

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

Als

B/bin/bash

Cstop

Drm

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'ls' which only lists files, not open a shell.

The command docker exec -it webapp /bin/bash opens an interactive shell inside the 'webapp' container, allowing you to debug inside it.

3fill in blank

hard

Fix the error in the command to view logs of a container named 'db'.

Docker

docker logs [1]

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

Adb

Bdatabase

Clog

Dcontainer

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong container names like 'database' or 'container'.

The correct container name is 'db'. Using the exact container name is necessary to view its logs.

4fill in blank

hard

Fill both blanks to create a Docker command that shows logs and follows new log entries for container 'api'.

Docker

docker logs [1] [2]

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

A-f

Bapi

C--tail

Dstart

Attempts:

3 left

💡 Hint

Common Mistakes

Using '--tail' instead of '-f' to follow logs.

The command docker logs api -f shows the logs of the 'api' container and keeps following new log entries live.

5fill in blank

hard

Fill all three blanks to create a command that builds a Docker image named 'myapp' from the current directory.

Docker

docker [1] -t [2] [3]

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

Abuild

Bmyapp

C.

Drun

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'run' instead of 'build' to create an image.

The command docker build -t myapp . builds a Docker image named 'myapp' using the Dockerfile in the current directory.

Practice

1. Why is debugging containers important in Docker environments?

easy

A. It helps find and fix problems inside isolated app environments.

B. It speeds up container creation time.

C. It automatically updates container images.

D. It reduces the size of container images.

Solution

1. Step 1: Understand container isolation

   Containers run apps in isolated environments, so problems inside them may not be visible outside.

2. Step 2: Importance of debugging

   Debugging lets you look inside the container to find and fix app issues that affect functionality.

3. Final Answer:

   It helps find and fix problems inside isolated app environments. -> Option A

4. Quick Check:

   Debugging = Fix problems inside containers [OK]

Hint: Remember: Debugging = fixing inside isolated containers [OK]

Common Mistakes:

• Thinking debugging speeds up container creation
• Confusing debugging with image size reduction
• Assuming debugging auto-updates images

2. Which Docker command lets you run a shell inside a running container for debugging?

easy

A. docker run -it container_name /bin/bash

B. docker logs container_name

C. docker build -t container_name .

D. docker exec -it container_name /bin/bash

Solution

1. Step 1: Identify command to run inside running container

   To run commands inside a running container, use docker exec.

2. Step 2: Confirm correct syntax

   docker exec -it container_name /bin/bash opens an interactive shell inside the container.

3. Final Answer:

   docker exec -it container_name /bin/bash -> Option D

4. Quick Check:

   Run shell inside container = docker exec [OK]

Hint: Use 'docker exec' to enter running containers [OK]

Common Mistakes:

• Using 'docker run' which starts a new container
• Confusing 'docker build' with running commands
• Using 'docker logs' which only shows logs

3. What will be the output of this command if the container 'webapp' is running and has logs?

docker logs webapp

medium

A. Starts a new container named 'webapp'.

B. Shows the logs output of the 'webapp' container.

C. Opens an interactive shell inside 'webapp'.

D. Deletes the 'webapp' container.

Solution

1. Step 1: Understand 'docker logs' command

   This command fetches and displays the logs from a running or stopped container.

2. Step 2: Apply to 'webapp' container

   Since 'webapp' is running, the command outputs its logs to the terminal.

3. Final Answer:

   Shows the logs output of the 'webapp' container. -> Option B

4. Quick Check:

   docker logs = show container logs [OK]

Hint: docker logs shows container output messages [OK]

Common Mistakes:

• Thinking it starts or deletes containers
• Confusing logs with shell access
• Expecting logs from images instead of containers

4. You tried to run docker exec -it mycontainer /bin/bash but got an error: "exec: "/bin/bash": stat /bin/bash: no such file or directory". What should you do to debug this?

medium

A. Try docker exec -it mycontainer /bin/sh instead.

B. Restart the Docker daemon.

C. Rebuild the container image.

D. Use docker logs to check container logs.

Solution

1. Step 1: Understand the error message

   The error means the container does not have /bin/bash available.

2. Step 2: Use an alternative shell

   Many containers have /bin/sh instead of /bin/bash. Running docker exec -it mycontainer /bin/sh will open a shell.

3. Final Answer:

   Try docker exec -it mycontainer /bin/sh instead. -> Option A

4. Quick Check:

   Use /bin/sh if /bin/bash missing [OK]

Hint: Use /bin/sh if /bin/bash not found in container [OK]

Common Mistakes:

• Restarting Docker daemon unnecessarily
• Rebuilding image without checking shell availability
• Using logs instead of shell for interactive debugging

5. You have a container running a web app that crashes sometimes. You want to debug it by checking logs and opening a shell inside the container. Which sequence of commands is best?

hard

A. docker build webapp; docker logs webapp

B. docker exec -it webapp /bin/bash; docker logs webapp

C. docker logs webapp; docker exec -it webapp /bin/bash

D. docker stop webapp; docker exec -it webapp /bin/bash

Solution

1. Step 1: Check logs first

   Use docker logs webapp to see error messages and clues about the crash.

2. Step 2: Open shell for deeper debugging

   Use docker exec -it webapp /bin/bash to enter the container and inspect files or processes.

3. Final Answer:

   docker logs webapp; docker exec -it webapp /bin/bash -> Option C

4. Quick Check:

   Logs first, then shell for debugging [OK]

Hint: Check logs before shell to understand issues [OK]

Common Mistakes:

• Trying to exec shell before checking logs
• Building image instead of debugging running container
• Stopping container before debugging shell