hardMultiple ChoiceObjective-mapped
Google ACE Practice Question: A SaaS company serves 200 enterprise customers,…
A SaaS company serves 200 enterprise customers, each requiring complete data isolation in separate databases. The company needs to provision a new customer database within minutes and manage 200 databases with minimal overhead. Which GCP approach scales most efficiently?
⚠ Common exam trap
A common mix-up: candidates confuse 'data isolation' with 'physical separation' and assume separate instances are required, but GCP's Cloud SQL supports logical isolation via separate databases on a single instance, which is far more efficient and still meets the isolation requirement.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
A single Cloud SQL instance with a separate schema (database) per customer, provisioned via API automation
It uses a single Cloud SQL instance with separate schemas (databases) per customer, which allows you to achieve complete data isolation while minimizing overhead. Provisioning a new schema via API automation takes seconds, and managing 200 schemas on one instance is far more efficient than managing 200 separate instances. This approach scales efficiently because Cloud SQL supports up to 10,000 databases per instance, and you can leverage connection pooling and shared resources without sacrificing isolation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
200 separate Cloud SQL instances, one per customer
Why it's wrong here
Spinning up 200 separate Cloud SQL instances, one per customer, introduces massive operational overhead: each instance requires its own patching schedule, automated backups, monitoring, failover configuration, and maintenance window. Cost scales linearly from the first day, even for customers with tiny workloads, and connection management becomes a nightmare because the application must handle 200 separate endpoints and connection pools. This approach also fails to scale — adding a new customer means provisioning another full instance with its own CPU, memory, and storage, which is slow, expensive, and unnecessary when lighter-weight multi-tenant patterns exist.
- ✓
A single Cloud SQL instance with a separate schema (database) per customer, provisioned via API automation
Why this is correct
A single Cloud SQL instance with a separate schema (database) per customer gives each tenant its own isolated set of tables while sharing the underlying compute and storage resources. Because schemas are logical constructs, a customer can be provisioned in sub-minute time via API calls (e.g., using the Cloud SQL Admin API or Terraform) without restarting the instance or creating a new instance. This design strikes a practical balance: tenant data is separated at the query layer, so a cross-schema error is far less likely than with a shared table, while costs and operational effort stay manageable because you run and maintain only one instance and its connection endpoints.
- ✗
Storing all customer data in a single shared database with customer_id as a discriminator column
Why it's wrong here
A shared database with a customer_id discriminator provides logical data separation only, not physical isolation. A single SQL error, an indexing mistake, or a missing WHERE clause can silently leak one tenant's rows to another, and foreign-key or join misconfigurations compound the risk. This model also makes it extremely difficult to offer per-customer compliance guarantees (e.g., GDPR erasure or audit isolation) because all data lives in the same tables, and it places the full burden of tenant security on application-level query correctness.
- ✗
Using BigQuery with a separate dataset per customer
Why it's wrong here
BigQuery is a columnar OLAP data warehouse designed for high-throughput analytical queries over large datasets, not for powering the transactional, row-level read/write operations of a SaaS application. It does not support row-level UPDATE/DELETE with low latency, ACID transactions for OLTP workloads, or single-row point lookups at the performance required for an application backend. Moreover, making per-customer API calls to BigQuery for every transaction would incur high query costs and latency, making it fundamentally unsuitable for this use case regardless of the dataset-per-customer isolation.
Go deeper
Related to this question
About these practice questions
One of 769 original ACE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.