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.

How Authorized Views, Row Policies and Labels Secure BigQuery

BigQuery Authorized Views with Row-Level Security and Labels

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

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.

Explanations

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.

What This Option Proposes

This option relies on standard SQL views, broad source dataset permissions, manual IAM assignment of the bigquery.filteredDataViewer role, and dataset-level label inheritance.

Why It Doesn't Meet the Requirement

Breaches source dataset isolation: Standard views require querying users to have direct roles/bigquery.dataViewer permissions on the source dataset and base tables, exposing sensitive raw tables to analysts.
Improper row-level security implementation: The bigquery.filteredDataViewer role is a system-managed role that should never be applied directly to a principal via IAM. Row security must be configured via CREATE ROW ACCESS POLICY DDL statements.
Faulty label inheritance assumption: In BigQuery, dataset labels do not propagate or automatically inherit down to child tables and views.

Key Characteristics and Limitations

Direct IAM assignment of system-managed roles can lead to inconsistent access control states.
Standard views do not encapsulate underlying table permissions across different datasets.
Omitting table-level labels leaves individual tables unclassified in metadata and billing exports.

This Answer Would Be Correct If

Analysts had full clearance to inspect underlying raw transaction tables and BigQuery supported automatic top-down label inheritance from datasets to tables.

View source documentation

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.

What This Option Proposes

This option proposes using primitive basic IAM roles at the project level, materialized views inside the base dataset, and schema description fields to handle security, filtering, and classification.

Why It Doesn't Meet the Requirement

Violates least-privilege principles: Basic roles (Owner, Editor, Viewer) grant broad, non-granular permissions across all project resources and do not restrict access to specific rows or columns.
Exposes underlying dataset: Creating materialized views directly in the source dataset requires analysts to access that dataset, preventing proper isolation between aggregate views and raw tables.
Cannot support billing chargeback: Schema descriptions are descriptive text fields and cannot be queried or grouped in Google Cloud Billing export tables for automated cost attribution like key-value labels.

Key Characteristics and Limitations

Basic project roles override fine-grained resource policies and increase exposure to data exfiltration.
Materialized views in the source dataset do not provide authorization boundaries like authorized views.
Descriptions do not integrate with billing filters or automated organizational policy enforcement.

This Answer Would Be Correct If

The organization had no multi-tenant billing requirements and wished to grant unrestricted project-wide data access to all team members.

View source documentation

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.

View source documentation

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.

What This Option Proposes

This option suggests granting dataset-level administrative privileges to analysts, using DROP ROW ACCESS POLICY commands for rule management, and relying on VPC Service Controls for resource classification.

Why It Doesn't Meet the Requirement

Excessive permissions: Granting roles/bigquery.admin to business analysts provides full control over data, schema, and security policies, violating least privilege and exposing raw transactions.
Incorrect perimeter usage: VPC Service Controls establishes network-level security perimeters around Google Cloud APIs to prevent unauthorized data exfiltration; it does not classify table metadata or provide internal chargeback tracking.
Fails row-level security requirements: Attempting to delete the last row-level access policy from a table using DROP ROW ACCESS POLICY results in an error; DROP ALL ROW ACCESS POLICIES must be used instead.

Key Characteristics and Limitations

Administrative roles allow users to modify or delete audit configurations and row access policies.
Network perimeters control API ingress/egress rather than row/table granularity or billing metadata.
BigQuery enforces specific DDL constraints when dropping the final row access policy on a table.

This Answer Would Be Correct If

The objective was to establish a network perimeter preventing data export while granting analysts administrative control over dataset lifecycle management.

View source documentation

Last updated August 27, 2026Validated August 27, 2026

BigQuery Authorized Views with Row-Level Security and Labels

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?

Explanations

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.

What This Option Proposes

This option relies on standard SQL views, broad source dataset permissions, manual IAM assignment of the bigquery.filteredDataViewer role, and dataset-level label inheritance.

Why It Doesn't Meet the Requirement

Breaches source dataset isolation: Standard views require querying users to have direct roles/bigquery.dataViewer permissions on the source dataset and base tables, exposing sensitive raw tables to analysts.
Improper row-level security implementation: The bigquery.filteredDataViewer role is a system-managed role that should never be applied directly to a principal via IAM. Row security must be configured via CREATE ROW ACCESS POLICY DDL statements.
Faulty label inheritance assumption: In BigQuery, dataset labels do not propagate or automatically inherit down to child tables and views.

Key Characteristics and Limitations

Direct IAM assignment of system-managed roles can lead to inconsistent access control states.
Standard views do not encapsulate underlying table permissions across different datasets.
Omitting table-level labels leaves individual tables unclassified in metadata and billing exports.

This Answer Would Be Correct If

Analysts had full clearance to inspect underlying raw transaction tables and BigQuery supported automatic top-down label inheritance from datasets to tables.

View source documentation

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.

What This Option Proposes

This option proposes using primitive basic IAM roles at the project level, materialized views inside the base dataset, and schema description fields to handle security, filtering, and classification.

Why It Doesn't Meet the Requirement

Violates least-privilege principles: Basic roles (Owner, Editor, Viewer) grant broad, non-granular permissions across all project resources and do not restrict access to specific rows or columns.
Exposes underlying dataset: Creating materialized views directly in the source dataset requires analysts to access that dataset, preventing proper isolation between aggregate views and raw tables.
Cannot support billing chargeback: Schema descriptions are descriptive text fields and cannot be queried or grouped in Google Cloud Billing export tables for automated cost attribution like key-value labels.

Key Characteristics and Limitations

Basic project roles override fine-grained resource policies and increase exposure to data exfiltration.
Materialized views in the source dataset do not provide authorization boundaries like authorized views.
Descriptions do not integrate with billing filters or automated organizational policy enforcement.

This Answer Would Be Correct If

The organization had no multi-tenant billing requirements and wished to grant unrestricted project-wide data access to all team members.

View source documentation

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

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

View source documentation

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.

What This Option Proposes

Why It Doesn't Meet the Requirement

Excessive permissions: Granting roles/bigquery.admin to business analysts provides full control over data, schema, and security policies, violating least privilege and exposing raw transactions.
Incorrect perimeter usage: VPC Service Controls establishes network-level security perimeters around Google Cloud APIs to prevent unauthorized data exfiltration; it does not classify table metadata or provide internal chargeback tracking.
Fails row-level security requirements: Attempting to delete the last row-level access policy from a table using DROP ROW ACCESS POLICY results in an error; DROP ALL ROW ACCESS POLICIES must be used instead.

Key Characteristics and Limitations

Administrative roles allow users to modify or delete audit configurations and row access policies.
Network perimeters control API ingress/egress rather than row/table granularity or billing metadata.
BigQuery enforces specific DDL constraints when dropping the final row access policy on a table.

This Answer Would Be Correct If

The objective was to establish a network perimeter preventing data export while granting analysts administrative control over dataset lifecycle management.

View source documentation

Last updated August 27, 2026Validated August 27, 2026

BigQuery Authorized Views with Row-Level Security and Labels

Explanations

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

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.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

What This Architecture Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

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.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Google Cloud Resource Hierarchy for Data Governance

BigQuery Materialized View Partition Expiration Alignment

Cloud Storage Dual-Region Turbo and BigQuery Cross-Region Replication

Looker Studio Viewer Credentials for BigQuery RLS

BigQuery ML Vertex AI MLOps Pipeline

Intercepting Aggregated Log Sink

BigQuery Authorized Views with Row-Level Security and Labels

Explanations

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

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.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

What This Architecture Is

How It Meets the Requirements

Key Advantages and Capabilities

Why This Is Optimal

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.

What This Option Proposes

Why It Doesn't Meet the Requirement

Key Characteristics and Limitations

This Answer Would Be Correct If

Try 10 interactive questions like this one, free

Related questions

Google Cloud Resource Hierarchy for Data Governance

BigQuery Materialized View Partition Expiration Alignment

Cloud Storage Dual-Region Turbo and BigQuery Cross-Region Replication

Looker Studio Viewer Credentials for BigQuery RLS

BigQuery ML Vertex AI MLOps Pipeline

Intercepting Aggregated Log Sink