Prepare and test your skills
Prepare and test your skills
Conditional access controls in Google Cloud are Identity and Access Management (IAM) (opens in a new tab) allow policies that grant a role only when a condition expression evaluates to true. A standard binding always grants the permissions in the role, while a conditional binding grants the same permissions only for requests that match attributes such as resource tags, resource name, resource type, service, IP address, or date/time. This refinement enforces least privilege by keeping broad hierarchy grants narrow without creating a separate role for every exception.
How allow policies flow from organization to resource is defined by the Google Cloud resource hierarchy and downward inheritance. The Organization resource sits at the apex, folders sit below the organization, projects sit inside folders or the organization, and service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints sit inside exactly one project. Resource Manager (opens in a new tab) creates and organizes this hierarchy, so moving a node also moves which policies the node inherits.
The IAM model that attaches to this hierarchy has four connected parts: principal who requests access, role that collects permissions, permission that allows one operation, and IAM allow policy that binds principals to a role on a resource. The effective allow policy for any resource is the union of the policy set directly on that resource plus all policies inherited from its parents. A grant at a higher level therefore flows to every child, while a grant at a lower level applies only within that child.
| Hierarchy level | Scope of grant | Inheritance effect |
|---|---|---|
| Organization | All resources under the company node | Inherited by every folder, project, and resource |
| Folder | Projects and subfolders inside the folder | Inherited by contained projects, folders, and their resources |
| Project | Trust boundary for services in the project | Inherited by all resources within that project |
| Resource | Single service resource, such as a Pub/Sub topic | Applies only to that resource, plus inherits from project, folder, and organization |
Choose a higher level when many children need the same access, and choose a lower level or add a condition when only a subset should have it. Because Owner includes Editor and Editor includes Viewer, an inherited role that already covers the needed permissions makes an additional lower-level grant redundant.
IAM Conditions are condition expressions added to a role binding that restrict when the binding grants access. The binding still connects a principal to a role on an organization, folder, project, or resource, but the permissions in the role can be used only if the request satisfies the condition. For resource-based control, the condition can test the name, type, and service of the target resource.
Resource-based conditions work on many services that accept IAM allow policies, including BigQuery, Bigtable, Cloud Storage, Compute Engine, Cloud SQL, Spanner, Secret Manager, Cloud Key Management Service, Pub/Sub Lite, and Google Kubernetes Engine. The same pattern adapts from projects to any supported resource type: attach the allow policy at the parent container, then limit the binding with a resource.name, resource.type, or resource.service test. This lets one project-level grant cover dozens of matching resources without granting access to non-matching resources in the same project.
Exam tip: A conditional binding never removes access from an unconditional binding — if a principal has the role without a condition, the principal always has that role even when a condition on another binding is false.
Tags in Resource Manager are annotations attached to resources that enable fine-grained, context-aware allow and deny decisions across the hierarchy. A tag can mark purpose, environment, or sensitivity, such as production versus sandbox, and a conditional IAM policy or organization policy then allows or denies access only when the target resource carries that specific tag. Because tags travel with resources independent of folder placement, one policy can enforce the same rule on scattered resources that share a tag.
Tag conditions complement hierarchy inheritance by adding a second axis of control. Hierarchy inheritance answers where the policy applies, while the tag condition answers which tagged resources inside that scope are actually accessible. Use tags and conditional enforcement when folder boundaries alone are too coarse, such as allowing an operation in production only on resources tagged for a specific team or data classification.
Resource-name prefix conditions grant access to a group of resources whose full resource names share a starting string. The prefix convention typically encodes purpose or ownership, such as virtual machine names that start with a team or workload identifier, and the condition grants the role only when resource.name starts with that prefix. Data flows from the principal's request to IAM evaluation to the target resource, and access is permitted only after both the role check and the prefix match succeed.
This approach reduces the number of individual resource-level bindings while preserving least privilege within a project. First, define a consistent naming pattern for the group, then create a single conditional binding at the project level, then verify that non-matching resources remain inaccessible. Choose prefix conditions when membership can be expressed in the name itself, and choose tags when membership depends on properties that names cannot safely carry.
Operational limits for resource-based conditions determine whether a condition will behave safely in production, especially when policies inherit and when permissions operate at the parent. Review these limits before applying resource-based conditions broadly, because an inherited condition that assumes one service may fail or over-grant on another service in the same hierarchy.
Custom IAM roles with precise permissions are user-created roles that contain only the permissions required for a task. Identity and Access Management (IAM) (opens in a new tab) controls who has what access to which resources by attaching an allow policy to a resource. An allow policy (opens in a new tab) contains role bindings that associate a principal, such as a user, group, or service account, with a role on a specific organization (opens in a new tab), folder, project, or resource.
Custom, predefined, and basic roles are the three IAM role types, and they differ in who manages them and how much access they grant. Permissions have the form service.resource.verb and correspond closely to API methods, such as resourcemanager.organizations.get to get organization details. You never grant a permission directly to a principal; you bundle permissions into a role and grant the role on a resource, and a principal can hold multiple roles on the same resource.
| Role type | What it contains | Choose when |
|---|---|---|
| Predefined role | Google-managed permissions for common tasks in a service, such as Pub/Sub Publisher (roles/pubsub.publisher) to publish to a topic | A predefined role matches the task without large extras |
| Custom role | Only the permissions you specify, with complete control over the list | No predefined role fits and you need to remove excess permissions |
| Basic role | Thousands of permissions across services with broad access, including Owner (roles/owner), Editor, and Viewer | Only for test or development, not for production |
Custom roles carry tradeoffs that matter at advanced scope. Custom roles have higher maintenance burden than predefined roles because you must track permission changes, and there is a limit to how many custom roles you can have in a project and in an organization. Basic roles are the riskiest default because they grant far more than most jobs need, so replace them in production with the most limited predefined role or a custom role, using role recommendations and Policy Simulator to verify that access will still work.
Selecting only the permissions a task requires means starting from the exact API actions in the task and including nothing else. For visibility work, viewing an inherited policy requires resourcemanager.organizations.getIamPolicy on the organization, resourcemanager.folders.getIamPolicy on the folder, or resourcemanager.projects.getIamPolicy on the project. When a custom role includes folders.list and folders.get for browsing, it should also include projects.list and projects.get so navigation works consistently.
Several permissions expand effective privilege and require extra care in a custom role. The setIamPolicy permission on organization, folder, and project resources allows the holder to grant all other permissions, so it should be assigned with care. Granting Project IAM Admin (roles/resourcemanager.projectIamAdmin) or Folder IAM Admin allows modification of allow policies without granting direct read, write, and administrative access to all data resources, while granting Owner allows access and modification of almost all resources including allow policies. The Service Account User role is similarly sensitive because users who can act as a service account can access all resources to which that service account has access.
Exam tip: setIamPolicy on an organization, folder, or project effectively allows granting all other permissions on that scope, so never include it in a custom role unless policy administration is the intended job.
Applying custom roles at the right level in the hierarchy determines how far the permissions reach because allow policies inherit downward. The organization is the root node, folders are children of the organization or another folder, projects are children of the organization or a folder, and service resources are descendants of projects. A role granted on a container applies to that container and to all descendants, so a grant at the organization affects everything below it while a grant on a single topic, virtual machine, or dataset affects only that resource.
Least-privilege placement means granting the custom role at the smallest scope that still covers the work. If a principal only needs to publish messages, grant Publisher on that Pub/Sub topic rather than on the project. If a principal needs access to 3 of 10 projects in a folder, grant the role on each of the 3 projects individually rather than on the folder, because a folder grant would expose the other 7 projects. If the same access must span multiple projects, grant once at the folder level so projects inherit it automatically, and use IAM Conditions when you need an organization- or folder-level grant that applies to only a subset of folders or projects.
Inheritance behavior creates operational details that affect custom-role design. Allow policies are additive, so moving a project into a folder can grant additional roles and moving it out can remove roles and break apps or workflows. To understand effective access on a resource you must view all allow policies that affect it, including inherited policies, and the Google Cloud console shows inherited roles on a resource only if those roles are grantable on that resource. Prefer granting custom roles to groups rather than individual users, treat each application component as a separate trust boundary with its own service account and only its required permissions, audit setIamPolicy() calls in audit logs and audit group ownership and membership, and restrict membership to your domain with the iam.allowedPolicyMemberDomains organization policy constraint.
Mapping the resource hierarchy and evaluating policy inheritance means tracing how IAM policies flow from the top node downward. The Google Cloud resource hierarchy is a parent-child tree that controls where access policies attach and how they flow downward. The Organization resource (opens in a new tab) sits at the root, folders branch below it, projects sit inside folders or the organization, and service resources sit inside exactly one project. The effective Identity and Access Management (IAM) allow policy for any resource is the union of its own policy plus every allow policy inherited from its parents.
Resource hierarchy levels and trust boundaries define four levels that combine ownership, visibility, and policy inheritance. Resource Manager (opens in a new tab) is the service that creates and organizes this hierarchy, so moving a node in Resource Manager also moves which policies the node inherits. Each folder or resource has exactly one parent, folders can nest up to 10 levels deep, a parent folder can hold no more than 300 direct child folders, and folder display names must be unique within the same level.
| Level | What it contains | How its allow policy propagates |
|---|---|---|
| Organization resource | Folders and projects for the whole company | Roles granted here are inherited by every descendant and give central visibility and control |
| Folder | Projects, other folders, or both | Roles granted here are inherited by all contained projects and subfolders, creating a delegation and isolation boundary |
| Project | Service resources such as Compute Engine virtual machines, Pub/Sub topics, Cloud Storage buckets, and Cloud VPN endpoints | Roles granted here act as a trust boundary and are inherited by all resources inside that project |
| Service resource | A single instance such as a Pub/Sub topic or Compute Engine instance | Roles granted here apply only to that resource and combine with inherited project, folder, and organization grants |
A project moved into a new folder or organization immediately stops inheriting from its old parent and starts inheriting from its new parent. Billing is assigned at the project level, but cost reports can aggregate by folder hierarchy. A single organization node is recommended except for testing major IAM changes, running a sandbox without production organization policies, or separating a sub-company that may be sold.
How IAM allow policy inheritance works is that permissions flow only downward and lower-level grants only add access. The access model uses four connected concepts: a principal who requests access, a permission that allows one operation, a role that collects permissions, and an IAM allow policy that binds principals to a role on a resource.
The effective allow policy for a child is the parent policy plus the child policy. For example, if project_1 grants the Editor role to Kalani and its topic topic_a grants the Publisher role to Nur, the effective access on topic_a is Editor for Kalani plus Publisher for Nur. If inherited access already covers the need, an extra grant on the child is redundant and has no effect, because basic roles are concentric with Owner including Editor and Editor including Viewer.
Controls that restrict or override inherited access are needed because allow inheritance alone cannot remove access at a lower level. Deny policies attach at the organization, folder, or project level, are evaluated before allow policies, and can block permissions that an inherited allow policy would otherwise grant. This makes deny the only way to carve out an exception below a broad allow grant without removing the higher grant.
Organization policies and hierarchical firewall policies also inherit, but with different override behavior. Organization policies are inherited by descendants yet can be superseded by a policy defined lower in the tree, so a folder can set a guideline for the whole branch while allowing a project exception. Hierarchical firewall policies inherit implicitly from the organization or folder, where each level can allow traffic, deny traffic, or delegate the decision to a lower level. Cloud Logging aggregated sinks can similarly collect logs at the folder or organization level for centralized audit of the same boundary.
Exam tip: Lower-level allow policies are additive and never remove inherited access; to restrict an inherited allow, use a deny policy, which is evaluated before allows.
Applying least privilege across the hierarchy means granting each principal the smallest role at the highest level that still covers the job, and pushing narrow grants as low as possible. Broad roles at the organization node expand to every folder, project, and resource below it, so organization grants should be limited to central administrators, auditors, and viewers who truly need company-wide reach. Folders enforce consistent security boundaries for a department, environment, or regulated workload set, while projects isolate teams and environments such as production versus staging because quotas, default trust, and many IAM settings are per-project.
Resource-level roles provide the tightest control by adding access to one Pub/Sub topic, Compute Engine instance, bucket, or dataset without widening project access. Use Google Groups for membership, grant Folder Viewer and Organization Viewer narrowly for visibility, and delegate folder creation and moves through the Folder Admin role, which only the Organization Admin can initially assign. Keep bootstrap infrastructure-as-code resources and shared services in separate folders directly below the organization so their powerful policies do not inherit into workload folders and workload policies do not leak into shared foundations.
setIamPolicy permission on an organization, folder, or project allows granting all other permissions on that scope and must be excluded from custom roles unless policy administration is the intended job.The effective allow policy for a resource is the union of its own policy plus all policies inherited from its organization, folder, and project parents, so permissions flow only downward. A grant at the organization is inherited by every folder, project, and resource below it, a folder grant is inherited by contained projects and resources, a project grant is inherited by all resources inside that project, and a resource grant applies only to that resource.
Lower-level allow policies are additive and never remove inherited access, so to restrict an inherited allow you must use a deny policy. Deny policies attach at the organization, folder, or project level and are evaluated before allow policies, which makes them the way to block permissions that an inherited allow would otherwise grant.
Use a conditional binding when a broad hierarchy grant should apply only to requests that match attributes such as resource tags, resource name, resource type, service, IP address, or date and time. The binding still connects a principal to a role on an organization, folder, project, or resource, but the permissions can be used only if the condition evaluates to true, and it never removes access granted by a separate unconditional binding.
Use a custom role when no predefined role matches the task without large extras and you need to include only the permissions the task requires. Predefined roles are Google-managed collections for common tasks, while basic roles such as Owner, Editor, and Viewer grant thousands of permissions across services and should be used only for test or development, not for production. Exclude the setIamPolicy permission from custom roles unless policy administration is the intended job, because on an organization, folder, or project it allows granting all other permissions on that scope.
An enterprise organization is refining access controls to comply with the principle of least privilege across its development environments. The security team needs to grant an operational group the Compute Instance Admin role (roles/compute.instanceAdmin.v1) on a folder containing multiple projects.
The access policy must meet the following constraints:
environment: development Resource Manager tag (either directly attached or inherited).Which IAM condition expression should the security engineer attach to the role binding?
Last updated