BigQuery IAM is one of those topics the Professional Data Engineer exam loves to test through scenarios. You'll see a question describe an analyst team, a data engineering team, and maybe an external auditor, and then ask which role to grant to which principal at which resource level. If you don't have the role names and their scopes memorized, you'll burn time second-guessing yourself. Below is the framing I use to keep them straight, plus how the team-specific dataset pattern actually shows up on the exam.
BigQuery has a long list of predefined IAM roles, but the Professional Data Engineer exam circles around a specific subset. Here are the ones I'd commit to memory.
BigQuery Admin gives full control over BigQuery resources. It can be granted at the project, dataset, row, table, and view level. This is the most powerful role and you grant it sparingly. On the exam, if a question hands BigQuery Admin to a regular analyst, that's almost always the wrong answer.
BigQuery User lets a principal create datasets and manage jobs. It can be granted at the project and dataset level. This is a good default for someone who needs to do real work in BigQuery but shouldn't own everything.
BigQuery Data Owner manages and shares datasets and views. It can be granted at the project or dataset level. Think of this as the role for the person responsible for a particular dataset's lifecycle.
BigQuery Data Editor can create, modify, and delete table data. It applies at the project, dataset, table, and view levels. This is the right role when someone needs to write rows but shouldn't be re-sharing the dataset with the world.
BigQuery Data Viewer is read-only access to tables and views. It can be granted at the project, dataset, table, and view levels. This is the workhorse role for analysts who just need to query.
BigQuery Job User allows running jobs and queries. It is granted at the project level only. This one trips people up because it sounds redundant with the other roles, but it is not. To run a query, a principal needs both the ability to read the data (Data Viewer on the dataset, for instance) and the ability to launch a job in some project (Job User on that project). Those two permissions often live in different projects, which is exactly what the exam likes to test.
BigQuery Metadata Viewer grants access to dataset and table metadata such as schema, without access to the underlying data. This is useful for tooling, data catalogs, and any case where someone needs to see structure but not rows.
The single most common BigQuery IAM exam question I've seen in some form goes like this. An analyst in Project A needs to query a dataset that lives in Project B. What roles do they need, and where?
The answer is BigQuery Job User on Project A (where they will launch the query and where the billing happens), and BigQuery Data Viewer on the dataset in Project B. If you grant Data Viewer on Project A, they can't see the data. If you grant Job User on Project B, they can't launch the job in their own project. The split matters.
Cross-project querying is a real pattern in enterprise BigQuery setups, where one project owns the data warehouse and other projects own the analytical workloads. Knowing how to split job-running permissions from data-reading permissions is a Professional Data Engineer fundamental.
The second IAM pattern the exam likes is team-specific datasets. The setup looks something like this. You have Team A and Team B. Team A owns Dataset A and Team B owns Dataset B. Each team needs full edit access to its own dataset and read access to the other team's dataset so they can join across them.
The clean way to wire this up is with Google Groups. You create team-a@yourcompany.com and team-b@yourcompany.com, put people in the right group, and then grant IAM roles to the group instead of to individuals. The grants look like this.
gcloud projects add-iam-policy-binding my-project \
--member="group:team-a@yourcompany.com" \
--role="roles/bigquery.jobUser"
bq add-iam-policy-binding \
--member="group:team-a@yourcompany.com" \
--role="roles/bigquery.dataEditor" \
my-project:dataset_a
bq add-iam-policy-binding \
--member="group:team-a@yourcompany.com" \
--role="roles/bigquery.dataViewer" \
my-project:dataset_bTeam B gets the mirror image. When someone joins or leaves a team, you update group membership and the IAM grants follow automatically. No one is editing project policies every time there's a personnel change.
Every BigQuery IAM question on the Professional Data Engineer exam rewards the answer that gives the principal the minimum role at the most specific scope. If a question describes someone who only needs to read one table, the right answer is Data Viewer on that table, not Data Viewer on the dataset, and definitely not Admin on the project.
The wrong-answer distractors usually fall into two buckets. Either they grant a role that is too broad (Admin when Data Editor would do), or they grant the right role at the wrong scope (project-level when dataset-level was sufficient). When two options look close, the one with the tighter scope is almost always correct.
One more thing worth knowing. BigQuery supports authorized views and authorized datasets, which let a view or dataset query data the requesting user doesn't have direct access to. This is how you build dashboards over sensitive tables without granting analysts access to the underlying rows. The exam touches this lightly, but if a question describes hiding raw data while exposing aggregated results, authorized views are the answer.
My Professional Data Engineer course covers BigQuery IAM in the context of the full data warehouse module, including authorized views, dataset-level access control, and the cross-project patterns the exam tests.
