1: Configuring access

Learning Objectives

By the end of this chapter, you will be able to:

• Design Cloud Directory Sync and SAML SSO with a third-party identity provider, and apply the controls that mitigate service account key risk and ACL drift across folders and projects at scale.
• Operate the super administrator role under a separation-of-duties model that combines short-lived credentials, IAM Conditions, and organization policies as preventive guardrails.
• Automate user lifecycle provisioning, configure Workload Identity Federation for external workloads, write IAM deny policies, and reason about how the resource hierarchy propagates allow and deny semantics.
• Administer Cloud Identity users and groups through the Directory and Cloud Identity Groups APIs, and design impersonation-first patterns for least-privilege access at every node of the hierarchy.
• Configure Workforce Identity Federation pools and providers for external human users, enforce password and session policies, and bind context-aware access decisions through Access Context Manager.
• Harden default service accounts, set up SAML and OAuth client configuration, and apply Policy Intelligence (IAM Recommender, Policy Analyzer, Policy Troubleshooter) to find and fix over-permissive grants.
• Decide when a service account is the right identity, enforce two-step verification, and route permissions through groups.
• Govern the service account lifecycle (create, disable, authorize), separate privileged duties across IAM role families, and grant just-in-time elevation with Privileged Access Manager.

Executive Summary

• Identity on Google Cloud splits into three planes: Cloud Identity (the human directory plus SAML/OAuth), Workforce Identity Federation (external human identities without provisioning to Cloud Identity), and Workload Identity Federation (non-human external workloads). Every authorization decision is then evaluated against an IAM allow policy, IAM deny policies, IAM Conditions, Access Context Manager levels, and the organization policy constraint set.
• Service account keys, primitive roles on default service accounts, and unconditional iam.serviceAccountTokenCreator grants are the three highest-impact identity risks the exam tests; all three are avoidable with impersonation, Workload Identity Federation, and short-lived credentials.
• The resource hierarchy (Organization, Folders, Projects, Resources) propagates allow policies downward and is the surface where org policy constraints and IAM deny policies act as guardrails that cannot be overridden by lower-level grants.
• Policy Intelligence, Privileged Access Manager, and IAM Conditions together provide the just-enough, just-in-time, conditioned-access controls expected on a regulated environment.

Assumptions

• The reader has working knowledge of Google Cloud fundamentals (resource hierarchy, projects, basic IAM grants) and at least one year of operating Google Cloud.
• The chapter uses the canonical role name format roles/<service>.<role> and the canonical principal formats (user:, group:, serviceAccount:, principal:, principalSet:).
• Region examples assume us-central1 unless stated. Project IDs follow the convention acme-prod-001, organization ID 123456789012.
• The terms Organization, Folder, Project, Resource, IAM allow policy, IAM deny policy, principal, predefined role, custom role, and basic role (Owner/Editor/Viewer) are used with the exact meaning given in the official IAM documentation.