Exercise 2: The Two Things DEBUG=False Does — Possible Solution
====================================================================

THE TWO SEPARATE THINGS THAT HAPPEN
------------------------------
Per this chapter, flipping DEBUG to False changes two genuinely unrelated-sounding behaviors from one single setting. First, Django stops showing its own detailed error page on an unhandled exception - no more full traceback, source code, local variable values, or settings displayed to whoever triggered the error. Second, per Chapter 5's own forward reference, Django's automatic static file serving stops working entirely - static files that were served automatically throughout development are no longer served by Django itself at all once DEBUG=False.

WHY LEAVING DEBUG=True IN PRODUCTION IS A REAL SECURITY PROBLEM
------------------------------
Per this chapter, the detailed error page shown under DEBUG=True reveals genuinely dangerous information to any random visitor who happens to trigger an unhandled exception - not just a stack trace, but actual source code, the values of local variables at the moment of the error, and potentially sensitive settings. In production, this means any bug that causes an error could hand a stranger enough information to understand exactly how the application works internally, or worse, leak actual sensitive data that happened to be sitting in a variable at that moment.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly identifies both consequences of DEBUG=False (disabled detailed error pages and disabled automatic static serving), and correctly explains the concrete security risk of leaving detailed error pages exposed to real visitors in production.