Database containers for local development in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Docker command for running a PostgreSQL container

You run this command to start a PostgreSQL container locally:

docker run --name pg-test -e POSTGRES_PASSWORD=secret -d -p 5432:5432 postgres:15

What is the output of docker ps --filter name=pg-test --format '{{.Status}}' immediately after running?

A Up 5 seconds

B Restarting (1) 3 seconds ago

C Created

D Exited (1) 2 seconds ago

💡 Hint

Think about what status a healthy running container shows.

When a container starts successfully and is running, the status shows 'Up' with the time since start. 'Exited' means it stopped, 'Created' means it hasn't started, and 'Restarting' means it failed and is retrying.

❓ Configuration

intermediate

Correct Docker Compose service for MySQL with persistent data

Which Docker Compose service configuration correctly sets up a MySQL container with a persistent volume for data storage?

A

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - /var/lib/mysql
volumes:
  mysql-data:

B

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - mysql-data:/var/lib/mysql
volumes:
  mysql-data:

C

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - ./data:/var/lib/mysql
volumes:
  mysql-data:

D

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - mysql-data:/etc/mysql

💡 Hint

Persistent data should be stored in the container's data directory, not config directory.

MySQL stores data in /var/lib/mysql inside the container. Mounting a named volume there ensures data persists. Option B correctly maps the volume. Option B misses the volume name, A uses a relative path which is valid but not named volume, D mounts to wrong path.

❓ Troubleshoot

advanced

Diagnosing PostgreSQL container connection failure

You start a PostgreSQL container with:

docker run --name pg -e POSTGRES_PASSWORD=pass -d -p 5432:5432 postgres

But when you try to connect from your host using psql -h localhost -p 5432 -U postgres, it fails with "connection refused".
What is the most likely cause?

A Docker daemon is not running

B The port 5432 is blocked by the container firewall

C The POSTGRES_PASSWORD environment variable was not set correctly

D PostgreSQL inside the container is not listening on all interfaces, only on localhost inside container

💡 Hint

Think about how PostgreSQL listens for connections inside the container versus outside.

By default, PostgreSQL listens on localhost inside the container, so external connections fail unless configured to listen on 0.0.0.0. Docker port mapping alone does not expose the service if PostgreSQL is not listening on all interfaces.

🔀 Workflow

advanced

Order of steps to safely update a database container with data persistence

You want to update your MySQL container image to a newer version without losing data stored in a Docker volume.
Which is the correct order of steps?

A 1,2,3,4

B 2,1,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

You must stop the container before pulling and restarting with new image.

Stopping the container first ensures no data corruption. Then pull the new image, start a new container with the existing volume to keep data, and finally verify data integrity.

✅ Best Practice

expert

Best practice for managing secrets in database containers for local development

Which approach is the best practice for handling database passwords in Docker containers during local development?

A Leave the password empty for convenience during development

B Use Docker secrets even in local development for passwords

C Pass passwords via environment variables from a local .env file excluded from version control

D Hardcode the password in the Dockerfile environment variables

💡 Hint

Consider security and convenience balance in local development.

Using a local .env file excluded from version control keeps secrets out of code but allows easy configuration. Hardcoding is insecure, Docker secrets are complex for local dev, and empty passwords are insecure.

Practice

1. What is the main benefit of using a database container for local development?

easy

A. You can run a database without installing it on your computer

B. It makes your computer run faster

C. It automatically writes your application code

D. It replaces the need for a database in production

Solution

1. Step 1: Understand what a database container does

   A database container runs a database inside a Docker container, so you don't need to install the database software directly on your computer.

2. Step 2: Identify the main benefit for local development

   This means you can start and stop the database easily without changing your computer setup.

3. Final Answer:

   You can run a database without installing it on your computer -> Option A

4. Quick Check:

   Database container = no local install needed [OK]

Hint: Containers run databases isolated, no install needed [OK]

Common Mistakes:

• Thinking containers speed up the computer
• Confusing containers with code generators
• Believing containers replace production databases

2. Which Docker command correctly starts a PostgreSQL database container exposing port 5432?

easy

A. docker build -p 5432 postgres

B. docker start -p 5432 postgres

C. docker create postgres -p 5432:5432

D. docker run -d -p 5432:5432 postgres

Solution

1. Step 1: Identify the correct command to run a container with port mapping

   The command to start a container and map ports is docker run -d -p hostPort:containerPort image. Here, -d runs it in the background.

2. Step 2: Check each option

   docker run -d -p 5432:5432 postgres uses docker run -d -p 5432:5432 postgres, which is correct. docker start -p 5432 postgres uses docker start which does not support -p. docker create postgres -p 5432:5432 uses docker create which creates but does not start the container. docker build -p 5432 postgres uses docker build which builds images, not runs containers.

3. Final Answer:

   docker run -d -p 5432:5432 postgres -> Option D

4. Quick Check:

   Run + port mapping = docker run -d -p [OK]

Hint: Use 'docker run -d -p host:container image' to start with ports [OK]

Common Mistakes:

• Using 'docker start' with port flags
• Confusing 'docker create' with 'docker run'
• Using 'docker build' to run containers

3. What will be the output of the command docker ps after running docker run -d -p 3306:3306 --name mysql-db mysql?

medium

A. No containers running

B. An error saying port 3306 is already in use

C. A running container named mysql-db with port 3306 mapped

D. A stopped container named mysql-db

Solution

1. Step 1: Understand what the command does

   The command runs a MySQL container in detached mode (-d), names it mysql-db, and maps port 3306 on the host to port 3306 in the container.

2. Step 2: Predict the output of docker ps

   docker ps lists running containers. Since the container runs detached and should start successfully, it will show a running container named mysql-db with port 3306 mapped.

3. Final Answer:

   A running container named mysql-db with port 3306 mapped -> Option C

4. Quick Check:

   Detached run + docker ps = running container shown [OK]

Hint: Detached run shows container in 'docker ps' list [OK]

Common Mistakes:

• Assuming 'docker ps' shows stopped containers
• Expecting errors without port conflicts
• Confusing 'docker ps' with 'docker ps -a'

4. You tried to start a PostgreSQL container with docker run -d -p 5432:5432 postgres but got an error that port 5432 is already in use. What should you do to fix this?

medium

A. Stop the service using port 5432 or map to a different host port

B. Change the container port to 5433

C. Remove the postgres image and try again

D. Use docker build instead of docker run

Solution

1. Step 1: Understand the port conflict error

   The error means something on your computer is already using port 5432, so Docker cannot map the container's port to it.

2. Step 2: Fix the conflict by stopping the service or changing host port

   You can stop the program using port 5432 or map the container port to a different host port like 5433 using -p 5433:5432.

3. Final Answer:

   Stop the service using port 5432 or map to a different host port -> Option A

4. Quick Check:

   Port conflict fix = stop service or change host port [OK]

Hint: Change host port or stop conflicting service to fix port error [OK]

Common Mistakes:

• Changing container port instead of host port
• Removing image does not fix port conflicts
• Using 'docker build' instead of 'docker run'

5. You want to reset your local MySQL database container to start fresh without losing your data volume. Which Docker command sequence is correct?

hard

A. docker rm mysql-db && docker run -d -p 3306:3306 --name mysql-db mysql

B. docker stop mysql-db && docker rm mysql-db && docker run -d -p 3306:3306 --name mysql-db mysql

C. docker restart mysql-db && docker run mysql

D. docker stop mysql-db && docker run -d -p 3306:3306 --name mysql-db mysql

Solution

1. Step 1: Stop and remove the existing container

   To reset the container, first stop it with docker stop mysql-db and then remove it with docker rm mysql-db. This removes the container but not the data volume.

2. Step 2: Run a new container with the same name and port mapping

   Start a new container with docker run -d -p 3306:3306 --name mysql-db mysql to get a fresh instance connected to the existing data volume.

3. Final Answer:

   docker stop mysql-db && docker rm mysql-db && docker run -d -p 3306:3306 --name mysql-db mysql -> Option B

4. Quick Check:

   Stop + remove + run = reset container without losing volume [OK]

Hint: Stop and remove container before rerunning to reset it [OK]

Common Mistakes:

• Restarting container does not reset it
• Removing container without stopping first
• Running new container without removing old one