Access control in BigQuery shows up on the Professional Cloud Architect exam in two flavors. The first is recognition of the predefined IAM roles and what level of the resource hierarchy they apply to. The second is a design pattern for handing out those roles when multiple teams share a project. I want to cover both here.
BigQuery has more predefined roles than you need to know cold for the exam, but a handful come up often enough that I treat them as required reading. Each role can be granted at one or more levels of the resource hierarchy, and the level matters because it controls how broad the grant ends up being.
BigQuery Admin gives full control over BigQuery resources. You can attach it at the project, dataset, row, table, or view level. It is the most powerful role on the list and the one I would reserve for a small group.
BigQuery User lets a principal create datasets and manage jobs. It applies at the project and dataset levels. This is a common starting role for someone who needs to do real work in BigQuery without being handed Admin.
BigQuery Data Owner is for managing and sharing datasets and views. It applies at the project and dataset levels. The mental model I use is that Data Owner is about the container, not the contents, so it is the role you grant when someone needs to decide who else gets in.
BigQuery Data Editor grants the ability to create, modify, and delete table data. It applies at the project, dataset, table, and view levels. If a person or service account needs to write rows, this is usually what they get.
BigQuery Data Viewer is read-only access to tables and views. It applies at the project, dataset, table, and view levels. I lean on this role hard for analysts and downstream consumers who should never be modifying anything.
BigQuery Job User lets a principal run jobs and queries. It applies only at the project level. This one trips people up because Job User on its own does not give access to any data. It only allows the principal to spend the project's query slots and run jobs against data they already have access to through some other grant.
BigQuery Metadata Viewer grants access to dataset and table metadata, like schema information, without exposing the underlying data. It applies at the project, dataset, table, and view levels. It is useful when someone needs to inspect what exists without being able to read rows.
The pattern across all of these is that the role names map to the verbs people perform and the resource scopes follow the hierarchy: project, dataset, table, view, and in a few cases row. When a Professional Cloud Architect exam question hands you a scenario where someone needs to query but not change anything, Data Viewer plus Job User is the typical answer. When the scenario is about creating and managing datasets, User or Data Owner is in play depending on whether sharing is part of the requirement.
The second piece of access management to know for the exam is the team-specific dataset pattern. The setup is simple to draw. Imagine Team A and Team B working in the same BigQuery project. Team A owns Dataset A and Team B owns Dataset B. Team A gets edit access on Dataset A and view access on Dataset B. Team B gets edit access on Dataset B and view access on Dataset A.
Each team has full control over its own data and can still read across the boundary when needed, but neither team can accidentally modify the other team's tables. That separation between edit and view is the whole point.
The way you implement this without losing your mind is Google Groups. You organize users into a group per team, and you grant the IAM roles to the group rather than to individual users. When someone joins or leaves a team, you update the group membership in one place and the BigQuery permissions follow automatically. There is no scavenger hunt through dataset-level grants to track down what a departing employee had access to.
In role terms, edit access on a team's own dataset is usually BigQuery Data Editor at the dataset level, often paired with Data Owner if the team needs to manage sharing. View access on the other team's dataset is BigQuery Data Viewer at the dataset level. Job User at the project level rounds it out so that members of either team can actually run queries.
This is the pattern Google reaches for when an exam question describes multiple teams sharing a BigQuery project, asks for clean separation of write privileges with shared visibility, and looks for an answer that scales as people come and go. The combination of dataset-level role grants and group-based assignment is what makes it work.
My Professional Cloud Architect course covers BigQuery IAM and team-specific datasets alongside the rest of the storage and analytics material.
