GCP Database Engineer common mistakes
GCP Database Engineer · Understand the traps and how to avoid them.
Designing a Cloud SQL instance for high availability by adding a read replica and calling it done, without enabling regional (multi-zone) availability on the primary, then failing questions about automatic failover of the write endpoint.
Candidates conflate read scaling with write-path HA. Read replicas do not fail over automatically for writes; only regional HA with a standby and a single stable IP provides automatic failover. The two features look similar on the console and both say 'replica', so the distinction blurs under time pressure.
What to do instead
Memorize the failure model: Cloud SQL regional HA keeps a synchronous standby in a second zone and fails over the primary endpoint automatically; read replicas are asynchronous, serve reads, and can be promoted manually. When a scenario says 'minimize RTO for writes with no application changes', the answer is regional HA, not replicas.
Choosing a globally consistent, strongly consistent database when the workload is a simple high-throughput key-value or session store, or the reverse-choosing Firestore or Bigtable for workloads that need multi-row ACID transactions and relational joins.
Candidates pattern-match on buzzwords ('global', 'serverless', 'NoSQL') without mapping the access pattern, consistency requirement, and transaction shape to the product. Spanner, Firestore, Bigtable, and Cloud SQL have very different guarantees, and the exam scenarios hide the deciding constraint in a clause.
What to do instead
Build a decision table keyed on four questions: (1) Do you need multi-object ACID transactions? (2) Do you need relational joins and SQL? (3) What is the access pattern-point lookups by row key, document queries, or analytic scans? (4) What consistency and latency do you need globally? Spanner for globally consistent relational; Cloud SQL for regional relational; Firestore for document/mobile with strong per-document consistency; Bigtable for wide-column high-throughput single-key access with no cross-row transactions.
Treating Bigtable and Spanner schema design like relational design-using monotonically increasing keys, randomizing keys to spread load, or expecting secondary-index-like query flexibility-and then answering performance questions as if any column could be filtered efficiently.
Candidates carry over RDBMS intuition. In Bigtable, row-key design determines hotspotting and query patterns, and there are no secondary indexes; in Spanner, interleaving and primary key choice drive locality and hotspotting. Without hands-on schema design, the performance implications are invisible.
What to do instead
Learn the key-design rules explicitly: Bigtable row keys should be designed for the query patterns and to avoid sequential hotspotting (e.g., field-promoted or hashed prefixes), and scans are by key range only. Spanner primary keys should avoid monotonically increasing values unless using bit-reversed sequences, and interleaved tables should be used for parent-child locality. Practice mapping a query list to a key design.
Configuring Cloud SQL or AlloyDB backups and assuming point-in-time recovery is available, or assuming a backup restores in place rather than creating a new instance, and missing the RPO/RTO implications in scenario questions.
Backup, PITR, and restore semantics differ across products and are easy to skim. Candidates assume 'backups are on' means any point in time is recoverable and that recovery is fast and in-place.
What to do instead
Know the specifics: Cloud SQL automated backups plus binary logging (or WAL) enable PITR within a retention window; restores create a new instance and require repointing the application; AlloyDB and Spanner have their own backup/PITR mechanisms with different retention defaults. For each product, state the RPO (backup frequency vs continuous log), RTO (restore time, new instance, DNS/connection change), and where the restore lands.
Designing a multi-database architecture where each database is individually highly available but the end-to-end solution has a single point of failure-for example, an application tier that writes to Cloud SQL and asynchronously replicates to BigQuery with no handling of replication lag, duplicate delivery, or partial failure.
Candidates optimize each component in isolation and never draw the data-flow diagram with failure points. Cross-database consistency, idempotency, and ordering are the hard part of heterogeneous solutions, and they are rarely practiced.
What to do instead
For any multi-database scenario, explicitly diagram the data flow and annotate: source of truth, replication mechanism (CDC via Datastream, export/load, application dual-write), lag tolerance, idempotency key, and reconciliation job. Prefer a single system of record with derived copies, and design consumers to tolerate at-least-once delivery and stale reads.
Using federated queries or external tables as a production serving path-joining BigQuery to Cloud SQL or querying external files on every request-instead of materializing data into the analytical store.
Federated query is convenient for ad hoc analysis and demos, so candidates propose it for production dashboards and cross-system joins. They miss the latency, quota, and load implications on the source operational database.
What to do instead
Treat federation and external tables as exploration tools. For production, use Datastream or batch extraction to land data in BigQuery (or Bigtable for serving), then query native tables. Reserve federated queries for low-frequency lookups and state the trade-off when a scenario explicitly allows it.
Planning a migration around a single cutover with downtime and a one-shot dump/restore, rather than a continuous replication phase with a short, validated cutover-and ignoring schema and data type conversion issues until the cutover window.
Candidates underestimate migration risk and treat it as a copy operation. Real migrations need a baseline load, ongoing change capture, validation, and a reversible cutover, and heterogeneous migrations (e.g., Oracle or SQL Server to PostgreSQL) surface type, sequence, and stored-procedure incompatibilities late.
What to do instead
Use the standard pattern: assess and profile, convert schema with a tool (e.g., Database Migration Service or the conversion workspace), do a baseline load, replicate ongoing changes with CDC, validate row counts and checksums continuously, then cut over in a short window with a tested rollback. Budget explicit time for heterogeneous schema and code conversion and for application connection-string changes.
Assuming Database Migration Service handles every source and every heterogeneity automatically-including cross-engine conversions, triggers, stored procedures, and large objects-without a validation and remediation phase.
Marketing-level familiarity with DMS leads candidates to treat it as a black box. The exam tests whether you know what is automated versus what requires manual conversion and testing.
What to do instead
State the boundary: DMS automates connectivity, baseline load, and CDC for supported source/target pairs, but heterogeneous schema conversion and procedural code need separate tooling and manual review. Always include a validation phase (data checksums, application regression tests, performance comparison) and a rollback plan in the answer.
Sizing and deploying databases without connecting instance tier, storage type, disk throughput, and connection management to the workload-for example, ignoring connection pooling limits, max_connections, or the fact that Cloud SQL disk size affects IOPS and throughput.
Candidates focus on the database engine and forget the infrastructure coupling. Cloud SQL performance scales with disk size and type; connection exhaustion is a common production failure; and serverless clients can overwhelm a database without a pooler.
What to do instead
In every deployment answer, name the sizing levers: machine tier (vCPU/memory), disk type and size (which drives IOPS/throughput on Cloud SQL), connection pooling (e.g., Cloud SQL Auth Proxy plus a pooler, or AlloyDB/Cloud SQL connectors), and read replicas for read scaling. Match the lever to the bottleneck the scenario describes.
Ignoring network and security architecture in deployment designs-placing databases on public IPs, forgetting private IP and VPC peering/Private Service Connect, or omitting IAM database authentication and encryption key management.
Candidates treat security as a checkbox and default to the simplest connectivity that works in a lab. Exam scenarios embed requirements like 'no public internet exposure' or 'customer-managed encryption keys' that change the design.
What to do instead
Default to private connectivity (private IP, Private Service Connect, or VPC peering), IAM-based authentication where supported, and CMEK when the scenario requires key control. Explicitly state how clients reach the database (Auth Proxy or connector, private DNS), and verify the design satisfies the stated network and compliance constraints before finalizing.