Scenario practice questions

Your Cloud SQL for MySQL instance is experiencing intermittent performance degradation. You suspect that the issue is due to a sudden spike in connections from a specific application. Which metric and monitoring approach would best help you correlate the connection spike with performance degradation?

Trap 1: Monitor 'cloudsql.googleapis.com/network/received_bytes_count' and…

Network bytes received is a throughput metric, not a direct indicator of connection spikes.

Trap 2: Monitor 'cloudsql.googleapis.com/database/mysql/replication/seconds_…

This metric tracks replication lag, which is unrelated to connection spikes causing performance issues.

Trap 3: Monitor 'cloudsql.googleapis.com/instance/uptime' and check for…

Uptime indicates availability, not connection spikes or performance.

A
Monitor 'cloudsql.googleapis.com/network/received_bytes_count' and compare with connection count.
Why wrong: Network bytes received is a throughput metric, not a direct indicator of connection spikes.
B
Monitor 'cloudsql.googleapis.com/database/mysql/replication/seconds_behind_master' and compare with query latency.
Why wrong: This metric tracks replication lag, which is unrelated to connection spikes causing performance issues.
C
Monitor 'cloudsql.googleapis.com/instance/uptime' and check for instance restarts during degradation.
Why wrong: Uptime indicates availability, not connection spikes or performance.
D
Monitor 'cloudsql.googleapis.com/database/mysql/threads/threads_connected' and correlate with CPU utilization and query latency.
Threads connected directly indicates active connections, and correlating with CPU and latency helps identify the impact.

Question 2hardmultiple choice

A team uses Cloud Monitoring SLO monitoring with a request-based SLI. The SLO is defined as the proportion of requests returning HTTP 200 with latency under 500ms over a 30-day window. They notice that the SLO is being violated due to a slow increase in latency from a specific backend. Which alerting strategy will best detect this gradual degradation early?

Trap 1: Alert on any single request exceeding 500ms

Too noisy; individual outliers are not indicative of SLO violation.

Trap 2: Fast burn alert with burn rate 14 and 1-hour window

Fast burn alerts are for rapid consumption; a slow increase might not trigger them.

Trap 3: Alert when average latency exceeds 500ms for 1 minute

This might detect degradation but not tied to error budget consumption rate.

A
Alert on any single request exceeding 500ms
Why wrong: Too noisy; individual outliers are not indicative of SLO violation.
B
Fast burn alert with burn rate 14 and 1-hour window
Why wrong: Fast burn alerts are for rapid consumption; a slow increase might not trigger them.
C
Slow burn alert with burn rate 5 and 6-hour window
Slow burn alerts are designed to detect gradual budget consumption.
D
Alert when average latency exceeds 500ms for 1 minute
Why wrong: This might detect degradation but not tied to error budget consumption rate.

Question 3mediummultiple choice

Refer to the exhibit. The query joins two large tables and aggregates results. Which optimization would most likely reduce the high shuffle bytes in Stage 3?

Exhibit

Refer to the exhibit. In a BigQuery query plan, you see the following stage statistics:

Stage 2: WRITE, 1.2 GB shuffled, 45 seconds
Stage 3: SHUFFLE, 2.5 GB shuffled, 80 seconds
Stage 4: AGGREGATE, 0.5 GB input, 15 seconds

Trap 1: Ensure both tables are clustered on the join key.

Clustering can reduce shuffle but not as much as filtering.

Trap 2: Use a broadcast join hint to force one table to be broadcast.

Broadcast joins only help if one table is small.

Trap 3: Add an ORDER BY clause to sort the data before aggregation.

ORDER BY would increase shuffle.

A
Add a WHERE clause to filter rows before the join.
Filtering early reduces the data that needs to be shuffled.
B
Ensure both tables are clustered on the join key.
Why wrong: Clustering can reduce shuffle but not as much as filtering.
C
Use a broadcast join hint to force one table to be broadcast.
Why wrong: Broadcast joins only help if one table is small.
D
Add an ORDER BY clause to sort the data before aggregation.
Why wrong: ORDER BY would increase shuffle.

Question 4hardmultiple choice

A financial services firm runs a multi-region Spanner instance with the nam-eur-asia1 configuration. They need to ensure that if the leader region (us-central1) becomes unavailable, failover to another region occurs automatically within 1 minute. What is the expected RPO and RTO for this scenario?

Trap 1: RPO ~ 0, RTO ~ 15 seconds

RTO is under 1 minute but not typically 15 seconds; RPO is around 15 seconds, not zero.

Trap 2: RPO ~ 1 hour, RTO ~ 5 minutes

RPO is much lower and RTO is under 1 minute.

Trap 3: RPO = 0, RTO < 1 minute

Spanner multi-region does not guarantee zero data loss; RPO is about 15 seconds.

A
RPO ~ 15 seconds, RTO < 1 minute
This matches Spanner's documented RPO and RTO for multi-region failover.
B
RPO ~ 0, RTO ~ 15 seconds
Why wrong: RTO is under 1 minute but not typically 15 seconds; RPO is around 15 seconds, not zero.
C
RPO ~ 1 hour, RTO ~ 5 minutes
Why wrong: RPO is much lower and RTO is under 1 minute.
D
RPO = 0, RTO < 1 minute
Why wrong: Spanner multi-region does not guarantee zero data loss; RPO is about 15 seconds.

Question 5hardmultiple choice

An organization has a Cloud SQL for MySQL instance that stores sensitive data. They need to encrypt the data at rest using a customer-managed encryption key (CMEK). The database engineer creates a Cloud KMS key ring and key, and configures the Cloud SQL instance to use CMEK. However, after 30 days, the instance becomes inaccessible and the error message indicates the CMEK key is disabled. What is the most likely cause?

Trap 1: The Cloud SQL instance exceeded the number of times it can access…

There is no access count limit for CMEK keys.

Trap 2: The CMEK key was rotated, and the old key version was disabled.

Key rotation creates a new version; the old version remains enabled for decryption unless disabled.

Trap 3: The CMEK key expired, causing automatic disablement.

Cloud KMS keys do not auto-expire; they must be explicitly disabled or deleted.

A
The CMEK key was disabled by the key administrator for security reasons.
If the key is disabled, Cloud SQL cannot access it, causing the instance to become unavailable.
B
The Cloud SQL instance exceeded the number of times it can access the CMEK key.
Why wrong: There is no access count limit for CMEK keys.
C
The CMEK key was rotated, and the old key version was disabled.
Why wrong: Key rotation creates a new version; the old version remains enabled for decryption unless disabled.
D
The CMEK key expired, causing automatic disablement.
Why wrong: Cloud KMS keys do not auto-expire; they must be explicitly disabled or deleted.

Question 6mediummultiple choice

An engineer needs to migrate a 500 GB MySQL database to Cloud SQL. The source is in a private network with no public IP. The Cloud SQL instance will also use a private IP. Which connectivity method should the engineer use for Database Migration Service?

Trap 1: Assign a public IP to the source database and allowlist it in Cloud…

Exposing the source to the internet is a security risk and may not be possible.

Trap 2: Use Cloud VPN to connect the source network to Cloud SQL.

Cloud VPN establishes a secure network tunnel between an on-premises network and a Google Cloud VPC. While this provides network connectivity, it does not fulfil the specific private connectivity requirements for Database Migration Service (DMS) to access the source database. DMS's private connectivity option leverages Private Service Access, connecting a Google-managed service producer VPC to the customer's VPC, which then needs to reach the source. Cloud VPN is tempting as it secures private network paths, and would be the correct choice for general network-level private access between on-premises and Cloud environments, or if the migration tool could be deployed within the customer's VPC.

Trap 3: Configure IP allowlisting on Cloud SQL to accept traffic from the…

IP allowlisting is only for public IP connections.

A
Assign a public IP to the source database and allowlist it in Cloud SQL.
Why wrong: Exposing the source to the internet is a security risk and may not be possible.
B
Use VPC peering between the source network and the Cloud SQL VPC.
VPC peering enables private connectivity for DMS.
C
Use Cloud VPN to connect the source network to Cloud SQL.
Why wrong: Cloud VPN establishes a secure network tunnel between an on-premises network and a Google Cloud VPC. While this provides network connectivity, it does not fulfil the specific private connectivity requirements for Database Migration Service (DMS) to access the source database. DMS's private connectivity option leverages Private Service Access, connecting a Google-managed service producer VPC to the customer's VPC, which then needs to reach the source. Cloud VPN is tempting as it secures private network paths, and would be the correct choice for general network-level private access between on-premises and Cloud environments, or if the migration tool could be deployed within the customer's VPC.
D
Configure IP allowlisting on Cloud SQL to accept traffic from the source's private IP range.
Why wrong: IP allowlisting is only for public IP connections.

Question 7mediummultiple choice

A site reliability engineer is defining an SLO for a service that processes user uploads. The team wants to measure success as the proportion of uploads completed within 2 seconds. Which type of SLI should they use?

Trap 1: Throughput-based SLI measuring requests per second

Throughput measures volume, not latency compliance.

Trap 2: Freshness-based SLI measuring time since last successful upload

Freshness is used for batch or streaming data pipelines, not individual request latency.

Trap 3: Availability-based SLI using successful/total requests

Availability measures whether a request succeeded (e.g., HTTP 200), not its latency.

A
Throughput-based SLI measuring requests per second
Why wrong: Throughput measures volume, not latency compliance.
B
Freshness-based SLI measuring time since last successful upload
Why wrong: Freshness is used for batch or streaming data pipelines, not individual request latency.
C
Latency-based SLI measuring proportion of requests under a threshold
This directly captures the requirement: fraction of uploads completed within 2 seconds.
D
Availability-based SLI using successful/total requests
Why wrong: Availability measures whether a request succeeded (e.g., HTTP 200), not its latency.

Question 8hardmultiple choice

You need to set up disaster recovery for a Cloud SQL for PostgreSQL instance. The primary instance is in us-central1, and you want a standby in us-west1 that can be promoted to a standalone instance during a regional outage. The solution must minimize data loss and recovery time. Which approach should you take?

Trap 1: Configure cross-region automated backups with a retention of 7 days

Backups have higher RPO and RTO compared to a live replica. This is less optimal than a cross-region replica.

Trap 2: Set up an on-premise PostgreSQL instance and configure streaming…

This requires external connectivity and is not a fully managed solution within GCP.

Trap 3: Use gcloud sql instances create with a backup configuration…

This is invalid; backup configuration is not an instance.

A
Configure cross-region automated backups with a retention of 7 days. In the event of a disaster, restore the latest backup to a new instance in us-west1.
Why wrong: Backups have higher RPO and RTO compared to a live replica. This is less optimal than a cross-region replica.
B
Set up an on-premise PostgreSQL instance and configure streaming replication from Cloud SQL to the on-premise instance.
Why wrong: This requires external connectivity and is not a fully managed solution within GCP.
C
Create a cross-region read replica in us-west1. During a disaster, promote the replica to a standalone instance.
A cross-region read replica is the best option: it stays up-to-date (asynchronously) and can be promoted quickly.
D
Use gcloud sql instances create with a backup configuration pointing to us-west1, but this does not create a live standby.
Why wrong: This is invalid; backup configuration is not an instance.