Exercise 3: APP_KEY and Its Django Parallel — Possible Solution
====================================================================

WHAT APP_KEY IS USED FOR
------------------------------
Per this chapter, APP_KEY, generated once via php artisan key:generate, is what Laravel uses to encrypt cookies and sign sessions. It's the cryptographic foundation underneath every encrypted value and every session token the application issues.

WHAT HAPPENS IF IT'S ROTATED
------------------------------
Per this chapter, rotating APP_KEY makes every existing encrypted cookie and session unreadable, since they were encrypted or signed using the old key and can no longer be verified against the new one. Every currently logged-in user is effectively signed out and has to log in again.

THE PARALLEL TO DJANGO'S SECRET_KEY
------------------------------
Per this chapter, this is the identical consequence Django Rebuild 11 already described for rotating Django's own SECRET_KEY - Django's sessions and signed values are equally dependent on that one key, and changing it invalidates them the same way. Laravel's APP_KEY and Django's SECRET_KEY play the same structural role in each framework, with the same real-world effect when rotated.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that APP_KEY underlies cookie encryption and session signing, correctly explains that rotating it invalidates every existing session and encrypted cookie, and correctly draws the parallel to Django's SECRET_KEY having the identical role and consequence.