5.3. Reflection Checkpoint

Key Takeaways

• IAM policies bind a member to a role at some level of the resource hierarchy, and inherit downward automatically — but only IAM Deny policies, not ordinary lower-level allow-policies, can block an inherited grant.
• Primitive, predefined, and custom roles trade breadth for precision — least-privilege scenarios that no predefined role matches exactly call for a custom role, not the closest available predefined one.
• Service accounts are workload identities, not human ones, and the entire security model around them centers on minimizing standing permissions and eliminating long-lived, exportable keys wherever possible.
• Impersonation and Workload Identity Federation both solve the same underlying problem — acting as another identity without ever possessing its long-lived credentials — for callers inside and outside Google Cloud, respectively.

Connecting Forward

With all four scored domains covered, Phase 6 shifts to exam-day readiness: strategy for pacing and flagging questions, a consolidated quick-reference for the decision points covered across every domain, and mixed-topic practice questions that mirror the exam's actual format.

Self-Check Questions

• Without re-reading 5.1.1, can you explain why a lower-level IAM allow-policy can't revoke a permission granted higher up the hierarchy, and what feature actually can?
• If a colleague suggests downloading a service account's JSON key and distributing it to whoever needs to "impersonate" it, what would you correct about that plan using 5.2.2?