BigQuery access is controlled through Identity and Access Management, the same IAM system used across Google Cloud. You grant a role to an identity, and that role carries a set of permissions. What makes BigQuery worth studying on its own is that roles can be granted at several levels, from the whole project down to an individual dataset, table, or view, and not every role can be applied at every level. The Professional Cloud Database Engineer exam tends to test whether you can match a role to the access a person actually needs and grant it at the right scope, so it helps to know what each of the common predefined roles allows and where it can be attached.
Google Cloud ships a set of predefined roles for BigQuery that cover the usual access patterns, so in most cases you do not need to build custom roles. The following are the ones to be familiar with.
The BigQuery Admin role provides full control over all BigQuery resources. It can be granted at the project, dataset, table, and view levels, which makes it the most powerful role for managing any part of the BigQuery environment. Because it carries broad authority, it is the role you grant sparingly.
The BigQuery User role lets a person create datasets and manage jobs. It can be granted at the project and dataset levels. This gives users the flexibility to work with data within those scopes without granting them control over the wider environment.
The BigQuery Data Owner role is meant for managing and sharing datasets and views. It can be assigned at the project, dataset, table, and view levels, giving ownership over resources at those granular levels.
The BigQuery Data Editor role grants permission to create, modify, and delete table data. It can be assigned at the project, dataset, table, and view levels, which makes it the right fit for people who need to edit or manage the data directly rather than just read it.
The BigQuery Data Viewer role is for users who only need read access. It allows read-only access to tables and views and can be granted at the project, dataset, table, and view levels.
The BigQuery Job User role is narrower. It allows a person to run jobs and queries, and it is granted at the project level. This lets someone execute queries without being given access to specific datasets or tables, which is useful when query execution and data access are managed separately.
The BigQuery Metadata Viewer role provides access to metadata about datasets and tables, such as schema information, without access to the underlying data itself. It can be assigned at the project, dataset, table, and view levels.
The detail to carry into the exam is that the level a role applies at is part of what distinguishes it. Data Viewer, Data Editor, Data Owner, and Admin all reach down to the table and view level, so you can scope them tightly. The User role stops at the dataset level, and the Job User role applies only at the project level. When a question asks how to give someone exactly the access they need, the answer usually comes down to picking the role whose permissions and available levels line up with the requirement, rather than over-granting at the project level when a dataset or table grant would do.
Because these roles can be attached at different points in the BigQuery hierarchy, you can build a finely tuned permission structure. A person who only needs to read one team's tables can be given Data Viewer on that dataset, not on the whole project. Someone who runs scheduled queries but should not see arbitrary data can be given Job User at the project level and then granted data access only where it is actually required. Matching the role and the scope to the need is the habit the exam rewards, and it is also what keeps access from sprawling wider than intended.
A common pattern is to organize data so that each team works within its own dataset. Consider two teams, Team A and Team B, each with a dataset of its own, Dataset A and Dataset B. Team A is given edit access to Dataset A so it can change that data, and only view access to Dataset B so it can read but not modify the other team's data. Team B has the mirror arrangement, with edit access to Dataset B and view access to Dataset A. This separates editing from viewing across teams and keeps each team in control of its own data while still being able to see what other teams have.
The piece that makes this manageable is Google Groups. Rather than assigning IAM roles to individual users, you organize people into Google Groups based on their team or department and assign the roles to the groups. When someone joins or leaves a team, you update the group membership and their access follows, with no need to edit permissions user by user. For a structure like the one above, each group is given edit access only to its designated dataset and view access to the others, which produces clear data separation and security across teams without a lot of per-person administration.
This is also a point the Professional Cloud Database Engineer exam likes to surface. When a scenario describes access that changes as people move between teams, granting roles to Google Groups is generally the cleaner answer than granting them to individuals, because it keeps the permission model tied to team membership rather than to a list of names that has to be maintained by hand.
Our Professional Cloud Database Engineer course covers BigQuery identity and access management alongside dataset organization and IAM role selection, with practice questions that drill these distinctions.
