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.

• ✓

  Enable regional persistent disk and configure a standby instance in a different zone.

  Why this is correct

  Cloud SQL's high availability configuration uses a regional persistent disk, which synchronously replicates data between zones, combined with a standby instance in a different zone. In the event of a zonal outage, Cloud SQL automatically detects the failure and promotes the standby, typically within tens of seconds. Because replication is synchronous, the RPO is effectively zero, ensuring no committed transactions are lost. This is the correct choice for an availability requirement within a single region.

• ✗

  Use point-in-time recovery.

  Why it's wrong here

  Point-in-time recovery (PITR) relies on WAL archiving and allows you to restore the database to any second within the configured retention window. However, this is a manual restoration process that creates a new instance from a backup plus archived WAL logs — it does not provide automatic failover. If the zone is down, the backup and archived logs may also be unreachable unless they are stored redundantly, and the RTO is typically minutes to hours. PITR is a data-recovery mechanism, not an availability feature.

• ✗

  Configure connection pooling.

  Why it's wrong here

  Connection pooling, whether via pgBouncer or Cloud SQL's built-in pooler, reuses database connections to reduce the CPU and latency overhead of establishing new sessions. While pooling improves throughput and reduces connection churn, it has no effect on the underlying instance's resilience — if the primary instance becomes unavailable, the pool's endpoints also fail. Poolers don't track the health of the instance or trigger failover; they merely multiplex connections to the same backend. Thus, connection pooling addresses performance, not zone-level availability.

• ✗

  Set up a cross-region read replica.

  Why it's wrong here

  A cross-region read replica is an asynchronous read-only copy of the primary instance in a different Google Cloud region. It is designed for geographic disaster recovery and offloading read traffic, but it does not serve as an automatic failover target for a zonal outage in the primary region. Promoting a read replica to primary requires manual intervention, and because replication is asynchronous, committed transactions that haven't yet been replicated could be lost. For a single-region availability requirement, a same-region HA standby with regional persistent disk is the appropriate mechanism, not a cross-region replica.

Go deeper

Related to this question