Google ACE Planning and Configuring a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use a smaller machine type and add a read replica

  Why it's wrong here

  Downsizing the primary instance's machine type would lower its compute cost, but adding a read replica introduces a second, full Cloud SQL instance billed as a standalone instance — compute, storage, and network egress all incur charges. Each read replica also requires a long-lived instance that replicates the primary, so it cannot simply replace the original instance's cost. For a workload that is idle outside business hours, the replica runs continuously regardless of primary activity, making this combination unambiguously more expensive than a single correctly-sized instance.

• ✓

  Change the activation policy to ON_DEMAND

  Why this is correct

  Setting the activation policy to ON_DEMAND tells Cloud SQL to shut down the instance when it has had no connections for a configurable idle period (default 15 minutes) and to start it automatically when a new connection arrives. While stopped, you are billed only for persistent storage and static IP allocation, not for vCPUs or memory, which is the dominant cost for intermittent workloads. This policy is ideal for development and test environments, but it is disabled for high-availability configurations because failover requires the instance to be always on. It also introduces a cold-start delay on every reconnect.

• ✗

  Migrate to Cloud Spanner for better cost efficiency

  Why it's wrong here

  Migrating from Cloud SQL for PostgreSQL to Cloud Spanner is not a cost-saving measure for a small workload; Spanner is a horizontally scalable, globally replicated database that bills per node or processing unit plus storage, and even a single regional node carries a substantial monthly price tag. You would also need to redesign schemas, transactions, and query dialects because Cloud Spanner does not natively support PostgreSQL syntax unless using the PostgreSQL-compatible dialect, which still has different operational and pricing characteristics. For a simple PostgreSQL database with modest usage, Cloud SQL's per-instance compute pricing is far more economical than Cloud Spanner's minimum commitment.

• ✗

  Enable deletion protection and manually stop the instance after hours, start it before hours

  Why it's wrong here

  Enabling deletion protection on a Cloud SQL instance only prevents an accidental DELETE call from removing the instance; it has no effect on billing and does not schedule any stop or start behavior. Manually stopping the instance after hours and starting it before hours is valid, but it requires an external automation trigger such as Cloud Scheduler, Cloud Functions, or a cron job, and if that automation fails or someone forgets, the instance stays up and incurs compute charges. ON_DEMAND avoids that operational dependence by letting Cloud SQL handle the full lifecycle, and deletion protection can still be added alongside it as a safety net.

Go deeper

Related to this question