Exercise 1: Why the Editor Basic Role Is a Poor Production Choice — Possible Solution
====================================================================

Google's own real documentation explicitly states that basic roles
(Owner, Editor, Viewer) "shouldn't be used in production
environments." The Editor role in particular grants real, broad,
sweeping access across nearly every resource type in the Project -
far more than a specific developer's own real task actually requires.

Granting Editor "to do everything they need quickly" means the
developer's own account (or anything using its credentials) can now
modify or delete resources completely unrelated to their actual work
- a real, unnecessarily large blast radius if that account or its
credentials are ever compromised, and a real violation of least
privilege regardless of whether anything ever actually goes wrong.

ANSWER: Google recommends against Editor in production because it
grants far broader real access than almost any specific task actually
needs, creating an unnecessarily large blast radius if the account is
ever compromised. The real alternative is a Predefined role scoped to
the specific real task (e.g. a role granting only the specific
Compute Engine or Storage permissions the developer's own work
requires), or a Custom role built from exactly the needed permissions
if no predefined role fits closely enough.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly explains WHY the broad role is risky (unnecessary
blast radius, not just "Google says not to"), and names the specific
real alternative role types the chapter itself describes, rather than
vaguely suggesting "use a more restrictive role."