Courseiva
hardMultiple ChoiceObjective-mapped

Google ACE Practice Question: Your Cloud SQL for MySQL primary instance in…

Your Cloud SQL for MySQL primary instance in `us-central1` has failed. Cloud SQL HA automatically fails over to the standby. After the failover, your application is experiencing intermittent connection errors. What is the most likely cause and solution?

⚠ Common exam trap

Google Cloud often tests the misconception that IP addresses change during HA failover, leading candidates to incorrectly choose Option A, but in Cloud SQL HA the VIP remains constant, and the real issue is stale connections in the application pool.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Application connection pools hold stale connections to the failed primary; configure pools to validate connections and reconnect after failure.

After a Cloud SQL HA failover, the standby instance becomes the new primary with the same IP address, but existing application connections that were established to the old primary are now broken. Connection pools that do not validate connections before reuse will attempt to use these stale connections, causing intermittent errors. Configuring the pool to test connections (e.g., via `SELECT 1` or JDBC `connectionTestQuery`) and automatically reconnect resolves this by discarding dead connections and establishing fresh ones to the new primary.

Answer analysis

Option-by-option breakdown

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

  • The standby instance has a different IP address; update the connection string.

    Why it's wrong here

    A Cloud SQL HA instance retains its public and private IP address across a failover, because the IP is attached to the instance resource, not to the underlying VM. The standby is configured with the same address, so a connection string that uses the instance's IP or DNS name remains valid after automatic failover. Updating the connection string would cause additional downtime and does nothing to clear the stale sockets in the pool.

  • Application connection pools hold stale connections to the failed primary; configure pools to validate connections and reconnect after failure.

    Why this is correct

    Connection pools retain TCP sessions that were established with the original primary; when failover occurs, those sessions are forcibly terminated and remain marked as 'open' in the pool. Without validation, the pool hands out dead connections and the application sees errors immediately after failover. Configure the pool to test connections before borrowing (e.g., testOnBorrow with a lightweight SELECT 1, or initialization/eviction checks) and to create new connections automatically. Using the Cloud SQL Auth Proxy also masks this by re-establishing connections to the new primary seamlessly.

  • The standby replica must be manually promoted before it can accept connections.

    Why it's wrong here

    Cloud SQL high availability uses automatic failover: when the primary becomes unreachable, the standby is promoted to primary without any manual action and immediately begins accepting connections and serving traffic. The promoted instance reassigns the same IP and endpoint, so clients do not need to change configuration or manually trigger promotion. The real issue is that the application's connection pool is still holding sockets from the old primary, which is why reconnection must be handled at the pool level.

  • The MySQL binary log is incomplete after failover; run `mysqlcheck` to repair tables.

    Why it's wrong here

    Cloud SQL HA for MySQL guarantees that every committed transaction on the primary is replicated to the standby before acknowledgment, so there is no binary-log gap to recover after failover. The mysqlcheck utility checks and repairs table corruption; it has no bearing on replication logs or connection continuity. Because the standby already contains all committed data, running mysqlcheck is unnecessary and would not restore the broken pooled sessions.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

This ACE question is part of Courseiva's 769-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This ACE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the ACE exam.