An enterprise organization is designing a centralized data repository in BigQuery to store sensitive financial transactions across multiple regions. The data governance and security framework requires the following: Regional business analysts must be able to query specific analytical aggregations without having read access to the underlying source dataset or base tables. Data engineers requiring direct base table access must have row-level access dynamically restricted to their assigned region using native BigQuery row-level security (RLS). Data classification metadata and billing chargeback keys must be maintained at both the dataset and individual table levels. Which combination of administrative and security configurations meets these governance requirements?

Create authorized views in a separate dataset to share aggregates with analysts, define row-level security on base tables via CREATE ROW ACCESS POLICY DDL while assigning table read permissions without manually binding the system-managed bigquery.filteredDataViewer IAM role, and apply classification labels explicitly to both the datasets and tables.: ### What This Architecture Is This architecture leverages **BigQuery authorized views**, **Row-Level Access Policies (RLS)**, and **resource-level labeling** to enforce fine-grained access control, least-privilege security, and metadata classification across datasets and tables. ### How It Meets the Requirements * **Secure data sharing with analysts**: Creating an **authorized view** in a separate dataset allows regional business analysts to query aggregated data without granting them any IAM permissions or read access on the underlying source dataset or base tables. * **Row-level security enforcement**: Creating row-level access policies with the `CREATE ROW ACCESS POLICY` DDL statement dynamically restricts rows returned to specified grantees based on filter conditions. BigQuery automatically assigns the system-managed `bigquery.filteredDataViewer` role to policy grantees. Engineers only require standard table read access (`bigquery.tables.getData` or `roles/bigquery.dataViewer`) to execute queries against the filtered table. * **Metadata and billing attribution**: Because **dataset labels are not inherited** by underlying tables or views, applying key-value classification labels explicitly to both datasets and tables ensures accurate resource tracking and storage chargeback. ### Key Advantages and Capabilities * **Decoupled data access**: Authorized views permit granular access delegation while keeping raw underlying tables fully protected from broader analyst groups. * **Automated role management**: Row-level policies automatically manage the filtered data viewer role for assigned principals without risk of manual IAM misconfigurations. * **Fine-grained cost attribution**: Labeling resources independently at dataset and table levels enables granular billing breakdowns by cost center and sensitivity rating. * **Least-privilege adherence**: Prevents over-permissioning by avoiding basic project-level roles in favor of resource-scoped predefined IAM roles. ### Why This Is Optimal This solution follows Google Cloud security best practices by strictly separating compute and data consumption via authorized views, relying on native SQL DDL for declarative row access controls, and avoiding assumptions about label inheritance.

Bigquery Dataset Table Security Governance Architecture | professional-cloud-data-engineer

Bigquery Dataset Table Security Governance Architecture

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.

An enterprise organization is designing a centralized data repository in BigQuery to store sensitive financial transactions across multiple regions. The data governance and security framework requires the following:

Regional business analysts must be able to query specific analytical aggregations without having read access to the underlying source dataset or base tables.
Data engineers requiring direct base table access must have row-level access dynamically restricted to their assigned region using native BigQuery row-level security (RLS).
Data classification metadata and billing chargeback keys must be maintained at both the dataset and individual table levels.

Which combination of administrative and security configurations meets these governance requirements?

Create authorized views in a separate dataset to share aggregates with analysts, define row-level security on base tables via CREATE ROW ACCESS POLICY DDL while assigning table read permissions without manually binding the system-managed bigquery.filteredDataViewer IAM role, and apply classification labels explicitly to both the datasets and tables.

Grant regional analysts the roles/bigquery.admin role scoped to the base dataset, use DROP ROW ACCESS POLICY to clear previous row access rules when removing filters, and manage table classification solely through VPC Service Controls perimeters.

Create standard SQL views in a reporting dataset, grant analysts roles/bigquery.dataViewer on the source dataset, configure row-level security by granting the bigquery.filteredDataViewer IAM role directly to data engineers in IAM, and apply classification labels only at the dataset level to inherit them down to tables.

Implement dynamic row filters using basic Owner, Editor, and Viewer roles at the project level, create materialized views in the source dataset for regional analysts, and use schema descriptions instead of key-value labels for cost allocation and classification.

Professional Cloud Data Engineer

Bigquery Dataset Table Security Governance Architecture

Related questions