LEARN. PRACTICE. GROW.Concept and mechanism
An IAM decision combines principal, role, and resource. Start with the concrete task: reading objects in one bucket does not require administering the organization. Predefined roles simplify management when they match requirements; custom roles can remove extra actions but need ownership and maintenance. Analysis must include inheritance. Removing a local grant does not remove permission still granted by an ancestor. Also consider deny and other applicable controls before concluding effective access. Diagnosis should record identity, action, resource, and relevant policy so review is reproducible. A list of role names without context is insufficient to decide whether access is proportionate.
Guided application
Service accounts introduce additional boundaries. Attaching an account to a VM through actAs does not automatically permit creating every token type for that account. A credential-generation request needs the corresponding permission and a limited scope. During project-to-APS handover, use separate identities when responsibilities differ and test with the identity that will actually operate the service. An administrator rehearsing with broad privileges does not demonstrate that the contingency role works. Record the reason for each grant, its review owner, and allowed and denied access tests, including folder inheritance.
If a user loses a project role but retains access, inspect groups and ancestors before concluding removal failed.
Common pitfalls
Owner used as diagnosis; local removal treated as complete revocation; custom roles without maintenance; actAs treated as every token permission.
Related topics: Federation, impersonation, and pipelines · Projects, context, quotas, and costs
Authorization should be explainable by task, resource, and effective identity.
Reference: IAM overview · Standard exam guide linked 2026-09-29; edition date unconfirmed