Prepare and test your skills
Prepare and test your skills
Designing group hierarchies is the practice of creating logical collections of users that mirror job functions or project teams and granting roles to the groups instead of to individuals. A parent group carries the Identity and Access Management (IAM) (opens in a new tab) role in a resource allow policy, and nested child groups inherit that access through membership. This structure enforces role-based access control and least privilege while reducing administrative work, because access changes when people join, move, or leave instead of requiring IAM policy edits.
A functional group hierarchy organizes Google Groups (opens in a new tab) by job responsibility so each group receives only the permissions needed for that function. Groups are named collections of Google Accounts and service accounts with a unique email address, such as gcp-billing-admins@example.com, and IAM roles granted to that email apply to every member. Foundational hierarchies separate highly privileged organization administration from narrower network, billing, security, and development duties across the organization, folder, and project resource hierarchy.
Recommended starting groups for this hierarchy (opens in a new tab) include:
gcp-organization-admins for administering all organization resources, assigned only to the most trusted usersgcp-billing-admins for setting up billing accounts and monitoring usagegcp-network-admins for creating Virtual Private Cloud networks, subnets, and firewall rulesgcp-hybrid-connectivity-admins for creating Cloud VPN instances and Cloud Router devicesgcp-security-admins for managing security policies, access management, and organization constraint policiesgcp-logging-monitoring-admins for full Cloud Logging and Cloud Monitoring use, paired with gcp-logging-monitoring-viewers for read-only accessgcp-developers for designing, coding, and testing applicationsgcp-devops for creating continuous integration and delivery pipelines, monitoring, and provisioningThe hierarchy trades broad visibility for risk, so organization-level roles apply to all contained resources and must be granted sparingly. Because holders of organization admin rights can access all Google Cloud resources, that function can use individual accounts instead of a group when tighter control is required. Assign more than one user to each remaining administrative group so duties remain covered without widening any single group.
Permission inheritance through nested groups means every member of a group receives all IAM roles granted to that group, and members of a nested child group receive them transitively. An administrator grants a role by adding the parent group email as a principal in the allow policy attached to an organization, folder, project, or service-specific resource such as a Compute Engine instance or Cloud Storage bucket. Roles granted on container resources flow down to all contained service resources, while roles granted on a service-specific resource limit access to only that resource for more granular control.
The flow runs from the resource allow policy to the parent group to each nested group and user, so adding or removing a member changes access without editing the IAM policy. A member inherits the IAM roles regardless of their Google Groups role, such as owner, manager, or member, because the Groups role controls discussion and management features, not IAM authorization. Service agents cannot be added to Google Groups unless the external members option is turned on, which places a trust boundary around automated Google-managed identities.
Exam tip: A Google Groups role controls who can manage or post to the group, while IAM roles granted to the group control who can access Google Cloud resources — all members inherit the IAM roles regardless of their Groups role.
The source of truth for group hierarchies is either Cloud Identity or an external identity provider connected through Workforce Identity Federation, and the choice determines where membership is managed. Google Workspace and Cloud Identity provide central provisioning of users and groups under a verified domain, with later synchronization to an external provider if needed. An external provider such as Microsoft Entra ID or Okta retains users and groups outside Google and asserts identities to Google Cloud through single sign-on.
| Option | Where groups are managed | How it connects to Google Cloud |
|---|---|---|
| Google Workspace or Cloud Identity | Users and groups are created and managed in Google as super administrator of the verified domain | Native management in the Groups page; can later synchronize with an external provider |
| External identity provider | Users and groups are created and managed in Entra ID, Okta, or another OIDC or SAML provider | Workforce identity pool trusts the provider, using a globally unique workforce pool ID and a provider ID that users specify at sign-in |
The federation path depends on the workforce pool, because the pool manages the external identities and their access to resources. First the pool and provider are created, then Google Cloud is configured in the external provider, then provider details are entered in Google Cloud to establish trust, and only after that are administrative groups mapped and users assigned. If federation is not ready, groups can be created temporarily in Cloud Identity or Google Workspace (opens in a new tab) and connected later.
Group lifecycle management covers creation, membership changes, and deletion, with audit trails that record who changed access and when. Group creation and deletion permissions are managed by Google Workspace, not IAM, while viewing groups in the Google Cloud console requires roles/resourcemanager.organizationViewer on the organization and viewing membership change logs requires roles/logging.viewer. Day-to-day access control uses group membership operations instead of IAM policy edits, which keeps policies stable as people join, move teams, or leave.
Deleting a group is irreversible and immediately removes the inheritance path for all nested members, so all IAM roles must be revoked from the group and at least 7 days allowed to pass before deletion to avoid unexpected access loss. Clear audit trails depend on enabling data sharing so Google Workspace events generate audit logs in Cloud Logging, where changes to IAM allow policies and changes to group membership can both be reviewed. Together, least-privilege role assignments, membership-based changes, and centralized logs let reviewers trace effective access from a resource back through parent and nested groups (opens in a new tab) to individual users.
Assigning and auditing IAM roles to groups is the practice of granting bundled permissions to a Google Group once and letting every member inherit that access, then continuously reviewing usage to remove excess privilege. A group is a named collection of Google Accounts and service accounts with a unique email address, such as gcp-billing-admins@example.com, and granting a role to the group updates the allow policy on the target resource. Auditing closes the loop by using IAM Recommender to rightsize bindings and Cloud Audit Logs to trace who changed policies and membership.
Group-based assignment implements role-based access control by mapping permissions to job responsibilities instead of to individual user accounts. An administrator edits the allow policy attached to a resource to bind a group principal to one or more roles, and IAM (opens in a new tab) uses that allow policy to decide whether a principal is authorized to act. Every member added to the group inherits all IAM roles granted to that group, regardless of the member's Google Groups role as owner, manager, or member.
Grants follow the Google Cloud resource hierarchy from organization to folder to project to service-specific resource. A role granted on a container resource such as an organization, folder, or project applies to all service-specific resources it contains, which gives central visibility and control but broad reach. A role granted on a service-specific resource such as a Compute Engine instance or Cloud Storage bucket limits access to just that resource, which supports granular control and the principle of least privilege.
Foundational administrator groups are starting-point bindings that separate duties for organization, network, billing, and security functions at the organization level. Each group receives only the predefined roles needed for its function, and highly privileged groups such as organization admins are assigned sparingly. When sensitive data or special workloads require tighter control, replace broad predefined roles with more fine-grained or custom roles.
| Group | Function | Key predefined roles |
|---|---|---|
grp-gcp-org-admin | Administers all organization resources | roles/resourcemanager.organizationAdmin, roles/resourcemanager.folderAdmin, roles/resourcemanager.projectCreator, roles/iam.organizationRoleAdmin, roles/orgpolicy.policyAdmin |
grp-gcp-network-admins | Creates networks, subnets, firewall rules, Cloud Router, Cloud VPN, and load balancers | roles/compute.networkAdmin, roles/compute.xpnAdmin, roles/compute.securityAdmin, roles/resourcemanager.folderViewer |
grp-gcp-billing-admin | Sets up billing accounts and monitors usage | roles/billing.admin, roles/billing.creator, roles/resourcemanager.organizationViewer |
grp-gcp-security-admins | Establishes organization security, access management, and organization constraint policies | roles/iam.securityReviewer, roles/securitycenter.admin, roles/orgpolicy.policyAdmin, roles/logging.privateLogViewer, roles/compute.viewer |
The table shows separation of duties in practice: network administration flows to network-focused Compute roles, billing administration flows to billing roles plus read-only organization visibility, and security administration flows to review, logging, and policy roles rather than full resource control. Administrators can add or remove roles to customize a group (opens in a new tab) and can delete an unused group, but deletion is irreversible. To avoid unexpected access changes, revoke all IAM roles from the group first and then wait at least 7 days before deleting it.
Exam tip: Every member of a Google Group inherits the same IAM roles granted to the group, regardless of whether their Google Groups role is owner, manager, or member.
IAM Recommender is the Policy Intelligence tool that uses machine learning to identify accounts and permissions that are no longer needed and to recommend least-privilege corrections. The recommender analyzes actual permission usage across members in the organization and produces insights, which are findings about notable usage patterns such as unused permissions and abandoned service accounts. Applying its REMOVE_ROLE recommendations rightsizes IAM bindings after employees change roles, leave, or finish temporary tasks.
At enterprise scale, recommendations from IAM Recommender can be exported to BigQuery for centralized review with visualization tools such as Looker. The export depends on the BigQuery Data Transfer Service, which pulls recommendation data from the Recommender service into a BigQuery dataset for querying:
recommendation_details where recommender = "google.iam.policy.Recommender" and recommender_subtype = "REMOVE_ROLE".This flow moves data from IAM Recommender to the BigQuery dataset to the reviewer, so group permissions are refined based on observed use rather than on original assumptions. Service agents cannot normally be added to Google Groups to receive these bindings unless the external members option is turned on.
Cloud Audit Logs in Cloud Logging provide the audit trail for identity lifecycle events, including changes to IAM allow policies and changes to group membership. When data sharing is enabled for the organization, Google Cloud automatically generates audit logs for actions taken in Google Workspace, such as adding a user to the organization or removing a user from a group. Reviewers can therefore trace both sides of an access change: the policy update that granted a group a role on a resource and the membership change that gave a specific user that group's access.
Viewing this history requires both identity and logging visibility. Group management permissions themselves are controlled by Google Workspace (opens in a new tab), not by IAM, while viewing groups and membership change logs in the Google Cloud console depends on IAM roles on the organization such as Organization Viewer (roles/resourcemanager.organizationViewer) and Logs Viewer (roles/logging.viewer). Custom roles or other predefined roles can supply the same permissions when narrower access is required.
Managing group lifecycle and synchronization is the end-to-end control of where identities originate, how group membership grants access, and when that access is removed or reviewed. In Google Cloud, Google Groups serve as the membership layer while IAM allow policies grant roles to those groups, so adding or removing a member changes effective access without editing the IAM policy itself. A complete lifecycle covers provisioning from an identity source, day-to-day membership changes for join, move, and leave events, safe deprovisioning and deletion, and periodic reviews that enforce least privilege.
The identity source determines where users and groups are created and how they connect to Google Cloud for single sign-on. Cloud Identity (opens in a new tab) is Google's identity as a service (IDaaS) solution that manages users and groups centrally, and Google Workspace provides the same directory capability with productivity services. An external identity provider retains users and groups in its own directory and connects to Google Cloud through federation, with later synchronization to Cloud Identity or Google Workspace also possible.
The guided setup in Google Cloud Setup: Users & groups offers the following peer paths:
Choose Google-central management when no external directory exists or rapid setup is needed, and choose federation when authoritative joiner, mover, and leaver processes already live in Entra ID, Okta, or another OpenID Connect or SAML provider.
| Management model | Where users and groups are authored | How Google Cloud access is established |
|---|---|---|
| Cloud Identity or Google Workspace | Users and managed user accounts plus groups are created in the Google directory | IAM roles are granted directly to Google Groups email addresses such as gcp-billing-admins@example.com |
| External identity provider with Workforce Identity Federation | Users and groups are created and managed in the external provider | Users sign in through a workforce identity pool where the external provider is registered as a trusted authority that asserts identities |
Provisioning creates the workforce identity pool trust, the administrative groups, and the membership links that drive IAM inheritance. To connect an external provider, the flow moves from Google Cloud to the provider and back to Google Cloud in order:
When Cloud Identity is the source, provisioning means creating one group per administrative function, creating managed user accounts for administrators, and assigning users to the groups that match their responsibilities. Before creating accounts, find and migrate existing consumer Google Accounts with unmanaged accounts tooling, and perform creation as a super administrator. Each group (opens in a new tab) is a named collection of Google Accounts and service accounts with a unique email address, and IAM roles granted to that address apply at scale across organization, folder, project, or service-specific resources.
Group creation and daily membership work in the Google Cloud console on the Groups page requires two separate permission planes. Group create, view, edit, and delete rights are Workspace group permissions managed by the Google Workspace administrator, not by IAM. Console use additionally depends on IAM roles on the organization, including Organization Viewer (roles/resourcemanager.organizationViewer) and, to view membership change logs, Logs Viewer (roles/logging.viewer). This split means the service depends on both the directory owner and the cloud resource owner to complete provisioning.
Exam tip: A member inherits all IAM roles granted to a Google group regardless of that member's Google Groups role, so the Groups role controls discussion and management rights, not cloud access.
Deprovisioning removes effective cloud access by removing group membership, revoking the group's IAM grants, or deleting the group when its function no longer exists. Because IAM inheritance flows from the group to each member, removing a user from Google Groups immediately removes all IAM roles that flowed only through that group, without touching the resource allow policy. This design supports role-based access control for join, move, and leave events: access changes follow membership changes, and permissions are never assigned to individual user accounts.
Group details, name, description, and membership are edited from View group details on the Groups page, where Add members and Remove members change the set of principals that inherit access. Features that are not IAM-related, such as moderation settings, joining rules, and post creation and viewing permissions, cannot be managed from the console and require opening the group with View in Google Groups. Service agents cannot be added to Google groups unless the external members option is turned on, which limits which automated identities can ride group-based grants.
Deleting a group is irreversible and permanently breaks the membership-to-role link for any remaining members. To avoid unexpected access changes, first revoke all IAM roles from the group, then wait at least 7 days before deleting it, then confirm deletion from the Groups page. The waiting period allows replicated policy evaluations, audits, and operational checks to surface hidden dependencies before the group identity disappears.
Review cycles validate that group memberships and role grants still match job requirements and remove orphaned access after role changes or departures. Policy Intelligence supports this work through the IAM recommender, which uses machine learning to identify accounts and permissions that are no longer used and to recommend least-privilege rightsizing. Recommendations include REMOVE_ROLE findings for unused role bindings, and insights highlight usage patterns such as unused permissions and abandoned service accounts that persist after tasks complete.
At enterprise scale, IAM recommender data flows from the Recommender service through BigQuery Data Transfer Service into a BigQuery dataset, where analysts query recommendation_details for google.iam.policy.Recommender findings and visualize results in Looker or Looker Studio. The review workflow is first, enable the BigQuery API and configure the export; then query the dataset for REMOVE_ROLE subtypes; then apply or reject each recommendation after human review. Applying a recommendation removes the unnecessary binding while leaving still-used access intact, which directly enforces the principle of least privilege across organization members.
Lifecycle evidence flows from Google Workspace into Cloud Logging when data sharing is enabled, automatically generating audit logs when a user is added to the organization or added to or removed from a group. Administrators with log viewing access can trace who changed group membership, correlate those changes with IAM policy changes, and prove that deprovisioning occurred. Together, automated provisioning from the authoritative identity source (opens in a new tab), membership-driven deprovisioning, and recommender plus audit-log reviews keep group-based authorization accurate as people join, move, and leave.
Every member of a parent Google Group receives all Identity and Access Management roles granted to that group email in a resource allow policy, and members of a nested child group inherit those roles transitively. Adding or removing a member changes effective access without editing the IAM policy, and roles granted on organization, folder, or project resources flow down to contained resources while roles on a service-specific resource apply only to that resource.
A Google Groups role of owner, manager, or member controls discussion and management features for the group, while Identity and Access Management roles granted to the group control access to Google Cloud resources. Every member inherits all Identity and Access Management roles granted to the group regardless of their Google Groups role.
Deleting a Google Group is irreversible and immediately removes the inheritance path for all nested members. All Identity and Access Management roles must first be revoked from the group and at least 7 days allowed to pass before deletion to avoid unexpected access loss.
Identity and Access Management Recommender uses machine learning to identify unused permissions and produces REMOVE_ROLE recommendations to rightsize group bindings for least privilege. Cloud Audit Logs in Cloud Logging trace both Identity and Access Management allow policy changes and group membership changes when data sharing is enabled, so reviewers can trace effective access from a resource back through parent and nested groups to individual users.
A financial services organization federates its workforce identity architecture with Cloud Identity and manages access across multiple Google Cloud projects using group-based IAM bindings. The security team must implement a group lifecycle and access governance strategy that satisfies the following requirements:
Which combination of Google Cloud identity and governance capabilities should the organization implement?
Last updated