Exercise 1: DEBUG, Production, and ALLOWED_HOSTS — Possible Solution
====================================================================

WHY DEBUG=True IS RISKY IN PRODUCTION
------------------------------
DEBUG=True shows full, detailed error pages whenever something goes wrong - complete stack traces, local variable values at the point of failure, and even snippets of source code. In development this is genuinely useful for diagnosing problems quickly. In production, the same behavior hands anyone who can trigger an error a real window into internal details - secrets, file paths, database structure - none of which should ever be visible to an actual visitor or attacker.

WHAT HAPPENS ONCE DEBUG=False WITHOUT ALLOWED_HOSTS CONFIGURED
------------------------------
Once DEBUG=False, Django enforces a real check: it refuses to serve any request at all unless the incoming request's Host header matches an entry in ALLOWED_HOSTS. If ALLOWED_HOSTS was never updated to include the real production domain, every single request gets rejected outright - the entire site appears completely broken, even though the code itself is working exactly as configured. This happens because DEBUG=True previously bypassed this host-checking behavior entirely, so the omission was never noticed until DEBUG was actually turned off.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why detailed error pages are appropriate in development but a real information-disclosure risk in production, and correctly describes the specific mechanism (Django rejecting every request due to an unmatched Host header) that causes a site to appear entirely broken once DEBUG=False without a properly configured ALLOWED_HOSTS.