BigQuery User Management Guide

• Model type: hybrid
• Description: BigQuery uses Google Cloud IAM for access control. Permissions can be granted at the organization, folder, project, dataset, table, or column level. Predefined roles bundle common permission sets. Custom roles can be created from individual IAM permissions. Dataset-level access can also be managed via the BigQuery API or Console Share dialog using legacy roles (OWNER, WRITER, READER) or IAM conditions. Column-level security is enforced via BigQuery policy tags (requires Data Catalog).
• Custom roles: Yes
• Custom roles plan: Available on all Google Cloud plans at no additional IAM cost. Requires resourcemanager.projects.setIamPolicy or equivalent permission to create and assign.
• Granularity: Organization > Folder > Project > Dataset > Table > Column (via policy tags). Row-level security is also available via row access policies.

1. Navigate to https://console.cloud.google.com/iam-admin/iam and select the target project.
2. Click 'Grant Access' (previously 'Add').
3. In the 'New principals' field, enter the user's Google account email, Google Group email, service account, or Cloud Identity domain.
4. Select one or more BigQuery IAM roles from the 'Select a role' dropdown (e.g., roles/bigquery.dataViewer + roles/bigquery.jobUser).
5. Optionally add IAM conditions to restrict access by resource, time, or other attributes.
6. Click 'Save'.
7. For dataset-level access: open BigQuery Studio at https://console.cloud.google.com/bigquery, select the dataset, click 'Sharing' > 'Permissions', then 'Add Principal', enter the principal and role, and save.

Required fields: Principal identifier (Google account email, Google Group, service account email, or Cloud Identity domain), At least one IAM role

Watch out for:

• The principal must already have a Google account or be a Google Workspace / Cloud Identity managed account. BigQuery cannot create user accounts itself.
• Project-level IAM grants apply to all datasets in the project unless overridden at the dataset level.
• Dataset-level grants are additive with project-level grants; there is no deny at dataset level to override a project-level grant (use IAM Deny policies for explicit denials, available in preview).
• Granting access to an external (non-org) Google account is possible but may be restricted by org policy constraints/iam.allowedPolicyMemberDomains.
• Column-level security requires creating policy tags in Data Catalog and assigning the Fine-Grained Reader role separately.
• Row-level security requires creating row access policies via DDL or the API; it is not managed through the IAM console.

• Can delete users: No
• Delete/deactivate behavior: BigQuery does not manage user accounts. Removing access means revoking IAM role bindings for the principal on the project, folder, or dataset. The Google account itself is managed in Google Workspace or Cloud Identity. Disabling or deleting the Google account in Cloud Identity/Workspace prevents all GCP access including BigQuery. Revoking IAM bindings removes BigQuery access without affecting the account.

1. To revoke project-level access: navigate to https://console.cloud.google.com/iam-admin/iam, locate the principal, click the edit (pencil) icon, remove the relevant BigQuery roles, and click 'Save'. Alternatively, click the delete (trash) icon to remove all project-level roles for that principal.
2. To revoke dataset-level access: open BigQuery Studio, select the dataset, click 'Sharing' > 'Permissions', find the principal, and click the remove icon next to their role.
3. To disable the underlying Google account (full access revocation across GCP): go to Google Workspace Admin Console (admin.google.com) > Directory > Users, select the user, and click 'Suspend user' or 'Delete user'.
4. To revoke access via gcloud CLI: run 'gcloud projects remove-iam-policy-binding PROJECT_ID --member=user:EMAIL --role=ROLE_ID'.

Watch out for:

• Scheduled queries (Data Transfer Service jobs) run as the creating user's credentials. Deleting or suspending that user will cause those jobs to fail. Re-own or recreate them under a service account before removing the user.
• If the user created datasets with themselves as OWNER via legacy dataset ACLs, those ACL entries remain but become orphaned. Audit dataset ACLs after removing a user.
• Removing a user from IAM does not immediately invalidate active OAuth tokens or short-lived credentials; token expiry (typically 1 hour) is required for full revocation unless using token revocation APIs.
• Org policy constraints/iam.allowedPolicyMemberDomains can prevent re-adding external accounts after removal.
• BigQuery audit logs (Cloud Audit Logs) retain records of the removed user's past actions regardless of account status.

• Where to check usage: Google Cloud Console > Billing > Reports (filter by BigQuery service) or Cloud Console > BigQuery > Admin > Capacity Management for slot usage. IAM principal-level query costs visible via INFORMATION_SCHEMA.JOBS_BY_PROJECT or Cloud Audit Logs.
• How to identify unused seats: Query INFORMATION_SCHEMA.JOBS_BY_USER or INFORMATION_SCHEMA.JOBS_BY_PROJECT to identify principals who have not run jobs in a given period. Cross-reference with IAM policy to find principals with roles but no recent job activity. No built-in 'inactive user' report in the console.
• Billing notes: BigQuery has no per-seat licensing. All costs are usage-based (compute and storage). Granting or revoking IAM access has no direct billing impact. Costs are attributed to the project where jobs run, not to the individual user's account. Use project-level budgets and alerts in Cloud Billing to monitor spend.

BigQuery has no per-seat licensing. All costs are usage-based: compute (per TiB queried on-demand, or per slot-hour on capacity editions) and storage (per GB/month). Granting or revoking IAM access has no direct billing impact.

The operational cost of manual access management is query-side: identifying who has access but isn't using it requires custom INFORMATION_SCHEMA.JOBS_BY_USER queries. There is no built-in inactive-user report in the console. Without that discipline, over-provisioned roles accumulate silently and every app querying shared datasets may be running under broader permissions than intended.

Scheduled queries (Data Transfer Service jobs) run as the creating user's credentials by default. When that user is offboarded, those jobs fail. Re-owning them to a service account before removal is a manual step with no automated prompt.

The most consistent friction point reported by practitioners is the dual-layer admin surface: Google Workspace or Cloud Identity for account lifecycle, and the GCP/BigQuery console for IAM role assignment.

These are separate consoles with separate admin roles, and neither is aware of the other's state by default.

Dataset-level legacy ACLs (OWNER/WRITER/READER) and project-level IAM roles coexist in the same environment. Effective permissions are the union of both, which makes auditing non-trivial - especially when a user has been removed from IAM but retains a legacy dataset ACL entry.

OAuth token expiry adds a latency gap to offboarding: revoking IAM bindings does not immediately invalidate active tokens. Full revocation requires waiting for token expiry (typically up to one hour) unless token revocation APIs are called explicitly.

Common complaints:

• No direct BigQuery SCIM endpoint; user provisioning must go through Google Cloud Identity or Google Workspace, adding an extra layer of management.
• Must manage via Google Cloud Identity layer, which requires a separate admin console (admin.google.com) from the BigQuery/GCP console.
• Scheduled queries are tied to the creating user's identity rather than a service account by default, causing failures when users are offboarded.
• No built-in inactive user report; identifying unused access requires custom INFORMATION_SCHEMA queries.
• Dataset-level ACLs (legacy OWNER/WRITER/READER) and project-level IAM roles coexist, creating confusion about effective permissions.
• Column-level security requires a separate Data Catalog policy tag setup, which is not obvious from the BigQuery console alone.
• IAM Deny policies (needed to override inherited project-level grants at dataset level) were in preview and not generally available for all customers.
• External (non-org) Google accounts can be granted BigQuery access unless explicitly blocked by org policy, which is a common misconfiguration risk.

Manual management is workable for small, stable teams where dataset access is coarse-grained and changes infrequently. The IAM console is functional, role assignments are auditable via Cloud Audit Logs, and the predefined roles cover most analyst and engineering access patterns without custom configuration.

The model breaks down at scale in three specific ways: offboarding requires coordinated action across Cloud Identity, project-level IAM, and dataset-level ACLs with no single-pane view; scheduled query ownership creates hidden dependencies on individual user accounts; and column- or row-level security requires tooling (Data Catalog, DDL) that sits outside the standard IAM workflow.

Teams managing more than a handful of BigQuery users, or operating in environments with frequent role changes, will find the lack of a native inactive-user report and the absence of a unified offboarding checklist to be the sharpest edges.

Bottom line

BigQuery's access model is powerful and granular, but it is not self-contained. Every app and analyst workflow that depends on BigQuery data is only as well-governed as the IAM bindings and Cloud Identity accounts behind it.

The predefined roles are well-designed, but the operational burden - dual consoles, no inactive-user reporting, legacy ACL coexistence, and scheduled query ownership risk - means that manual management requires deliberate process discipline to stay clean.

Teams that treat IAM hygiene as a periodic audit task rather than a continuous workflow will accumulate access debt that is difficult to unwind without custom INFORMATION_SCHEMA queries and cross-system reconciliation.