Docker containerization in FastAPI - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What is the output when running this FastAPI app inside a Docker container?

Consider this FastAPI app code running inside a Docker container. What will the response be when accessing http://localhost:8000/hello?

FastAPI

from fastapi import FastAPI

app = FastAPI()

@app.get('/hello')
async def say_hello():
    return {'message': 'Hello from Docker!'}

A {"message": "Hello from Docker!"}

B 404 Not Found error

C 500 Internal Server Error

D Empty response with status 200

💡 Hint

Think about what the FastAPI route returns as JSON.

The FastAPI app defines a GET endpoint at '/hello' that returns a JSON with key 'message' and value 'Hello from Docker!'. When accessed correctly, the container serves this JSON response.

📝 Syntax

intermediate

Which Dockerfile snippet correctly exposes the FastAPI app port?

You want to expose port 8000 in your Dockerfile for a FastAPI app. Which snippet correctly does this?

A EXPOSE port 8000

B EXPOSE '8000'

C EXPOSE 8000

D EXPOSE:8000

💡 Hint

Check the Dockerfile syntax for exposing ports.

The correct Dockerfile syntax to expose a port is EXPOSE 8000 without quotes or extra words.

🔧 Debug

advanced

Why does the FastAPI app inside Docker fail to start with this command?

Given this Dockerfile CMD, the FastAPI app fails to start inside the container. What is the cause?

FastAPI

CMD ["uvicorn", "main:app"]

A uvicorn is not installed in the container

B Missing the --host 0.0.0.0 option to listen on all interfaces

C CMD should be a shell command string, not a JSON array

D The app should be run with python main.py instead

💡 Hint

Think about how Docker networking works and what IP the app listens on.

By default, uvicorn listens on 127.0.0.1 inside the container, which is not accessible externally. Adding --host 0.0.0.0 makes it listen on all interfaces, allowing external access.

❓ state_output

advanced

What is the value of the environment variable inside the FastAPI app running in Docker?

The Dockerfile sets ENV GREETING=Hi. Inside the FastAPI app, this code runs:

import os
from fastapi import FastAPI
app = FastAPI()

@app.get('/greet')
async def greet():
    return {"greeting": os.getenv('GREETING')}

What will the endpoint return?

A 500 Internal Server Error

B {"greeting": null}

C {"greeting": ""}

D {"greeting": "Hi"}

💡 Hint

Consider how environment variables set in Dockerfile are accessed in the app.

The environment variable GREETING is set in the Dockerfile and is accessible inside the container. The app reads it with os.getenv and returns its value.

🧠 Conceptual

expert

Which statement best explains why multi-stage builds are used in Docker for FastAPI apps?

Multi-stage builds help optimize Docker images. Which option correctly explains their main benefit for FastAPI apps?

A They separate build dependencies from runtime, reducing final image size

B They allow running multiple FastAPI apps in one container

C They enable automatic scaling of FastAPI apps inside Docker

D They provide a GUI to manage Docker containers

💡 Hint

Think about how build tools and runtime requirements differ.

Multi-stage builds let you install heavy build tools in one stage, then copy only the needed runtime files to the final image. This keeps the image small and efficient.

Practice

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

easy

A. To package the app and its environment so it runs the same everywhere

B. To write the FastAPI code faster

C. To replace the need for Python in the app

D. To automatically generate API documentation

Solution

1. Step 1: Understand Docker's role

   Docker packages an app with all its dependencies into a container.

2. Step 2: Recognize the benefit for FastAPI

   This container runs the app the same way on any machine, avoiding environment issues.

3. Final Answer:

   To package the app and its environment so it runs the same everywhere -> Option A

4. Quick Check:

   Docker ensures consistent app environment = A [OK]

Hint: Docker ensures your app runs identically on any machine [OK]

Common Mistakes:

• Thinking Docker speeds up coding
• Believing Docker replaces Python
• Confusing Docker with API doc tools

2. Which line correctly sets the base image in a Dockerfile for a FastAPI app using Python 3.12?

easy

A. BASE python:3.12

B. FROM python:3.12-slim

C. IMAGE python:latest

D. START python:3.12

Solution

1. Step 1: Recall Dockerfile syntax for base image

   The correct keyword to set the base image is FROM followed by the image name.

2. Step 2: Match the correct Python version format

   python:3.12-slim is a valid lightweight Python 3.12 image.

3. Final Answer:

   FROM python:3.12-slim -> Option B

4. Quick Check:

   Base image line starts with FROM = A [OK]

Hint: Dockerfile base image always starts with FROM keyword [OK]

Common Mistakes:

• Using BASE or IMAGE instead of FROM
• Omitting the version tag
• Using START which is invalid

3. Given this Dockerfile snippet for FastAPI, what will happen when you run the container?

FROM python:3.12-slim
WORKDIR /app
COPY . /app
RUN pip install fastapi uvicorn
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

medium

A. The container will fail because pip install is missing requirements.txt

B. The app will start but only listen on localhost inside the container

C. The FastAPI app will start and listen on port 8000 inside the container

D. The container will build but not run the app automatically

Solution

1. Step 1: Analyze the CMD command

   The CMD runs uvicorn with host 0.0.0.0 and port 8000, which means it listens on all interfaces inside the container.

2. Step 2: Check the RUN command

   pip installs fastapi and uvicorn directly, so dependencies are present for the app to run.

3. Final Answer:

   The FastAPI app will start and listen on port 8000 inside the container -> Option C

4. Quick Check:

   CMD runs uvicorn on 0.0.0.0:8000 = B [OK]

Hint: uvicorn host 0.0.0.0 means listen on all container interfaces [OK]

Common Mistakes:

• Assuming pip install needs requirements.txt always
• Thinking 0.0.0.0 means localhost only
• Believing CMD does not run automatically

4. You wrote this Dockerfile but your FastAPI app does not start inside the container:

FROM python:3.12-slim
WORKDIR /app
COPY . /app
RUN pip install -r requirements.txt
CMD uvicorn main:app --host 0.0.0.0 --port 8000

What is the likely error?

medium

A. CMD should be a JSON array, not a plain string

B. WORKDIR should be set after COPY

C. pip install command is missing fastapi package

D. COPY command should use absolute paths

Solution

1. Step 1: Check CMD syntax

   CMD should be given as a JSON array to avoid shell parsing issues in Dockerfiles.

2. Step 2: Identify the correct CMD format

   Correct CMD is: ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

3. Final Answer:

   CMD should be a JSON array, not a plain string -> Option A

4. Quick Check:

   CMD must be JSON array for correct execution = C [OK]

Hint: Use JSON array for CMD to run commands properly in Docker [OK]

Common Mistakes:

• Writing CMD as a plain string instead of array
• Changing WORKDIR order unnecessarily
• Assuming pip install misses fastapi if requirements.txt exists

5. You want to optimize your FastAPI Docker image to be smaller and faster to build. Which approach is best?

hard

A. Use the latest Python image without specifying a version

B. Install all packages globally on your host machine before building

C. Copy the entire project including unnecessary files into the image

D. Use a multi-stage Dockerfile with a build stage and a slim final stage

Solution

1. Step 1: Understand multi-stage builds

   Multi-stage builds allow building dependencies in one stage and copying only needed files to a smaller final image.

2. Step 2: Recognize benefits for FastAPI Docker images

   This reduces image size and speeds up build by excluding build tools and caches from the final image.

3. Final Answer:

   Use a multi-stage Dockerfile with a build stage and a slim final stage -> Option D

4. Quick Check:

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

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

Common Mistakes:

• Installing packages on host instead of inside container
• Copying unnecessary files bloats image
• Using latest tag risks unexpected changes