Prepare and test your skills
Prepare and test your skills
An Identity and Access Management (IAM) (opens in a new tab) permission is the smallest unit of access and allows one specific action on one type of Google Cloud resource. Permissions use the format SERVICE.RESOURCE.VERB, such as compute.instances.list to list Compute Engine instances, bigtable.instances.list to list Bigtable instances, or pubsub.topics.publish to publish to a Pub/Sub topic. Permissions usually match API methods one-to-one, so calling a method requires its matching permission.
Permissions are never assigned directly to a user, group, or service account in BigQuery (opens in a new tab). When a principal calls a Google Cloud API, IAM checks whether a role granted to that principal contains the minimum permission needed for that 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. A principal can be a user, Google group, or service account, and when the principal receives a role, the principal receives every permission inside that role. When a principal receives multiple roles, the effective access is the union of all permissions in all roles, so access only grows as more roles are added.
A role granted on a parent resource also applies to descendants of that resource through policy inheritance in the resource hierarchy. 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. In BigQuery, grantable resources include datasets and management objects:
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.
Basic, predefined, and custom roles differ in how broad their permissions are and who defines them. Basic roles provide broad access across many services, predefined roles provide granular access for one service and are managed by Google Cloud, and custom roles provide exact access from a customer-chosen list of permissions.
| 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 customer-chosen list of permissions | Customer | Predefined definitions change too often or include more access than needed |
The legacy basic roles, formerly called primitive roles, build on each other:
roles/viewer) allows read-only viewing of existing resources and data across all services without changing state.roles/editor) includes all Viewer access plus creating, changing, and deleting resources for most services, but not all actions for all services.roles/owner) includes all Editor access plus administration such as managing roles and permissions, setting up billing, and managing tag bindings.Basic roles include thousands of permissions and have important limits for data work. Conditions cannot be added to bindings for legacy basic roles, and Owner does not contain every permission, such as modifying Cloud Billing payment information or creating IAM deny policies. Predefined roles are scoped to one service, so work that spans services needs a role for each service, such as a BigQuery role plus a separate Cloud Storage role. Predefined roles can change over time because Google Cloud may add permissions when services gain capabilities, while custom roles stay fixed unless the owner changes them.
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.
Resource level in BigQuery controls whether access is broad or limited to one dataset or table. Least privilege means giving each principal no more access than is needed, so administrators choose the narrowest resource level that still lets the principal do its work. Narrower grants reduce exposure because the principal receives permissions only on the data it needs and not on sibling resources.
A hierarchy showing how an IAM role granted at the organization, folder, or project level flows down through datasets to tables, views, and routines, with callouts that narrower grant levels follow least privilege.
| Grant level | Scope of access | Choose when |
|---|---|---|
| Organization, folder, or project | All BigQuery resources in that organization, folder, or project | The principal needs broad access across many datasets |
| 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 |
| 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 other resources in the project. Roles can be applied even more narrowly to tables and views and to routines, so a principal can read from one table but not write to it or read the rest of the dataset. To verify exactly which permissions a role contains before granting it, use the BigQuery IAM roles and permissions reference, the IAM roles and permissions index, the gcloud iam roles describe command, or the roles.get() method in the IAM API.
Basic roles provide broad access across many services and resources, predefined roles provide granular access for one service and a common job pattern and are managed by Google Cloud, and custom roles provide an exact customer-chosen list of permissions. Basic roles include Viewer for read-only viewing of existing resources and data, Editor that includes all Viewer access plus creating, changing and deleting resources, and Owner that includes all Editor access plus administration such as managing roles and permissions, setting up billing and managing tag bindings. Predefined roles are scoped to one service so work spanning services needs a role for each service, and Google Cloud may add permissions to predefined roles over time while custom roles stay fixed unless the owner changes them.
Grant at the organization, folder, or project level when the principal needs broad access across many datasets, at the dataset level when the principal needs all or most tables in one dataset but nothing else, and at the table, view, or routine level when the principal needs only one or a few objects inside a larger dataset. Least privilege means giving each principal no more access than is needed, so choose the narrowest resource level that still lets the principal do its work. A role granted on a project applies to all BigQuery resources in that project through policy inheritance, while a dataset grant applies only to that dataset and a table, view, or routine grant applies only to that object.
An Identity and Access Management permission is the smallest unit of access and allows one specific action on one type of Google Cloud resource, while a role is a named collection of permissions granted to a principal such as a user, Google group, or service account. Permissions are never assigned directly to a user, group, or service account in BigQuery and IAM checks whether a role granted to the principal contains the minimum permission needed when the principal calls an API. When a principal receives multiple roles, the effective access is the union of all permissions in all roles, so access only grows as more roles are added.
Last updated