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.