Why production setup differs in Django - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is DEBUG set to False in production?

In Django, what is the main reason to set DEBUG = False in a production environment?

A To prevent detailed error pages from showing sensitive information to users.

B To enable automatic database migrations on every request.

C To allow Django to serve static files directly in production.

D To disable the admin interface for security reasons.

💡 Hint

Think about what information you want to keep private from users.

Setting DEBUG = False stops Django from showing detailed error pages that can reveal sensitive data. This protects your app from exposing internal details to users.

❓ component_behavior

intermediate

Effect of ALLOWED_HOSTS in production

What happens if the ALLOWED_HOSTS setting in Django is empty when running in production with DEBUG = False?

A Django will serve static files instead of dynamic pages.

B Django will raise a <code>DisallowedHost</code> error and refuse to serve requests.

C Django will automatically add the current host to <code>ALLOWED_HOSTS</code>.

D Django will accept requests from any host without restriction.

💡 Hint

Consider what happens when a request comes from a host not listed in ALLOWED_HOSTS.

When DEBUG is False, Django checks ALLOWED_HOSTS to prevent HTTP Host header attacks. If empty, it raises DisallowedHost error.

❓ lifecycle

advanced

Static files handling difference in production

In Django, why do we run collectstatic during production setup but not usually in development?

A Because development servers do not support static files at all.

B Because <code>collectstatic</code> compiles Python code into bytecode for faster execution.

C Because in production, static files must be gathered in one place for the web server to serve efficiently.

D Because <code>collectstatic</code> deletes all static files to save disk space.

💡 Hint

Think about how static files like images and CSS are served differently in production.

In production, static files are collected into a single directory so a web server like Nginx can serve them efficiently. Development server serves them automatically without collecting.

📝 Syntax

advanced

Correct way to configure database in production

Which of the following Django DATABASES settings is correctly configured for a PostgreSQL production database?

A {'default': {'ENGINE': 'django.db.backends.postgresql', 'NAME': '', 'USER': '', 'PASSWORD': '', 'HOST': '', 'PORT': ''}}

B {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 'prod_db.sqlite3'}}

C {'default': {'ENGINE': 'django.db.backends.mysql', 'NAME': 'prod_db', 'USER': 'admin', 'PASSWORD': 'securepass'}}

D {'default': {'ENGINE': 'django.db.backends.postgresql', 'NAME': 'prod_db', 'USER': 'admin', 'PASSWORD': 'securepass', 'HOST': 'db.example.com', 'PORT': '5432'}}

💡 Hint

Look for the correct engine and filled connection details for PostgreSQL.

Option D correctly uses the PostgreSQL engine and provides all necessary connection details for production.

🔧 Debug

expert

Diagnosing a production error with static files

A Django app in production shows broken CSS and images. The developer forgot to run collectstatic. What error or behavior will the browser most likely show?

A 404 Not Found errors for static file URLs.

B 500 Internal Server Error on every page load.

C CSS and images load normally without any errors.

D Django raises a DisallowedHost error.

💡 Hint

Think about what happens when static files are missing on the server.

If static files are not collected, the web server cannot find them, causing 404 errors when the browser requests CSS or images.