Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
BigQuery Policy Tags for Dynamic PII Masking
Free sample question, answered and explained below. The Professional Data Engineer practice bank has 1,353 more like it. Try 10 free: instant score, no account.
An enterprise is designing a multi-environment data processing architecture across separate Development and Production Google Cloud environments. The architecture must satisfy the following governance and compliance requirements:
- Data Classification and Access Control: A centralized taxonomy must classify sensitive personally identifiable information (PII). Production analysts with explicit clearance must be able to view cleartext values, while developers and testers in the development environment must only see masked data.
- Cryptographic Security: All persistent data in BigQuery datasets and Cloud Storage buckets must be encrypted using Customer-Managed Encryption Keys (CMEK) via Cloud KMS/Cloud HSM, with strict cryptographic key isolation between environments.
- Lifecycle Management: Development storage buckets must automatically delete intermediate test data older than 30 days to limit exposure and reduce costs, whereas production audit data must be retained under an immutable compliance policy.
Which combination of architectural controls and services best satisfies these requirements?
Explanations
Execute Sensitive Data Protection API inspection jobs on production tables during runtime analytics queries. Disable CMEK in the development environment to minimize operational cost, and configure Cloud Logging export sinks to trigger Cloud Run for object deletions.
Execute Sensitive Data Protection API inspection jobs on production tables during runtime analytics queries. Disable CMEK in the development environment to minimize operational cost, and configure Cloud Logging export sinks to trigger Cloud Run for object deletions.
What the option is/does
This option dynamically scans and redacts data using Sensitive Data Protection API inspection during BI query execution, relies only on Google-default encryption keys in development, and uses Cloud Logging triggers with Cloud Run to delete storage objects.
Why it doesn't meet the requirement
- Violates CMEK Requirement: Disabling CMEK in the development environment directly fails the explicit requirement that all persistent data across both environments must be protected using CMEK.
- Performance and Cost Inefficiency: Calling Sensitive Data Protection inspection APIs synchronously during ad-hoc analytics queries creates massive latency, query degradation, and excessive API costs compared to BigQuery native dynamic masking.
- Over-engineered Deletion: Orchestrating log sinks and Cloud Run containers to delete storage objects is brittle and redundant when native Cloud Storage Object Lifecycle Management is available.
Key characteristics/limitations
- Sensitive Data Protection inspection is intended for data discovery, classification, and batch/stream de-identification, not runtime per-query row masking in BigQuery.
- Default Google-managed keys do not provide customer control over key rotation and revocation policies.
This answer would be correct if
The dataset schema was completely unstructured and unknown, requiring continuous real-time content inspection without strict CMEK mandates in pre-production.
Additional context
Sensitive Data Protection should be used during ingestion pipelines (e.g., Dataflow) or for profiling datasets, while BigQuery policy tags and dynamic data masking should handle runtime query masking.
Share a single Cloud KMS CMEK key across development and production projects. Apply BigQuery AEAD encryption functions at ingestion, grant developers BigQuery Admin roles to modify masking functions, and create scheduled Cloud Functions to truncate development tables every 30 days.
Share a single Cloud KMS CMEK key across development and production projects. Apply BigQuery AEAD encryption functions at ingestion, grant developers BigQuery Admin roles to modify masking functions, and create scheduled Cloud Functions to truncate development tables every 30 days.
What the option is/does
This option centralizes encryption on a single shared KMS key, encrypts columns manually via BigQuery AEAD encryption functions, gives developers administrative privileges, and uses custom Cloud Functions for data purging.
Why it doesn't meet the requirement
- Breaks Environment Isolation: Sharing a single Cloud KMS key across development and production collapses the cryptographic security boundary and violates segregation of duties.
- Over-privileged Access: Granting developers the BigQuery Admin role violates the principle of least privilege and allows unauthorized alterations to schemas, security policies, and underlying tables.
- Unnecessary Maintenance: Using custom Cloud Functions for table truncation adds operational overhead compared to declarative Cloud Storage lifecycle rules and BigQuery partition expiration.
Key characteristics/limitations
- BigQuery AEAD functions require analysts to pass keysets within SQL queries, which exposes key usage and complicates standard analytics queries.
- Shared CMEK keys prevent independent key rotation and compliance tracking per environment.
This answer would be correct if
A unified cryptographic keyset was required across external databases and serverless scripts were mandated for multi-cloud cleanup.
Additional context
Production and non-production environments should always maintain separate cryptographic key lifecycles to avoid unintended blast radius expansion during key revocation or compromise.
Define a centralized policy tag taxonomy with dynamic data masking in a shared governance project; grant the Fine-Grained Reader role exclusively to cleared production analysts while withholding it in development. Provision isolated Cloud KMS CMEK keys for each environment. Configure Cloud Storage Object Lifecycle Management with age-based deletion rules for development buckets, and enforce locked Bucket Retention Policies on production buckets.
Define a centralized policy tag taxonomy with dynamic data masking in a shared governance project; grant the Fine-Grained Reader role exclusively to cleared production analysts while withholding it in development. Provision isolated Cloud KMS CMEK keys for each environment. Configure Cloud Storage Object Lifecycle Management with age-based deletion rules for development buckets, and enforce locked Bucket Retention Policies on production buckets.
What the solution is
This architecture establishes an enterprise-grade governance foundation that enforces uniform data classification, fine-grained access security, strong cryptographic isolation, and automated lifecycle policies across distinct environments.
How it meets Data Classification and Access Control
- Standardized Taxonomy & Dynamic Data Masking: By defining policy tags in a centralized data governance project and applying them across BigQuery columns, schema classification remains uniform across both environments.
- Role-Based De-identification: BigQuery dynamic data masking evaluates permissions at query runtime. Users lacking the Fine-Grained Reader (
roles/datacatalog.categoryFineGrainedReader) role (such as development and testing personnel) automatically receive masked column values (e.g., nullified, hashed, or partially redacted), while authorized production data analysts with the role view cleartext data.
How it meets Cryptographic Security
- CMEK Isolation: Using distinct Cloud KMS / Cloud HSM Customer-Managed Encryption Keys per environment guarantees cryptographic boundary separation, ensuring development workloads cannot access or impact production key material.
How it meets Lifecycle Management
- Development Deletion Rules: Cloud Storage Object Lifecycle Management uses native rules (such as
Age: 30withDeleteaction) to purge obsolete test datasets automatically without manual intervention. - Production Immutability: Production compliance and audit data are protected by Bucket Lock retention policies, ensuring data cannot be overwritten or prematurely deleted before the regulatory retention duration expires.
Key advantages
- Eliminates code differences between environments by enforcing masking dynamically at query runtime rather than rewriting schemas.
- Minimizes the risk of production key compromise by isolating KMS key rings across folders and projects.
- Automates storage optimization and regulatory compliance through declarative lifecycle policies.
Why this is optimal
This approach leverages native Google Cloud governance tools (Dataplex / Data Catalog policy tags, BigQuery dynamic data masking, Cloud KMS, and Cloud Storage lifecycle management) to maintain strict security boundaries while preserving pipeline operational consistency between development and production.
Deploy client-side Tink encryption with hardcoded cryptographic keys inside Dataflow pipeline templates. Create separate BigQuery authorized views for development and production workloads, and apply uniform 3-year bucket retention policies across all Cloud Storage buckets in both environments.
Deploy client-side Tink encryption with hardcoded cryptographic keys inside Dataflow pipeline templates. Create separate BigQuery authorized views for development and production workloads, and apply uniform 3-year bucket retention policies across all Cloud Storage buckets in both environments.
What the option is/does
This option relies on client-side encryption using the Tink library where cryptographic keys are embedded directly within Dataflow code artifacts, uses standard SQL authorized views for data masking, and enforces a single 3-year retention policy everywhere.
Why it doesn't meet the requirement
- Security anti-pattern: Hardcoding cryptographic keys inside pipeline templates violates basic key management standards and exposes private key material in version control.
- Fails Dynamic Access Control: Authorized views require maintaining parallel views and separate dataset permissions across environments, increasing operational complexity compared to centralized policy tags and native dynamic data masking.
- Fails Lifecycle Differentiation: Applying a uniform 3-year retention policy to development buckets directly violates the requirement to purge development test data after 30 days.
Key characteristics/limitations
- Embedded keys cannot be rotated securely or isolated across environments.
- Authorized views do not dynamically adapt based on caller identity without complex custom SQL logic.
- Static long-term retention in development leads to unnecessary storage costs and increased data liability.
This answer would be correct if
The scenario required client-side field encryption prior to entering Google Cloud network boundaries and lacked access to centralized IAM-driven dynamic masking.
Additional context
Hardcoding secret material into pipeline binaries or templates poses severe exposure risks that violate compliance standards like CIS Benchmarks and FedRAMP.
Try 10 interactive questions like this one, free
Answer them yourself and get your score the moment you finish. No account needed.
Full access includes
- 1,353 practice questions across all 5 exam domains
- Every answer explained: why it is right, and why the others are not
- Scout, an AI tutor that answers your follow-up questions
- Readiness tracking by domain, so you know when to book the exam
Related questions
Keep the momentum going with these hand-picked practice scenarios
AdvancedProfessional Data Engineer
Google Cloud Environment Isolation and Service Account Impersonation
Multi-environment use cases (development vs. production)
AdvancedProfessional Data Engineer
Cloud Build Binary Authorization VPC Service Controls
Multi-environment use cases (development vs. production)
AdvancedProfessional Data Engineer
BigQuery target_job_concurrency and Autoscaling Cost Metrics
Observability of data processes (e.g., Cloud Monitoring, Cloud Logging, BigQuery admin panel)
AdvancedProfessional Data Engineer
BigQuery Authorized Views Least Privilege
Security, data masking, Identity and Access Management (IAM), and Cloud Data Loss Prevention (Cloud DLP)
AdvancedProfessional Data Engineer
Cloud Build Multi-Step Pipeline
CI/CD (Continuous Integration and Continuous Deployment)
FundamentalAssociate Data Practitioner
Cloud Storage Lifecycle matchesStorageClass Condition
Evaluate Google Cloud services for archiving data given business requirements
Last updated Validated