Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Dataplex Raw and Curated Zones for Lakehouse Staging
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 building an enterprise data lakehouse architecture on Google Cloud using Dataplex to ingest and process transaction records from multiple operational databases. The architecture must satisfy the following requirements:
- Multi-tiered staging: Isolate raw, unvalidated ingestion data from validated, standardized data ready for analytics consumption.
- Schema discovery and evolution: Automatically register data definitions in the catalog while preventing unvalidated structural breaking changes in downstream consumption tables.
- Storage cost and performance optimization: Minimize query scanning overhead and transition aging raw data to lower-cost storage classes.
Which Dataplex lake and storage architecture should the team implement?
Explanations
Configure a single Cloud Storage bucket within a Dataplex Raw zone using unpartitioned CSV files. Route all analytical queries through Cloud Service Mesh using the waterfall by zone load balancing algorithm to minimize cross-zone query latency across Dataplex assets.
Configure a single Cloud Storage bucket within a Dataplex Raw zone using unpartitioned CSV files. Route all analytical queries through Cloud Service Mesh using the waterfall by zone load balancing algorithm to minimize cross-zone query latency across Dataplex assets.
What this option does
This approach stores all raw and curated records as unpartitioned CSV files in a single bucket and attempts to use Cloud Service Mesh traffic management to optimize data lakehouse query execution.
Why it doesn't meet the requirement
- Multi-tiered staging: Fails to establish structured Raw and Curated zones to manage data maturity transitions.
- Schema discovery and evolution: CSV files lack strong embedded schema metadata and do not support structured schema evolution rules, leading to brittle query layers.
- Storage cost and performance optimization: Unpartitioned CSV files force full-table scans, significantly increasing BigQuery processing costs and latency. Furthermore, Cloud Service Mesh is an infrastructure networking solution for microservice traffic routing, not an analytics query execution optimizer.
Key limitations
- Inefficient Querying: BigQuery cannot perform partition pruning or columnar projection on unpartitioned CSV files.
- Irrelevant Networking Controls: Service mesh algorithms (such as waterfall by zone) manage RPC/HTTP traffic between microservices and have no role in data lakehouse tiering.
This answer would be correct if
You were designing network traffic management for containerized microservices spanning multiple Compute Engine zones to reduce cross-zone networking egress.
Create a Dataplex lake containing a Raw zone (configured for Cloud Storage buckets with Object Lifecycle Management to transition objects to Nearline/Coldline) and a Curated zone (configured for BigLake Parquet tables partitioned by ingestion date). Enable Dataplex metadata harvesting with schema discovery on the Raw zone, while enforcing strict schema definitions and automated data quality checks before promoting transformed data into the Curated zone.
Create a Dataplex lake containing a Raw zone (configured for Cloud Storage buckets with Object Lifecycle Management to transition objects to Nearline/Coldline) and a Curated zone (configured for BigLake Parquet tables partitioned by ingestion date). Enable Dataplex metadata harvesting with schema discovery on the Raw zone, while enforcing strict schema definitions and automated data quality checks before promoting transformed data into the Curated zone.
What this architecture is
This architecture establishes a multi-tiered Dataplex lake topology dividing storage assets into distinct Raw and Curated zones. It pairs Cloud Storage object lifecycle management with columnar BigLake storage formats and automated metadata discovery.
How it meets the requirements
- Multi-tiered staging: Dataplex organizes storage buckets and BigQuery datasets into Raw (unstructured/semi-structured landing) and Curated (standardized, cleaned, and modeled) asset zones, ensuring logical isolation and access boundary enforcement.
- Schema discovery and evolution: Enabling automated metadata harvesting and schema discovery in the Raw zone allows Dataplex to detect incoming file structures without breaking downstream pipelines. Enforcing schema contracts and data quality scans before promotion protects Curated zone tables from unvalidated schema drift.
- Storage cost and performance optimization: Object Lifecycle Management on raw Cloud Storage buckets automatically shifts objects to Nearline or Coldline storage classes after defined retention intervals. Partitioning the curated BigLake Parquet tables by date ensures query pruning and maximizes scan efficiency in analytical workloads.
Key advantages
- Granular Governance: Applies uniform IAM security policies across distributed buckets and tables within specific Dataplex zones.
- Data Integrity: Blocks malformed or non-conforming data records at the Raw-to-Curated transformation stage.
- Query Optimization: Partitioning and columnar Parquet format drastically reduce BigQuery bytes scanned and query execution latencies.
- Automated Lifecycle: Automatically reduces storage costs without manual engineering intervention.
Deploy a Dataplex Curated zone mapped exclusively to unindexed Firestore in Datastore mode entities. Implement keys-only projection queries to prevent data quality issues, and use Cloud KMS key version rotation to automate the archiving and lifecycle tiering of historical records.
Deploy a Dataplex Curated zone mapped exclusively to unindexed Firestore in Datastore mode entities. Implement keys-only projection queries to prevent data quality issues, and use Cloud KMS key version rotation to automate the archiving and lifecycle tiering of historical records.
What this option does
This proposal relies on Firestore in Datastore mode as the primary lakehouse storage engine, utilizing projection queries for data governance and KMS key rotation for data lifecycle management.
Why it doesn't meet the requirement
- Multi-tiered staging: Datastore is a NoSQL transactional document database designed for application OLTP workloads, not an analytical lakehouse storage layer supporting raw/curated staging zones.
- Schema discovery and evolution: Keys-only or projection queries are read optimization patterns for NoSQL databases, not automated data cataloging or schema evolution mechanisms.
- Storage cost and performance optimization: Cloud KMS key rotation generates new cryptographic versions for encryption at rest; it does not transition data across storage classes or enforce data retention policies.
Key limitations
- Wrong Engine: Firestore in Datastore mode is not suitable for petabyte-scale lakehouse analytics or Dataplex asset zoning.
- Misused Cryptography: KMS rotation does not manage file storage classes or data lifecycle rules.
This answer would be correct if
The objective was to build a highly scalable transactional NoSQL backend requiring low-latency entity lookups and query projection cost savings.
Create a single Dataplex Raw zone that contains both the Cloud Storage landing buckets and production BigQuery datasets. Configure Dataplex to automatically propagate all detected schema modifications directly to production analytics tables, and rely on Cloud SQL automatic storage scaling to manage analytical capacity.
Create a single Dataplex Raw zone that contains both the Cloud Storage landing buckets and production BigQuery datasets. Configure Dataplex to automatically propagate all detected schema modifications directly to production analytics tables, and rely on Cloud SQL automatic storage scaling to manage analytical capacity.
What this option does
This configuration combines unvalidated landing storage and production analytical datasets into a single Dataplex Raw zone and enables uncontrolled schema propagation directly to production analytics consumers.
Why it doesn't meet the requirement
- Multi-tiered staging: Fails to isolate unvalidated landing assets from cleansed business datasets by placing both storage layers in a single Raw zone.
- Schema discovery and evolution: Unrestricted, automatic schema modification propagation directly into production analytical tables risks introducing breaking schema changes, type mismatches, and pipeline failures for downstream analytical consumers.
- Storage cost and performance optimization: It ignores tiered Cloud Storage lifecycle policies and incorrectly identifies Cloud SQL automatic storage increase rather than native BigQuery/Cloud Storage lifecycle and partitioning mechanics.
Key limitations
- No Staging Isolation: Blurs data quality boundaries and exposes raw, potentially corrupted data to business analysts.
- Fragile Pipelines: Schema evolution in raw files directly alters downstream production tables without validation.
This answer would be correct if
The workload required a flat, unstructured sandbox for ad-hoc exploration where formal governance, tiering, and data quality validation were explicitly out of scope.
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
BigLake Fine-Grained Access Control
Data staging, cataloging, profiling, and discovery (data governance)
AdvancedProfessional Data Engineer
Dataplex Discovery and Tag Templates
Data staging, cataloging, profiling, and discovery (data governance)
AdvancedProfessional Data Engineer
Bigtable Time-Series Row Key Design
Choosing managed services (e.g., BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore, Memorystore)
AdvancedProfessional Data Engineer
Cloud Composer Highly Resilient Private IP
Job automation and orchestration (e.g., Cloud Composer and Workflows)
AdvancedProfessional Data Engineer
Analytics Hub Subscriber Email Logging
BigQuery sharing (Analytics Hub)
FundamentalAssociate Data Practitioner
Model Registry Default Alias Reassignment Requirement
Organize models in Model Registry
Last updated Validated