Your enterprise maintains a central BigQuery dataset named source_sales in project corp-analytics-prod that contains detailed order information and customer personally identifiable information (PII). You need to publish a collection of curated analytical views that exclude sensitive PII to an external analytics partner group (partner-analysts@partner.com). The implementation must satisfy the following requirements: Prevent partner analysts from querying or browsing underlying tables in source_sales directly. Automatically permit all current and future views in the publishing dataset to read data from source_sales without individual view authorization. Follow the principle of least privilege for IAM permissions while allowing partner analysts to execute queries against the published views. Which configuration should you implement?

Create a new dataset named partner_views in the same region as source_sales. Authorize partner_views on the source_sales dataset. Grant roles/bigquery.user to the partner group on the project containing partner_views, and grant roles/bigquery.dataViewer on the partner_views dataset.: ### What BigQuery Authorized Datasets and Role Bindings Are An **authorized dataset** allows all views (both existing and future) within a designated dataset to access data from a shared source dataset without needing separate authorizations for each view. Combining this with granular Identity and Access Management (IAM) roles enables secure, least-privilege data sharing with external or internal consumers. ### How It Meets the Requirements * **Prevent direct access to `source_sales`**: The partner analysts are not granted any IAM roles on the `source_sales` dataset or its tables. Because `partner_views` is configured as an authorized dataset on `source_sales`, BigQuery verifies authorization at the dataset boundary, keeping the underlying source tables completely shielded from the analysts. * **Automatic access for all current and future views**: Authorizing the entire `partner_views` dataset on `source_sales` automatically grants access to all views defined within it, eliminating the operational overhead of authorizing individual views. * **Least privilege query execution**: Granting `roles/bigquery.user` at the project level provides the necessary `bigquery.jobs.create` permission to run query jobs, while granting `roles/bigquery.dataViewer` strictly at the `partner_views` dataset level limits view/read access exclusively to the curated dataset. ### Key Advantages and Capabilities * **Centralized Governance**: Avoids managing individual Access Control Lists (ACLs) per view by grouping published views into a dedicated dataset. * **Strict Isolation**: Ensures source PII columns omitted in view definitions remain inaccessible to external partners. * **Regional Compatibility**: Ensures compliance with BigQuery requirements that authorized datasets reside in the same regional location as the shared source dataset. * **Scalable Operations**: New views added to the publishing dataset immediately inherit query permissions against the source dataset. ### Why This Is Optimal This architecture establishes a clean separation between data ownership and consumption. It minimizes administrative complexity compared to individual authorized views, strictly isolates base tables containing PII, and applies minimal required IAM permissions across project and dataset boundaries.

Bigquery Authorized Dataset Least Privilege Sharing | professional-cloud-data-engineer

Bigquery Authorized Dataset Least Privilege Sharing

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

Your enterprise maintains a central BigQuery dataset named source_sales in project corp-analytics-prod that contains detailed order information and customer personally identifiable information (PII). You need to publish a collection of curated analytical views that exclude sensitive PII to an external analytics partner group (partner-analysts@partner.com).

The implementation must satisfy the following requirements:

Prevent partner analysts from querying or browsing underlying tables in source_sales directly.
Automatically permit all current and future views in the publishing dataset to read data from source_sales without individual view authorization.
Follow the principle of least privilege for IAM permissions while allowing partner analysts to execute queries against the published views.

Which configuration should you implement?

Create a new dataset named partner_views in a separate region. Authorize each individual view on the source_sales dataset. Grant roles/bigquery.admin to the partner group on the project containing partner_views.

Create a new dataset named partner_views in the same region as source_sales. Authorize partner_views on the source_sales dataset. Grant roles/bigquery.user to the partner group on the project containing partner_views, and grant roles/bigquery.dataViewer on the partner_views dataset.

Create a new dataset named partner_views in the same region as source_sales. Grant roles/bigquery.dataViewer to the partner group on source_sales, and configure dynamic data masking on all PII columns using policy tags.

Create all analytical views directly inside the source_sales dataset. Apply row-level access policies to the source tables and grant roles/bigquery.dataViewer to the partner group on the source_sales dataset.

Professional Cloud Data Engineer

Bigquery Authorized Dataset Least Privilege Sharing

Related questions