Exercise 3: Narrow Override vs. Global Disable — Possible Solution
====================================================================

WHY THE TWO ARE DIFFERENT LEVELS OF RISK
------------------------------
Per this chapter's warn-box, right-clicking one specific, known-trustworthy-but-unsigned app and choosing Open is a narrow, deliberate exception that applies only to that single app - Gatekeeper keeps enforcing its normal checks against everything else on the machine. Running `sudo spctl --master-disable` turns Gatekeeper off entirely, for every single app that will ever be opened on that machine going forward, not just the one app the user actually meant to allow. Both technically "bypass Gatekeeper" in the sense that an unsigned app ends up running, but one affects a single, specific, already-evaluated case, while the other removes the protection completely and indefinitely.

THE EARLIER CHAPTER'S PRINCIPLE THIS ECHOES
------------------------------
This chapter explicitly ties it back to Chapter 3's own admin-account guidance: prefer the smallest override that solves the actual problem in front of you, rather than reaching for a broader, standing change when a narrow, one-time exception would do. Chapter 3 applied this to not using an admin account as a daily driver (the same least-privilege reasoning Database Security 3 established); this chapter applies the identical reasoning to Gatekeeper overrides.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains the difference in scope (one app vs. every app, indefinitely) between the two overrides as the actual source of the risk difference, and correctly identifies Chapter 3's own least-privilege/narrow-override principle as the earlier chapter being echoed here.