Why production setup matters in Flask - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to run a Flask app in development mode.

Flask

if __name__ == '__main__':
    app.run(debug=[1])

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

A0

BTrue

CNone

DFalse

Attempts:

3 left

💡 Hint

Common Mistakes

Setting debug to False disables helpful error messages.

Using None or 0 does not enable debug mode.

Setting debug=True runs the Flask app in development mode with helpful error messages and auto-reload.

2fill in blank

medium

Complete the code to import the production-ready WSGI server.

Flask

from [1] import WSGIServer

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

Aflask

Bhttp.server

Cwerkzeug.serving

Dgevent.pywsgi

Attempts:

3 left

💡 Hint

Common Mistakes

Importing from flask or werkzeug.serving is for development only.

http.server is not suitable for production Flask apps.

gevent.pywsgi provides a production-ready WSGI server for Flask apps.

3fill in blank

hard

Fix the error in the production server start command.

Flask

http_server = WSGIServer(('0.0.0.0', [1]), app)
http_server.serve_forever()

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

A5000

B'5000'

C'app'

Dapp

Attempts:

3 left

💡 Hint

Common Mistakes

Using quotes around the port number causes a type error.

Passing the app object as the port causes errors.

The port number must be an integer, not a string, so use 5000 without quotes.

4fill in blank

hard

Fill both blanks to create a dictionary comprehension filtering environment variables.

Flask

prod_env = {key: value for key, value in [1].items() if key.[2]('PROD_')}

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

Aos.environ

Bos.getenv

Cstartswith

Din

Attempts:

3 left

💡 Hint

Common Mistakes

Using os.getenv returns a single value, not a dictionary.

Using 'in' instead of 'startswith' does not filter keys correctly.

Use os.environ to access environment variables and startswith to filter keys starting with 'PROD_'.

5fill in blank

hard

Fill all three blanks to configure Flask app for production.

Flask

app.config['DEBUG'] = [1]
app.config['TESTING'] = [2]
app.config['ENV'] = '[3]'

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

AFalse

BTrue

Cproduction

Ddevelopment

Attempts:

3 left

💡 Hint

Common Mistakes

Leaving debug or testing enabled in production risks security.

Setting ENV to 'development' causes unwanted debug features.

In production, DEBUG and TESTING should be False, and ENV set to 'production'.

Practice

1. Why should you avoid using Flask's built-in server in a production environment?

easy

A. Because it requires extra configuration to run on Windows

B. Because it automatically enables debug mode which is good for production

C. Because it only supports Python 2, not Python 3

D. Because it is not designed to handle high traffic and is not secure enough

Solution

1. Step 1: Understand Flask's built-in server purpose

   Flask's built-in server is meant for development and testing, not for production use.

2. Step 2: Recognize production needs

   Production requires servers that handle many users securely and efficiently, which Flask's server does not provide.

3. Final Answer:

   Because it is not designed to handle high traffic and is not secure enough -> Option D

4. Quick Check:

   Flask built-in server is for development, not production [OK]

Hint: Remember: Flask server is for dev, not real users [OK]

Common Mistakes:

• Thinking Flask server is secure for production
• Confusing debug mode with production mode
• Believing Flask server supports all OS without issues

2. Which of the following is the correct way to disable debug mode in a Flask app for production?

easy

A. app.debug = True

B. app.run(debug=True)

C. app.run(debug=False)

D. app.debug = 'off'

Solution

1. Step 1: Identify how to set debug mode in Flask

   Debug mode is controlled by the debug parameter in app.run or by setting app.debug to True or False.

2. Step 2: Choose the correct way to disable debug

   Setting debug=False in app.run disables debug mode properly for production.

3. Final Answer:

   app.run(debug=False) -> Option C

4. Quick Check:

   debug=False disables debug mode [OK]

Hint: Use debug=False to turn off debug mode [OK]

Common Mistakes:

• Setting debug=True in production
• Using string 'off' instead of boolean False
• Not disabling debug mode at all

3. Given this Flask app code snippet running in production with debug off:

from flask import Flask
app = Flask(__name__)

@app.route('/')
def home():
    return 'Hello, World!'

if __name__ == '__main__':
    app.run(debug=False)

What will a user see when visiting the root URL?

medium

A. The text 'Hello, World!'

B. A detailed error page if something goes wrong

C. A blank page because debug is off

D. A server crash due to missing production server

Solution

1. Step 1: Analyze the route function

   The '/' route returns the string 'Hello, World!'.

2. Step 2: Understand debug mode effect

   Debug mode off means no detailed error pages, but normal responses still work.

3. Final Answer:

   The text 'Hello, World!' -> Option A

4. Quick Check:

   Route returns 'Hello, World!' regardless of debug [OK]

Hint: Route returns response text regardless of debug mode [OK]

Common Mistakes:

• Thinking debug off means no output
• Expecting error page on normal route
• Assuming server crashes without Gunicorn

4. You deployed a Flask app with debug mode off but users report seeing detailed error messages. What is the most likely cause?

medium

A. The app is running with Flask's built-in server in debug mode despite code settings

B. The app is using Gunicorn which always shows debug info

C. The app's secret key is missing

D. The app is running on Python 2 instead of Python 3

Solution

1. Step 1: Check server and debug mode

   Flask's built-in server can override debug settings if run with debug enabled.

2. Step 2: Understand production server role

   Using a production server like Gunicorn prevents debug info leakage; built-in server is unsafe.

3. Final Answer:

   The app is running with Flask's built-in server in debug mode despite code settings -> Option A

4. Quick Check:

   Built-in server with debug on leaks errors [OK]

Hint: Check if built-in server runs with debug on [OK]

Common Mistakes:

• Blaming Gunicorn for debug info
• Ignoring server choice in production
• Confusing secret key with debug mode

5. You want to deploy a Flask app securely in production. Which combination of steps is best practice?

hard

A. Use Flask built-in server, enable debug mode, and hardcode secret keys

B. Use Gunicorn server, disable debug mode, and keep secret keys out of code

C. Use Gunicorn server, enable debug mode, and store secret keys in code

D. Use Flask built-in server, disable debug mode, and ignore secret keys

Solution

1. Step 1: Choose a production-ready server

   Gunicorn is a production server designed to handle real traffic safely.

2. Step 2: Configure debug mode and secrets

   Debug mode must be off to avoid exposing sensitive info; secret keys should be kept secure and not hardcoded.

3. Final Answer:

   Use Gunicorn server, disable debug mode, and keep secret keys out of code -> Option B

4. Quick Check:

   Production needs Gunicorn, no debug, secure secrets [OK]

Hint: Gunicorn + debug off + secure secrets = safe production [OK]

Common Mistakes:

• Using built-in server in production
• Leaving debug mode enabled
• Hardcoding secret keys in code