Prepare and test your skills
Prepare and test your skills
Permission granularity and role composition in Identity and Access Management (IAM) (opens in a new tab) describe how small, single-action permissions are packaged into broader roles for data services such as BigQuery (opens in a new tab). A permission allows one specific action on one type of resource, while a role is a collection of permissions granted to a principal such as a user, group, or service account. This packaging lets administrators follow least privilege by giving each principal no more access than is needed for its work.
An IAM permission is the smallest unit of access and allows a principal to perform one specific action on a Google Cloud resource. Permissions use the format SERVICE.RESOURCE.VERB, for example compute.instances.list to list Compute Engine instances or bigtable.instances.list to list Bigtable instances. Permissions usually correspond one-to-one with API methods, so calling a method requires its matching permission, such as needing pubsub.topics.publish to call the Pub/Sub projects.topics.publish method.
Permissions are never assigned directly to users, groups, or service accounts in BigQuery. When a principal calls a Google Cloud API, IAM checks whether a role granted to that principal contains the minimum permission needed for the resource. A single data operation can require several permissions, such as bigtable.tables.get plus bigtable.tables.readRows to find and read a table, which is why roles bundle related permissions together.
An IAM role is a named collection of permissions that is granted to a principal on a particular resource. When a principal receives a role, the principal receives every permission inside that role, and when a principal receives multiple roles, the effective access is the union of all permissions in all roles. Each role has a title for display in the console, a name used in allow policies such as roles/bigquery.dataViewer, an ID, a description, a launch stage such as ALPHA, BETA, or GA, and its permission list.
Roles are granted on a resource but also apply to descendants of that resource through policy inheritance in the resource hierarchy. In BigQuery, grantable resources include datasets and the objects inside them, plus management objects. These grantable resources include:
A role granted on a project therefore applies to all BigQuery resources in that project, while a role granted on a dataset or on a single table applies only to that dataset or table and its children.
Basic, predefined, and custom roles differ in how broad their permissions are and who defines them. Basic roles provide broad access across Google Cloud resources, predefined roles provide granular access for a specific service and are managed by Google Cloud for common use cases, and custom roles provide granular access from a user-specified list of permissions. Predefined roles can change over time because Google Cloud may add new permissions or new predefined roles when BigQuery gains capabilities, while custom roles stay fixed unless the owner changes them.
| Role type | Scope of access | Managed by | Choose when |
|---|---|---|---|
| Basic roles | Broad access across many services and resources | Google Cloud | Broad administration is needed, not least-privilege data access |
| Predefined roles | Granular access for one service and common job pattern | Google Cloud | A standard data job such as viewing or editing BigQuery data fits the need |
| Custom roles | Exact user-chosen list of permissions | Customer | Predefined definitions change too often or include more access than needed |
Exam tip: Do not grant BigQuery basic roles at the dataset level — the dataset-level Owner basic role does not provide table access permissions and gives excessive, uneven access.
Role scope in BigQuery controls whether access is broad or limited to one dataset or table. Granting a BigQuery role on an organization, folder, or project through Resource Manager gives permissions on all BigQuery resources in that organization or project. Assigning a role at the dataset level gives access to only that specific dataset without giving access to other datasets in the project, because datasets are child resources of projects.
A vertical tree of the resource hierarchy from Organization down to Folder, Project, Dataset, and Tables/Views/Routines, with role grants inheriting downward to all descendants. Side callouts describe the access scope at each level and warn against granting dataset-level basic roles.
Granting roles on individual resources within a dataset gives the narrowest access for table-level work. Roles can be applied directly to tables and views and to routines, which supports patterns such as allowing a user to read from one table but not write to it. To verify exactly which permissions a role contains before granting it, view the role in the console, run gcloud iam roles describe, call roles.get() for predefined roles, or check the BigQuery IAM roles and permissions reference and the IAM permissions reference.
Basic roles and predefined roles in Identity and Access Management (IAM) (opens in a new tab) are two different ways to grant permissions to a principal on a resource. A principal can be a user, a Google group, or a service account, and a permission has the format SERVICE.RESOURCE.VERB, such as pubsub.topics.publish. When a role is granted on a project, folder, or organization, lower-level resources inherit that grant through the resource hierarchy, so a grant at the project level flows down to the BigQuery (opens in a new tab) datasets and Cloud Storage buckets inside that project.
Basic roles are highly permissive roles that grant broad access across all Google Cloud services in a project. The legacy basic roles, formerly called primitive roles, are Viewer (roles/viewer), Editor (roles/editor), and Owner (roles/owner), and each one includes thousands of permissions. A principal with a legacy basic role also receives extra access that individual services provide to basic-role holders, such as Cloud Storage convenience values and BigQuery special group membership.
The three legacy basic roles build on each other in scope:
| Legacy basic role | Scope | What it allows |
|---|---|---|
Viewer (roles/viewer) | Read-only across all services | View existing resources and data without changing state |
Editor (roles/editor) | All Viewer access plus state changes | Create, change, and delete resources for most services, but not all actions for all services |
Owner (roles/owner) | All Editor access plus administration | Manage roles and permissions for the project, set up billing for the project, and complete sensitive tasks such as managing tag bindings |
Basic roles have important limitations for data services. Conditions cannot be added to bindings for legacy basic roles, and the Owner role does not contain every permission, such as modifying Cloud Billing payment information or creating IAM deny policies. The Owner role can only be granted to Google Accounts, service accounts in the organization, and Google groups in the organization, and the Google Cloud console must be used when the user is outside the organization or the project is outside any organization.
Predefined roles are granular, service-specific roles that are created and maintained by Google. Predefined roles give access to only one service or use case, and Google automatically updates their permissions when new features, permissions, or services are added. Because a predefined role applies only to its own service, additional roles are required for other services.
Predefined roles share three practical characteristics:
An account with only an App Engine Deployer role can deploy apps but cannot view or create objects in Cloud Storage without a separate Cloud Storage predefined role. The same separation applies between BigQuery roles and Cloud Storage roles, so work that spans two services needs a role for each service.
The difference between basic and predefined roles is scope and control. A basic role applies to all services and resources in a project, so an Editor can change both application settings and storage settings, while a predefined role limits the principal to one service and to the permissions in that role. For least privilege, the recommended choice is the most limited predefined role that contains the permissions the principal needs, adding a second predefined role when work spans two services rather than using one broad role.
Exam tip: Do not grant basic roles in production unless there is no alternative; use basic roles only for small projects or development and test environments, and use predefined roles for production data access.
Least-privileged access in Identity and Access Management means no IAM principal should have more permissions than it actually needs. An IAM principal is a user, group, or service account that calls a Google Cloud API, and that call succeeds only when the principal has the minimum IAM permissions required for the resource. BigQuery (opens in a new tab) uses IAM to grant granular access to specific data resources while preventing access to other resources.
Permissions, roles, and principals work together through grants that IAM checks on every API call. Permissions in BigQuery are the individual rights to perform actions on resources, but permissions are never assigned directly to users, groups, or service accounts. A role is a collection of permissions that is granted to a principal on a particular resource, and the principal receives all permissions contained in that role.
A grant on a parent resource automatically applies to all of that resource's descendants in the resource hierarchy. For example, a role granted on a project applies to the datasets, tables, and views inside that project because datasets are child resources of projects. When a principal receives multiple roles, the effective permissions are the union of each role's permissions, so access only grows as more roles are added.
Predefined, custom, and basic roles compare by who defines them and how broadly they apply. Predefined roles in BigQuery are collections of permissions that are managed by Google Cloud and designed for common use cases and access patterns. Custom roles are collections where the organization chooses its own list of permissions to match a specific job that predefined roles do not fit. Basic roles are broad, legacy roles that existed before IAM and provide excessive and uneven access in BigQuery.
Predefined roles can change over time because Google Cloud may add new permissions to existing predefined roles or introduce new predefined roles when BigQuery adds capabilities. Organizations that need role definitions to remain unchanged should create custom roles instead of relying on predefined roles. To check whether a predefined role contains specific permissions, use one of these supported methods:
gcloud iam roles describe commandroles.get() method in the IAM APIExam tip: Do not grant BigQuery basic roles at the dataset level because they provide excessive and uneven access — the Owner basic role does not provide table access permissions.
Least privilege in BigQuery is applied by choosing the narrowest resource level that still lets the principal do its work. Access can be granted at the organization, folder, or project level, at the dataset level, or on individual resources inside a dataset. Narrower grants reduce exposure because the principal receives permissions only on the data it needs and not on sibling resources.
| Grant level | Scope of access | Choose when |
|---|---|---|
| Resource Manager resources | All BigQuery resources in the organization, folder, or project | The principal needs broad access across many datasets in that project or organization |
| Dataset | One specific dataset without access to other datasets in the project | The principal needs all or most tables in one dataset but nothing else in the project |
| Table, view, or routine | One table, view, or routine without full access to its parent dataset | The principal needs only one or a few objects inside a larger dataset |
Roles at the dataset level provide access to a specific dataset without providing complete access to the project's other resources. Roles can be applied even more narrowly to tables and views and to routines, so a principal can read one table without reading the rest of the dataset. IAM policies for BigQuery can also cover connections, saved queries, data canvases, data preparations, pipelines, and repositories, which lets administrators separate data-reading work from management and sharing work.
An Identity and Access Management permission allows one specific action on one Google Cloud resource, while an Identity and Access Management role is a named collection of permissions granted to a principal such as a user, group, or service account. Permissions are never assigned directly to principals in BigQuery, and when a principal receives multiple roles the effective access is the union of all permissions in all roles.
Basic roles provide broad access across many Google Cloud services and are for broad administration rather than least-privilege data access, predefined roles provide granular access for one service and common job pattern and fit standard data jobs such as viewing or editing BigQuery data, and custom roles provide an exact customer-chosen list of permissions when predefined definitions change too often or include more access than needed. For least privilege, use the most limited predefined role that contains the needed permissions and add a second predefined role when work spans two services rather than using one broad role.
A BigQuery role granted on a project applies to all BigQuery resources in that project, a role granted on a dataset applies only to that dataset and the tables, views, and routines inside it, and a role granted on a table, view, or routine applies only to that object. Grants follow policy inheritance so a grant on a parent resource applies to descendants, which is why dataset or table level grants limit exposure compared to project level grants.
A data engineering team wants to allow a new team member to upload raw data files to a Google Cloud Storage bucket. Following the principle of least privilege, the team wants to ensure the user receives only the specific capability to write objects (such as storage.objects.create), without gaining unnecessary administrative control or wide access across the entire project.
Which statement accurately describes how Google Cloud IAM structures permissions and roles to fulfill this access requirement?
Last updated