What's changed: Created Professional Cloud Security Engineer Chapter 1 (Domain 1 "Configuring access": Cloud Identity/GCDS/SSO(SAML/OAuth)/super admin/user lifecycle/Workforce Identity Federation; service accounts/default SA/key auditing/Workload Identity Federation/short-lived credentials/impersonation/2SV; IAM predefined-custom/separation of duties/IAM conditions/IAM deny policies/groups/Access Context Manager/Policy Intelligence/Privileged Access Manager; resource hierarchy/folders/projects/organization policies (pre-built-custom)/inheritance).
1.2Authorization controls and resource hierarchy
Understand IAM privileged roles and separation of duties, IAM/ACL permissions, IAM conditions and IAM deny policies, least privilege at organization/folder/project/resource, Access Context Manager, Policy Intelligence, permissions via groups, Privileged Access Manager, and the resource hierarchy (managing folders/projects at scale, pre-built/custom org policies, inheritance).
After authentication comes authorization: who can do what. Achieve least privilege via the resource hierarchy, conditions, deny policies, and time-bound privilege.
1.2.1IAM and least-privilege authorization
Grant access with IAM. Avoid basic roles—use predefined/custom roles—and prevent any single over-powerful person with separation of duties. Grant permissions to groups, and combine IAM conditions (time/IP/resource) to narrow with IAM deny policies to explicitly forbid. Define access boundaries (who, from where) with Access Context Manager (access levels), and find over-privilege/recommendations with Policy Intelligence (e.g., IAM Recommender). Avoid standing high privilege with Privileged Access Manager (PAM), elevating only when needed with auto-expiry. Map "explicitly forbid = IAM deny policy," "conditional grant = IAM conditions," and "temporary elevation = Privileged Access Manager."
1.2.2Resource hierarchy and organization policies
Design access control along the resource hierarchy (organization→folders→projects→resources), inheriting IAM and constraints. At scale, organize folders/projects by environment/team/business unit. Enforce org-wide guardrails with organization policies (pre-built constraints or custom org policies), inherited down the hierarchy (e.g., disallow external IPs, restrict regions). "Grant = IAM" and "enforce constraints = organization policy" are separate layers—combine both for least privilege plus guardrails.
Common: requirement → means. E.g., "allow only under conditions (time/IP/resource)" = IAM conditions; "explicitly forbid an action" = IAM deny policy; "elevate privilege only when needed with auto-expiry" = Privileged Access Manager; "find/recommend reducing over-privilege" = Policy Intelligence; "disallow external IPs org-wide" = organization policy; "define access-source boundaries" = Access Context Manager.
Watch the mix-ups: (1) IAM (grants) vs organization policies (enforced constraints) are different layers. (2) IAM deny policies take precedence over allows—they express explicit prohibition. (3) Basic roles (Owner/Editor) are over-broad—use predefined/custom.
1.2.3Section summary
- IAM = predefined/custom + group grants; narrow with conditions, forbid with deny policies; keep separation of duties
- Avoid standing high privilege via Privileged Access Manager (time-bound); reduce over-privilege with Policy Intelligence
- Inherit via the resource hierarchy; org-wide guardrails = organization policies (pre-built/custom)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To explicitly forbid a specific action regardless of any allow roles, which is best?
Q2. To avoid standing admin privilege, elevating temporarily with approval and auto-expiry, which is best?
Q3. To enforce org-wide "no resources outside certain regions" via inheritance, which is best?
Q4. To find granted-but-unused over-privilege and get reduction recommendations, which is best?
Q5. To allow access only when attributes like time or source IP meet conditions, which is best?