What's changed: Created Professional Cloud Architect Chapter 5 (Domain 3 "Security and compliance": IAM/least privilege/governance = avoid basic roles/predefined-custom/groups, service accounts/Workload Identity Federation, organization policies/guardrails; data protection and compliance = GMEK/CMEK/CSEK/Cloud KMS/Cloud EKM, Sensitive Data Protection/Cloud DLP, data residency, Assured Workloads/Cloud Audit Logs/VPC Service Controls).
5.1IAM, least privilege, and organizational governance
Understand designing least privilege with IAM (avoid basic roles; predefined/custom roles), service accounts and Workload Identity Federation, enforcing constraints with organization policies, and designing permission inheritance and guardrails along the resource hierarchy.
Security starts with governing "who can access what." The architect designs least privilege and consistent guardrails with IAM and organization policies.
5.1.1IAM and least privilege
IAM defines who (member) gets which role (permissions) on which resource. Avoid overly broad basic roles (Owner/Editor/Viewer); grant fitting predefined roles or least-privilege custom roles. Granting via groups eases management. Use service accounts for apps/workloads, and for external identities avoid distributing keys by federating securely with Workload Identity Federation. Map "least privilege for people and apps" and "avoid key distribution = Workload Identity Federation."
5.1.2Organization policies and guardrails
Organization policies enforce constraints along the resource hierarchy (e.g., disallow resource creation outside certain regions, disallow external IPs). This is a guardrail (enforcing what must not happen), distinct from IAM "grants." Inherited from Org → Folder → Project, it applies org-wide rules from the top. Map "org-wide constraints = organization policies (inherited)" and "grants = IAM, prohibitions/constraints = organization policies."
Common: requirement → means. E.g., "read-only with least privilege" = predefined/custom role; "permissions for an app" = service account; "federate from external identity without keys" = Workload Identity Federation; "disallow creation outside certain regions" = organization policy; "manage permissions in bulk" = grant to groups.
Watch the mix-ups: (1) Basic roles are too broad—use predefined/custom with least privilege. (2) IAM (grants) and organization policies (enforced constraints) are different layers. (3) Avoid distributing service-account keys—prefer Workload Identity Federation / short-lived credentials.
The organization identity foundation is Cloud Identity (centralized users/groups/devices and SSO), tying the same identities as Google Workspace to cloud permissions. Centralize security posture in Security Command Center, which detects misconfigurations, vulnerabilities, and threats and prioritizes risk.
5.1.3Section summary
- IAM least privilege: avoid basic roles, use predefined/custom, manage via groups
- Apps use service accounts; external identities use Workload Identity Federation (avoid key distribution)
- Organization policies enforce constraints via inheritance (a layer separate from IAM grants)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To allow read-only access to a dataset with least privilege, which role best fits?
Q2. To disallow resource creation outside certain regions org-wide, what do you use?
Q3. Which is the appropriate principal to grant permissions to an app/workload?
Q4. To federate securely from external identities (other clouds/on-prem) without distributing SA keys, what do you use?
Q5. Which correctly describes IAM vs organization policies?
Q6. To make granting permissions to many users manageable, which best fits?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.