Advanced
Prepare and test your skills
Advanced
Prepare and test your skills
Isolating SaaS Tiers with BigQuery Projects and Slots
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.
A SaaS organization is redesigning its analytics platform on Google Cloud to handle a projected tenfold increase in tenant onboarding and raw data volume. Currently, ingestion workloads, storage, and customer-facing analytical queries share resources in a monolithic project, leading to severe compute contention, complex schema maintenance, and quota bottlenecks.
You need to design a scalable, modular architecture that leverages BigQuery's separation of storage and compute to isolate compute resource allocation across tenant tiers while allowing storage and analytical pipelines to scale independently.
Which architectural approach should you recommend?
Explanations
Deploy dedicated Compute Engine virtual machines running Apache Spark for each tenant tier, connecting directly to a shared BigQuery dataset containing a single monolithic fact table filtered using row-level security.
Deploy dedicated Compute Engine virtual machines running Apache Spark for each tenant tier, connecting directly to a shared BigQuery dataset containing a single monolithic fact table filtered using row-level security.
What This Option Proposes
This pattern provisions dedicated Compute Engine virtual machine clusters running self-managed Apache Spark for processing and analytics, querying a single monolithic BigQuery fact table restricted with row-level security policies.
Why It Doesn't Meet the Requirement
- Fails to Leverage Managed Scalability: Relying on fixed VM clusters reintroduces infrastructure management overhead, server limits, and rigid capacity planning, defeating the purpose of adopting BigQuery's serverless architecture.
- Storage and Query Contention: Funneling all tenants through a single massive table filtered solely by row-level security creates significant metadata locking and concurrency bottlenecks as tenant counts grow tenfold.
- High Maintenance Overhead: Self-managing Compute Engine instances requires manual scaling, patching, and operational upkeep.
Key Limitations
- Lacks native autoscaling and elasticity compared to managed BigQuery slots.
- Increases administrative complexity with cluster lifecycle and Spark configuration management.
- Single monolithic tables increase query scan costs and potential slot starvation.
This Answer Would Be Correct If
The workload specifically required a non-Google-managed custom open-source processing runtime that cannot run on BigQuery or Dataflow, and data isolation had to be strictly handled within a single shared database table.
Create a separate Google Cloud project per tenant containing both the tenant's Cloud Storage data lake and dedicated BigQuery on-demand compute resources, connected via cross-project VPC networks.
Create a separate Google Cloud project per tenant containing both the tenant's Cloud Storage data lake and dedicated BigQuery on-demand compute resources, connected via cross-project VPC networks.
What This Option Proposes
This option implements a project-per-tenant isolation model, where every onboarding customer receives an entirely independent Google Cloud project containing its own Cloud Storage buckets, BigQuery datasets, and default on-demand billing allocations.
Why It Doesn't Meet the Requirement
- Project and Quota Scalability Limits: As tenant counts increase tenfold, managing thousands of distinct projects hits hard administrative limits, such as VPC Service Controls perimeter project limits (maximum 10,000 projects) and service account management limits.
- Lack of Centralized Capacity Allocation: Utilizing default on-demand query pricing in isolated projects prevents centralized slot reservation sharing, pooled compute governance, and predictable tiered service level agreements.
- High Operational Friction: Rolling out centralized schema updates and analytical pipeline evolutions across thousands of disparate tenant projects requires complex orchestration.
Key Limitations
- Exceeds organization limits for security perimeters as tenant scale expands.
- Disables cross-tier compute optimization and slot sharing.
- Fragmented architecture complicates enterprise-wide data governance and lineage tracking.
This Answer Would Be Correct If
Every tenant legally mandated complete physical project isolation, dedicated billing accounts, and zero shared Google Cloud infrastructure boundaries.
Establish a centralized data pipeline project that ingests and dual-writes data into dedicated per-tenant BigQuery datasets within a core data storage project, and decouple query execution by creating compute tier projects mapped to BigQuery slot reservations using fair scheduling.
Establish a centralized data pipeline project that ingests and dual-writes data into dedicated per-tenant BigQuery datasets within a core data storage project, and decouple query execution by creating compute tier projects mapped to BigQuery slot reservations using fair scheduling.
What BigQuery Multi-Project Architecture Is
A multi-project architecture in Google Cloud decouples data pipelines, core dataset storage, and query computation into isolated projects. By capitalizing on BigQuery's native separation of storage and compute, analytical processing capacity can be managed independently from underlying persistent data assets.
How It Meets the Requirements
- Accommodate Projected Data Volume and Velocity: By centralizing ingestion within a dedicated data pipeline project running Dataflow to write directly to tenant datasets, data processing scales horizontally without consuming query slots from end-user workloads.
- Isolate Compute Resources Across Tiers: Creating separate reservation compute tier projects allows the business to map customer query workloads to dedicated BigQuery slot reservations. Built-in fair scheduling balances utilization within a tier while seamlessly reallocating idle slots across tiers.
- Independent Modular Evolution: Storing customer data across dedicated datasets within a centralized data storage project prevents quota exhaustion (such as project-level concurrency limits) while isolating tenant security via IAM and VPC Service Controls without duplicating infrastructure.
Key Advantages
- Eliminates Resource Contention: Decouples batch/streaming ingestion pipelines from interactive customer analytics.
- Predictable Performance: Guarantees compute capacity for premium tiers using explicit slot assignments.
- Scalable Governance: Uses dataset-level isolation and tenant-scoped service accounts to enforce least-privilege security.
- Cost Efficiency: Automatically reuses idle capacity across compute reservations through fair scheduling.
Why This Is Optimal
Alternative architectures that deploy full virtual clusters or monolithically bundle query and storage layers run into rigid scaling limits and resource contention. Decoupling storage into dedicated datasets and mapping workloads to reservation projects fully exploits BigQuery's serverless elasticity.
Maintain all data in a single BigQuery dataset in a monolithic project, and create up to 2,500 tenant-specific authorized views clustered on customer IDs while relying entirely on default on-demand query pricing.
Maintain all data in a single BigQuery dataset in a monolithic project, and create up to 2,500 tenant-specific authorized views clustered on customer IDs while relying entirely on default on-demand query pricing.
What This Option Proposes
This pattern retains all analytical data inside a single centralized BigQuery dataset in a single project and exposes customer subsets using authorized views clustered on tenant IDs, using on-demand pricing for compute execution.
Why It Doesn't Meet the Requirement
- Hard Quota Limits: BigQuery enforces a strict quota limit of 2,500 authorized resources (including authorized views) per dataset, making it unsuitable for accommodating substantial tenant growth.
- Compute and Concurrency Contention: On-demand pricing shares a default project concurrency limit (100 concurrent queries), leading to query queuing and unpredictable execution times during traffic spikes.
- Tightly Coupled Components: Ingestion and serving remain coupled in the same project, allowing unoptimized user queries to degrade background data transformations.
Key Limitations
- Hits hard dataset architectural quotas as tenant volume grows beyond 2,500.
- Does not provide dedicated compute isolation or slot allocation for high-priority tiers.
- Schema adjustments on base tables risk breaking dependencies across thousands of authorized views.
This Answer Would Be Correct If
The tenant count was guaranteed to remain well under 2,500, query concurrency was very low, and the organization prioritized immediate zero-copy view definitions over compute isolation.
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
BigQuery Authorized Datasets
Mapping current and future business requirements to the architecture
AdvancedProfessional Data Engineer
BigQuery Facade Views
Mapping current and future business requirements to the architecture
AdvancedProfessional Data Engineer
Cloud Data Fusion Argument Setter Plugin
Transformations
AdvancedProfessional Data Engineer
Cloud SQL ENCRYPTED_ONLY Private Services Access VPC-SC
Data encryption
AdvancedProfessional Data Engineer
BigQuery SCD Denormalization with Nested STRUCTs
Designing the data model
AdvancedProfessional Cloud DevOps Engineer
Ephemeral Project TTL and Cost Governance
Managing ephemeral environments
Last updated Validated