Docker containerization in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when you run this Dockerfile for a Django app?

Consider this Dockerfile for a Django project. What will be the output when you build and run the container?

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

Django

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

A The Django development server starts inside the container and listens on port 8000 on all interfaces.

B The Django server will start but only listen on localhost inside the container, so it won't be accessible externally.

C The container will fail because the requirements.txt file is not copied before pip install.

D The container will run but exit immediately because CMD is missing the entrypoint.

💡 Hint

Think about what the CMD command does and how the server binds to network interfaces.

The CMD runs the Django development server binding to 0.0.0.0:8000, which means it listens on all network interfaces inside the container, making it accessible if the port is published.

📝 Syntax

intermediate

Identify the syntax error in this Docker Compose service for Django

Look at this docker-compose.yml snippet for a Django service. Which option correctly identifies the syntax error?

version: '3.9'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    command: python manage.py runserver 0.0.0.0:8000
    environment:
      - DEBUG=True
      - SECRET_KEY='mysecret'
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB: mydb
      - POSTGRES_USER: user
      - POSTGRES_PASSWORD: pass

Django

version: '3.9'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    command: python manage.py runserver 0.0.0.0:8000
    environment:
      - DEBUG=True
      - SECRET_KEY='mysecret'
    depends_on:
      - db
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB: mydb
      - POSTGRES_USER: user
      - POSTGRES_PASSWORD: pass

A The 'depends_on' field must be a string, not a list.

B The environment variables under 'db' use colon syntax instead of dash list syntax, causing a syntax error.

C The 'command' field must be a list, not a string.

D The 'volumes' mapping is invalid because it uses relative path without quotes.

💡 Hint

Check how environment variables are defined in YAML for lists vs mappings.

In docker-compose.yml, the 'environment' key expects either a list of strings ('- KEY=value') or a mapping ('KEY: value'). Under 'db', it uses a list of mappings ('- KEY: value'), which is invalid YAML structure for Docker Compose environment variables and causes a configuration parsing error.

❓ state_output

advanced

What is the value of the environment variable DEBUG inside the Django container?

Given this docker-compose.yml snippet, what will be the value of DEBUG inside the running Django container?

services:
  web:
    image: django:latest
    environment:
      DEBUG: 'False'
      SECRET_KEY: 'abc123'
    command: python manage.py runserver 0.0.0.0:8000

Django

services:
  web:
    image: django:latest
    environment:
      DEBUG: 'False'
      SECRET_KEY: 'abc123'
    command: python manage.py runserver 0.0.0.0:8000

A The boolean value False.

B The value will be undefined because environment variables cannot be set this way.

C The string 'False' (not a boolean false).

D An empty string because environment variables are always strings.

💡 Hint

Remember environment variables are always strings inside containers.

Environment variables in Docker are always strings. So DEBUG will be the string 'False', not a boolean false.

🔧 Debug

advanced

Why does the Django container fail to connect to the database?

You have this docker-compose.yml:

services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mydb
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass

The Django app inside 'web' fails to connect to the database. What is the most likely cause?

Django

services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/mydb
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass

A The 'depends_on' does not wait for the database to be ready, so Django connects too early.

B The DATABASE_URL environment variable is incorrectly formatted and missing the password.

C The database container 'db' is not ready when Django tries to connect, causing connection failure.

D The port 5432 is not exposed on the 'db' container, so Django cannot reach it.

💡 Hint

Think about what 'depends_on' controls and what it does not guarantee.

'depends_on' only controls container startup order but does not wait for the database service to be ready to accept connections. Django tries to connect before Postgres is ready, causing failure.

🧠 Conceptual

expert

Which Dockerfile instruction best improves build caching for a Django app?

You want to optimize Docker image build times for your Django app. Which Dockerfile instruction order helps maximize cache reuse?

1. COPY . .
2. RUN pip install -r requirements.txt
3. COPY requirements.txt ./
4. WORKDIR /app

Django

COPY . .
RUN pip install -r requirements.txt
COPY requirements.txt ./
WORKDIR /app

A 1,2,4,3

B 4,3,2,1

C 1,3,2,4

D 1,2,3,4

💡 Hint

Think about which files change most often and how Docker caches layers.

To maximize cache reuse, first set the working directory, then copy only requirements.txt, then install dependencies, then copy the rest of the app. This way, if only app code changes, Docker reuses the cached pip install layer.

Practice

1. What is the main purpose of using Docker with a Django application?

easy

A. To write Django code faster

B. To automatically generate Django templates

C. To replace the Django ORM with a container

D. To package the app and its environment for easy sharing and deployment

Solution

1. Step 1: Understand Docker's role

   Docker packages an app with all its dependencies so it runs the same everywhere.

2. Step 2: Connect to Django app deployment

   This packaging makes sharing and deploying Django apps consistent and easy.

3. Final Answer:

   To package the app and its environment for easy sharing and deployment -> Option D

4. Quick Check:

   Docker packages app + environment = B [OK]

Hint: Docker bundles app + environment for consistent deployment [OK]

Common Mistakes:

• Thinking Docker speeds up coding
• Confusing Docker with Django features
• Believing Docker replaces Django components

2. Which of the following is the correct way to start a Django app inside a Dockerfile?

easy

A. EXPOSE python manage.py runserver

B. RUN python manage.py runserver

C. CMD python manage.py runserver 0.0.0.0:8000

D. COPY python manage.py runserver

Solution

1. Step 1: Identify Dockerfile commands

   CMD sets the command to run when the container starts.

2. Step 2: Match command to Django app start

   Running 'python manage.py runserver 0.0.0.0:8000' starts the Django server accessible outside the container.

3. Final Answer:

   CMD python manage.py runserver 0.0.0.0:8000 -> Option C

4. Quick Check:

   CMD runs app on container start = A [OK]

Hint: Use CMD to run Django server with 0.0.0.0 binding [OK]

Common Mistakes:

• Using RUN instead of CMD to start server
• Misusing EXPOSE as a command
• Confusing COPY with execution commands

3. Given this Dockerfile snippet for a Django app:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt ./
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

What happens when you build and run this container?

medium

A. The container fails because requirements.txt is missing

B. The Django app runs and listens on port 8000 inside the container

C. The app runs but listens only on localhost inside the container

D. The container runs but does not start the Django server

Solution

1. Step 1: Analyze Dockerfile commands

   The Dockerfile installs dependencies, copies code, and runs the Django server on 0.0.0.0:8000.

2. Step 2: Understand container networking

   Binding to 0.0.0.0 means the app listens on all interfaces inside the container, ready for port mapping.

3. Final Answer:

   The Django app runs and listens on port 8000 inside the container -> Option B

4. Quick Check:

   CMD runs server on 0.0.0.0:8000 = A [OK]

Hint: 0.0.0.0 means app listens inside container for external access [OK]

Common Mistakes:

• Assuming app is accessible without port mapping
• Confusing 0.0.0.0 with localhost
• Thinking COPY runs code

4. You wrote this Dockerfile for your Django app:

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

When you build and run the container, the server does not start. What is the likely problem?

medium

A. The CMD command is missing the IP and port to bind to

B. The WORKDIR command is in the wrong place

C. The requirements.txt file is not copied before pip install

D. The base image python:3.12 does not support Django

Solution

1. Step 1: Check CMD command correctness

   Running 'python manage.py runserver' defaults to binding on 127.0.0.1, which is inside the container only.

2. Step 2: Understand container network binding

   Without binding to 0.0.0.0, the server is not accessible outside the container, so it seems like it does not start.

3. Final Answer:

   The CMD command is missing the IP and port to bind to -> Option A

4. Quick Check:

   Missing 0.0.0.0 binding causes server invisibility = D [OK]

Hint: Always bind Django server to 0.0.0.0 in Docker CMD [OK]

Common Mistakes:

• Assuming default runserver binds externally
• Thinking WORKDIR order breaks container
• Believing base image lacks Django support

5. You want to optimize your Django Docker container to reduce image size and speed up builds. Which approach is best?

hard

A. Use a multi-stage Dockerfile to install dependencies separately and copy only needed files

B. Install all Python packages globally on the host machine

C. Copy the entire project folder after installing dependencies

D. Use the latest full Python image without slimming

Solution

1. Step 1: Understand multi-stage builds

   Multi-stage Dockerfiles let you build dependencies in one stage and copy only necessary files to the final image, reducing size.

2. Step 2: Compare other options

   Installing packages on host or copying everything increases image size and reduces portability.

3. Final Answer:

   Use a multi-stage Dockerfile to install dependencies separately and copy only needed files -> Option A

4. Quick Check:

   Multi-stage builds optimize image size and build speed = C [OK]

Hint: Multi-stage Dockerfiles keep images small and builds fast [OK]

Common Mistakes:

• Installing packages outside container
• Copying unnecessary files increases size
• Using large base images without slimming