professional-cloud-data-engineer
Prepare and test your skills
Prepare and test your skills
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.
Keep the momentum going with these hand-picked practice scenarios
Want more questions like this?
Get a free certification question every week.
Last updated
An enterprise data lake integrates Google Cloud Storage and BigQuery data assets governed by Dataplex. A data engineer needs to enforce row-level security on a centralized transactions table so regional analysts can only view data corresponding to their assigned region.
A junior administrator recommends granting the Filtered Data Viewer (roles/bigquery.filteredDataViewer) IAM role directly to the regional analyst user groups at the BigQuery dataset level, and then executing CREATE ROW ACCESS POLICY DDL statements for each region.
Why does this approach violate Google Cloud security best practices, and what is the correct implementation?
Row-level access policies cannot be combined with IAM roles; you must grant the BigQuery Admin role to regional groups and use CREATE OR REPLACE ROW ACCESS POLICY to rotate access.
Assigning Filtered Data Viewer at the dataset level blocks BigQuery table pruning; principals must instead be granted BigQuery Data Viewer at the dataset level and assigned negative IAM condition tags.
The Filtered Data Viewer role requires uniform bucket-level access on Cloud Storage; you should instead configure fine-grained object ACLs on Cloud Storage and sync permissions using Dataplex.
Granting Filtered Data Viewer via IAM at the dataset level allows principals to view rows permitted by all row-level policies in that dataset; principals must only be granted access by listing them directly within each DDL CREATE ROW ACCESS POLICY statement.
Row-level access policies cannot be combined with IAM roles; you must grant the BigQuery Admin role to regional groups and use CREATE OR REPLACE ROW ACCESS POLICY to rotate access.
Assigning Filtered Data Viewer at the dataset level blocks BigQuery table pruning; principals must instead be granted BigQuery Data Viewer at the dataset level and assigned negative IAM condition tags.
The Filtered Data Viewer role requires uniform bucket-level access on Cloud Storage; you should instead configure fine-grained object ACLs on Cloud Storage and sync permissions using Dataplex.
Granting Filtered Data Viewer via IAM at the dataset level allows principals to view rows permitted by all row-level policies in that dataset; principals must only be granted access by listing them directly within each DDL CREATE ROW ACCESS POLICY statement.
Filtered Data Viewer Role IsThe Filtered Data Viewer (roles/bigquery.filteredDataViewer) is a specialized, system-managed role in BigQuery designed strictly for row-level security access control. When a row access policy is created on a table, BigQuery automatically and implicitly grants this role to the principals specified in the policy definition.
Granting the role manually through IAM at the dataset or project level is a major security anti-pattern because it circumvents row filter scoping, allowing grantees to query data permitted across any row access policy in that resource scope. The optimal and supported method is to manage grantees strictly through SQL DDL CREATE ROW ACCESS POLICY ... ON table_name GRANT TO ('group:...') FILTER USING (...) statements.