Google Cloud Expert

GCP-PCDBE

Google Cloud Professional Cloud Database Engineer

The Google Cloud Professional Cloud Database Engineer certification validates the ability to design, create, manage, and troubleshoot Google Cloud database solutions. This certification is designed for database professionals who design and implement secure, scalable, and reliable database solutions that support application and business requirements.

The exam covers designing scalable and highly available cloud database solutions using Cloud SQL, Cloud Spanner, Firestore, Bigtable, and Memorystore, managing solutions that span multiple database technologies including relational, NoSQL, and in-memory databases, migrating data solutions using Database Migration Service, Datastream, and BigQuery Data Transfer Service, and deploying scalable and highly available databases including replication, backup and recovery, and disaster recovery strategies.

This certification is recommended for professionals with at least three years of industry experience and one year of hands-on experience designing and managing database solutions on Google Cloud. It validates the ability to choose the right database solution for specific workloads, implement database security and compliance controls, optimize database performance and costs, and manage database operations at scale.

Updated Jun 2024 Database

Въпроси

Пробни тестове

70%

Минимален резултат

Прегледи

Общо опити

Ср. резултат

Процент на успеваемост

Дискусии

Пробни тестове Флаш карти Теми на изпита Пищов

€5.00

GCP-PCDBE Practice Exam 1

Comprehensive practice exam for the Professional Cloud Database Engineer certification covering database service selection, schema design, data migration strategies, replication configuration, and high availability implementation across Cloud SQL, Spanner, Firestore, and Bigtable.

50 Q 120 минути 70%

Пробно караме

€5.00

GCP-PCDBE Practice Exam 2

Second practice exam covering AlloyDB for PostgreSQL, Cloud SQL read replicas cross-region, Spanner multi-region configurations, Memorystore for Redis, Database Migration Service, Datastream for change data capture, automated backup schedules, point-in-time recovery, database monitoring with Cloud Monitoring, and slow query analysis.

50 Q 120 минути 70%

Пробно караме

€5.00

GCP-PCDBE Practice Exam 3

Third practice exam focusing on database security with encryption and IAM, Spanner query optimization, Bigtable performance tuning, cross-database data synchronization, and Cloud SQL maintenance windows.

50 Q 120 минути 70%

Пробно караме

€5.00

GCP-PCDBE Practice Exam 4

Fourth practice exam covering database capacity planning, cost optimization strategies, Firestore composite indexes, AlloyDB machine learning integration, Datastream replication patterns, and disaster recovery testing.

50 Q 120 минути 70%

Пробно караме

€5.00

GCP-PCDBE Practice Exam 5

Fifth practice exam covering database performance troubleshooting, connection management patterns, multi-region active-active architectures, data warehouse integration with BigQuery, and advanced Spanner features.

50 Q 120 минути 70%

Пробно караме

€5.00

GCP-PCDBE Practice Exam 6

Final comprehensive practice exam integrating all database engineering domains with complex multi-database architectures, advanced migration scenarios, and production database operations management.

50 Q 120 минути 70%

Пробно караме

Отключете цялото съдържание за GCP-PCDBE

6 Пробен/и тест/ове + Флаш карти — 3 месеца достъп

€39.99 €26.99 Спестете 30%

или включено в месечен абонамент / пакет съдържание

GCP-PCDBE Cheat Sheet

Кратък справочник - 6 раздели

Безплатен достъп

Cloud SQL Overview

Cloud SQL is Google Cloud's fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server. It handles patching, backups, replication, encryption, and high-availability while exposing the standard engine interface so existing applications connect with no code changes. Cloud SQL is regional (single-region HA) rather than multi-regional; use Spanner or AlloyDB for global requirements.

MySQL

Versions 5.6, 5.7, 8.0, 8.4
InnoDB storage engine
Binary log based replication
Up to 624 GB RAM, 96 vCPU
Up to 64 TB storage

PostgreSQL

Versions 11 through 16
Logical + physical replication
Extensions (PostGIS, pgvector)
Up to 624 GB RAM, 96 vCPU
Up to 64 TB storage

SQL Server

2017, 2019, 2022
Standard, Enterprise, Express, Web
Active Directory authentication
Cross-region read replicas
Up to 624 GB RAM

High Availability (Regional HA)

Enabling HA provisions a synchronous standby instance in a different zone of the same region using regional persistent disks. On primary failure, Cloud SQL performs automatic failover in 60-120 seconds. The standby is not readable - it is strictly for failover.

# Create a highly-available Cloud SQL MySQL instance
gcloud sql instances create prod-mysql \
    --database-version=MYSQL_8_0 \
    --tier=db-n1-standard-4 \
    --region=europe-west2 \
    --availability-type=REGIONAL \
    --storage-type=SSD \
    --storage-size=500GB \
    --storage-auto-increase \
    --backup-start-time=03:00 \
    --enable-bin-log \
    --retained-backups-count=14 \
    --retained-transaction-log-days=7 \
    --maintenance-window-day=SUN \
    --maintenance-window-hour=4 \
    --maintenance-release-channel=production

REGIONAL: synchronous replication to standby in another zone. Automatic failover. ~60-120s RTO. Recommended for production.

ZONAL: single-zone. No standby. Cheaper but downtime during zone failure or maintenance. Dev/test only.

Read Replicas

Read replicas offload read traffic from the primary using asynchronous replication. They can be in-region (recommended, lower lag) or cross-region (DR, global reads). Up to 10 read replicas per primary. Replicas can be promoted to standalone primaries for DR cutover.

# Same-region read replica
gcloud sql instances create prod-mysql-replica-1 \
    --master-instance-name=prod-mysql \
    --tier=db-n1-standard-4 \
    --region=europe-west2

# Cross-region read replica (DR use case)
gcloud sql instances create prod-mysql-dr-replica \
    --master-instance-name=prod-mysql \
    --tier=db-n1-standard-4 \
    --region=us-central1

# Promote replica to standalone primary (DR cutover)
gcloud sql instances promote-replica prod-mysql-dr-replica

Caveat: Binary logging must be enabled on the primary for replicas. Replica lag grows with write load; monitor cloudsql.googleapis.com/database/replication/replica_lag.

Storage & Auto-Increase

Cloud SQL storage is irreversible - you can grow it but never shrink. Always enable storage auto-increase to prevent the instance from going read-only when full. Size is tied to IOPS: 30 IOPS/GB for SSD, up to 60,000 read + 30,000 write IOPS.

SSD: low-latency OLTP, up to 64 TB
HDD: cheaper, throughput workloads, up to 64 TB
Auto-increase adds 5 GB at a time when <10% free
Cannot shrink disk - export and reimport to smaller instance if needed

Backups & Point-in-Time Recovery (PITR)

Automated backups are daily; manual on-demand backups do not expire automatically. PITR restores to any second within the transaction log retention window (default 7 days, up to 35).

# Enable PITR (MySQL bin-log / PostgreSQL WAL)
gcloud sql instances patch prod-mysql \
    --enable-point-in-time-recovery \
    --retained-transaction-log-days=7

# Restore to a new instance at a specific point in time
gcloud sql instances clone prod-mysql prod-mysql-restored \
    --point-in-time='2026-04-17T09:15:00.000Z'

# List backups
gcloud sql backups list --instance=prod-mysql

# Restore from a specific backup
gcloud sql backups restore BACKUP_ID \
    --restore-instance=prod-mysql-restored \
    --backup-instance=prod-mysql

Connectivity & Security

Private IP (VPC)

Uses VPC peering with Private Services Access. No public exposure. Required for most production workloads. Allocate a /24 or larger.

Public IP + Authorized Networks

Discouraged. If used, combine with SSL enforcement and narrow CIDR ranges. Prefer Auth Proxy instead.

# Cloud SQL Auth Proxy (recommended for all app tiers)
cloud-sql-proxy --private-ip \
    --auto-iam-authn \
    my-project:europe-west2:prod-mysql

# Enable IAM database authentication (MySQL / Postgres)
gcloud sql instances patch prod-mysql \
    --database-flags=cloudsql_iam_authentication=on

# Create IAM-auth database user
gcloud sql users create [email protected] \
    --instance=prod-mysql \
    --type=cloud_iam_service_account

Auth Proxy benefits: short-lived credentials via IAM, automatic TLS, no SSL cert management, works with Private IP without VPN.

Maintenance Windows

Choose a weekly window (day + hour) for Google-initiated restarts. Use the production release channel to receive updates later than preview. Deny periods block maintenance for up to 90 days around launches.

gcloud sql instances patch prod-mysql \
    --maintenance-window-day=SUN \
    --maintenance-window-hour=4 \
    --maintenance-release-channel=production \
    --deny-maintenance-period-start-date=2026-11-15 \
    --deny-maintenance-period-end-date=2026-12-31 \
    --deny-maintenance-period-time=00:00:00

Exam Tips

Regional HA for production, zonal for dev/test.
For cross-region DR, use cross-region read replicas and promote during failover.
Cloud SQL cannot scale writes horizontally - if you outgrow it, move to Spanner or AlloyDB.
Always enable storage auto-increase + PITR in production.
Auth Proxy + IAM DB auth is the Google-recommended connection pattern.

Cloud Spanner Overview

Cloud Spanner is a globally distributed, strongly consistent, horizontally scalable relational database. It combines SQL (ANSI 2011 + PostgreSQL dialect) with NoSQL-like horizontal scalability. Spanner uses TrueTime (atomic clocks + GPS) to deliver external consistency - the strongest isolation level commercially available.

Regional Configurations

3 replicas in 3 zones of one region
99.99% SLA
Lowest write latency
Examples: regional-europe-west2

Multi-Region Configurations

Read-write + read-only + witness replicas
99.999% SLA (five nines)
Examples: nam-eur-asia1, eur3
Higher write latency (quorum across regions)

TrueTime & External Consistency

TrueTime exposes an uncertainty interval TT.now() = [earliest, latest]. Spanner waits out the uncertainty on commit so that any later transaction sees a strictly later timestamp - this is external consistency, stronger than linearizability. It means no stale reads, no clock skew anomalies across regions.

Strong reads: always see latest committed data (default).
Stale reads: read at exact_staleness or bounded_staleness for lower latency/cost on read replicas.
Read-only transactions: lock-free snapshot reads, recommended for reporting.

Schema Design: Interleaved Tables

Interleaving a child table in its parent physically co-locates rows on the same split, making parent-child joins and transactions cheap. Up to 7 levels of interleaving.

CREATE TABLE Customers (
    CustomerId   STRING(36) NOT NULL,
    Name         STRING(200),
    Email        STRING(200),
    CreatedAt    TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp=true),
) PRIMARY KEY (CustomerId);

CREATE TABLE Orders (
    CustomerId   STRING(36) NOT NULL,
    OrderId      STRING(36) NOT NULL,
    Total        NUMERIC,
    Status       STRING(20),
    OrderDate    TIMESTAMP NOT NULL,
) PRIMARY KEY (CustomerId, OrderId),
  INTERLEAVE IN PARENT Customers ON DELETE CASCADE;

-- Secondary index with STORING clause to avoid base-table lookups
CREATE INDEX OrdersByStatus
    ON Orders(Status, OrderDate DESC)
    STORING (Total);

Avoiding Hotspots

Spanner partitions data by primary-key ranges (splits). Monotonically increasing keys (timestamps, auto-increment) create a single-split hotspot that kills throughput. Fixes:

Bad

CREATE TABLE Events (
  EventTimestamp TIMESTAMP NOT NULL,
  EventId STRING(36),
  ...
) PRIMARY KEY (EventTimestamp);

Good

CREATE TABLE Events (
  ShardId INT64 NOT NULL,   -- hash(EventId) % N
  EventTimestamp TIMESTAMP NOT NULL,
  EventId STRING(36) NOT NULL,
  ...
) PRIMARY KEY (ShardId, EventTimestamp, EventId);

Alternatives: use UUIDv4 primary keys, bit-reverse a sequential ID, or prefix with a hash shard.

DML vs Mutations

DML (SQL)

Standard INSERT/UPDATE/DELETE
Supports WHERE conditions, joins
Partitioned DML for large batch ops
Higher overhead per row

Mutations (API)

Buffered row-level changes
Insert / Update / InsertOrUpdate / Replace / Delete
Faster for bulk loads
No conditional logic

-- Partitioned DML for large updates (bypasses single transaction limits)
UPDATE Orders SET Status = 'ARCHIVED'
WHERE OrderDate < TIMESTAMP '2024-01-01';

Backup, Restore & PITR

# Create on-demand backup (retention up to 1 year)
gcloud spanner backups create orders-backup-20260418 \
    --instance=prod-spanner \
    --database=orders \
    --retention-period=30d

# Restore backup to a new database
gcloud spanner databases restore orders-restored \
    --instance=prod-spanner \
    --backup=orders-backup-20260418 \
    --backup-instance=prod-spanner

# PITR: configure version retention (up to 7 days)
gcloud spanner databases ddl update orders \
    --instance=prod-spanner \
    --ddl='ALTER DATABASE orders SET OPTIONS(version_retention_period="7d")'

Capacity units: Processing Units (100 PU = 1/10 node). Minimum 100 PU for production. Scale compute independently from storage.

Exam Tips

Spanner is the answer for global, strongly consistent, relational workloads.
Use interleaving for parent-child 1:N relationships to co-locate reads/writes.
Never use monotonic primary keys - shard or use UUIDs.
STORING indexes satisfy queries without base-table lookups.
Use Partitioned DML for large batch modifications.

NoSQL & In-Memory Services

Google Cloud offers Firestore (document), Bigtable (wide-column), and Memorystore (in-memory) for non-relational workloads. Picking the right one hinges on access pattern, consistency needs, and scale.

Firestore

Native Mode

Real-time listeners & mobile SDKs
Security Rules (client-side auth)
Up to 10k writes/sec per database
Strongly consistent for single docs

Datastore Mode

Backend-only (no real-time)
IAM-based auth
Millions of writes/sec
Backwards compatible with Datastore

Indexes: Firestore auto-indexes single fields. Composite indexes (multi-field, multi-direction) must be declared. Cannot perform arbitrary ad-hoc queries - every query must be served by an index.

# Declare a composite index
gcloud firestore indexes composite create \
    --collection-group=orders \
    --field-config=field-path=status,order=ascending \
    --field-config=field-path=created_at,order=descending

# Security Rule example (Native mode)
rules_version = '2';
service cloud.firestore {
  match /databases/{db}/documents {
    match /users/{userId} {
      allow read: if request.auth != null && request.auth.uid == userId;
      allow write: if request.auth != null && request.auth.uid == userId
                   && request.resource.data.keys().hasOnly(['name','email']);
    }
  }
}

Transactions: up to 500 document writes per transaction, automatic retry on contention. Use runTransaction for atomic read-modify-write.

Cloud Bigtable

Sparse, petabyte-scale wide-column store. Ideal for time-series, IoT, AdTech, and operational analytics with >1 TB and high throughput. Low single-digit ms latency. No SQL - HBase API.

Row Key Design

Single index = the row key
Reverse timestamp for recent-first
Field promotion: entity#reverseTS
Avoid sequential or timestamp-leading keys

Storage

SSD: low-latency OLTP
HDD: archival, >10 TB, infrequent reads
Storage type cannot be changed later

# Create a Bigtable instance with replication (dual-cluster HA)
gcloud bigtable instances create iot-metrics \
    --display-name="IoT Metrics" \
    --cluster-config=id=iot-europe,zone=europe-west2-a,nodes=3,storage-type=SSD \
    --cluster-config=id=iot-us,zone=us-central1-a,nodes=3,storage-type=SSD

# App profiles: single-cluster routing vs multi-cluster routing
gcloud bigtable app-profiles create failover-profile \
    --instance=iot-metrics \
    --route-any \
    --transactional-writes=false

# Row-key design example:
# device#<reverseTimestamp>
# device-0042#9223372036853775807

Scaling: nodes handle ~10k QPS each and ~2.5 TB SSD / ~8 TB HDD. Bigtable auto-rebalances tablets across nodes. Add nodes for throughput.

Memorystore

Redis (Standard)

1 primary + 1 replica (HA)
Automatic failover
Up to 300 GB per instance
Persistence (RDB snapshots)

Redis Cluster

Horizontal sharding
Scales to TBs
Zero-downtime scaling
Cluster-mode client required

Memcached

Multi-node, no replication
Best for simple caching
Up to 5 TB per instance
No persistence

# Create a Memorystore for Redis instance with HA
gcloud redis instances create cache-prod \
    --size=5 \
    --region=europe-west2 \
    --tier=STANDARD_HA \
    --redis-version=redis_7_0 \
    --network=projects/my-project/global/networks/default \
    --connect-mode=PRIVATE_SERVICE_ACCESS \
    --enable-auth \
    --transit-encryption-mode=SERVER_AUTHENTICATION

Decision Cheat

Mobile app with real-time sync? Firestore Native.
High-throughput backend document store? Firestore Datastore mode.
IoT / time series / AdTech > 1 TB? Bigtable.
Session store / page cache? Memorystore Redis.
Simple ephemeral cache, huge capacity? Memorystore Memcached.

BigQuery for Analytics

BigQuery is a serverless, petabyte-scale, columnar data warehouse. Storage and compute are separated: data lives in Capacitor (compressed columnar) on Colossus, queries run on Dremel slots. This decoupling allows independent scaling of the two.

Slots: On-Demand vs Reservations

On-Demand

Billed per TB scanned ($6.25/TB)
Up to 2000 slots per project
No commitment
Unpredictable cost at scale

Capacity (Editions)

Standard / Enterprise / Enterprise Plus
Autoscaling + baseline slots
1-year or 3-year commitments
Predictable, often cheaper

# Create a reservation and assign to a project
bq mk --reservation \
    --project_id=admin-project \
    --location=EU \
    --slots=500 \
    --edition=ENTERPRISE \
    prod-reservation

bq mk --assignment \
    --reservation_id=admin-project:EU.prod-reservation \
    --assignee_id=analytics-project \
    --assignee_type=PROJECT \
    --job_type=QUERY

Partitioning & Clustering

Partitioning splits a table into segments BigQuery can prune; clustering physically orders data within each partition by up to 4 columns for block pruning.

-- Time-unit column partitioned + clustered
CREATE TABLE analytics.events (
  event_id      STRING,
  user_id       STRING,
  event_type    STRING,
  country       STRING,
  event_time    TIMESTAMP,
  payload       JSON
)
PARTITION BY DATE(event_time)
CLUSTER BY event_type, country, user_id
OPTIONS (
  partition_expiration_days = 365,
  require_partition_filter  = TRUE   -- blocks unbounded scans
);

-- Integer-range partitioning
CREATE TABLE sales.orders (
  order_id INT64,
  total    NUMERIC,
  region   STRING
)
PARTITION BY RANGE_BUCKET(order_id, GENERATE_ARRAY(0, 1000000000, 1000000))
CLUSTER BY region;

Partition types

Ingestion time (_PARTITIONTIME)
Time-unit column (DATE/TIMESTAMP/DATETIME)
Integer range
Max 4000 partitions per table

Clustering

Up to 4 columns, ordered
Helps range/equality/IN filters
Auto re-clustering on ingest
Complements partitioning

Materialized Views & BI Engine

Materialized views precompute aggregations and auto-refresh with incremental maintenance. They transparently accelerate queries against the base table via automatic query rewrite.

CREATE MATERIALIZED VIEW analytics.daily_events
OPTIONS (
  enable_refresh = TRUE,
  refresh_interval_minutes = 30
) AS
SELECT
  DATE(event_time) AS event_date,
  country,
  event_type,
  COUNT(*)        AS event_count,
  COUNT(DISTINCT user_id) AS unique_users
FROM analytics.events
GROUP BY 1, 2, 3;

BI Engine is an in-memory acceleration layer that caches tables/query fragments for sub-second dashboards (Looker Studio, Tableau). Reserve memory per project/location.

Data Transfer Service, BQML & External Tables

Data Transfer Service (DTS)

Scheduled ingestion from Google Ads, Google Analytics, YouTube, S3, Redshift, Teradata, Cloud Storage, and more. No-code, managed retries.

BigQuery ML (BQML)

Train ML models with SQL: linear/logistic regression, k-means, ARIMA_PLUS, boosted trees, DNNs, Vertex AI remote models (Gemini).

CREATE OR REPLACE MODEL analytics.churn
OPTIONS (model_type='LOGISTIC_REG', input_label_cols=['churned'])
AS SELECT * EXCEPT(user_id) FROM analytics.training_set;

External Tables & BigLake

Query data in Cloud Storage (Parquet, ORC, Avro, CSV, JSON), Bigtable, or Cloud SQL without loading. BigLake adds fine-grained IAM + row/column policies on lake data.

Cost Control

Always partition + cluster tables > 1 GB.
Enforce require_partition_filter to prevent full scans.
Set project/user query byte-scanned quotas.
Use materialized views or BI Engine for hot dashboards.
Flat-rate (capacity) pricing for predictable heavy workloads.

Migrating to Google Cloud

Google Cloud provides two complementary services: Database Migration Service (DMS) for homogeneous/heterogeneous migrations, and Datastream for serverless change data capture (CDC) into BigQuery, Cloud SQL, or Cloud Storage.

DMS (Database Migration Service)

Homogeneous

MySQL -> Cloud SQL for MySQL
PostgreSQL -> Cloud SQL / AlloyDB
SQL Server -> Cloud SQL for SQL Server
Free during migration
Continuous until promotion

Heterogeneous

Oracle -> PostgreSQL / AlloyDB
SQL Server -> PostgreSQL (preview)
Schema conversion workbench
Manual review of unsupported objects

# Create a connection profile for the source (MySQL)
gcloud database-migration connection-profiles create mysql \
    onprem-mysql-src \
    --region=europe-west2 \
    --host=10.0.0.5 --port=3306 \
    --username=dmsuser \
    --password-secret=projects/my-project/secrets/mysql-pw/versions/latest

# Destination: a new Cloud SQL instance
gcloud database-migration connection-profiles create cloudsql \
    cloudsql-dest --region=europe-west2 \
    --cloudsql-settings-database-version=MYSQL_8_0 \
    --cloudsql-settings-tier=db-n1-standard-4

# Create & start migration job
gcloud database-migration migration-jobs create mysql-to-csql \
    --region=europe-west2 \
    --type=CONTINUOUS \
    --source=onprem-mysql-src \
    --destination=cloudsql-dest \
    --vpc-peering-connectivity=projects/my-project/global/networks/default

gcloud database-migration migration-jobs start mysql-to-csql \
    --region=europe-west2

# Promote the replica (cutover)
gcloud database-migration migration-jobs promote mysql-to-csql \
    --region=europe-west2

Datastream (Serverless CDC)

Reads change events from Oracle, MySQL, PostgreSQL, or SQL Server and streams them to BigQuery (direct), Cloud Storage, or Cloud SQL with low latency (seconds). Ideal for real-time analytics and replication-based migrations.

Use Case 1

OLTP -> BigQuery analytics replica with <15s lag.

Use Case 2

CDC to Cloud Storage for audit/archive.

Use Case 3

Feed Dataflow pipelines for enrichment.

One-Shot vs Continuous Migration

One-Shot (Snapshot)

Single dump + load. Requires an outage window equal to dump+load time. Best for small databases or non-critical systems.

• mysqldump / pg_dump
• bq load from Cloud Storage
• DMS one-time migration

Continuous (CDC)

Initial load + ongoing replication of changes. Cutover window limited to DNS switch. Best for production OLTP with strict RTO.

• DMS CONTINUOUS type
• Datastream
• Native replication (binlog/WAL)

Dual-Write & Cutover Strategies

For heterogeneous migrations or when replication tools do not cover the source, the application writes to both databases during transition:

Phase 1: Backfill

Bulk copy historical data (Dataflow, Storage Transfer, pg_dump) to target. Verify row counts and checksums.

Phase 2: Dual Write

App writes to source (canonical) and target (shadow). Reads still from source. Monitor divergence.

Phase 3: Dual Read, Target Canonical

Flip reads to target; writes still to both. Validate for days.

Phase 4: Cutover

Stop writes to source. Retire it. Document rollback plan.

Exam Tips

DMS for most lift-and-shift; Datastream for analytics CDC.
Oracle -> PostgreSQL is the classic DMS heterogeneous path.
Private VPC peering is preferred over IP allowlists.
Always validate post-migration with row counts + sample checksums.
Keep a rollback plan until the source is decommissioned.

Operations, HA & IAM

Running databases in production requires proactive monitoring, tested backups, and least-privilege IAM. Google Cloud provides Cloud Monitoring, Query Insights, and Active Assist recommendations to close the feedback loop.

Cloud Monitoring Metrics

Every managed database exposes Cloud Monitoring metrics automatically. Set SLO-based alerts instead of threshold alerts wherever possible.

Service	Critical Metrics
Cloud SQL	`cpu/utilization`, `memory/utilization`, `disk/utilization`, `replication/replica_lag`, `mysql/innodb_buffer_pool_pages_free`
Spanner	`instance/cpu/utilization_by_priority`, `instance/storage/used_bytes`, `lock_stat/total/lock_wait_time`, hot-keys via key visualizer
Bigtable	`server/cpu_load`, `server/cpu_load_hottest_node`, `server/latencies`, `disk/bytes_used`
BigQuery	`slots/allocated`, `query/execution_times`, `job/num_in_flight`, `storage/total_bytes`
Firestore	`document/read_count`, `document/write_count`, `api/request_count`, `index/write_count`

Query Insights & Slow Query Log

Query Insights (Cloud SQL + AlloyDB) surfaces top queries by load, latency, and I/O with end-to-end tracing (application -> database). Always enable in production.

# Enable Query Insights on Cloud SQL for Postgres
gcloud sql instances patch prod-postgres \
    --insights-config-query-insights-enabled \
    --insights-config-record-application-tags \
    --insights-config-record-client-address \
    --insights-config-query-string-length=4500

# Enable MySQL slow query log (flag)
gcloud sql instances patch prod-mysql \
    --database-flags=slow_query_log=on,long_query_time=1

# Retrieve slow log entries
gcloud logging read \
    'resource.type="cloudsql_database" AND log_name:"mysql-slow.log"' \
    --limit=50 --format=json

Active Assist Recommendations

Recommender service (part of Active Assist) analyzes usage and emits:

Idle instance recommender - flags Cloud SQL instances with no traffic.
Overprovisioned instance recommender - suggests tier downgrades.
High availability recommender - detects missing HA on production-sized instances.
Out-of-disk recommender - warns before Cloud SQL runs out of storage.
Spanner cost optimization - right-sizing processing units.

gcloud recommender recommendations list \
    --project=my-project \
    --location=europe-west2 \
    --recommender=google.cloudsql.instance.OutOfDiskRecommender

HA & Backup Strategies

Zonal vs Regional vs Multi-Region

Zonal: survives node failure, not zone outage
Regional: survives zone outage (Cloud SQL HA)
Multi-region: survives region outage (Spanner, multi-region buckets, BigQuery multi-region)

Backup Rules of Thumb

Automated daily + on-demand before changes
Transaction log retention = max acceptable RPO
Export to Cloud Storage for long-term/cold
Quarterly restore drills - backups untested == no backups

IAM Best Practices

Grant predefined roles at the smallest scope: instance > project > folder.
Use IAM database authentication for Cloud SQL (MySQL/Postgres) and AlloyDB to avoid password sprawl.
Separate roles: roles/cloudsql.admin (provisioning) from roles/cloudsql.client (app connect) from roles/cloudsql.editor (limited ops).
Store passwords in Secret Manager; never in source or env files.
Use CMEK (Customer-Managed Encryption Keys) via Cloud KMS where compliance requires key custody.
Log access with Cloud Audit Logs (Admin Activity is free; Data Access must be opted in).

# Grant least-privilege app role
gcloud projects add-iam-policy-binding my-project \
    --member='serviceAccount:[email protected]' \
    --role='roles/cloudsql.client' \
    --condition='expression=resource.name.startsWith("projects/my-project/instances/prod-"),title=prod-only'

# Enable CMEK when creating a Spanner instance
gcloud spanner databases create orders \
    --instance=prod-spanner \
    --kms-key=projects/my-project/locations/europe-west2/keyRings/db-ring/cryptoKeys/spanner-key

Troubleshooting Quick Reference

Symptom	Likely Cause	Action
Cloud SQL read-only	Out of disk	Enable auto-increase; patch storage size
High replica lag	Long-running write or DDL on primary	Batch writes, resize replica, check binlog throughput
Spanner CPU pegged, one hot node	Hotspot on monotonic key	Check Key Visualizer, reshape row key, add hash prefix
Bigtable tail latency spike	Hot tablet or HDD cold read	Inspect Key Visualizer, add nodes, move to SSD
BigQuery 'resources exceeded'	Unbounded join / large shuffle	Filter earlier, approximate aggregations, add reservation
Firestore 'quota exceeded'	500 writes/sec on single collection, hot index	Shard documents, split composite index

Operational Pillars

Observability: metrics + logs + Query Insights + traces.
Reliability: regional HA, tested backups, PITR within RPO.
Security: IAM DB auth, CMEK, Private IP, Secret Manager, audit logs.
Cost: right-sizing via Recommender, reservations for predictable workloads.
Change mgmt: deny-maintenance windows around launches, production release channel.

GCP-PCDBE

Google Cloud Professional Cloud Database Engineer

GCP-PCDBE Practice Exam 1

GCP-PCDBE Practice Exam 2

GCP-PCDBE Practice Exam 3

GCP-PCDBE Practice Exam 4

GCP-PCDBE Practice Exam 5

GCP-PCDBE Practice Exam 6

Отключете цялото съдържание за GCP-PCDBE

Преглед (10 / 120)

Флаш карти

Налични езици

Теми на изпита

GCP-PCDBE Cheat Sheet

Cloud SQL Overview

MySQL

PostgreSQL

SQL Server

High Availability (Regional HA)

Read Replicas

Storage & Auto-Increase

Backups & Point-in-Time Recovery (PITR)

Connectivity & Security

Private IP (VPC)

Public IP + Authorized Networks

Maintenance Windows

Exam Tips

Cloud Spanner Overview

Regional Configurations

Multi-Region Configurations

TrueTime & External Consistency

Schema Design: Interleaved Tables

Avoiding Hotspots

Bad

Good

DML vs Mutations

DML (SQL)

Mutations (API)

Backup, Restore & PITR

Exam Tips

NoSQL & In-Memory Services

Firestore

Native Mode

Datastore Mode

Cloud Bigtable

Row Key Design

Storage

Memorystore

Redis (Standard)

Redis Cluster

Memcached

Decision Cheat

BigQuery for Analytics

Slots: On-Demand vs Reservations

On-Demand

Capacity (Editions)

Partitioning & Clustering

Partition types

Clustering

Materialized Views & BI Engine

Data Transfer Service, BQML & External Tables

Data Transfer Service (DTS)

BigQuery ML (BQML)

External Tables & BigLake

Cost Control

Migrating to Google Cloud

DMS (Database Migration Service)

Homogeneous

Heterogeneous

Datastream (Serverless CDC)

Use Case 1

Use Case 2

Use Case 3

One-Shot vs Continuous Migration

One-Shot (Snapshot)

Continuous (CDC)

Dual-Write & Cutover Strategies

Phase 1: Backfill

Phase 2: Dual Write

Phase 3: Dual Read, Target Canonical