Prepare and test your skills
Prepare and test your skills
Managing Cloud Identity is the control plane for workforce users, groups, and federation that determines who can authenticate to Google Cloud. Cloud Identity (opens in a new tab) holds the managed user account, while user identities (opens in a new tab) from external providers are either synchronized into it or federated at sign-in time. Groups bind identity to authorization because Identity and Access Management (IAM) roles are granted to groups rather than to individuals.
Google Cloud Directory Sync (GCDS) is a provisioning bridge that copies users and groups from on-premises Active Directory to Cloud Identity or Google Workspace without copying passwords. Data flows from Active Directory to the GCDS host over Lightweight Directory Access Protocol (LDAP), then from the GCDS host to Google over HTTPS to the Directory API. The GCDS host must run on a separate machine with LDAP access to Active Directory, not on a domain controller, and its XML configuration file holds an OAuth refresh token that must be stored in a restricted folder.
GCDS depends on dedicated identities on both sides of the sync boundary. On the Active Directory side it authenticates as a dedicated domain user, while on the Google side it authenticates as a dedicated Cloud Identity user with the Super Admin role that is exempt from single sign-on (SSO) and protected with 2-step verification. Attribute mapping controls how an Active Directory object becomes a Google user, using givenName for given name, sn for family name, and userPrincipalName, domain substitution, or mail attribute for the primary email. Filtering rules limit scope to active person accounts, usually with Sub-tree scope and exclusion of disabled accounts, computer objects, and the sync account itself.
SAML SSO with a third-party identity provider (IdP) lets users authenticate at the external IdP and then access Google without a separate Google password. In this model Google acts as the SAML service provider and the external system such as Active Directory Federation Services acts as the SAML IdP using SAML 2.0 HTTP POST binding. SSO succeeds only when the user exists in Cloud Identity and has a matching identity in the external IdP, because GCDS does not synchronize passwords.
The ordered sign-in flow moves the browser from Google to the IdP and back:
RelayState and SAMLRequest.google.com.Trust requires matching identifiers on both sides. Google stores the IdP entity ID, sign-in and sign-out URLs, and verification certificate, while the IdP stores the Google Entity ID and ACS URL as a Claims-aware relying-party trust.
Super administrator accounts control the Cloud Identity domain and the lifecycle of the Google Cloud organization resource, including assigning the Organization Administrator role and recovering accounts. The super administrator that creates the organization automatically receives the Organization Administrator role. The Organization Administrator then controls daily resource administration, including allow and deny policies and IAM grants, but cannot create folders or projects without additional roles.
Secure provisioning keeps emergency identity control with super admins and routine control with Organization Administrators. Best practice grants the Organization Administrator role to a private group such as gcp-organization-admins without including the super admin user, assigns IAM roles to groups such as gcp-billing-admins and gcp-security-admins, and maintains more than one super administrator and more than one Organization Administrator. Super admins bypass organization SSO and authenticate directly to Cloud Identity, so they require mandatory MFA with phishing-resistant hardware security keys, separate alice-admin@example.com style logins, short sessions, and disabled self-recovery with peer-assisted recovery by another super admin.
Exam tip: Super admins bypass organization SSO and authenticate directly to Cloud Identity, so enforce 2-step verification with security keys in Cloud Identity even when MFA is already enforced at the external IdP.
Automated lifecycle management connects join, move, and leave events to group membership so IAM access follows automatically. Concepts (opens in a new tab) for provisioning include direct management in Cloud Identity, synchronization with GCDS where each user has both an external and a Google account, and Workforce Identity Federation where each user keeps only the external account and signs in through a workforce identity pool. In all models IAM roles are assigned once to role-aligned groups, and users gain or lose permissions only by entering or leaving groups.
Workforce Identity Federation avoids duplicating users by authorizing federated identities through IAM principal identifiers. Identifiers starting with principal:// address exactly one subject, while identifiers starting with principalSet:// address a group, an attribute value, or the whole pool with /*. Attribute mappings use Common Expression Language (CEL) to translate IdP claims into google.subject, google.groups, and custom attributes, with a 16 KB limit per provider and a 400-group sign-in limit. Session duration defaults to one hour and must stay between 15 minutes and 12 hours, applying equally to token exchange, console sessions through auth.cloud.google, and gcloud sessions.
Continue with this study guide: Managing Cloud Identity
Managing service accounts means giving every workload its own non-human identity with only the permissions its task needs. A user-managed service account has the form SERVICE_ACCOUNT_ID@PROJECT_ID.iam.gserviceaccount.com, is attached to the resource running the code, and calls Google Cloud APIs under that identity. Traffic flows from the workload to Google Cloud APIs as the attached account, while authorization decisions flow back from IAM allow policies on target resources.
Default service accounts increase blast radius because many workloads inherit the same broad permissions. The Compute Engine default account and the App Engine default account may automatically receive the Editor role on the project, which allows reading and modifying almost all resources. Cloud Build carries the same risk when no account is specified because it may select an account with broad storage and source access. Compromise of one workload can therefore affect data owned by all workloads sharing that default account.
Replacement uses per-workload identities with minimal predefined roles scoped to one bucket, dataset, or repository, plus IAM Conditions where needed. In App Engine a per-version account covers one version, an app-level custom default covers all services without a per-version account, and the auto-created default should remain only for legacy use. In Google Kubernetes Engine (GKE), Workload Identity links a Kubernetes ServiceAccount to a Google service account so pods receive only the Google roles they need, instead of sharing the node identity. Guardrails preserve least privilege by enforcing iam.automaticIamGrantsForDefaultServiceAccounts to block new automatic Editor grants, a constraint enforced by default for organizations created after May 3, 2024.
A service account is required whenever automation must run without a person signing in, including API scripts, delivery pipelines, runtime application code, and component-to-component calls. API scripts should each use a dedicated account so disabling that account stops only that script. Cloud Deploy runs as an execution identity that must hold the Cloud Deploy Runner role plus runtime permissions such as Container Developer and Service Account User, with explicit cross-project trust when the account and target sit in different projects.
Stable workload identity is the reason to choose a service account over a user account. User accounts have passwords, support browser sign-in, and are suspended on departure, while service accounts have no password, cannot sign in through a browser, and persist when builders change teams. Privilege escalation occurs when a lower-privileged user authenticates as a more-privileged account through impersonation or keys, runs code on a resource with an attached privileged account, or edits allow policies to grant impersonation ability. Shell access, deployment rights, and impersonation rights must therefore be treated as equivalent to the data access they unlock.
Provisioning a custom service account creates the identity and then authorizes both what it can access and who can use it. A role granted to an account controls what workloads running as that account can do, while a role granted on an account controls who can become or attach that account. The ordered workflow is first create the account, then bind a predefined role to the account on project resources, then grant roles/iam.serviceAccountUser on the account to the deployer, then create the Compute Engine instance with --service-account set to the account email.
Short-lived credentials avoid distributing long-lived keys by minting temporary tokens through the Service Account Credentials API. The flow moves trust without copying a secret: the source authenticates with its own credentials, calls the Credentials API on the target account, and receives a token signed by the target's Google-owned key, with OAuth access tokens expiring by default after one hour. Each account can have up to 10 user-managed key pairs, where Google stores only the public key and the holder of the private file can act as the account. Keyless delegation instead authenticates with an attached account or federation, builds a JWT with a sub claim for domain-wide delegation, and calls signJwt without downloading a static key.
Workload Identity Federation is the trust broker that lets workloads outside Google Cloud authenticate without downloadable keys. The external provider authenticates the workload, Google Cloud validates that credential through Security Token Service, and the workload receives short-lived credentials to act as a designated service account. Federation supports OpenID Connect (OIDC) and SAML 2.0 providers, including AWS, Azure, GitHub, GitLab, and enterprise directories.
Attribute mapping translates external token fields referenced as assertion into google.subject, google.groups, and custom attributes, and mappings must be treated as a security boundary because changing them changes who matches existing grants. IAM policies then grant roles to principal identifiers built with the numeric project number, where principal:// addresses one federated subject and principalSet:// addresses a group or attribute set. Federated workloads gain access either by direct IAM grants on the federated principal or by impersonating a dedicated service account with roles/iam.workloadIdentityUser, with best practice favoring a dedicated account per workload in the same project as the resources.
Service account impersonation occurs when one authenticated principal temporarily acts as a service account to gain that account's permissions. Binding impersonation roles on the target account itself limits blast radius: granting Service Account Token Creator on one account email allows impersonating only that identity, while granting it at the project level allows impersonating all accounts in the project. Service Account Token Creator mints access tokens, ID tokens, and signed blobs, Service Account OpenID Connect Identity Token Creator mints only OIDC ID tokens, and Service Account User with iam.serviceAccounts.actAs allows attaching the account to compute.
Temporary elevation centralizes privilege in a scoped account and distributes only short-lived use through group membership, often with expiring membership, IAM Conditions, or Privileged Access Manager for just-in-time elevation. Auditing joins Cloud Asset Inventory for which keys exist, Policy Intelligence and monitoring for which keys are unused or over-privileged, and Cloud Audit Logs with principalEmail and serviceAccountKeyName for who used which key. Rotation must create, deploy, and verify the new key before deleting the old key, while compromise response disables the key, finds every grant with Policy Analyzer, and contains stolen tokens with deny policies and VPC Service Controls perimeters. Service agents (opens in a new tab) are distinct Google-managed identities that must not be confused with these customer-managed impersonation targets.
Exam tip: Granting a role to a service account controls what that account can access, while granting Service Account User on a service account controls who can attach and use that account.
Continue with this study guide: Managing service accounts
Managing authentication means proving workforce identity once and then limiting how long and where the resulting credentials can be used. Cloud Identity issues cached credentials after login, session policies force periodic re-authentication, and per-request and perimeter controls limit stolen tokens. Together these controls govern the session lifecycle from enrollment to expiry.
Time-bound Google Cloud sessions control how long cached Google Cloud credentials remain valid before the user must re-authenticate with a password or security key. New organizations receive a default of 16 hours for Google Cloud services, while older organizations may still allow never requiring re-authentication and must be reviewed. Administrators should enforce between 1 and 24 hours, which bounds how long an attacker can reuse a compromised gcloud CLI token.
Session length for Google Cloud services governs API and gcloud access, while session length for Google services governs web sign-in across Workspace and does not control Google Cloud re-authentication. Federated alignment requires configuration on both sides: Cloud Identity limits the Google session so expiry forces fresh federation, and the external IdP requires MFA and limits its own session so MFA recurs. If the IdP session is longer than the Google session, the user could re-authenticate without a fresh MFA challenge. Authentication and authorization use cases (opens in a new tab) distinguish this interactive user flow from workload flows that use service accounts and federation.
Per-request checks and resource perimeters limit what a stolen token can still do while it remains valid. Chrome Enterprise Premium evaluates an access level on every user API request using source IP and client mutual TLS (mTLS) certificate, and rejects traffic that fails those conditions. VPC Service Controls defines a service perimeter around supported resources and blocks API traffic to restricted services when the request originates from outside that perimeter.
| Control | Boundary enforced | Identities covered |
|---|---|---|
| Chrome Enterprise Premium | User-to-Google check on every API call | Only user identities in the organization |
| VPC Service Controls | Resource perimeter around services | All user and service account identities |
Continuous authentication for SSH adds a human checkpoint for Compute Engine. OS Login with 2-Step Verification (2SV) requires password or security-key re-authentication on each SSH connection, so stolen OAuth tokens alone are insufficient. Traffic through Identity-Aware Proxy (IAP) for SSH also requires periodic credential refresh with MFA. OS Login 2SV works only when MFA is also enforced in Cloud Identity or the external IdP, because privileged instance admins could otherwise disable it through metadata.
SAML federation divides authentication work among the principal who requests access, the Google-operated service provider that needs proof, and the external IdP that authenticates the user and returns a signed assertion. SAML performs authentication only, while authorization remains controlled by IAM grants and account state. Establishing trust means Google stores the IdP entity ID, SSO URLs, and token-signing certificate, while the IdP registers Google as the relying party with the service-provider entity ID and Assertion Consumer Service (ACS) URL.
Mapping converts IdP NameID and attributes into the Google subject and attributes such as google.subject, attribute.user_email, and google.groups, with only required attributes sent to minimize assertion size. By default Google uses google.com as Issuer in requests and expects google.com as Audience in responses; the domain-specific google.com/a/DOMAIN form is used only when multiple Cloud Identity accounts force the IdP to distinguish sign-ons. OAuth 2.0 issues scoped tokens that let an application act on a federated user's behalf without sharing credentials, with Workforce Identity Federation OAuth integration working only with IAP. A leaked workforce OAuth secret must be rotated in order: create a new credential, disable the old credential, then delete the old credential after the replacement is in use.
Configuring and enforcing 2-step verification requires a password plus a second factor before an account can manage Google Cloud. Accounts subject to enforcement must enroll before accessing the Google Cloud console and Firebase console, while traffic to workloads and IAP-protected applications continues to flow. Separate paths sit outside this requirement, including Workspace apps under separate Workspace policy, YouTube, workload data planes, and gcloud CLI, although 2SV becomes part of sign-in after the user enables it.
Enforcement lifecycle moves from upcoming enforcement in the reminder window to enforced where console access triggers enrollment to compliant where the requirement is satisfied. Organizations using Enterprise Cloud Identity without SSO can receive a one-time 90-day extension or opt out by disabling enforcement, which bypasses the requirement without disabling 2SV for already-enrolled users. Hardware security keys provide phishing-resistant protection because the physical key must be present, with Titan Security Keys recommended for super admins, while phone factors remain vulnerable to SIM swap and interception. Security Command Center flags missing enforcement and disabled strong authentication, and Access Context Manager can enforce credential strength with CEL on authentication claims. Adding multi-factor authentication to a web app (opens in a new tab) follows the same principle of requiring a second factor at sign-in.
Exam tip: Session length for Google Cloud services expires gcloud and API credentials on a 1 to 24 hour policy with a 16 hour default, while session length for Google services controls only Workspace web sessions.
Continue with this study guide: Managing authentication
Managing and implementing authorization controls means binding principals to roles at a defined scope and checking every request against that binding. Identity and Access Management (IAM) allow policies grant permissions, while IAM Conditions, IAM deny policies, principal access boundary policies, and organization constraints narrow that access. A toxic combination occurs when one principal holds both grant permissions such as resourcemanager.projects.setIamPolicy and data-use permissions.
Separation between grant authority and resource use keeps policy administration distinct from data use. Project IAM Admin can assign bindings for a project but does not by itself grant data use, while application roles such as Chronicle API Admin provide full feature use. Enforcement follows a fixed order: the principal sends a request, the service queries IAM policies for that user or group, IAM returns a decision based on roles, conditions, and scope, and the service enables only granted features.
Privileged Access Manager (PAM) provides temporary elevation with justification, approvals, and history. An administrator creates an entitlement defining who can request which roles on which resources, a requester creates a time-bound grant with justification, and PAM removes the roles automatically at expiry. Alternatives without built-in workflow include IAM Conditions with time limits, Google Groups with expiring membership, and service account impersonation where a group holds only Token Creator on a privileged account. The PAM lifecycle moves from entitlement to request to approval to active grant to expiry into auditable history.
The effective allow policy for any resource is the union of its own policy plus all policies inherited from its organization, folder, and project parents. A grant at a higher level flows to every child, while a grant at a lower level applies only within that child. Because Owner includes Editor and Editor includes Viewer, an inherited role that already covers the need makes a lower-level grant redundant.
Deny evaluation happens before allow evaluation on every request. Traffic flows from the request to the deny engine first and then, only if no deny rule blocks it, to allow evaluation. A deny policy attaches at an organization, folder, or project and flows downward, with up to 500 deny policies and 500 deny rules per resource and propagation generally within 2 minutes. Each rule names denied principals, denied permissions such as iam.googleapis.com/roles.delete, optional exception principals, and an optional CEL condition based only on resource tags. Conditional allow bindings grant a role only when a CEL expression on resource name, type, service, tags, IP, or time evaluates to true, but a conditional binding never removes access granted by an unconditional binding for the same principal and role.
Uniform Bucket-Level Access (UBLA) is the recommended Cloud Storage model that disables object ACLs and enforces one bucket IAM policy for all objects. When UBLA is enabled, requests that try to set or read object ACLs are rejected and data flows from the requester to a single IAM check against the bucket policy plus inherited ancestors. Legacy ACLs instead attach separate lists to the bucket and to each object, letting a permissive object ACL survive a restrictive bucket policy and forcing audit of every object.
Custom IAM roles contain only the permissions required for a task, with permissions in the form service.resource.verb bundled into a role and granted on a resource. Predefined roles fit common tasks, custom roles remove excess permissions when no predefined role fits, and basic Owner, Editor, and Viewer roles should remain only for test use. The setIamPolicy permission effectively allows granting all other permissions on its scope, so it must be excluded from custom roles unless policy administration is intended. Scoped policies for Access Context Manager break normal inheritance because they can be granted only at the organization level or on individual policies.
Access Context Manager defines context-aware boundaries from identity, device, and network signals. An access policy is the organization-wide container for access levels and VPC Service Controls perimeters, but a level alone blocks nothing until attached through bindings, IAM conditions, or ingress rules. A regular perimeter defines one security zone, while a bridge perimeter connects projects in different regular perimeters for controlled sharing. Cross-perimeter flows need a matching pair: an egress rule on the source perimeter and an ingress rule on the destination perimeter.
Policy Intelligence shows what access exists, what would change, and why a request was allowed or denied. IAM Recommender compares granted permissions with actually used permissions and suggests tighter roles, Policy Analyzer audits effective access as the union of direct and inherited grants, Policy Simulator replays the last 90 days of activity against a proposed policy, and Policy Troubleshooter explains current decisions but returns Unknown when group membership cannot be resolved. Managing permissions through groups keeps allow policies stable by granting roles once to group emails such as gcp-organization-admins and changing access through membership, where removal immediately removes roles that flowed only through that group.
Exam tip: A deny always wins over an allow grant, and expired IAM Conditions remain in the allow policy until removed, while deny policies never support time-based exemptions.
Continue with this study guide: Managing and implementing authorization controls
Defining the resource hierarchy means organizing every Google Cloud resource under a single organization node so governance flows downward to workloads. The hierarchy starts at the organization root, branches into folders that group related work, and ends in projects that host virtual machines, buckets, and networks. Projects act as the core billing and trust boundary, while folders act as policy attach points and isolation boundaries. About resource hierarchy (opens in a new tab) defines this organization-to-folder-to-project structure.
Governance flows through a single parent path where every folder or project has exactly one parent. Organization policies are inherited by descendants but can be superseded by a lower folder or project policy, IAM allow policies are inherited and additive so a folder grant applies to all contained projects, and IAM deny policies are evaluated before allows and can block an inherited allow. For example, Compute Instance Admin granted on a folder applies to all contained projects unless a higher deny blocks it.
Scale is bounded by folder limits and move semantics. A parent folder can contain up to 300 direct child folders, folders can nest up to 10 levels deep, and display names must be unique within the same level. Creating a project in a folder requires the Project Creator role on that folder. Moving a project does not carry inherited permissions with it: directly attached policies move with the project while inherited policies stay with the source parent, so moving from a folder that granted Storage Object Creator removes that access unless the destination grants it.
Choosing a hierarchy model means following policy and autonomy needs rather than copying the corporate chart. Decide a resource hierarchy for your landing zone (opens in a new tab) compares environment, region, and accountability groupings that trade central consistency for team autonomy.
| Hierarchy model | Top-level grouping | Control tradeoff |
|---|---|---|
| Based on application environments | Development, testing, and production folders | Centralized; consistent production controls but less team autonomy |
| Based on regions or subsidiaries | Subsidiary and regional folders such as APAC and EMEA | Federated; independent regulatory controls but more coordination |
| Based on accountability framework | Product or module folders | Decentralized; product-owner control but harder organization-wide guardrails |
Enterprise separation uses dedicated folder branches so each owner controls only its scope, such as a Network Team folder for VPCs, a Cluster Team folder for platform clusters, and a Tenants folder for tenant resources. Placing clusters in dedicated projects improves cluster-configuration isolation, workload-security isolation, and per-project quota isolation, while per-environment folders above them still allow shared policies and aggregated log sinks.
The Organization Policy Service stores constraints that cascade from organization to folders to projects. Custom constraints are administrator-defined YAML rules with CEL expressions that restrict specific resource fields when predefined constraints are imprecise. First the administrator defines the constraint, then creates the policy that uses it, and only then does the control plane evaluate new create or update requests against it.
List and boolean constraints combine differently down the tree. List constraints merge child values with inherited values, support up to 500 values and 32 KB, and support under: subtree expansion such as under:folders/VALUE_A. Boolean constraints override rather than merge, so the child enforce: true or enforce: false replaces the parent for that branch. Changes can take up to 15 minutes to enforce, apply only to later creates and updates, and automatically cover projects added later. Testing moves from Policy Simulator preview to dry-run audit logging in dryRunSpec to live denial in spec, where describe --effective and Policy Analyzer show the resolved effective policy.
Exam tip: Allow policies inherit and add together down the hierarchy, but deny policies are applied first and can override an allow; list-constraint children merge while boolean-constraint children override.
Continue with this study guide: Defining the resource hierarchy
google.com.principal:// for one subject and principalSet:// for a group, attribute, or whole pool, with CEL attribute mappings, session duration between 15 minutes and 12 hours, and Policy Intelligence tools that require non-federated identities for recommender and simulator work.Use Google Cloud Directory Sync (GCDS) when each user should have both an external account and a Google account synchronized from Active Directory to Cloud Identity without synchronizing passwords. Use Workforce Identity Federation when each user should keep only the external account and sign in through a workforce identity pool without duplicating users. In both models, Identity and Access Management roles are assigned once to role-aligned groups and users gain or lose permissions only by entering or leaving groups.
The Compute Engine default account and the App Engine default account may automatically receive the Editor role on the project, which allows reading and modifying almost all resources, so compromise of one workload can affect data owned by all workloads sharing that account. Replacement uses per-workload identities with minimal predefined roles scoped to one bucket, dataset, or repository, plus Identity and Access Management Conditions where needed. In Google Kubernetes Engine, Workload Identity links a Kubernetes ServiceAccount to a Google service account so pods receive only the Google roles they need instead of sharing the node identity.
The effective allow policy for any resource is the union of its own policy plus all policies inherited from its organization, folder, and project parents, so a grant at a higher level flows to every child. Deny evaluation happens before allow evaluation on every request, so a deny policy attached at an organization, folder, or project flows downward and blocks an inherited allow when it matches. Conditional allow bindings grant a role only when a Common Expression Language expression evaluates to true, but a conditional binding never removes access granted by an unconditional binding for the same principal and role.
Super administrator accounts bypass organization single sign-on and authenticate directly to Cloud Identity, so they require mandatory multi-factor authentication with phishing-resistant hardware security keys, separate administrator-style logins, short sessions, and disabled self-recovery with peer-assisted recovery by another super administrator. Best practice maintains more than one super administrator and more than one Organization Administrator, grants the Organization Administrator role to a private group without including the super admin user, and assigns routine Identity and Access Management roles to groups.
Last updated