Last reviewed: May 2026
Build the AWS services on the PCDOE exam with plain Terraform — one block at a time, each tied back to an exam domain. The same code works on OpenTofu.
By the end of this lab you'll have provisioned, with plain Terraform, one instance of each of GCP's three flagship managed-DB services — Cloud SQL Postgres (HA + automated backups), Cloud Spanner (regional, single-node), and Cloud Bigtable (single-node dev cluster). Four blocks; the PCDOE workload → service decision matrix in code.
This is the most cost-heavy lab in the GCP set; read the cost note carefully before applying.
Drop the snippets into a single main.tf, run terraform init, then terraform apply step-by-step.
>= 1.5 or OpenTofu >= 1.6.your-project-id in the provider block.Three line items bill aggressively:
db-perf-optimized-N-2, regional HA): ~$100/month.~$700/month combined. This is by far the most expensive lab in the CertLabPro set. Apply, take a screenshot, destroy. Or apply piece by piece (terraform apply -target=...) to provision and destroy one service at a time.
Enable Cloud SQL, Spanner, and Bigtable APIs.
terraform {
required_version = ">= 1.5"
required_providers {
google = { source = "hashicorp/google", version = "~> 6.0" }
}
}
provider "google" {
project = "your-project-id" # REPLACE
region = "us-central1"
}
locals {
labels = {
project = "certlabpro-pcdoe"
managed_by = "terraform"
}
}
resource "google_project_service" "sqladmin" {
service = "sqladmin.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "spanner" {
service = "spanner.googleapis.com"
disable_on_destroy = false
}
resource "google_project_service" "bigtableadmin" {
service = "bigtableadmin.googleapis.com"
disable_on_destroy = false
}Cloud SQL is GCP's managed Postgres / MySQL / SQL Server — vertically scaled, regional. PCDOE exam tests this Cloud-SQL-for-relational-with-known-vertical-scale-ceiling shape vs Spanner (horizontal scale, distributed transactions).
We provision with availability_type = "REGIONAL" (HA — synchronous replica in a different zone, automatic failover), automated daily backups, and point-in-time recovery enabled (the PCDOE-recommended default).
resource "google_sql_database_instance" "main" {
name = "certlabpro-pcdoe-pg"
database_version = "POSTGRES_15"
region = "us-central1"
settings {
tier = "db-perf-optimized-N-2"
availability_type = "REGIONAL" # HA — synchronous standby
backup_configuration {
enabled = true
point_in_time_recovery_enabled = true
start_time = "02:00"
backup_retention_settings {
retained_backups = 7
}
}
maintenance_window {
day = 7 # Sunday
hour = 3
update_track = "stable"
}
insights_config {
query_insights_enabled = true
query_string_length = 1024
record_application_tags = true
}
}
deletion_protection = false # lab-only
depends_on = [google_project_service.sqladmin]
}Cloud Spanner is PCDOE's horizontally-scaled, strongly-consistent, globally-distributed relational DB — the only product on the GCP exam blueprint that delivers SQL semantics across continents with strong consistency. PCDOE exam frames it as Cloud SQL for vertical, Spanner for horizontal.
We provision the smallest possible footprint: 1 Processing Unit (PU) regional, the PCDOE-recommended dev configuration. Production Spanner provisions 100+ PUs (or 1+ Nodes — 1 Node = 1000 PUs).
resource "google_spanner_instance" "main" {
name = "certlabpro-pcdoe"
config = "regional-us-central1"
display_name = "PCDOE lab Spanner"
processing_units = 100 # 1 Node = 1000 PUs; 100 PU = ~$65/month floor
labels = local.labels
depends_on = [google_project_service.spanner]
}
resource "google_spanner_database" "main" {
instance = google_spanner_instance.main.name
name = "labdb"
ddl = [
"CREATE TABLE items (id STRING(36) NOT NULL, name STRING(MAX), created_at TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true)) PRIMARY KEY (id)",
]
deletion_protection = false # lab-only
}Cloud Bigtable is PCDOE's wide-column NoSQL service — low-latency reads/writes at huge scale (think: time-series, IoT, ad-tech). PCDOE exam frames it as Bigtable for wide-column write-heavy, vs Firestore (document, mobile-first), vs Spanner (relational, distributed).
We provision a single-node SSD cluster (the smallest possible). One column family cf1 with infinite-version garbage collection — production deployments would use age-or-version-based GC policy.
Bigtable has no zero-cost tier — even idle, a 1-node SSD cluster bills ~$540/month. Destroy promptly.
resource "google_bigtable_instance" "main" {
name = "certlabpro-pcdoe-bt"
display_name = "PCDOE lab Bigtable"
instance_type = "PRODUCTION"
cluster {
cluster_id = "certlabpro-pcdoe-bt-c1"
zone = "us-central1-a"
num_nodes = 1
storage_type = "SSD"
}
labels = local.labels
deletion_protection = false # lab-only
depends_on = [google_project_service.bigtableadmin]
}
resource "google_bigtable_table" "items" {
name = "items"
instance_name = google_bigtable_instance.main.name
column_family {
family = "cf1"
}
}terraform destroy tears down everything — do this promptly to stop the ~$700/month bill. The Cloud SQL instance destroys (lab-only deletion_protection = false). The Spanner instance + database destroy clean (no production-deletion-protection block in the way). The Bigtable instance + table destroy cleanly.
PCDOE covers many DB-engineering surfaces this lab can't fit — Firestore (the document DB for mobile / web apps), Memorystore (managed Redis + Memcached), Cloud SQL for MySQL / SQL Server (covered Postgres only), Cloud SQL read replicas + cross-region replicas, AlloyDB for Postgres (the higher-perf Postgres-compatible service), Bigtable replication + autoscaling, Spanner's geo-replication configs (multi-region, dual-region), Database Migration Service (DMS — managed migration from on-prem MySQL / Postgres to Cloud SQL), Datastream (CDC), Bigtable's HBase API surface, Firestore's Datastore-mode legacy API, Cloud Backup and DR Service (the managed cross-service backup product), and Cloud Storage as a backup destination.
We stick to the Cloud SQL + Spanner + Bigtable trio because they're the PCDOE decision-matrix endpoints — every exam scenario tests which of these three (plus Firestore + AlloyDB) for this workload?. Firestore + AlloyDB + Memorystore would each add a meaningful slice but the cost makes a 5-service lab impractical.
For service-by-service conceptual coverage, see the Browse, Playbook, and Editorial sections of this cert page.