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.

StudyCerts

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Bigquery Authorized Dataset Least Privilege Sharing

Section: Publishing datasets

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 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.

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 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. Grant roles/bigquery.dataViewer to the partner group on source_sales, and configure dynamic data masking on all PII columns using policy tags.

Professional Cloud Data Engineer

professional-cloud-data-engineer

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Advanced

Prepare and test your skills

Track Readiness

Set Exam Goal

Bigquery Authorized Dataset Least Privilege Sharing

Section: Publishing datasets

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?

Explanations

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.

View source documentation

Professional Cloud Data Engineer

Bigquery Authorized Dataset Least Privilege Sharing

Professional Cloud Data Engineer

Bigquery Authorized Dataset Least Privilege Sharing

What BigQuery Authorized Datasets and Role Bindings Are

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

Related questions