ExamFinch.com My Study

Study guide

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB

Practice this exam

Google Cloud Associate Cloud Engineer ACE

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Exam Overview

1.1 About the GCP Associate Cloud Engineer Exam 1.2 How to Use This Study Guide & Build a Study Plan

2 Chapter 2: Resource Hierarchy, IAM Basics & Cloud Identity

2.1 The GCP Resource Hierarchy: Organizations, Folders & Projects 2.2 Organization Policies & Granting IAM Roles 2.3 Cloud Identity: Managing Users and Groups

3 Chapter 3: APIs, Quotas & Billing Configuration

3.1 Enabling APIs and Provisioning Cloud Operations Suite 3.2 Assessing and Requesting Quota Increases 3.3 Billing Accounts, Project Linking & Billing Exports 3.4 Billing Budgets and Alerts

4 Chapter 4: Planning Compute & Storage Resources

4.1 Choosing the Right Compute Option: GCE vs. GKE vs. Cloud Run vs. Cloud Functions 4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning 4.3 Choosing a Data Storage Product: Cloud SQL, BigQuery, Firestore, Spanner & Bigtable 4.4 Cloud Storage Classes & Persistent Disk Types

5 Chapter 5: Planning Network Resources

5.1 Load Balancing Options and Use Cases 5.2 Regional Resource Placement & High Availability Planning 5.3 Network Service Tiers: Premium vs. Standard

6 Chapter 6: Deploying Compute Engine Workloads

6.1 Launching Compute Engine Instances: Disks, SSH Keys & Availability Policies 6.2 Managed Instance Groups, Instance Templates & Autoscaling 6.3 OS Login and VM Manager for Fleet Configuration

7 Chapter 7: Deploying Google Kubernetes Engine Workloads

7.1 Installing and Configuring kubectl 7.2 Deploying GKE Clusters: Autopilot, Regional, Private & GKE Enterprise 7.3 Deploying Containerized Applications to GKE

8 Chapter 8: Deploying Serverless & Event-Driven Applications

8.1 Deploying Applications to Cloud Run and Cloud Functions 8.2 Event-Driven Architectures: Pub/Sub, Cloud Storage Triggers & Eventarc

9 Chapter 9: Deploying Data Solutions

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB 9.2 Deploying Pub/Sub, Dataflow & Loading Data into Google Cloud

10 Chapter 10: Deploying Networking Resources & Infrastructure as Code

10.1 Creating VPCs, Subnets & Shared VPC 10.2 Firewall Rules, Cloud VPN & VPC Network Peering 10.3 Infrastructure as Code: Terraform, Config Connector, Cloud Foundation Toolkit & Helm

11 Chapter 11: Managing Compute Engine & GKE in Production

11.1 Connecting to and Managing Running Compute Engine Instances 11.2 Working with Snapshots and Custom Images 11.3 Managing GKE Clusters: Node Pools, Workloads & Artifact Registry Access 11.4 Horizontal and Vertical Pod Autoscaling in GKE

12 Chapter 12: Managing Cloud Run, Storage & Database Operations

12.1 Managing Cloud Run Revisions, Traffic Splitting & Scaling 12.2 Managing and Securing Cloud Storage Objects & Lifecycle Policies 12.3 Querying, Estimating Costs, Backup & Job Monitoring for Databases (Cloud SQL, BigQuery, Spanner, Dataflow)

13 Chapter 13: Networking Operations, Monitoring & Logging

13.1 Networking Operations: Subnets, Static IPs, Cloud DNS & Cloud NAT 13.2 Cloud Monitoring: Alerts, Custom Metrics & Dashboards 13.3 Cloud Logging: Buckets, Log Analytics, Routers & Filtering 13.4 Diagnostics, Ops Agent, Managed Service for Prometheus & Audit Logs

14 Chapter 14: IAM Policies & Role Types

14.1 IAM Policies: Structure, Bindings & Policy Hierarchy 14.2 IAM Role Types: Basic, Predefined & Custom Roles

15 Chapter 15: Service Accounts & Security Configuration

15.1 Creating Service Accounts & Assigning Least-Privilege Permissions 15.2 Assigning Service Accounts to Resources & Managing SA IAM Policies 15.3 Service Account Impersonation & Short-Lived Credentials

16 Chapter 16: Exam Readiness — Scenarios & Test-Day Strategy

16.1 Common ACE Exam Scenarios & Decision Frameworks 16.2 Test-Day Logistics, Time Management & Final Review Checklist

9.1 Deploying Data Products: Cloud SQL, Firestore, Spanner, BigQuery & AlloyDB

Key Takeaways Explain This Topic AI

Cloud SQL scales vertically only (bigger tier, read replicas); Spanner scales horizontally across regions with strong consistency, sized in processing units (100 PU increments, with 1,000 PU equal to 1 node).

Firestore has two mutually exclusive modes chosen at creation -- Native (recommended for new apps) and Datastore (legacy) -- and a single project can host multiple databases of either mode.

AlloyDB clusters have exactly one primary instance (HA = 2 nodes across zones, Basic = 1 node) plus up to 20 nodes of read pool capacity sharing the same storage layer for near-zero replication lag.

A BigQuery dataset's location is set at creation and is immutable; partitioning and clustering are also configured only when a table is created.

Know the deployment gcloud/bq flags for each product -- the exam tests recognition of terms like --availability-type , --processing-units , --type=firestore-native , and --instance-type=PRIMARY .

Last updated: July 2026

Why This Section Matters

Domain 3, "Deploying and implementing a cloud solution," is the single heaviest domain on the Associate Cloud Engineer (ACE) exam at 25% of the exam weight, and the official exam guide's data-solutions bullet -- "Deploying data products (e.g., Cloud SQL, Firestore, BigQuery, Spanner, Pub/Sub, Dataflow, Cloud Storage, AlloyDB)" -- names eight products in a single sentence. That density is a signal: expect several ACE questions that hand you a workload description and ask which database or data product to deploy , then follow up with the exact gcloud / bq command or console setting needed to stand it up correctly. This section covers the five stateful data stores from that bullet -- Cloud SQL , Firestore , Spanner , BigQuery , and AlloyDB . Pub/Sub, Dataflow, and Cloud Storage-based data loading are covered in the next section (9.2), since they behave more like data-movement products than data stores.

The ACE exam does not test SQL syntax or deep database administration theory. It tests which product fits which requirement and what the deployment options are called -- machine tier vs. processing units vs. read pools. Missing this section usually shows up as choosing Cloud SQL for a workload that actually needs Spanner's horizontal scale, or forgetting that Firestore ships in two incompatible modes chosen only once, at creation time.

  • Core Deployment Concepts by Product
  • Cloud SQL -- Managed Relational Database

Cloud SQL is Google Cloud's fully managed service for MySQL , PostgreSQL , and SQL Server . You deploy an instance , not a cluster: gcloud sql instances create orders-db \

  • -database-version=POSTGRES_15 \
  • -tier=db-custom-4-16384 \
  • -region=us-central1 \
  • -storage-type=SSD \
  • -storage-size=100GB \
  • -availability-type=REGIONAL

--tier selects the machine type (either the older db-n1-standard-* family or the newer db-custom-CPU-RAM naming).

--storage-type is SSD (default; lower latency) or HDD (cheaper; for rarely accessed data) -- availability depends on the machine series.

--availability-type=REGIONAL provisions a synchronous standby in a second zone that Cloud SQL fails over to automatically. The default, ZONAL , has no standby.

Storage auto-increases up to a configurable limit -- no manual disk resizing during normal operation.

Read replicas (including cross-region replicas) scale reads, but Cloud SQL as a whole scales vertically only : a hard per-instance CPU/RAM ceiling, no built-in horizontal write scaling.

Firestore -- Serverless Document Database

Firestore is a serverless NoSQL document database offered in two mutually exclusive modes , chosen once at database-creation time:

Native mode -- the modern document model with real-time listeners, mobile/web SDKs, and offline sync. Google recommends Native mode for all new applications .

Datastore mode -- retained for legacy applications built against the original Datastore API; it removes several old Datastore limits (queries are now strongly consistent, and the 25-entity-group transaction cap is gone). gcloud firestore databases create \

  • -database='catalog-db' \
  • -location=nam5 \
  • -type=firestore-native

A single project can host multiple Firestore databases -- a (default) database plus additional named ones -- and each independently picks Native or Datastore mode; teams use this to isolate a QA database from production without a second project. --location accepts a single region or a multi-region value ( nam5 , eur3 ); multi-region trades a small latency cost for continent-wide durability.

Spanner -- Globally Distributed Relational Database

Cloud Spanner is the product to reach for when a workload needs relational (SQL) semantics at global scale with strong, externally consistent transactions -- something Cloud SQL cannot do, because Cloud SQL is bound to a single region and scales only vertically.

Compute capacity is expressed in processing units (PU) :

  • Capacity Unit
  • 100-900 PU Configured in multiples of 100
  • 1,000 PU Equals exactly 1 node
  • 2,000 / 3,000 PU ... Equivalent to 2 / 3 ... nodes
  • Storage capacity 10 TiB per node (per 1,000 PU)

The instance configuration is chosen at creation and is not something you casually change afterward:

Regional -- all resources live in a single region (minimum 3 replica servers per node).

Dual-region -- resources span two regions within one country.

Multi-region -- resources span multiple regions/continents (minimum 5 replica servers per node) for the strongest availability and the lowest read latency for globally distributed users. gcloud spanner instances create sales-instance \

  • -config=regional-us-central1 --processing-units=100 \
  • -description="Sales OLTP"
  • gcloud spanner databases create sales-db \
  • -instance=sales-instance --ddl='CREATE TABLE Orders (...)'
  • BigQuery -- Serverless Data Warehouse

Deploying a BigQuery workload starts with a dataset -- a top-level container that sets the default location for every table inside it. That location choice is immutable : a dataset created in US cannot later be moved to EU ; you must recreate it and copy the data. Inside a dataset you create native tables (data stored in BigQuery), external tables (query data in place in Cloud Storage or Bigtable without loading it first), or views . bq mk --dataset --location=US myproject:sales_ds

bq mk --table sales_ds.orders schema.json

Two deployment-time features matter for the exam: partitioning (splitting a table by a date/timestamp column, by ingestion time, or by an integer range so queries scan fewer bytes) and clustering (sorting data within each partition by up to four columns). Both reduce bytes scanned -- and therefore cost -- and both are configured only when the table is created.

AlloyDB -- PostgreSQL-Compatible, Disaggregated Architecture

AlloyDB for PostgreSQL separates compute from storage. A cluster contains exactly one primary instance (the writer -- either HA , with an active node and a standby node in different zones, or Basic , a single node for non-production use) plus zero or more read pool instances (up to 20 nodes total across the cluster). Read pool instances all read from the same underlying storage as the primary, so they achieve near-zero replication lag rather than the lag typical of traditional replicas. gcloud alloydb clusters create sales-cluster --region=us-central1 --network=default

  • gcloud alloydb instances create sales-primary --cluster=sales-cluster \
  • -region=us-central1 --instance-type=PRIMARY
  • Decision Table: Which Product to Deploy
  • Requirement Deploy
  • Managed MySQL/PostgreSQL/SQL Server, single region, moderate scale Cloud SQL
  • Serverless NoSQL for a mobile/web app needing real-time sync Firestore (Native mode)
  • Legacy application tied to the original Datastore API Firestore (Datastore mode)
  • Relational SQL needing horizontal, global scale with strong consistency Spanner
  • Petabyte-scale SQL analytics / data warehouse BigQuery
  • PostgreSQL-compatible OLTP with higher throughput than Cloud SQL AlloyDB
  • Exam Scenario

A retailer's checkout service currently runs on a single Cloud SQL for PostgreSQL instance. As the company expands to simultaneous storefronts in the US and the EU, the team needs strict transactional consistency across regions for shared inventory counts, with no single point of failure. Cloud SQL cannot meet this requirement -- it is bound to one region and scales only vertically, and cross-region read replicas would only be eventually consistent. The correct deployment is a Spanner multi-region instance configuration , sized in processing units, which delivers horizontally scalable SQL with cross-region strong consistency.