A financial SaaS enterprise is designing a multi-tenant data access architecture in BigQuery to serve both internal analytics teams and external client organizations. The data architecture must satisfy the following technical and compliance requirements: Tenant Scaling & Regionalization: Support scaling from 500 to over 5,000 distinct tenant organizations located across multiple global Google Cloud regions. Performance Optimization: Enable each tenant to apply independent table partitioning and clustering schemes tailored to their specific querying workloads. Column Governance: Dynamically obscure sensitive payment card data for general data analysts while providing plaintext access to authorized compliance auditors with the Fine-Grained Reader role. Which architecture should the data engineering team implement to satisfy these requirements?

Configure a data ingestion pipeline using Dataflow to write tenant-specific records into dedicated per-tenant BigQuery datasets in each tenant's local region, allowing tailored clustering and partitioning schemes. Apply Dataplex policy tags with dynamic data masking rules on sensitive columns, granting the Fine-Grained Reader role to compliance auditors.: ### What the Dedicated Dataset Architecture with Dynamic Data Masking Is A **dedicated dataset per tenant** design segregates tenant data into discrete BigQuery datasets (or subset tables) written by an upstream orchestration or ETL/ELT service like **Cloud Dataflow**. This is combined with **Dataplex policy tags** and **dynamic data masking** to enforce granular, role-based column access control natively within BigQuery. ### How It Meets the Requirements - **Tenant Scaling & Regionalization**: A dataset-per-tenant pattern bypasses the hard limit of **2,500 authorized resources** per dataset associated with authorized views. It also allows tenant datasets and tables to reside in different **Google Cloud regions**, accommodating regional residency and latency requirements for globally distributed clients. - **Performance Optimization**: Because each tenant receives dedicated physical tables/datasets rather than shared logical views over a centralized monolithic table, each tenant can configure **custom partitioning and clustering strategies** optimized for their individual query patterns. - **Column Governance**: Applying **policy tags** with **dynamic data masking** masks sensitive fields (such as credit card numbers or PII) at runtime for standard users while revealing plaintext values to auditors who hold the **Fine-Grained Reader** (`roles/datacatalog.categoryFineGrainedReader`) role. ### Key Advantages - **High horizontal scalability**: Seamlessly scales past 5,000 tenants without colliding with authorized resource or view quotas. - **Granular lifecycle and regional management**: Allows data lifecycle rules, geographic placement, and backup schedules to be customized per tenant. - **Centralized policy governance**: Policy tag taxonomies govern column masking uniformly across all tenant tables. - **Predictable performance**: Tenant workloads are decoupled, avoiding shared scan overheads and unoptimized cluster keys. ### Why This Is Optimal Using Dataflow to write dedicated per-tenant datasets eliminates the 2,500 resource ceiling and single-region constraint inherent to **authorized views**, while native **dynamic data masking** provides robust column-level security without maintaining duplicate, obfuscated views.

Secure Multi Tenant Bigquery Access Architecture | professional-cloud-data-engineer

Secure Multi Tenant Bigquery Access Architecture

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 financial SaaS enterprise is designing a multi-tenant data access architecture in BigQuery to serve both internal analytics teams and external client organizations. The data architecture must satisfy the following technical and compliance requirements:

Tenant Scaling & Regionalization: Support scaling from 500 to over 5,000 distinct tenant organizations located across multiple global Google Cloud regions.
Performance Optimization: Enable each tenant to apply independent table partitioning and clustering schemes tailored to their specific querying workloads.
Column Governance: Dynamically obscure sensitive payment card data for general data analysts while providing plaintext access to authorized compliance auditors with the Fine-Grained Reader role.

Which architecture should the data engineering team implement to satisfy these requirements?

Create a centralized fact table in a primary dataset and expose authorized views filtered by tenant ID to each tenant. Enforce column-level security by assigning basic IAM Viewer permissions to compliance auditors and IAM Billing User permissions to standard analysts.

Deploy authorized materialized views in each tenant's Google Cloud project referencing a central source table. Use Cloud Storage Bucket Lock retention policies on the BigQuery export buckets to prevent unmasked column exposure.

Configure a data ingestion pipeline using Dataflow to write tenant-specific records into dedicated per-tenant BigQuery datasets in each tenant's local region, allowing tailored clustering and partitioning schemes. Apply Dataplex policy tags with dynamic data masking rules on sensitive columns, granting the Fine-Grained Reader role to compliance auditors.

Consolidate all tenant records into a single multi-region fact table and create BigQuery row access policies for each tenant. Apply Customer-Managed Encryption Keys (CMEK) separately to sensitive table columns to mask payment data dynamically.

Professional Cloud Data Engineer

Secure Multi Tenant Bigquery Access Architecture

Related questions