Google Cloud Professional Cloud Database Engineer - Fact Sheet¶

Quick Reference¶

Exam Code: Professional Cloud Database Engineer Duration: 120 minutes (2 hours) Questions: 50-60 questions Passing Score: ~70% (not officially published) Cost: $200 USD Validity: 2 years Difficulty: ⭐⭐⭐⭐⭐ (Expert-level database engineering certification) Prerequisites: Recommended 3+ years of industry experience, including 1+ year designing and managing database solutions on GCP

Exam Domains¶

Core Database Engineering Principles¶

Database Selection Framework¶

📖 Database Selection Guide - Comprehensive database decision guide

Key Selection Criteria: 1. Data Model - Relational, document, key-value, wide-column, time-series 2. Scalability - Vertical vs horizontal scaling requirements 3. Consistency - Strong vs eventual consistency needs 4. Latency - Read/write latency requirements 5. Availability - SLA requirements and downtime tolerance 6. Cost - Operational and licensing costs

Essential Resources: - 📖 Database Services Overview - All GCP database offerings - 📖 Choosing Database Services - Service comparison - 📖 Database Best Practices - Design guidelines - 📖 Database Migration Guide - Migration fundamentals

Cloud SQL - Managed Relational Databases¶

Cloud SQL Architecture¶

Supported Engines: - MySQL 5.6, 5.7, 8.0 - PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16 - SQL Server 2017, 2019, 2022 (Standard and Enterprise)

Core Features: - Automatic replication, backup, failover - Up to 96 vCPUs and 624 GB RAM per instance - Up to 64 TB storage with automatic storage increase - Point-in-time recovery up to 7 days (configurable to 35 days) - Read replicas for read scaling - 📖 Cloud SQL Overview - Complete architecture guide - 📖 Cloud SQL Features - Feature comparison by engine - 📖 Instance Settings - Configuration options - 📖 Quotas and Limits - Service limitations

High Availability Configuration¶

Regional HA Architecture: - Primary instance in zone A, standby in zone B (same region) - Synchronous replication to standby - Automatic failover (typically 60-120 seconds) - Regional persistent disks for data durability - Shared VIP address for automatic connection routing - 📖 High Availability Overview - HA architecture - 📖 Enabling High Availability - HA setup - 📖 Regional Persistent Disks - Storage architecture

Failover Behavior: - Automatic failover on instance or zone failure - Manual failover available for testing - Connection pooling recommended to handle failover - Approximately 60-120 seconds RTO - Zero RPO (synchronous replication) - 📖 Managing Failover - Failover operations

Backup and Recovery¶

Automated Backups: - Daily automated backups during maintenance window - Retention: 1 to 365 days (default 7 days) - On-demand backups anytime - Differential backups (only changed data) - Stored in multi-regional Cloud Storage - 📖 About Backups - Backup fundamentals - 📖 Creating Backups - Backup procedures - 📖 Restoring from Backups - Recovery procedures

Point-in-Time Recovery (PITR): - Restore to any point in time within retention period - Requires binary logging enabled - Creates new instance from backup - Does not overwrite existing instance - 📖 Point-in-Time Recovery - PITR setup and usage

Replication Architecture¶

Read Replicas: - Asynchronous replication from primary - Multiple read replicas per instance (up to 10 for MySQL, PostgreSQL) - Can be in different region (cross-region replica) - Read-only access - Can be promoted to standalone instance - 📖 Replication Overview - Replication architecture - 📖 Creating Read Replicas - Replica setup - 📖 Cross-Region Replicas - Geographic replication

External Replication: - Replicate to/from external MySQL servers - Support for on-premises to Cloud SQL - Cloud SQL to external servers - Useful for migration and hybrid scenarios - 📖 Replicating from External Server - External to Cloud SQL - 📖 Replicating to External Server - Cloud SQL to external

Connection Management¶

Connection Options: - Public IP with SSL/TLS encryption - Private IP (VPC peering, no public internet) - Cloud SQL Proxy (secure local connection) - Cloud SQL Auth Proxy (automated credential management) - 📖 Connection Overview - Connection methods - 📖 Cloud SQL Proxy - Proxy architecture - 📖 Private IP - VPC connectivity - 📖 Authorized Networks - IP allowlisting

Connection Pooling: - Reduces connection overhead - PgBouncer for PostgreSQL - ProxySQL or MySQL Router for MySQL - Managed in application layer - 📖 Connection Pooling Best Practices - Connection management

Performance Optimization¶

Instance Sizing: - Machine types: db-f1-micro to db-n1-highmem-96 - Custom machine types available - Vertical scaling with brief downtime - Consider read replicas for horizontal read scaling - 📖 Machine Types - Instance sizing

Storage Performance: - SSD persistent disks (default) - Storage automatically increases (optional) - IOPS scale with storage size - 10 GB to 64 TB per instance - 📖 Storage Options - Storage configuration

Query Optimization: - Query Insights for performance monitoring - Slow query logging - Performance Schema (MySQL) and pg_stat_statements (PostgreSQL) - Indexing strategies - 📖 Query Insights - Query performance analysis - 📖 Troubleshooting Performance - Performance tuning

Maintenance and Updates¶

Maintenance Windows: - Weekly maintenance window (configurable day and hour) - Self-service maintenance deferral (up to 3 weeks) - Automatic minor version updates - Major version upgrades manual - 📖 Maintenance - Maintenance operations - 📖 Database Versions - Version management

Cloud Spanner - Global Distributed Database¶

Cloud Spanner Architecture¶

Key Characteristics: - Horizontally scalable relational database - Global distribution with strong consistency - ACID transactions across continents - 99.999% availability SLA (multi-region) - Automatic sharding and replication - 📖 Cloud Spanner Overview - Architecture fundamentals - 📖 Spanner Concepts - Distributed architecture - 📖 TrueTime and External Consistency - Consistency model

Instance Configurations: - Regional: Single region, 99.99% SLA - Multi-region: 3+ regions, 99.999% SLA - Dual-region: 2 regions with witness in third - 📖 Instance Configurations - Available configurations - 📖 Regional vs Multi-Regional - Configuration comparison

Schema Design Best Practices¶

Primary Key Design: - Avoid monotonically increasing keys (creates hotspots) - Use UUID or hash-based keys for distribution - Reverse timestamp pattern for time-series - Composite keys for entity hierarchies - 📖 Schema Design Overview - Complete design guide - 📖 Primary Keys - Key selection strategies - 📖 Avoiding Hotspots - Performance patterns

Interleaved Tables: - Parent-child table relationships - Co-locates related data physically - Improves query performance for related data - Maximum 7 levels of interleaving - ON DELETE CASCADE support - 📖 Interleaved Tables - Interleaving design - 📖 Parent-Child Relationships - Relationship modeling

Secondary Indexes: - Global indexes vs local indexes - Null-filtered indexes to reduce storage - Storing clause to include non-key columns - Index size impacts write performance - 📖 Secondary Indexes - Index design - 📖 Index Best Practices - Optimization guidelines

Transactions and Consistency¶

Transaction Types: - Read-write transactions: Strong consistency - Read-only transactions: Lock-free, can be stale - Partitioned DML: Large-scale updates - Batch transactions: Multiple statements - 📖 Transactions - Transaction model - 📖 Read-Only Transactions - Optimized reads - 📖 Partitioned DML - Bulk operations

Staleness Bounds: - Strong reads: Most recent data, higher latency - Bounded staleness: Data within time bound - Exact staleness: Data at specific timestamp - 📖 Timestamp Bounds - Read consistency options

Scaling and Performance¶

Compute Capacity: - Node-based pricing (1000 processing units per node) - Processing units: 100 to 1000s - Autoscaling available - Regional capacity: 1000 QPS per node - 📖 Nodes and Processing Units - Capacity planning - 📖 Autoscaling - Automatic scaling

Performance Best Practices: - Batch reads and writes - Use read-only transactions when possible - Avoid cross-region transactions for latency - Partition large datasets - 📖 Query Best Practices - SQL optimization - 📖 Performance Tuning - CPU optimization

Backup and Recovery¶

Backup Features: - On-demand and scheduled backups - Point-in-time recovery within 7 days - Cross-region backup copies - Retention up to 366 days - Version retention for multi-version database - 📖 Backup and Restore - Backup overview - 📖 Point-in-Time Recovery - PITR configuration

Change Streams¶

Change Data Capture: - Track data changes in real-time - Partition-level change tracking - Query change streams with SQL - Integration with Dataflow - Use cases: Auditing, replication, analytics - 📖 Change Streams - CDC architecture - 📖 Querying Change Streams - Stream queries

AlloyDB for PostgreSQL¶

AlloyDB Architecture¶

Key Features: - PostgreSQL-compatible (100% compatible with PostgreSQL 14) - 4x faster than standard PostgreSQL for transactional workloads - Up to 100x faster for analytical queries - Separation of compute and storage - Columnar engine for analytics - 📖 AlloyDB Overview - Architecture guide - 📖 AlloyDB Features - Feature highlights - 📖 AlloyDB vs Cloud SQL - Service comparison

Cluster Architecture: - Primary instance for read-write operations - Read pool instances for read scaling (up to 20) - Automated storage scaling (no downtime) - Cross-region replication for DR - 📖 Cluster Management - Cluster operations - 📖 Read Pool - Read scaling

High Availability and Backup¶

HA Configuration: - Regional HA with synchronous replication - Automatic failover (typically 60 seconds or less) - Continuous backup to Cloud Storage - Point-in-time recovery - 📖 High Availability - HA architecture - 📖 Backup and Recovery - Backup options

Cross-Region Replication: - Asynchronous replication to secondary region - Independent read pools in secondary region - Promotion capability for DR scenarios - 📖 Cross-Region Replication - Geo-replication

Columnar Engine¶

Analytics Acceleration: - Automatic data synchronization to columnar format - No schema changes required - Transparently accelerates analytical queries - Works alongside traditional row-based storage - 📖 Columnar Engine - Analytics optimization

Migration to AlloyDB¶

Migration Paths: - Database Migration Service for online migration - Offline migration with pg_dump/pg_restore - Native PostgreSQL replication - 📖 Migrating to AlloyDB - Migration strategies - 📖 Database Migration Service - DMS integration

Firestore - NoSQL Document Database¶

Firestore Architecture¶

Database Modes: - Native Mode: Real-time synchronization, mobile/web SDKs - Datastore Mode: Server-side applications, backward compatible - Cannot switch modes after database creation - 📖 Firestore Overview - Complete guide - 📖 Choosing Native or Datastore Mode - Mode comparison

Data Model: - Documents contain fields (key-value pairs) - Documents organized in collections - Subcollections for hierarchical data - Document size limit: 1 MB - 📖 Data Model - Structure and organization - 📖 Data Types - Supported field types

Native Mode Features¶

Real-Time Capabilities: - Real-time listeners for data synchronization - Offline data persistence (mobile/web) - Automatic multi-region replication - Strong consistency within document - 📖 Real-Time Updates - Live data synchronization - 📖 Offline Data - Offline persistence

Querying: - Compound queries with multiple filters - Composite indexes for complex queries - Array membership queries - Pagination with cursors - 📖 Queries - Query syntax - 📖 Indexes - Index management - 📖 Query Limitations - Query constraints

Transactions and Batches¶

ACID Transactions: - Atomic reads and writes - Maximum 500 documents per transaction - 10 MB transaction size limit - Automatic retry on conflicts - 📖 Transactions - Transaction model - 📖 Batched Writes - Batch operations

Security Rules¶

Access Control: - Rule-based security at document level - Authentication integration (Firebase Auth, Identity Platform) - Request-time evaluation - Testing framework for rules - 📖 Security Rules - Security overview - 📖 Writing Rules - Rule syntax - 📖 Testing Rules - Rule validation

Performance and Scaling¶

Scalability: - Automatic scaling (no capacity planning) - 1 million concurrent connections per database - 10,000 writes per second per database (default) - Higher limits available on request - 📖 Quotas and Limits - Service limits - 📖 Best Practices - Performance optimization

Bigtable - Wide-Column NoSQL Database¶

Bigtable Architecture¶

Use Cases: - Time-series data (IoT, monitoring, analytics) - Financial data (transaction history, stock ticks) - IoT and sensor data - Marketing data (user behavior, clickstream) - Graph data - 📖 Bigtable Overview - Architecture and use cases - 📖 Storage Model - Data organization

Key Characteristics: - Petabyte-scale capacity - Sub-10ms latency at high percentiles - Linear scalability with nodes - HBase API compatible - No downtime for cluster resizing - 📖 Instances, Clusters, and Nodes - Infrastructure concepts

Schema Design¶

Row Key Design (Critical for Performance): - Row key determines data distribution - Avoid sequential/monotonically increasing keys - Field promotion: Move frequent queries to row key - Salting: Add prefix to distribute load - Reverse timestamp for time-series - 📖 Schema Design - Design fundamentals - 📖 Row Key Selection - Key strategies - 📖 Time-Series Schema - Time-series patterns

Column Families: - Group related columns - Keep column families small (ideally 1-3) - Different GC policies per family - Column qualifiers don't need pre-definition - 📖 Column Families - Family design - 📖 Garbage Collection - Data retention policies

Replication¶

Multi-Cluster Replication: - Eventually consistent replication - Up to 4 clusters per instance - Cross-region replication for DR - Read from any cluster - Write to any cluster (last write wins) - 📖 Replication Overview - Replication architecture - 📖 Replication Settings - Configuration options

App Profiles: - Control routing for read/write requests - Single-cluster routing: Reads from one cluster - Multi-cluster routing: Reads from nearest cluster - Automatic failover configuration - 📖 App Profiles - Traffic routing

Performance and Scaling¶

Cluster Sizing: - 1 node = 10,000 QPS reads, 10,000 QPS writes (approximate) - SSD nodes: 8 TB per node, best latency - HDD nodes: 16 TB per node, lower cost - Autoscaling based on CPU or storage - 📖 Performance Guide - Sizing and tuning - 📖 Autoscaling - Automatic scaling

Performance Best Practices: - Pre-split tables for bulk loading - Use bulk reads (batch API) - Connection pooling and reuse - Monitor key metrics: CPU, storage, latency - Avoid single row operations when possible - 📖 Bulk Loading - Import optimization - 📖 Optimizing Performance - Tuning guide

Backup and Recovery¶

Backup Features: - Table-level backups - Restore to same or different cluster - Cross-instance backup copying - Incremental backups - Retention policies - 📖 Backups - Backup overview - 📖 Disaster Recovery - DR strategies

Memorystore - Managed In-Memory Databases¶

Memorystore for Redis¶

Redis Architecture: - Fully managed Redis instances - Sub-millisecond latency - Versions: Redis 4.0, 5.0, 6.x, 7.0 - Up to 300 GB per instance - 📖 Memorystore for Redis Overview - Architecture guide - 📖 Redis Features - Configuration options

Service Tiers: - Basic Tier: Single zone, no replication, lower cost - Standard Tier: HA with cross-zone replication, automatic failover - 📖 Service Tiers - Tier comparison - 📖 High Availability - HA configuration

Use Cases: - Application caching - Session storage - Real-time analytics - Pub/Sub messaging - Leaderboards and counters - 📖 Redis Use Cases - Common patterns

Maintenance and Scaling: - Automatic maintenance with minimal disruption - Vertical scaling (instance size) - No horizontal scaling (use sharding at app level) - In-place upgrades for versions - 📖 Scaling Instances - Capacity management - 📖 Maintenance - Maintenance windows

Memorystore for Memcached¶

Memcached Architecture: - Fully managed Memcached - Protocol-compatible with OSS Memcached - Shared-core to 32 vCPUs per node - 1 GB to 256 GB per node - Up to 20 nodes per instance - 📖 Memorystore for Memcached Overview - Architecture guide

High Availability: - Multi-node configuration - Regional distribution across zones - Automatic node replacement - No persistence (in-memory only) - 📖 Memcached Architecture - Instance design

Database Migration Service (DMS)¶

Migration Service Overview¶

Supported Sources: - MySQL (on-premises, Cloud SQL, RDS, other clouds) - PostgreSQL (on-premises, Cloud SQL, RDS, other clouds) - Oracle Database - SQL Server - AlloyDB for PostgreSQL - 📖 Database Migration Service Overview - Service introduction - 📖 Supported Databases - Source and target matrix

Migration Types: - Continuous migration (minimal downtime) - One-time migration (offline) - 📖 Migration Concepts - Migration types

MySQL Migration¶

Migration Architecture: - Uses native MySQL replication - Source as primary, destination as replica - Continuous replication until cutover - Minimal downtime migration - 📖 MySQL Migration Guide - Complete MySQL guide - 📖 MySQL Migration Prerequisites - Source preparation - 📖 Creating MySQL Migrations - Migration setup

Connectivity Methods: - IP allowlisting - Reverse SSH tunnel - VPC peering - 📖 MySQL Connectivity - Connection options

PostgreSQL Migration¶

Migration Features: - Native PostgreSQL logical replication - Schema and data migration - Continuous migration with low downtime - Pre-migration validation - 📖 PostgreSQL Migration Guide - Complete PostgreSQL guide - 📖 PostgreSQL Prerequisites - Source configuration

AlloyDB Migration: - Direct migration from PostgreSQL to AlloyDB - Handles version compatibility - Optimizations for AlloyDB features - 📖 Migrating to AlloyDB - AlloyDB migration

Oracle Migration¶

Migration Strategies: - Heterogeneous migration (Oracle to PostgreSQL/AlloyDB) - Schema conversion tools - Data type mapping - 📖 Oracle Migration - Oracle to PostgreSQL - 📖 Schema Conversion - Schema translation

Migration Best Practices¶

Planning and Testing: - Assess source database compatibility - Test migration with subset of data - Plan cutover window - Validate data integrity post-migration - Performance testing on target - 📖 Migration Best Practices - Migration guidelines - 📖 MySQL to Cloud SQL - MySQL migration patterns

Database Security and Compliance¶

Identity and Access Management¶

Database IAM: - Predefined roles: Cloud SQL Admin, Client, Viewer - Custom roles for fine-grained access - Service account authentication - IAM database authentication (Cloud SQL) - 📖 IAM for Cloud SQL - IAM integration - 📖 Cloud SQL IAM Roles - Role definitions - 📖 Database Authentication - Auth methods

Spanner IAM: - Instance-level and database-level permissions - Fine-grained access control - IAM conditions support - 📖 Spanner IAM - Access control

Encryption¶

Encryption at Rest: - Default encryption with Google-managed keys - Customer-Managed Encryption Keys (CMEK) with Cloud KMS - Database-level CMEK support - Backup encryption - 📖 Cloud SQL Encryption - Encryption options - 📖 CMEK for Cloud SQL - Customer keys - 📖 Spanner Encryption - Spanner CMEK

Encryption in Transit: - SSL/TLS for client connections - Certificate-based authentication - Private connectivity options - 📖 SSL Connections - SSL setup - 📖 Client Certificates - Certificate authentication

Network Security¶

VPC and Private IP: - Private IP for Cloud SQL (no public exposure) - VPC peering for private connectivity - Private Service Connect - VPC Service Controls for data perimeter - 📖 Private IP - Private connectivity - 📖 VPC Service Controls - Perimeter security

Authorized Networks: - IP allowlisting for public IP instances - Per-instance configuration - CIDR range support - 📖 Authorized Networks - IP access control

Audit Logging¶

Cloud Audit Logs: - Admin Activity logs (always enabled) - Data Access logs (configurable) - System Event logs - Policy Denied logs - 📖 Cloud SQL Audit Logs - Audit configuration - 📖 Spanner Audit Logs - Spanner auditing - 📖 Viewing Audit Logs - Log analysis

Database Audit Logging: - MySQL Enterprise Audit Plugin - PostgreSQL pgAudit extension - Query-level logging - 📖 MySQL Audit Plugin - MySQL auditing - 📖 PostgreSQL pgAudit - PostgreSQL auditing

Compliance¶

Compliance Certifications: - ISO 27001, 27017, 27018 - SOC ⅔ - PCI-DSS - HIPAA - FedRAMP - 📖 Compliance Resource Center - All certifications - 📖 Data Residency - Location controls

Monitoring and Operations¶

Cloud Monitoring¶

Database Metrics: - CPU, memory, disk utilization - Network throughput - Connection count and errors - Replication lag - Query performance metrics - 📖 Cloud SQL Monitoring - Metrics and alerts - 📖 Spanner Monitoring - Spanner metrics - 📖 Bigtable Monitoring - Bigtable metrics

Alerting: - Predefined alert policies - Custom alert policies - Notification channels (email, SMS, PagerDuty, etc.) - Alert conditions and thresholds - 📖 Creating Alerts - Alert configuration

Cloud Logging¶

Database Logs: - Error logs - Slow query logs - General query logs - Audit logs - Export to BigQuery for analysis - 📖 Cloud SQL Logs - Log types and access - 📖 Log Exports - Log sinks

Query Insights¶

Performance Analysis: - Top queries by execution time - Query frequency and patterns - Lock wait times - Resource consumption per query - Available for Cloud SQL MySQL and PostgreSQL - 📖 Query Insights Overview - Performance monitoring - 📖 Analyzing Query Performance - Troubleshooting

Spanner Monitoring¶

Key Metrics: - CPU utilization (< 65% recommended for headroom) - Storage utilization - Query statistics - Lock statistics - 📖 Monitoring CPU - CPU optimization - 📖 Query Statistics - Query analysis

Database Design Patterns¶

Relational Database Patterns¶

Normalization vs Denormalization: - Normalize for OLTP (transaction processing) - Denormalize for OLAP (analytical queries) - Consider read/write patterns - Balance storage vs query performance

Partitioning Strategies: - Horizontal partitioning (sharding) - Vertical partitioning (column splitting) - Range-based partitioning - Hash-based partitioning

NoSQL Design Patterns¶

Document Database Patterns (Firestore): - Embed vs reference - Denormalize for read performance - Collection group queries - Hierarchical data with subcollections

Wide-Column Patterns (Bigtable): - Row key as index - Column families for data grouping - Time-series with reverse timestamps - Avoid hotspots with key distribution

Caching Patterns¶

Cache-Aside: - Application checks cache first - On miss, load from database and populate cache - Suitable for read-heavy workloads

Write-Through: - Write to cache and database simultaneously - Ensures cache consistency - Higher write latency

Write-Behind: - Write to cache immediately - Asynchronous write to database - Better write performance, risk of data loss

Disaster Recovery Strategies¶

Backup Strategies¶

Backup Types: - Full backups - Incremental backups - Differential backups - Point-in-time recovery

Backup Retention: - Compliance requirements - Cost vs recovery needs - Lifecycle policies for long-term retention

High Availability Architecture¶

Multi-Zone Deployment: - Cloud SQL HA configuration - Automatic failover - Regional persistent disks - RTO: 60-120 seconds - RPO: Zero (synchronous replication)

Multi-Region Deployment: - Cloud Spanner multi-region - Cross-region read replicas - AlloyDB cross-region replication - Lower RPO/RTO for global applications

Disaster Recovery Testing¶

DR Drills: - Regular failover testing - Backup restoration validation - RTO/RPO measurement - Documentation and runbooks - Post-mortem analysis

Performance Optimization¶

Query Optimization¶

Indexing Strategies: - Index frequently queried columns - Composite indexes for multiple columns - Covering indexes to avoid table lookups - Avoid over-indexing (impacts writes)

Query Analysis: - Explain plans for query optimization - Identify slow queries - Optimize JOIN operations - Reduce data scanned

Connection Management¶

Connection Pooling: - Reduce connection overhead - Reuse database connections - Configure appropriate pool size - Handle connection failures gracefully

Connection Limits: - Cloud SQL: Based on machine type - Spanner: 10,000 sessions default (configurable) - Monitor active connections - Use Cloud SQL Proxy for connection management

Storage Optimization¶

Data Archival: - Move cold data to cheaper storage tiers - Cloud Storage for historical data - BigQuery for analytics on archived data - Lifecycle policies for automation

Compression: - Enable compression for backups - Compressed table formats - Reduce storage costs and improve I/O

Exam Scenarios and Solutions¶

Scenario 1: High-Volume Transactional System¶

Requirements: Global e-commerce, strong consistency, 100k+ TPS, 99.999% availability

Solution: - Cloud Spanner multi-region configuration - Schema design avoiding hotspots - Read-only transactions for queries - Connection pooling at application layer - Autoscaling for traffic bursts

Key Decision: Spanner for global scale with strong consistency, despite higher cost

Scenario 2: Time-Series IoT Data¶

Requirements: Billions of events per day, sub-10ms read latency, retention 7 years

Solution: - Bigtable for writes and recent data queries - Row key with reverse timestamp - HDD nodes for cost optimization - Backup to Cloud Storage for archival - Dataflow for bulk loading

Key Decision: Bigtable for massive scale and low latency; archive old data to reduce costs

Scenario 3: MySQL Migration with Minimal Downtime¶

Requirements: 2 TB MySQL database, < 1 hour downtime, validate before cutover

Solution: - Database Migration Service for continuous replication - Cloud SQL for PostgreSQL as target (or MySQL) - VPC peering for private connectivity - Parallel testing on replica - Planned cutover during low-traffic period

Key Decision: DMS for minimal downtime; test thoroughly before cutover

Scenario 4: Multi-Region Read Scaling¶

Requirements: Global user base, read-heavy workload, < 100ms latency worldwide

Solution: - Cloud SQL with cross-region read replicas - OR Cloud Spanner multi-region for writes - Cloud CDN for cacheable content - Regional routing with Load Balancer - Connection pooling per region

Key Decision: Cloud SQL read replicas if writes are regional; Spanner if global writes needed

Scenario 5: Real-Time Analytics on Operational Data¶

Requirements: PostgreSQL transactional database, real-time analytics without impacting OLTP

Solution: - AlloyDB for PostgreSQL - Columnar engine for analytical queries - Read pool for analytics separation - OR: Cloud SQL with read replicas, export to BigQuery - Dataflow for streaming CDC to BigQuery

Key Decision: AlloyDB columnar engine for integrated HTAP; BigQuery for separate analytics

Scenario 6: Compliance and Data Residency¶

Requirements: HIPAA compliance, data must stay in us-central1, audit all access

Solution: - Cloud SQL or Spanner in us-central1 - CMEK with Cloud KMS - Private IP only (no public exposure) - VPC Service Controls for perimeter - Cloud Audit Logs for all data access - IAM with least privilege

Key Decision: Regional instance configuration with encryption, auditing, and network isolation

Exam Tips and Strategy¶

Keywords to Watch¶

Question Patterns: - "Global transactions" → Cloud Spanner - "Sub-10ms latency" → Bigtable or Memorystore - "PostgreSQL-compatible" → Cloud SQL PostgreSQL, AlloyDB - "Real-time synchronization" → Firestore Native mode - "Time-series data" → Bigtable - "Strong consistency" → Cloud Spanner, Cloud SQL HA - "Minimal downtime migration" → Database Migration Service - "Analytical workload" → AlloyDB columnar engine, BigQuery - "Caching" → Memorystore - "Multi-region HA" → Cloud Spanner multi-region - "99.999% SLA" → Cloud Spanner multi-region - "Cost-effective" → Cloud SQL, Bigtable with HDD, proper sizing

Service Selection Decision Trees¶

Database Selection:

Relational database needed?
├─ YES → Global scale with multi-region writes?
│  ├─ YES → Cloud Spanner
│  └─ NO → PostgreSQL-based?
│     ├─ YES → High performance analytics?
│     │  ├─ YES → AlloyDB
│     │  └─ NO → Cloud SQL PostgreSQL
│     └─ NO → MySQL or SQL Server?
│        └─ Cloud SQL (MySQL/SQL Server)
└─ NO → Data access pattern?
   ├─ Wide-column/time-series → Bigtable
   ├─ Document/real-time → Firestore
   ├─ In-memory/caching → Memorystore
   └─ Analytics → BigQuery

Migration Decision:

Migration downtime tolerance?
├─ Minimal downtime (<1 hour) → Database Migration Service
├─ Several hours acceptable → Offline migration
│  └─ mysqldump/pg_dump + restore
└─ Testing/validation needed → DMS with extended replication

Time Management¶

• 120 minutes ÷ 50 questions = 2.4 minutes per question
• First pass: Answer straightforward questions (60 minutes)
• Second pass: Tackle scenario-based questions (45 minutes)
• Final pass: Review flagged questions (15 minutes)

Common Traps¶

• ❌ Choosing Cloud SQL when Spanner is needed for global scale
• ❌ Choosing Spanner when Cloud SQL would suffice (cost)
• ❌ Poor Bigtable row key design (sequential keys = hotspots)
• ❌ Not considering read replica lag for consistency requirements
• ❌ Ignoring CMEK requirements for compliance
• ❌ Forgetting to enable binary logs for PITR
• ❌ Not using Database Migration Service when available
• ❌ Overlooking AlloyDB for PostgreSQL analytical workloads
• ❌ Wrong Firestore mode selection (cannot change later)
• ❌ Underestimating connection limits and not using pooling

Study Checklist¶

Knowledge Areas: - [ ] Understand when to use each database service - [ ] Know Cloud SQL HA architecture and failover process - [ ] Understand Cloud Spanner schema design and hotspot avoidance - [ ] Know Bigtable row key design patterns for time-series - [ ] Understand AlloyDB columnar engine benefits - [ ] Know Firestore native vs Datastore mode differences - [ ] Understand Database Migration Service capabilities - [ ] Know backup and PITR configurations - [ ] Understand replication architectures (sync vs async) - [ ] Know encryption options (CMEK, SSL/TLS) - [ ] Understand IAM for database access - [ ] Know monitoring and alerting best practices

Hands-On Skills: - [ ] Deploy Cloud SQL with HA and read replicas - [ ] Create Cloud Spanner instance with interleaved tables - [ ] Design and implement Bigtable schema for time-series - [ ] Set up Database Migration Service migration - [ ] Configure CMEK for databases - [ ] Implement backup and recovery procedures - [ ] Set up monitoring and alerts - [ ] Use Query Insights for performance analysis - [ ] Configure private IP and VPC connectivity - [ ] Test failover scenarios

Preparation: - [ ] Build real database solutions on GCP - [ ] Complete official practice exam (80%+ score target) - [ ] Review case studies in exam guide - [ ] Read all linked documentation sections - [ ] Practice with gcloud, cbt, and gsutil CLI tools - [ ] Understand cost implications of design decisions - [ ] Test migration scenarios end-to-end - [ ] Practice DR and failover procedures

Pro Tip: The Professional Cloud Database Engineer exam heavily tests your ability to choose the right database service for specific requirements and design schemas that avoid common pitfalls. Focus on understanding trade-offs between services, cost implications, and operational considerations. Practice with real migrations and performance tuning scenarios!

Documentation Count: This fact sheet contains 200+ embedded documentation links to official Google Cloud documentation, covering all exam domains comprehensively.

Good luck! This certification demonstrates expert-level database engineering skills on Google Cloud Platform.