A service account from project A needs to read a BigQuery dataset in project B. The service account is granted roles/bigquery.dataViewer at the project B level. Yet the access is denied. What additional step is needed?
Dataset ACL can override project-level roles, requiring explicit grant.
Why this answer
D is correct because BigQuery datasets use Access Control Lists (ACLs) in addition to IAM policies. Even though the service account has the roles/bigquery.dataViewer IAM role at the project B level, this role grants access to list datasets and read metadata, but does not automatically grant access to the actual data within a dataset. The dataset's ACL must explicitly include the service account to allow reading the tables and views.
This is a common requirement when cross-project access is needed, as IAM roles at the project level do not propagate to dataset-level ACLs unless the dataset is configured to inherit permissions.
Exam trap
Google Cloud often tests the misconception that IAM roles at the project level are sufficient for cross-project data access, when in fact BigQuery datasets require explicit ACL entries for the service account to read data.
How to eliminate wrong answers
Option A is wrong because enabling the BigQuery API on project A is not required for the service account to read data in project B; the API must be enabled on the project where the dataset resides (project B), and it is likely already enabled. Option B is wrong because roles/bigquery.jobUser on project A grants permission to run jobs (e.g., queries) in project A, but does not grant read access to the dataset in project B; the service account needs data access in project B, not job execution rights in project A. Option C is wrong because roles/bigquery.user on project B allows listing datasets and running jobs, but does not grant read access to the actual data in the dataset; it is a higher-level role that still requires dataset-level ACLs for data access.