Exercise 2: Why SECRET_KEY Is a Genuine Secret — Possible Solution
====================================================================

WHY IT'S GENUINELY DIFFERENT FROM THE EXTERNAL API INTEGRATIONS
------------------------------
Open Food Facts and TheMealDB are both free, public APIs that never required any kind of API key at all in this course - there was simply no secret value to protect in either integration. SECRET_KEY is different: it's an internal cryptographic value Django itself uses, and if it were ever exposed, someone could use it to forge data that Django would treat as legitimately signed.

WHAT IT'S ACTUALLY USED TO PROTECT
------------------------------
Per this chapter, SECRET_KEY is used to sign user sessions, CSRF tokens (the same protection mechanism Chapter 6 relies on), and password-reset tokens. (Any two of these would satisfy the question.) If SECRET_KEY leaked, an attacker could use it to forge a valid session cookie and impersonate a logged-in user, among other things.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that neither external API in this course ever needed a real secret, contrasting that with SECRET_KEY's actual role as an internal cryptographic signing key, and correctly names at least two real things it protects (sessions, CSRF tokens, or password-reset tokens).