Cloud Digital Leader Why Cloud Technology Can Transform Business 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.

• ✗

  Autoscaling is not triggered because CPU utilization is below threshold

  Why it's wrong here

  Latency can remain high even when CPU is under its autoscaling threshold because the bottleneck is a downstream dependency, not compute capacity. In this architecture, the compute instances are not saturated; they are instead blocked waiting for database connections that have been exhausted. Consequently, the untriggered autoscaler is a red herring—CPU-based scaling would not have solved Cloud SQL connection exhaustion.

• ✗

  Insufficient Cloud SQL storage capacity

  Why it's wrong here

  Cloud SQL storage capacity is separate from its connection quota; a full disk triggers read-only errors or 'database is full' messages, not higher query latency caused by connection exhaustion. Storage is also auto-increased when the growth setting is enabled, so running out of space during a flash sale is unlikely and would manifest as operational failures rather than a gradual latency degradation. This misdiagnosis distracts from the true cause: the maximum allowed concurrent connections has been reached.

• ✗

  SSL/TLS encryption is causing overhead

  Why it's wrong here

  Modern CPUs include AES-NI instructions, making TLS encryption and decryption extremely cheap relative to the other work each query performs, and Cloud SQL connections use SSL handshakes that are amortized over the connection's lifetime. The latency spike during the flash sale is driven by connection contention—request queuing after the connection limit is hit—not by cryptographic overhead. SSL would add a few milliseconds at most, not the sustained slowdown attributable to a hard database connection ceiling.

• ✓

  Cloud SQL connection limit is reached

  Why this is correct

  Cloud SQL enforces a maximum number of concurrent client connections based on the selected machine tier (for example, 4,000 for many tiers). When the app autoscales, every new instance typically opens its own connection pool, and the total connections quickly surpass the database's limit; then new attempts queue or are rejected, directly raising query latency. This matches the flash-sale pattern, where the number of app instances spikes but the database tier stays fixed, so connection exhaustion is the expected root cause.

Go deeper

Related to this question