Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Cloud SQL (PostgreSQL)

  Why it's wrong here

  Cloud SQL for PostgreSQL is a managed PostgreSQL service that handles backups, replication, and maintenance, but it is architected for more moderate workloads. Its maximum storage capacity (64 TB per instance) technically fits 50 TB, but its compute and I/O limits cannot match AlloyDB's performance profile, especially for high-throughput or analytical queries. Moreover, Cloud SQL does not provide the same granular horizontal read scaling or the columnar acceleration that AlloyDB offers, so for a 50 TB, high-performance requirement, Cloud SQL is a possible but less optimal choice — AlloyDB is built precisely to exceed those limits.

• ✓

  AlloyDB for PostgreSQL

  Why this is correct

  AlloyDB for PostgreSQL is the correct choice because it is a fully managed, PostgreSQL-compatible database engineered for demanding enterprise workloads. It delivers up to 4× faster online transaction processing (OLTP) and up to 100× faster analytical queries than standard PostgreSQL, while providing 99.99% availability and horizontal read scaling via built-in columnar engine and read pools. Because it is wire-compatible with PostgreSQL, existing application code, drivers, and tools work unchanged — making it the only option that combines full PostgreSQL compatibility with the scale and performance needed for 50 TB of data.

• ✗

  Cloud Spanner

  Why it's wrong here

  Cloud Spanner is a globally distributed, horizontally scalable relational database, but it is not wire-compatible with PostgreSQL. Its SQL dialect, transaction semantics (especially around interleaved tables and commit timestamps), and client libraries differ substantially, so an existing PostgreSQL application would require rewriting queries and schema definitions. While Spanner can easily handle 50 TB and high throughput, the requirement here is to keep an existing PostgreSQL application running without code changes — therefore Spanner is technically powerful but architecturally wrong for this migration.

• ✗

  Bare metal PostgreSQL on Compute Engine

  Why it's wrong here

  Running PostgreSQL on Compute Engine means provisioning and operating your own VMs: you own the OS, database binaries, storage, replication, and all operational tasks. For a 50 TB high-performance workload, you would need to design a custom HA architecture (e.g., Patroni, streaming replication), manage point-in-time recovery, automate failover, and constantly apply security patches — all while handling unpredictable scaling and backup windows. This is the opposite of a fully managed service and introduces significant administrative overhead, making it a poor fit for a team that wants to focus on applications rather than infrastructure.

Go deeper

Related to this question