A DevOps team is centralizing application and access audit logs into BigQuery to satisfy strict data protection regulations (such as GDPR and HIPAA). The log management design must satisfy the following access and compliance requirements: Specific sensitive attributes (such as user identifiers and IP addresses) must be masked with hashing or nullification for general DevOps engineers during routine troubleshooting. Compliance officers must have access to the unmasked raw data within the same table. Engineers must only be permitted to query and view log records that originated from their assigned geographic region. The solution must prevent data duplication and avoid maintaining separate regional tables or physical clones. Which strategy should the DevOps team implement in BigQuery to meet these requirements?

Configure BigQuery Data Policies with a DATA_MASKING_POLICY on sensitive columns to mask fields for general engineers while granting RAW_DATA_ACCESS_POLICY to compliance officers, and define Row Access Policies on the log table to filter visible rows by geographic region.: ### What BigQuery Data Policies and Row Access Policies Are **BigQuery Data Policies** and **Row Access Policies** are fine-grained security controls built directly into BigQuery. Column-level data masking policies control how sensitive column data is displayed to different principals (such as masking via hash or null values), while row access policies act as an inline security filter determining which rows are returned to a user. ### How It Meets the Requirements * **Column Masking for DevOps Engineers**: Applying a `DATA_MASKING_POLICY` with masking expressions like `SHA256` or `ALWAYS_NULL` ensures DevOps engineers only see obfuscated sensitive log data. * **Raw Access for Compliance Officers**: Associating compliance officers with a `RAW_DATA_ACCESS_POLICY` on the same column policy allows them to inspect unmasked raw logs without duplicating tables. * **Regional Filtering**: Implementing `CREATE ROW ACCESS POLICY` with a `FILTER USING (region = ...)` statement ensures principals can only view rows corresponding to their assigned geographic boundary. * **No Table Duplication**: Both controls apply directly at query execution time against a single unified log table. ### Key Advantages * **Zero Infrastructure Overhead**: Enforced at the engine layer without requiring ETL duplication or maintenance of synchronized views. * **Granular Principle of Least Privilege**: Combines both vertical (column-level) and horizontal (row-level) security seamlessly. * **Centralized Governance**: Integrates natively with Cloud IAM and Data Catalog taxonomies. * **Auditability**: Complies with stringent data privacy frameworks like GDPR and HIPAA by preventing unauthorized sensitive data leakage. ### Why This Is Optimal Native BigQuery data policies and row-level access control enforce data masking and residency filtering simultaneously on a single centralized dataset, avoiding the cost, complexity, and synchronization drift of managing multiple filtered tables or custom export pipelines.

Bigquery Log Compliance Masking Row Level Security | Professional Cloud DevOps Engineer

Bigquery Log Compliance Masking Row Level Security

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.

A DevOps team is centralizing application and access audit logs into BigQuery to satisfy strict data protection regulations (such as GDPR and HIPAA). The log management design must satisfy the following access and compliance requirements:

Specific sensitive attributes (such as user identifiers and IP addresses) must be masked with hashing or nullification for general DevOps engineers during routine troubleshooting.
Compliance officers must have access to the unmasked raw data within the same table.
Engineers must only be permitted to query and view log records that originated from their assigned geographic region.
The solution must prevent data duplication and avoid maintaining separate regional tables or physical clones.

Which strategy should the DevOps team implement in BigQuery to meet these requirements?

Deploy a Sensitive Data Protection (DLP) de-identification pipeline to permanently overwrite all PII attributes with SHA256 hashes during log ingestion before loading into BigQuery, and use IAM dataset viewer permissions for access control.

Assign the bigquery.filteredDataViewer IAM role directly to DevOps engineers on the BigQuery project, and configure authorized views that use WHERE clauses to redact PII and partition data by region.

Configure an Assured Workloads data boundary to restrict physical storage to US and EU regions, and create duplicate BigQuery datasets per region with encrypted column backups.

Configure BigQuery Data Policies with a DATA_MASKING_POLICY on sensitive columns to mask fields for general engineers while granting RAW_DATA_ACCESS_POLICY to compliance officers, and define Row Access Policies on the log table to filter visible rows by geographic region.

Professional Cloud DevOps Engineer

Bigquery Log Compliance Masking Row Level Security

Related questions