Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Dataplex Lakes Zones and Column Level Governance
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 decentralized data mesh platform across multiple Google Cloud projects. The architecture requires establishing independent logical data domains, cataloging technical and business metadata, and enforcing standardized governance.
The design must satisfy the following technical requirements:
- Organize distributed Cloud Storage buckets and BigQuery datasets across different projects into logical domain boundaries without copying or moving the underlying storage.
- Apply consistent security and governance policies to cohesive data product subgroups within each domain.
- Classify and enforce fine-grained column-level access control and data masking on sensitive fields across analytical assets.
Which architectural strategy should the data engineering team implement using Dataplex and Dataplex Catalog?
Explanations
Create a single Dataplex lake per Google Cloud organization, attach each project's storage resources to multiple zones simultaneously, and deploy Cloud KMS customer-managed encryption keys (CMEK) to redact sensitive column values.
Create a single Dataplex lake per Google Cloud organization, attach each project's storage resources to multiple zones simultaneously, and deploy Cloud KMS customer-managed encryption keys (CMEK) to redact sensitive column values.
What CMEK and Multi-Zone Attachment Are
Customer-Managed Encryption Keys (CMEK) provide cryptographic control over data at rest across Google Cloud services using Cloud KMS. In Dataplex, lakes and zones form the governance hierarchy for organizing data assets.
Why It Doesn't Meet the Requirement
- Violates Dataplex asset constraints: A storage asset (BigQuery dataset or Cloud Storage bucket) can only be registered in a single Dataplex zone at any given time; it cannot be attached to multiple zones simultaneously.
- CMEK does not perform column masking: CMEK protects storage at rest against unauthorized physical media access or infrastructure compromise. It cannot perform dynamic column-level data masking (e.g., masking PII while allowing queries on non-sensitive columns).
- Monolithic lake topology: Using a single global lake for an entire organization fails to establish independent, autonomous domain boundaries required by a data mesh architecture.
Key Characteristics and Limitations
- An asset is strictly bounded to one zone and one lake within Dataplex.
- Encryption at rest is transparent to authorized query users and does not provide selective field-level redaction.
- Dataplex lakes must reside in a single region, whereas multi-region data mesh setups require region-appropriate lake definitions.
This Answer Would Be Correct If
This approach would be relevant if the primary requirement were meeting regulatory compliance for root key rotation and cryptographic disk erasure across enterprise infrastructure.
Create a Dataplex lake for each business domain, organize domain data products into Dataplex zones, register multi-project BigQuery datasets and Cloud Storage buckets as assets, and apply Policy Taxonomies with Policy Tags for column-level data masking and access control.
Create a Dataplex lake for each business domain, organize domain data products into Dataplex zones, register multi-project BigQuery datasets and Cloud Storage buckets as assets, and apply Policy Taxonomies with Policy Tags for column-level data masking and access control.
What Dataplex Lakes, Zones, and Policy Taxonomies Are
Dataplex (and Dataplex Universal Catalog) provides an intelligent data fabric that lets organizations build logical, decentralized data domains (data mesh) while maintaining centralized governance, discovery, and access management. Within Dataplex:
- Lakes represent logical data domains (such as Sales, Supply Chain, or Product).
- Zones represent sub-domains or distinct data products within a lake, grouping related storage resources to apply uniform governance.
- Assets map directly to underlying physical storage entities (BigQuery datasets and Cloud Storage buckets) residing in the same or different Google Cloud projects.
- Policy Taxonomies and Policy Tags provide column-level access control and dynamic data masking across BigQuery tables.
How It Meets the Requirements
- Logical multi-project organization without moving data: Dataplex lakes and zones allow referencing Cloud Storage buckets and BigQuery datasets located across multiple Google Cloud projects without physically replicating or moving data.
- Cohesive data product governance: Creating Dataplex zones enables data domain teams to group associated assets into data products and attach consistent access, discovery, and data management policies across all resources in that zone.
- Column-level security and data masking: Defining Policy Taxonomies with hierarchical Policy Tags in Dataplex Catalog allows security administrators to enforce column-level access permissions and data masking rules (e.g., hash, null, or default masking) on sensitive fields uniformly.
Key Advantages and Capabilities
- Zero Data Movement: Logical abstraction unifies storage across multiple projects without operational overhead or data duplication costs.
- Centralized Metadata & Policy Management: Tag templates and taxonomies standardize technical and business metadata across all domain boundaries.
- Granular Security Controls: Combines zone-level IAM inheritance with column-level policy tag access enforcement.
- Integrated Discovery: All assets registered in Dataplex lakes are automatically cataloged and searchable via Dataplex Universal Catalog.
Why This Is Optimal
This approach aligns with Google Cloud recommended architectures for data mesh and distributed governance. It decouples physical data location from logical domain ownership while utilizing native, scalable constructs for centralized policy administration.
Create separate BigQuery datasets in a single centralized project, configure BigLake external tables pointing to all Cloud Storage buckets, and use authorized views for column masking and domain separation.
Create separate BigQuery datasets in a single centralized project, configure BigLake external tables pointing to all Cloud Storage buckets, and use authorized views for column masking and domain separation.
What Centralized Datasets with Authorized Views Are
This architecture relies on creating a centralized data warehouse project where all BigQuery external tables (via BigLake) and views reside, using BigQuery authorized views to restrict column access and simulate logical domain isolation.
Why It Doesn't Meet the Requirement
- Fails logical domain orchestration: Consolidating all references into a single central project breaks the decentralized data mesh paradigm and creates a governance bottleneck.
- Complex and unmaintainable access control: Managing column-level security across hundreds of tables using individual authorized views is time-consuming, difficult to maintain, and prone to configuration drift compared to policy taxonomies.
- Lacks integrated data mesh discovery: It does not establish Dataplex lakes, zones, or native asset discovery structures for domain-level metadata governance.
Key Characteristics and Limitations
- Authorized views require maintaining custom SQL DDL for every schema variation.
- Does not automatically propagate metadata tags, data quality rules, or lineage tracking across domains.
- Scales poorly when multiple cross-functional domain teams need autonomous management of their respective data products.
This Answer Would Be Correct If
This approach would be appropriate for a small-scale, monolithic data warehouse where a single central administration team manages a limited number of SQL views with restricted column outputs.
Create a Dataplex lake for each business domain, register individual BigQuery tables and Cloud Storage objects as Dataplex assets, and assign Catalog Tag Templates with public read permissions to enforce column data masking.
Create a Dataplex lake for each business domain, register individual BigQuery tables and Cloud Storage objects as Dataplex assets, and assign Catalog Tag Templates with public read permissions to enforce column data masking.
What Tag Templates and Asset Registrations Are
Dataplex Catalog Tag Templates define structured schema templates (such as string, enum, or datetime fields) used to label, classify, and add business or technical metadata to BigQuery tables, views, and columns. Dataplex assets represent storage containers mapped to zones.
Why It Doesn't Meet the Requirement
- Invalid asset granularity: Dataplex assets only support registering BigQuery datasets and Cloud Storage buckets; individual BigQuery tables or specific storage objects cannot be registered directly as Dataplex assets.
- Tag templates do not enforce masking: Standard Catalog Tag Templates add contextual metadata for search and discovery, but they do not enforce column-level data masking. Column data masking requires Policy Taxonomies and Policy Tags associated with BigQuery data policies.
- Public read permissions: Setting tag templates to public read allows metadata discovery but provides zero access control or field redaction.
Key Characteristics and Limitations
- Dataplex asset registration is container-level (datasets/buckets), not table/object-level.
- Metadata tag templates capture contextual information (e.g., data steward, confidentiality level) rather than enforcing runtime IAM read restrictions or masking rules.
This Answer Would Be Correct If
This pattern would be correct if the objective were solely to build custom search attributes and business descriptions across assets without enforcing runtime security or column data masking.
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
Cloud Storage Lifecycle BigQuery Partitioning Clustering Materialized Views
Building a data platform based on requirements by using Google Cloud tools (e.g., Dataplex, Dataplex Catalog, BigQuery, Cloud Storage)
AdvancedProfessional Data Engineer
Google Cloud Data Platform Architecture
Building a data platform based on requirements by using Google Cloud tools (e.g., Dataplex, Dataplex Catalog, BigQuery, Cloud Storage)
AdvancedProfessional Data Engineer
Cloud Spanner INSERT_OR_UPDATE Idempotent Writes
Defining data transformation and orchestration logic
AdvancedProfessional Data Engineer
Cloud KMS Envelope Encryption
Data encryption
AdvancedProfessional Data Engineer
Pub/Sub Avro Schema Revision Deserialization
Data acquisition and import
FundamentalAssociate Data Practitioner
Dataform for BigQuery SQL Transformations
Select a data transformation tool (e.g., Dataproc, Dataflow, Cloud Data Fusion, Cloud Composer, Dataform) based on business requirements
Last updated Validated