Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
BigLake Access Delegation for Secure Data Lakehouse Queries
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 cost-effective data lakehouse architecture on Google Cloud. Several petabytes of structured analytical data are maintained in open columnar formats (such as Parquet) across Cloud Storage buckets and external cloud object stores. The security team requires that analysts query the data using standard BigQuery SQL and authorized views with fine-grained access controls, while strictly prohibiting granting end users direct object read permissions (storage.objects.get) to the underlying storage buckets.
Which architecture should you implement to meet these requirements?
Explanations
Create Cloud Storage object tables to read the raw files, and build materialized views directly on the object tables.
Create Cloud Storage object tables to read the raw files, and build materialized views directly on the object tables.
What object tables are
Object tables in BigQuery provide a SQL interface to query unstructured data (such as images, audio files, PDFs, or videos) stored in Cloud Storage by exposing file metadata (URI, size, content type) rather than parsing structured columnar records.
Why it doesn't meet the requirement
- Targeted at unstructured data: Object tables are specifically designed to analyze unstructured files and integrate with AI/ML models, not for querying structured columnar formats like Parquet, ORC, or Iceberg.
- Cannot serve as structured lakehouse tables: Object tables expose file-level metadata rather than tabular data schemas and cannot replace structured BigLake tables.
Key limitations
- Metadata-only view: Returns object metadata attributes (
uri,size,generation) rather than the records contained within columnar files. - Incompatible with structured BI queries: Cannot parse and execute relational aggregations or joins over Parquet/ORC payloads.
This answer would be correct if
The scenario required analyzing unstructured documents or image files stored in Cloud Storage with machine learning models and object-level metadata queries.
Create BigLake external tables using a Cloud Resource connection for access delegation, and configure authorized views over the BigLake tables for the analysts.
Create BigLake external tables using a Cloud Resource connection for access delegation, and configure authorized views over the BigLake tables for the analysts.
What BigLake external tables are
BigLake external tables extend BigQuery's compute and governance capabilities to data stored directly in object storage like Cloud Storage, Amazon S3, and Azure Blob Storage. They unify data lakes and warehouses by allowing analytical SQL queries on open file formats without requiring data duplication or ingestion into native storage.
How it meets the requirements
- Access delegation without bucket permissions: BigLake uses a Cloud Resource connection (backed by a dedicated service account) to access underlying storage. End consumers only require query permissions on the BigLake table or dataset, completely eliminating the need to grant users direct read permissions (
storage.objects.get) on the Cloud Storage bucket. - Fine-grained security & authorized views: BigLake tables natively support BigQuery's advanced governance features, including authorized views, row-level security, and column-level security, allowing secure data virtualization across multi-cloud object stores.
- Cost-effectiveness & open formats: Storing petabytes in open columnar formats (e.g., Parquet, ORC, Iceberg) in object storage avoids the costs of replicating and storing duplicate datasets in managed warehouse storage.
Key advantages
- Single source of truth: Preserves a unified open format in the lake while exposing SQL warehouse semantics.
- Access virtualization: Centralizes access control within BigQuery IAM without opening object-level storage ACLs.
- Multi-cloud interoperability: Works across Cloud Storage, Amazon S3, and Azure Blob Storage seamlessly.
- Performance optimization: Leverages BigQuery query planning and metadata caching on external files.
Why this is optimal
This approach satisfies the enterprise's governance requirement to prevent direct bucket access while delivering high query flexibility, open-format support, and centralized security administration.
Batch-load the open-format files from Cloud Storage into native BigQuery standard tables using physical storage billing.
Batch-load the open-format files from Cloud Storage into native BigQuery standard tables using physical storage billing.
What BigQuery native tables with physical storage billing are
Standard BigQuery tables ingest data into Google's internal columnar format (Capacitor) on Colossus storage. Physical storage billing charges for compressed physical bytes rather than logical uncompressed bytes.
Why it doesn't meet the requirement
- Requires data duplication: Ingesting petabytes of data from the existing data lake into BigQuery doubles storage requirements and incurs recurring batch loading pipelines and extra storage expenses.
- Breaks open lakehouse interoperability: Moving data into proprietary native tables prevents open-source engines and other cloud processing tools from directly accessing the files in open formats.
Key characteristics
- Managed storage: Provides the highest query performance with native Capacitor storage.
- Physical vs. logical billing: Cost-effective for highly compressed datasets with low change rates, but still incurs additional storage fees on top of object storage.
- Data pipeline overhead: Requires maintenance of ongoing batch ingest jobs to keep native tables synchronized with external files.
This answer would be correct if
The primary goal was maximizing analytical query execution performance regardless of data duplication or lakehouse open-format interoperability.
Create standard non-BigLake external tables pointing directly to the Cloud Storage URIs, and assign column-level security tags directly on the external tables.
Create standard non-BigLake external tables pointing directly to the Cloud Storage URIs, and assign column-level security tags directly on the external tables.
What non-BigLake external tables are
Non-BigLake external tables allow BigQuery to query data stored directly in external systems (like Cloud Storage, Google Drive, or Bigtable) without ingesting the data into native BigQuery storage.
Why it doesn't meet the requirement
- Requires direct bucket access: Non-BigLake external tables do not support access delegation. To execute queries, each analyst must possess direct Cloud Storage permissions, specifically
storage.objects.getandstorage.objects.list, which violates the security constraint. - No fine-grained security: Non-BigLake external tables do not support table-level fine-grained access controls, column-level security tags, or row-level security policies.
Key limitations
- Lacks access delegation: Every querying principal must have IAM permissions on the underlying Cloud Storage bucket.
- Limited governance: Cannot enforce column-level masking or row-filtering policies.
- Slower metadata handling: Lacks the advanced caching and governance abstractions built into BigLake.
This answer would be correct if
Analysts already had full read access to the underlying storage buckets and fine-grained column/row governance at the SQL layer was not required.
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 Spanner Multi-Region Consistency
Choosing managed services (e.g., BigQuery, BigLake, AlloyDB, Bigtable, Spanner, Cloud SQL, Cloud Storage, Firestore, Memorystore)
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 Deferrable Operators
Interactive or batch query jobs
AdvancedProfessional Data Engineer
BI Engine Materialized View Smart Tuning
BigQuery features for business intelligence (e.g., BI Engine, materialized views)
AdvancedProfessional Data Engineer
Apache Beam Dead Letter Side Outputs
Data cleansing
FundamentalAssociate Data Practitioner
Cloud Storage Dual-Region
Distinguish between primary and secondary data storage location type (e.g., regions, dual-regions, multi-regions, zones) for data redundancy
Last updated Validated