75 of 154 questions · Page 2/3 · Manage a solution that can span multiple database technologies · Answers revealed
A Cloud Bigtable instance has a hot spot causing performance degradation. Which tool helps identify the hot spot?
Key Visualizer is specifically designed to analyze access distribution and detect hot spots.
Why this answer
Key Visualizer is a built-in Bigtable tool that visualizes access patterns and helps identify hot spots (uneven load across row keys).
You have a Memorystore for Redis instance used as a cache. You need to scale it to handle increased load. The current instance is Basic Tier with 2 GB memory. Which TWO actions can you take to scale the instance? (Choose two.)
Vertical scaling increases capacity by adding more memory to a single node.
Why this answer
Memorystore supports vertical scaling by increasing memory size or changing to a higher tier (e.g., Basic to Standard, or Standard to Standard with more memory) – this is option A. Horizontal scaling is achieved by enabling Redis Cluster, which automatically shards data across multiple nodes – this is option E. Option B (creating additional instances with client-side sharding) is not a supported scaling method for Memorystore because it requires manual management and is not integrated with the service.
Option C (changing eviction policy to noeviction) does not scale the instance and risks data loss when memory is full. Option D (adding read replicas) is available only in Standard Tier, but it offloads read traffic, not scales the cache capacity.
A database administrator needs to restore a Cloud SQL for PostgreSQL instance to a specific point in time within the last 3 hours. Which configurations must be enabled to perform a point-in-time recovery (PITR)?
Correct. PITR requires automated backups and WAL archiving (transaction logs) with retention between 1-7 days.
Why this answer
PITR in Cloud SQL for PostgreSQL requires automated backups enabled and write-ahead log (WAL) archiving with a specified transaction log retention period (1-7 days). Binary logging is for MySQL, not PostgreSQL.
Which THREE metrics should you set up alerts for to proactively monitor the health of a Cloud SQL for MySQL instance? (Choose 3)
Replication lag indicates data consistency and is a key health metric for instances with replicas.
Why this answer
Replication lag (for instances with replicas) is critical because high lag can cause stale reads and data inconsistency. CPU utilization above 80% indicates resource exhaustion, leading to performance degradation. Disk usage must be monitored to prevent storage full conditions that can cause instance downtime.
These three metrics directly reflect instance health, whereas queries per second and network throughput are more related to workload performance, not health.
Exam trap
Google often tests the distinction between metrics that indicate instance health (e.g., replication lag, CPU utilization, disk usage) versus metrics that indicate performance or throughput (e.g., queries per second, network throughput), leading candidates to select the latter as health indicators.
A financial application uses Cloud Spanner and requires daily full backups stored in another region for compliance. The backups must be restorable without exporting/importing. Which backup method should they use?
Spanner backups can be created and stored in another region, restorable directly.
Why this answer
Spanner supports scheduled backups that can be configured for cross-region storage, allowing direct restoration to a new database without export/import. This meets the requirement of daily backups in another region with import-free restore. Option A (export to Avro files in Cloud Storage) requires import to restore, so it's incorrect.
Option B (Cloud Scheduler triggering a script that takes a snapshot in Cloud Storage) is not a built-in Spanner feature and would require export/import, making it unsuitable. Option D (on-demand backups copied manually) is possible but not ideal for daily backups as it lacks automation.
You notice that your Cloud SQL for MySQL instance's storage is filling up quickly. You have enabled automatic storage increase, but you want to manually increase the storage size by 50 GB to avoid any risk of reaching the limit. The current disk size is 200 GB. What is the correct gcloud command to resize the disk?
This increases the disk to 250 GB. The command is valid and disk resize is online.
Why this answer
The `gcloud sql instances patch` command is used to modify an existing Cloud SQL instance, and the `--storage-size` flag expects the value in GB as an integer (without the 'GB' suffix). Specifying `250` correctly increases the storage from 200 GB to 250 GB.
Exam trap
Google often tests the exact syntax of gcloud commands, specifically that the `--storage-size` flag takes a plain integer (no 'GB' suffix) and that `patch` is the correct subcommand for modifying an existing instance, not `update` or `resize`.
How to eliminate wrong answers
Option A is wrong because the `--storage-size` flag does not accept a unit suffix like 'GB'; it expects a plain integer representing gigabytes. Option C is wrong because `gcloud sql instances update` is not a valid command; the correct command is `gcloud sql instances patch`. Option D is wrong because `gcloud sql instances resize` is not a valid gcloud command; Cloud SQL storage resizing is done via the `patch` subcommand with the `--storage-size` flag.
A company uses Cloud Spanner and needs to implement change data capture (CDC) to stream changes to a downstream analytics pipeline. Which two features can they use? (Choose TWO.)
Changes from change streams can be published to Pub/Sub.
Why this answer
Spanner change streams capture row-level changes in a Cloud Spanner database. These changes can be consumed via Pub/Sub integration, allowing downstream analytics pipelines to process the data. Therefore, Option E (Spanner change streams) is correct for capturing the changes, and Option A (Pub/Sub integration) is correct for streaming them.
Option B (Cloud SQL for PostgreSQL logical replication) is not applicable as it is for Cloud SQL, not Spanner. Option C (Datastream) is used for database migrations and replication, not for CDC from Spanner. Option D (Bigtable replication) is for Bigtable, not Spanner.
A company uses Cloud SQL for PostgreSQL. They need to monitor the replication lag on a read replica. Which metric should they use in Cloud Monitoring?
Correct. This is the specific metric for PostgreSQL replicas.
Why this answer
For PostgreSQL replicas in Cloud SQL, the metric 'cloudsql.googleapis.com/database/postgresql/replication/replica_lag' measures lag in bytes (seconds can be derived). The metric 'replication_lag' is available for MySQL. For PostgreSQL, the specific metric is 'replica_lag'.
An engineer needs to monitor the replication lag of a Cloud SQL read replica. Which metric should they use in Cloud Monitoring?
This metric directly measures the lag between the primary and read replica.
Why this answer
The `replication_lag` metric in Cloud Monitoring directly measures the time delay between a primary Cloud SQL instance and its read replica, reported in seconds. This is the standard metric for monitoring how far behind the replica is in applying changes from the primary, which is critical for ensuring read-after-write consistency and data freshness.
Exam trap
In Google Cloud exams, candidates may confuse metrics that measure replication throughput (like sent_bytes_count) versus those that measure replication latency (like replication_lag), leading them to mistake data transfer volume for time delay.
How to eliminate wrong answers
Option B is wrong because `sent_bytes_count` tracks the volume of data transferred from the primary to the replica, not the time delay in replication, so it cannot indicate lag. Option C is wrong because `disk_bytes_used` measures storage consumption on the replica, which is unrelated to replication latency. Option D is wrong because `cpu_utilization` reflects the replica's processing load, not the replication delay, and high CPU does not necessarily correlate with lag.
You are managing a Memorystore for Redis instance that is part of a high-traffic e-commerce application. The instance uses the volatile-lru eviction policy and has persistence disabled. You need to improve data durability without losing the ability to evict keys with TTL. You also want to ensure that the instance can automatically recover from a zonal failure. Which TWO actions should you take? (Choose TWO.)
Correct. Enabling RDB persistence saves periodic snapshots, improving durability without affecting the volatile-lru eviction policy.
Why this answer
(Enable RDB persistence) improves data durability by taking periodic snapshots without interfering with the volatile-lru eviction policy, which only evicts keys with TTL. Option D (Standard Tier with replication) provides automatic failover across zones within a region, ensuring recovery from a zonal failure. Option A only reduces eviction frequency but does not address durability or zonal failover.
Option C is incorrect because Memorystore does not support native cross-region replicas. Option E uses manual exports, which do not enable automatic recovery and are not equivalent to persistence.
Exam trap
Candidates often confuse cross-region replicas with the Standard Tier's zonal replication. Standard Tier provides automatic failover within a region across zones, but not across regions. Also, manual exports via Cloud Scheduler are not a substitute for built-in persistence when durability is the goal.
A Cloud Memorystore for Redis instance is running out of memory. The team wants to automatically remove the least recently used keys when memory is full. Which eviction policy should they configure?
Evicts least recently used keys from all keys.
Why this answer
The `allkeys-lru` eviction policy is correct because it applies the LRU (Least Recently Used) algorithm to all keys in the Redis instance, not just those with an expiry set. This ensures that when memory is full, the least recently accessed keys are automatically removed, regardless of whether they have a TTL, which directly meets the requirement to free memory without manual intervention.
Exam trap
A common pitfall is confusing volatile-lru (only keys with TTL) with allkeys-lru (all keys), leading candidates to choose volatile-lru when the requirement is to consider all keys.
How to eliminate wrong answers
Option A is wrong because `volatile-lru` only evicts keys that have an expiry (TTL) set, leaving keys without expiry untouched, which may not free enough memory if the majority of keys are persistent. Option B is wrong because `volatile-ttl` evicts keys with the shortest remaining TTL first, which is not based on access patterns and may remove frequently used keys that happen to have a short TTL. Option C is wrong because `noeviction` prevents any eviction and instead returns errors on write operations when memory is full, which does not automatically remove any keys and can cause application failures.
A company is using Cloud Bigtable and wants to set up monitoring and alerting for replication lag between clusters. Which TWO metrics should they use? (Choose 2)
Correct. This metric shows the lag in operations.
Why this answer
`replication_lag` directly measures the time difference between the primary cluster and a replica cluster in Cloud Bigtable, which is the key metric for monitoring replication delay. Option D is also correct because `replication_delay` is another metric that tracks the same concept, often reported in seconds, and is used to alert when replicas fall behind. Both metrics are essential for ensuring data consistency and timely failover in multi-cluster Bigtable deployments.
Exam trap
Google Cloud often tests the distinction between `replication_lag` and `replication_delay` as two separate but valid metrics, while candidates may mistakenly think only one is correct or confuse them with cluster health metrics like CPU or disk usage.
A company is designing a disaster recovery plan for Cloud SQL for MySQL. They need to ensure the database can be recovered with minimal data loss (RPO of minutes) in case of a regional outage. Which TWO actions should they take?
A cross-region replica provides near-real-time data in another region for failover.
Why this answer
To achieve low RPO across regions, enable binary logging for PITR and configure a cross-region replica. Automated backups alone have a RPO of up to 24 hours.
A team is managing a Memorystore for Redis instance that needs to scale to handle increased traffic. They want to ensure high availability and the ability to distribute data across multiple nodes. Which three actions should they take? (Choose THREE.)
Redis Cluster provides horizontal scaling and sharding.
Why this answer
Memorystore for Redis offers vertical scaling (changing tier) and horizontal scaling via Redis Cluster (enabling clustering). For HA, they can create a standard tier instance with replication (a read replica).
You have a Cloud Spanner database that needs to be migrated from one region to another. You want to ensure no data loss and minimal downtime. Which approach should you use?
Backup/restore is the recommended method for moving a Spanner database between regions.
Why this answer
Cloud Spanner does not support in-place region changes or read replicas in different regions. The only supported method to migrate a Cloud Spanner database between regions with no data loss and minimal downtime is to create a backup of the database and restore it to a new instance in the target region. This approach ensures a consistent snapshot of the data and allows you to plan the cutover window to minimize downtime.
Exam trap
Google often tests the misconception that Cloud Spanner supports cross-region read replicas like other databases (e.g., Cloud SQL or MySQL), but Spanner's architecture uses a single regional or multi-region instance configuration with synchronous replication, not promotable replicas.
How to eliminate wrong answers
Option A is wrong because the `gcloud spanner instances move` command does not exist; Cloud Spanner instances cannot have their region changed after creation. Option C is wrong because Cloud Spanner does not support cross-region read replicas that can be promoted; replicas in Spanner are always part of the same instance and region configuration. Option D is wrong because exporting to CSV files using `gcloud spanner databases export` is not supported; Cloud Spanner only supports export to Avro format, and importing from CSV would require custom tooling and would not guarantee consistency or minimal downtime.
A company is migrating its on-premises PostgreSQL database to Cloud SQL. The database is 2 TB and the migration must have minimal downtime. The source database supports continuous archiving. Which three steps should they take? (Choose THREE.)
Once replication is caught up, promote the Cloud SQL instance to become the new primary.
Why this answer
Promoting the Cloud SQL instance to primary is the final step in a migration using continuous replication, which minimizes downtime by allowing the source database to remain operational until the cutover. This approach leverages Cloud SQL's ability to act as a replica that stays synchronized with the on-premises database via continuous archiving, ensuring data consistency with minimal interruption.
Exam trap
A common trap is confusing PostgreSQL's WAL-based replication with MySQL's binary logging; candidates familiar with MySQL may incorrectly select Option C, but for PostgreSQL to Cloud SQL, the correct approach uses Database Migration Service with continuous migration and WAL replication.
You are using Cloud Spanner and need to add a new column to an existing table. The table has millions of rows and must remain fully available for reads and writes during the schema change. What is the correct approach?
Spanner DDL operations are non-blocking, so the table remains available during schema changes.
Why this answer
Cloud Spanner supports non-blocking schema changes using DDL statements like ALTER TABLE ... ADD COLUMN. These operations are applied online without locking the table.
The --async flag is optional for running the command asynchronously. The statement is executed via gcloud spanner databases ddl update.
A Cloud Bigtable instance experiences a sudden increase in read latency and request errors. The operations team notices that one node is handling disproportionately more traffic. Which tool should they use to diagnose the issue?
Key Visualiser is designed to identify hot spots by visualising read/write patterns across key ranges.
Why this answer
Key Visualizer is the correct tool because it provides a heatmap of access patterns across row key ranges, allowing you to identify hot spots where a single node is overloaded due to uneven key distribution. This directly addresses the symptom of one node handling disproportionately more traffic, which is a common cause of increased latency and errors in Cloud Bigtable.
Exam trap
A common mistake is to choose Cloud Monitoring (formerly Stackdriver) because it shows aggregate latency and error metrics, but it does not pinpoint which row keys are causing the hotspot. Key Visualizer is the specialized tool for analyzing access patterns by row key range.
How to eliminate wrong answers
Option B is wrong because Stackdriver Monitoring (now Cloud Monitoring) provides aggregate metrics like average latency and error rates, but it does not offer per-node or per-key-range granularity to pinpoint which specific row keys are causing the hot spot. Option C is wrong because 'gcloud bigtable instances describe' returns metadata about the instance (e.g., display name, cluster configuration) but no real-time traffic distribution or performance data. Option D is wrong because the 'cbt' command is used for manual table operations like reading or writing data, not for diagnosing traffic imbalance or hot spots; scanning the table would not reveal which node is overloaded.
A database administrator wants to set up monitoring and alerting for Cloud SQL instances. They need to be notified when CPU utilisation exceeds 80% for more than 5 minutes and when replication lag on a read replica exceeds 30 seconds. Which two metrics should they create alerting policies for? (Choose TWO.)
This metric measures replication lag in seconds.
Why this answer
Cloud SQL provides the metric 'cloudsql.googleapis.com/database/cpu/utilization' for CPU usage and 'cloudsql.googleapis.com/database/replication/replica_lag' for replication lag. Alerting policies can be set on these metrics in Cloud Monitoring.
A team is designing a disaster recovery strategy for Cloud SQL. They need to be able to recover the database in a different region with a Recovery Point Objective (RPO) of less than 30 minutes. What should they configure?
Cross-region read replicas provide asynchronous replication with RPO typically in seconds to minutes. Promoting gives a new primary in the other region.
A gaming company uses Firestore in Native mode to store player profiles and game state. They need to query the data by both 'playerId' and 'lastLoginTimestamp' sorted descending. The current index configuration is automatic. How should they configure indexing to support this query efficiently?
Correct. A composite index with the exact order (asc/desc) is needed for efficient queries with ordering.
Why this answer
Firestore automatically creates single-field indexes for all fields. For queries with ordering on two fields, a composite index is required. The composite index must include both fields in the correct order (ascending or descending).
A Cloud SQL for PostgreSQL instance is experiencing a surge in read traffic. The team wants to offload read queries without affecting write latency. What should they do?
Same-region read replicas offload read traffic with minimal latency, preserving write performance on the primary.
Why this answer
Creating read replicas allows distributing read traffic, reducing load on the primary instance for writes. Read replicas are the standard solution for scaling read workloads.
A financial services company uses Cloud Bigtable for real-time fraud detection. They have a cluster with 10 nodes using HDD storage and are experiencing high latency due to disk throughput bottlenecks. They need to improve performance with minimal downtime. What should they do?
Correct. A new cluster with SSD must be created. Use replication to keep data in sync, then cut over with minimal downtime.
Why this answer
Cloud Bigtable does not support in-place conversion of storage from HDD to SSD. The only way to migrate to SSD storage is to create a new cluster with SSD, replicate data using Bigtable replication, and then update the application connection string to point to the new cluster. This approach minimizes downtime by allowing the old cluster to serve reads during replication.
Exam trap
The PCDOE exam often tests the misconception that you can change storage type in-place or that adding nodes solves all performance issues, but the key trap here is that HDD throughput is a hardware limitation that requires a new cluster with SSD to overcome.
How to eliminate wrong answers
Option A is wrong because Cloud Bigtable does not allow modifying the storage type of an existing cluster via the Cloud Console or any API; storage type is fixed at cluster creation. Option C is wrong because hot tablet detection and rebalancing address read/write hotspot issues, not disk throughput bottlenecks caused by HDD vs SSD performance. Option D is wrong because increasing the number of nodes adds CPU and memory capacity but does not resolve the fundamental I/O throughput limitation of HDD storage; the bottleneck is disk speed, not node count.
A company has a Cloud SQL for MySQL instance with a cross-region read replica for disaster recovery. During a regional outage, they need to promote the read replica to a standalone instance as quickly as possible. What is the correct procedure?
Correct. The promote-replica command promotes the replica to a standalone instance.
Why this answer
Promoting a read replica makes it a standalone instance. It can be done via the Cloud Console or gcloud command. The promotion is immediate, but the original primary may still be active if not stopped.
A developer wants to add a composite index in Firestore to support a query that filters on two fields: 'status' (equality) and 'createdAt' (range). How should the index be configured?
This composite index configuration supports equality on 'status' and range on 'createdAt'.
Why this answer
Firestore requires a composite index when a query combines an equality filter on one field with a range filter on another. The index must list the equality field first ('status') followed by the range field ('createdAt'), with ascending order for both to support the range query efficiently. This matches the Firestore index definition rules for composite indexes.
Exam trap
The PCDOE exam often tests the misconception that the order of fields in a composite index does not matter, but Firestore strictly requires the equality field to precede the range field to avoid a full collection scan.
How to eliminate wrong answers
Option B is wrong because single-field indexes are automatically created but cannot satisfy a query that filters on two different fields with different operators (equality and range); a composite index is mandatory. Option C is wrong because placing the range field ('createdAt') before the equality field ('status') would cause the query to fail or perform a full scan, as Firestore requires the equality field to be first in the composite index definition. Option D is wrong because an index exemption is used to exclude a field from automatic indexing, not to force index creation; it would actually prevent the needed index from being used.
An organization is using Memorystore for Redis and needs to ensure that when memory usage reaches the maximum, the cache evicts keys based on the least recently used (LRU) algorithm among keys with an expiry set. They also want to require password authentication for client connections. Which two configurations should be applied? (Choose TWO.)
AUTH password is set in Memorystore to require authentication.
Why this answer
The eviction policy 'volatile-lru' evicts keys with an expiry set using LRU. AUTH is configured by setting a password via the Redis AUTH command or in the Memorystore instance settings.
A Cloud Spanner database has a table with a primary key and a secondary index. The application frequently queries using a filter on the secondary index column and orders by the primary key. The queries are slow. What should the database administrator do to improve query performance?
A covering index includes all columns needed for the query, allowing Spanner to avoid accessing the base table, which can improve performance.
Why this answer
Cloud Spanner can use a secondary index to filter on a column, but when ordering by the primary key, Spanner often must fetch rows from the base table and then sort them, which is slow. Creating a covering index with the STORING clause includes all columns needed by the query (the filter column and the primary key, as well as any other selected columns). This allows Spanner to satisfy the query entirely from the index, avoiding both the table lookup and the sort, because the index already stores the primary key in order.
Option C is the correct syntax: `CREATE INDEX ... ON table (filter_column) STORING (other_columns)`.
A Cloud SQL for PostgreSQL instance is experiencing high read traffic. You need to offload read queries and ensure the solution can survive a regional outage. What should you do?
A cross-region read replica serves read traffic and can be promoted if the primary region fails, meeting both requirements.
Why this answer
Cross-region read replicas serve read traffic and provide disaster recovery if the primary fails. Creating a cross-region read replica reduces read load and can be promoted if the primary region fails. Option D is correct.
Option A (Cloud Memorystore cache) reduces latency but does not survive a regional outage. Option B (increasing machine type) helps performance but not regional failover. Option C (same-region read replica) does not survive a regional outage.
A company runs an e-commerce platform on Cloud SQL for PostgreSQL. They need to perform point-in-time recovery (PITR) to recover from a user error that occurred 30 minutes ago. Which configuration is required to enable PITR?
In Cloud SQL for PostgreSQL, PITR is enabled by automated backups with a retention of 1-7 days; WAL archiving is handled automatically.
You need to monitor the replication lag between a Cloud SQL for MySQL primary instance and its read replica. Which metric should you use to set up an alert?
This is the correct metric for replication lag.
Why this answer
Cloud SQL exposes a metric 'replication/replication_lag' (or 'cloudsql.googleapis.com/database/replication/replication_lag') that measures the lag in seconds between the primary and replica. This is the correct metric for alerting.
A Memorystore for Redis instance is running out of memory. The application can tolerate some data loss but not crashes. The team wants to ensure the instance remains available without manual intervention. Which eviction policy should they configure?
Correct. This evicts the least recently used keys across all keys, ensuring availability.
Why this answer
(allkeys-lru) is correct because it allows Redis to evict the least recently used keys from the entire keyspace when memory is full, which keeps the instance available without crashing. Since the application can tolerate some data loss but not crashes, this policy ensures memory pressure is relieved automatically, preventing out-of-memory errors that would cause the instance to become unavailable.
Exam trap
A common trap is to assume volatile policies (like volatile-lru or volatile-ttl) are safer because they only affect keys with TTL. However, if most keys lack expiration, these policies fail to free memory, leading to crashes—whereas allkeys-lru guarantees eviction across all keys to maintain availability.
How to eliminate wrong answers
Option A (volatile-lru) is wrong because it only evicts keys with an expiration set, leaving keys without TTL untouched; if the majority of data lacks expiration, memory may still fill up and cause instability. Option B (volatile-ttl) is wrong because it evicts keys based on shortest remaining TTL among volatile keys, which is unpredictable and may not free enough memory in time, risking crashes. Option C (noeviction) is wrong because it returns errors on write operations when memory is full, which would cause application crashes or unavailability, directly contradicting the requirement to avoid crashes.
A company is running a Cloud SQL for PostgreSQL instance for an e-commerce application. They need to enable point-in-time recovery (PITR) with a 7-day retention period. What configuration steps must be taken?
Correct. WAL archiving is needed for PITR, and backup retention is set via the flag.
Why this answer
Cloud SQL for PostgreSQL uses Write-Ahead Log (WAL) archiving to enable point-in-time recovery (PITR). You must enable automated backups (which automatically enables WAL archiving) and then set the backup retention period to 7 days using the `gcloud sql instances patch --backup-retention-days 7` command. This ensures that WAL logs are retained for the specified duration, allowing PITR within that window.
Exam trap
Candidates often mistakenly think that enabling automated backups in Cloud SQL automatically sets the retention period for point-in-time recovery (PITR) to 7 days. However, you must explicitly configure backup retention using the gcloud command to retain WAL logs for the desired duration. Additionally, some confuse the process with MySQL binary logging, but PostgreSQL uses WAL archiving for PITR.
How to eliminate wrong answers
Option A is wrong because cross-region backup replicas are used for disaster recovery and high availability, not for enabling PITR; they do not provide the WAL log retention required for point-in-time recovery. Option C is wrong because binary logging is a MySQL/MariaDB concept, not applicable to PostgreSQL; PostgreSQL uses WAL (Write-Ahead Log) for PITR, not binary logs. Option D is wrong because while enabling automated backups is necessary, the statement 'WAL archiving is automatic' is misleading; WAL archiving is automatically enabled only when automated backups are turned on, but the retention period must be explicitly configured via the `--backup-retention-days` flag—simply enabling automated backups with a 7-day retention without the patch command does not guarantee the correct configuration.
Which TWO actions are required to set up point-in-time recovery (PITR) for Cloud SQL for MySQL? (Choose 2)
Binary logging is required for PITR in MySQL to capture point-in-time changes.
A Cloud Bigtable cluster is currently using HDD storage. The team wants to switch to SSD for better performance. What is the correct approach?
Correct. A Bigtable instance can have multiple clusters; add a new SSD cluster, replicate data, then remove the HDD cluster.
Why this answer
In Cloud Bigtable, storage type is a property of the cluster, not the instance. You cannot change the storage type of an existing cluster. The correct approach is to add a new cluster with SSD storage to the same instance, then delete the original HDD cluster.
This allows you to migrate without data loss or downtime, as data is replicated across clusters in the same instance.
Exam trap
A common misconception is that you can update storage type on an existing cluster or that deleting a cluster preserves data in the instance. However, in Cloud Bigtable, storage type is immutable per cluster and data is tied to the cluster's existence.
How to eliminate wrong answers
Option B is wrong because the `gcloud bigtable clusters update` command does not support a `--storage-type` flag; storage type is immutable after cluster creation and cannot be changed via any command. Option C is wrong because it unnecessarily involves exporting to Cloud Storage and recreating the instance, which is complex and risks data loss or extended downtime; Cloud Bigtable supports multiple clusters per instance, making a simple cluster swap possible. Option D is wrong because deleting the cluster also deletes all data stored in that cluster; data is not retained in the instance when the only cluster is removed, as Cloud Bigtable stores data only in clusters.
A team wants to create a Cloud Spanner database backup and store it in a Cloud Storage bucket for long-term archival. Which method should they use?
Correct. Backup creates a full backup in Cloud Storage (Avro + Protobuf) that can be restored.
Why this answer
Cloud Spanner provides database-level backups directly to Cloud Storage in Avro + Protobuf format. Export/import is for migration, not archival backups.
A Cloud Spanner instance is backing up a 2 TB database daily to Cloud Storage using the built-in backup feature. The compliance team requires the backup to be stored in a specific regional bucket with a retention policy of 14 days. How should the database administrator configure this?
Correct. Export to Cloud Storage allows specifying a regional bucket. Object lifecycle rules can enforce a 14-day retention.
Why this answer
Spanner database backups are stored as managed backups within the Spanner service, not directly as files in Cloud Storage. However, they can be exported to Cloud Storage using the export API. The export can be configured to a specific bucket and region, and object lifecycle rules can enforce retention.
An application uses Firestore in Native mode. The query filters on two fields: 'status' (string) and 'created_date' (timestamp). The query returns results but the billing shows high document reads. What is the most likely cause?
Correct. Queries with equality on one field and inequality on another need a composite index to avoid scanning all documents.
Why this answer
In Firestore Native mode, queries that apply an inequality filter (e.g., >=, >, <, !=) on a field automatically require a composite index on both the equality filter field and the inequality filter field to avoid a full collection scan. Without that composite index, Firestore performs a back-end scan of all documents matching the equality filter, then applies the inequality filter in memory, resulting in high document reads. Option A correctly identifies that the inequality filter on 'created_date' is the most likely cause of the excessive reads because it forces Firestore to read and discard many documents that do not satisfy the timestamp condition.
Exam trap
A common pitfall is the misconception that missing ORDER BY or using array-contains causes high reads, when in fact the real culprit is the lack of a composite index for inequality filters combined with equality filters.
How to eliminate wrong answers
Option B is wrong because 'array-contains' does not always scan the entire collection; it can use an automatically created single-field index on the array field, and while it may read more documents than a simple equality filter, it does not inherently cause a full collection scan. Option C is wrong because single-field indexes are automatically created for all fields in Firestore Native mode by default, so 'status' is indexed without manual action. Option D is wrong because missing an ORDER BY clause does not cause a full scan; Firestore can still use indexes to satisfy the filter conditions, and ORDER BY only affects the ordering of results, not the number of documents read.
A team manages a Cloud Spanner database and needs to perform a schema change to add a new column to an existing table and create a secondary index. They want to avoid downtime and ensure the changes are applied without blocking reads or writes. Which two statements are correct about making these changes in Spanner? (Choose TWO.)
Spanner DDL changes are online and non-blocking.
Why this answer
In Cloud Spanner, both ALTER TABLE (to add columns) and CREATE INDEX are online, non-blocking operations. They can be run via DDL statements in the gcloud CLI or console. Indexes can be created as UNIQUE to enforce uniqueness.
A company is using Cloud SQL and wants to automatically increase storage when disk usage reaches a threshold. What should they configure?
Correct. This setting automatically increases storage.
Why this answer
Cloud SQL provides a built-in 'auto-storage increase' setting that, when enabled, automatically increases the instance's storage capacity when disk usage reaches a predefined threshold (typically 90% or when free space drops below a certain amount). This eliminates the need for manual intervention or custom automation, ensuring high availability and preventing out-of-disk errors.
Exam trap
The trap here is that candidates may over-engineer a solution (e.g., Cloud Functions or Monitoring alerts) when a simple, built-in configuration option exists, or they may confuse Active Assist recommendations with automated actions.
How to eliminate wrong answers
Option B is wrong because Active Assist provides recommendations for optimization (e.g., idle resources, underutilized instances) but does not automatically resize storage; it only suggests manual actions. Option C is wrong because setting up a Cloud Monitoring alert to manually increase storage still requires human intervention, which defeats the purpose of automatic scaling and introduces risk of downtime if the alert is missed. Option D is wrong because while a Cloud Function could theoretically resize the disk via API, this approach is unnecessarily complex, introduces custom code maintenance, and is not a native Cloud SQL feature; the built-in 'auto-storage increase' is the recommended and simpler solution.
A company is using Cloud SQL for PostgreSQL and needs to perform point-in-time recovery (PITR) to recover from a logical error that occurred 30 minutes ago. They have already configured automated backups. What additional configuration is required?
WAL archiving is controlled by this setting for PostgreSQL instances.
Why this answer
Cloud SQL PITR requires write-ahead log (WAL) archiving, which is enabled by setting the 'transaction log retention' in days (1-7). Automated backups alone do not capture continuous transaction logs.
A gaming company uses Cloud Spanner for a global leaderboard. They need to add a column to an existing table and create a secondary index on that column. The database must remain fully available during these changes. Which THREE statements are true?
Adding a NOT NULL column without default requires a table lock; with a default it is online.
Why this answer
In Cloud Spanner, when adding a NOT NULL column to an existing table, the column must have a DEFAULT value. This ensures that existing rows, which will be populated with the default value, satisfy the NOT NULL constraint without requiring a full table scan or blocking writes.
Exam trap
A common misconception is that schema changes in distributed databases require downtime or blocking, but Cloud Spanner's online DDL operations are designed to maintain full availability during both ALTER TABLE and CREATE INDEX.
A company uses Firestore in Native mode and has a collection with many documents containing array fields. They want to index the array values to support queries like 'array-contains'. What is the correct approach?
Correct. In Firestore Native mode, array fields are automatically indexed, so no additional configuration is needed for array-contains queries.
Why this answer
In Firestore Native mode, all fields are automatically indexed by default, including array fields. For array fields, the index includes each element, which allows queries using the `array-contains` operator to work without any additional configuration. Index exemptions are used to exclude specific fields from automatic indexing, not to enable indexing.
Therefore, no action is required.
Exam trap
Candidates often confuse Firestore Native mode with Datastore mode. In Native mode, indexes are automatic; in Datastore mode, indexes must be manually configured. Also, 'index exemption' is for excluding fields, not adding them.
A company uses Memorystore for Redis with Standard Tier (replication) and needs to ensure data durability in case of a zone failure. They also need to scale read throughput beyond a single instance. What should they do?
Redis Cluster provides horizontal scaling by sharding data, and with multiple shards across zones, it improves both availability and read throughput.
Why this answer
Memorystore for Redis Standard Tier provides cross-zone replication for high availability. To scale read throughput, they can use Redis Cluster (which shards data across multiple shards) or create read replicas. However, Memorystore does not support read replicas for Redis; instead, Redis Cluster provides horizontal scalability and high availability.
Upgrading to a larger instance scales vertically but not read throughput horizontally. Persistence is not natively supported in Memorystore.
A company uses Firestore in Datastore mode. They need to create a composite index for a query that filters on two properties. The query is already running and returning an error that an index is required. What is the correct way to create this index?
Composite indexes are manually defined via a YAML file and created with gcloud.
Why this answer
In Firestore (Datastore mode), composite indexes must be explicitly created before they can be used by queries that filter on multiple properties. The `gcloud datastore indexes create` command with a YAML file is the standard method to define and deploy these indexes, as the Datastore mode does not automatically create composite indexes from query patterns.
Exam trap
Google often tests the misconception that Datastore mode automatically creates composite indexes from query patterns, similar to Firestore Native mode's automatic index creation, but in Datastore mode, composite indexes must be manually defined.
How to eliminate wrong answers
Option B is wrong because modifying the query to use a single filter would change the query's logic and may not return the desired results; the requirement is to support the existing multi-property query, not to alter it. Option C is wrong because there is no 'auto-index' feature in the Datastore console; Firestore in Datastore mode only provides automatic single-property indexes, not composite indexes. Option D is wrong because composite indexes in Datastore mode are not created automatically based on query patterns; they must be explicitly defined and deployed by the user.
A Cloud SQL for MySQL instance is running low on disk space. You need to increase the storage without downtime. What is the correct approach?
Correct. gcloud sql instances patch --storage-size NEW_SIZE resizes online.
Why this answer
Cloud SQL for MySQL supports online storage resizing using the `gcloud sql instances patch` command or the Google Cloud Console, which allows you to increase the storage capacity without any downtime. The operation is performed while the instance remains available, and the underlying persistent disk is resized live, leveraging Google Cloud's live resize capability for Cloud SQL instances.
Exam trap
The trap here is that candidates may assume that any disk resize requires stopping the instance (as with traditional on-premises or some cloud VMs), but Cloud SQL's managed service allows online resizing without downtime, which is a key differentiator tested in the PCDOE exam.
How to eliminate wrong answers
Option A is wrong because creating a new instance and migrating data with mysqldump would require significant downtime during the dump and restore process, and it is unnecessarily complex when a simple online resize is available. Option B is wrong because while automatic storage increase can be enabled, manual resizing is also possible and is the direct solution to the problem; automatic increase only triggers when a threshold is reached, not for immediate manual intervention. Option C is wrong because stopping the instance to resize the disk would cause downtime, which contradicts the requirement to increase storage without downtime; Cloud SQL does not require stopping the instance for storage resizing.
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?
A cross-region read replica is the best option: it stays up-to-date (asynchronously) and can be promoted quickly.
Why this answer
Cross-region read replicas in Cloud SQL for PostgreSQL use synchronous replication (for regional replicas, it's asynchronous across regions, but still the best option for DR). Creating a cross-region read replica in us-west1 allows it to be promoted to a standalone instance in DR scenarios. Cross-region backups are point-in-time backups, not a live standby.
External replication is not managed by Cloud SQL.
A company has a Cloud SQL for PostgreSQL instance and wants to enable point-in-time recovery (PITR) with a recovery window of 5 days. Which configuration step is required?
Automated backups must be enabled with a retention period of 5 days to support PITR within that window.
Why this answer
PITR in Cloud SQL for PostgreSQL uses Write-Ahead Logging (WAL) archives. You must enable automated backups and set the backup retention to the desired recovery window (1-7 days). Binary logging is for MySQL, not PostgreSQL.
Cloud Storage archiving is separate. WAL archiving is automatically managed when automated backups are enabled with a retention period.
A Cloud SQL for MySQL instance is being used for a production application. The team wants to implement a disaster recovery plan that can recover from a regional outage with minimal data loss and automatic failover. Which three steps should they take? (Choose THREE.)
Backups are essential for recovery.
Why this answer
Automated backups in Cloud SQL for MySQL provide a baseline for disaster recovery by creating daily backups that can be restored to a new instance. With a suitable retention period, you can recover from data corruption or accidental deletion, though backups alone do not provide automatic failover or minimal data loss during a regional outage.
Exam trap
The trap here is that candidates confuse read replicas in the same region as providing disaster recovery for regional outages, but they only offer read scaling and high availability within the same region, not cross-region failover.
A company has a Firestore database in Native mode. They need to run a query that filters on two fields (status and date) and orders by date. The query is slow and returns an error that a matching index is missing. What must the engineer do to resolve this?
Firestore in Native mode requires a composite index for queries that filter on multiple fields or combine filters with ordering. The index must include both fields.
Why this answer
Firestore requires a composite index on both the equality filter field (status) and the order field (date) when a query uses equality filters on one field and an order on another. Without this composite index, the query cannot be executed efficiently and returns an error. Creating the composite index via the Firebase Console or gcloud CLI resolves the issue.
Exam trap
Google Cloud often tests the misconception that single-field indexes are automatically combined for multi-field queries, or that using 'IN' clauses bypasses indexing requirements, when in fact composite indexes are mandatory for such queries.
How to eliminate wrong answers
Option A is wrong because single-field indexes are insufficient for queries that filter on one field and order by another; Firestore does not automatically combine them to satisfy the query. Option B is wrong because rewriting the query with 'IN' clauses does not eliminate the need for a composite index; it still requires an index on the field being ordered. Option D is wrong because switching to Datastore mode is unnecessary and does not solve the indexing requirement; Datastore mode also requires composite indexes for similar queries.
Your Memorystore for Redis instance is used as a session store for a web application. You need to ensure that session data is not lost during a node failure. What should you do?
AOF persistence logs every write operation to disk, enabling near-real-time durability. In the event of a node failure, the AOF log can be replayed to recover data with minimal loss. This is the best option for session data that must not be lost.
Why this answer
Memorystore for Redis supports persistence via RDB snapshotting or AOF (Append-Only File). For minimal data loss during a node failure, AOF persistence is recommended because it logs every write operation, allowing recovery with only a few seconds of data loss (depending on fsync settings). Standard Tier with replication provides high availability but does not persist data to disk, so a full zone failure can cause data loss.
Periodic exports to Cloud Storage have gaps between exports, leading to data loss of up to the export interval. Therefore, enabling AOF persistence is the best approach to prevent data loss during a node failure.
Your team manages a Cloud SQL for MySQL instance used by a critical application. You need to ensure the instance is recoverable to any point within the last 4 days, with a Recovery Point Objective (RPO) of under 5 minutes. What configuration steps are required?
Automated backups plus binary logging (with appropriate retention) enables PITR with a 4-day window.
Why this answer
Point-in-time recovery (PITR) in Cloud SQL for MySQL requires both automated backups and binary logging to be enabled. The transaction log retention period (set via transactionLogRetentionDays) determines how far back you can perform PITR, with a maximum of 7 days. Enabling automated backups alone (option A) does not provide PITR because binary logging is needed.
Option B is incorrect because automated backups are required for PITR, and binary logging only without backups does not meet the recovery window. Option C with on-demand daily backups cannot provide an RPO under 5 minutes because binary logging captures ongoing changes. Therefore, option D is correct: enable automated backups, binary logging, and set the transaction log retention to 4 days to meet the 4-day recovery window and RPO under 5 minutes.
A Bigtable cluster is configured with SSD storage. The team needs to reduce costs by switching to HDD storage while maintaining the same cluster ID and node count. What is the correct approach?
A new cluster with HDD storage is required; data can be migrated via export/import.
Why this answer
Bigtable does not allow in-place modification of storage type (SSD vs. HDD) on an existing cluster. To switch storage, you must create a new instance with HDD storage and migrate data using export/import (e.g., via Cloud Storage and Dataflow).
Option C correctly describes this process, preserving the cluster ID and node count by recreating the instance with the same configuration but HDD storage.
Exam trap
Google often tests the immutability of Bigtable storage type and the misconception that you can simply update it via the console or CLI, leading candidates to choose options A or D.
How to eliminate wrong answers
Option A is wrong because Bigtable does not support editing the storage type of an existing cluster; the storage type is immutable after creation. Option B is wrong because deleting and recreating the cluster would lose the cluster ID and require manual data migration, but the question requires maintaining the same cluster ID, which is not possible with a delete/recreate approach. Option D is wrong because the gcloud bigtable instances update command cannot change the storage type; it only updates display names or labels, not the underlying storage medium.
A retail company uses Cloud SQL for MySQL with point-in-time recovery (PITR) enabled. They need to recover the database to a specific second from 2 days ago. The backup retention is set to 7 days. Which action should the engineer take to perform the recovery?
This is the correct method: using --point-in-time and restoring to a new instance (since same-instance restore is not supported for PITR).
Why this answer
Point-in-time recovery (PITR) in Cloud SQL uses binary logs to recover to any time within the configured retention period. The engineer can restore to a new instance using gcloud sql instances restore-backup with the --point-in-time flag and specify the exact timestamp. Restoring to the same instance is not supported; only to a new instance.
The --async flag is optional but not required. The recovery is not limited to full backups; binary logs allow precise time recovery.
A Cloud SQL for MySQL instance has a read replica in a different region. The team wants to monitor replication lag and receive alerts if lag exceeds 60 seconds. Which two steps should they take? (Choose TWO.)
This is the correct metric and threshold for alerting on lag.
Why this answer
The replication_lag metric is available in Cloud Monitoring. An alerting policy based on this metric with a threshold of 60 seconds will trigger notifications when lag exceeds that value.
A company is migrating on-premises PostgreSQL databases to Cloud SQL. They need to minimize downtime and ensure data consistency. Which THREE steps should they follow? (Choose 3)
Correct. DMS supports homogeneous PostgreSQL migrations with minimal downtime.
Why this answer
A typical migration uses Database Migration Service (DMS) with continuous replication for minimal downtime. Setting up replication and then promoting the Cloud SQL instance is standard.
You are monitoring Cloud Bigtable replication lag. Which metric should you use to determine if replicas are up to date, and what consistency level is typical for Bigtable replication?
Bigtable replication is asynchronous and eventually consistent; the 'replication_lag' metric measures the delay.
A company needs to store petabytes of time-series IoT sensor data and query it with single-digit millisecond latency at millions of reads per second. The data has a simple key-value structure with timestamps. Which Google Cloud database is MOST appropriate?
Bigtable is the correct choice: wide-column NoSQL, designed for time-series and IoT workloads, single-digit ms latency, and scales to millions of QPS with additional nodes.
Why this answer
Cloud Bigtable is designed for exactly this use case — petabyte-scale, low-latency (single-digit ms), high-throughput NoSQL storage for time-series, IoT, and financial data. It scales horizontally by adding nodes. BigQuery is optimised for analytics (seconds-to-minutes latency), Cloud SQL is for OLTP (limited to tens of thousands of QPS), and Firestore is for document data with hierarchical structure.
A Cloud SQL for MySQL instance is running low on disk space. You have enabled automatic storage increase, but you also want to be proactively alerted when disk usage exceeds 80%. Which steps should you take?
This is the correct way to get an alert when disk usage exceeds 80%.
Why this answer
Cloud Monitoring allows you to create alerting policies based on metrics. The disk usage metric for Cloud SQL is available, and you can set a threshold of 80%. Automatic storage increase is a separate setting that automatically increases storage when needed.
A startup is building a mobile application and needs a real-time database that automatically scales to handle sudden spikes in user traffic. They want to minimise operational overhead and only pay for the resources they use. Which Google Cloud database should they choose?
Firestore is serverless, auto-scaling, and pay-per-use, ideal for mobile apps.
Why this answer
Firestore is a fully managed, serverless NoSQL document database that automatically scales horizontally to handle sudden traffic spikes without manual intervention. It offers real-time data synchronization via listeners, and its pay-per-use billing model aligns with the startup's requirement to minimize operational overhead and only pay for consumed resources.
Exam trap
A common misconception is that Cloud Spanner is always the best scalable database, but candidates overlook that Spanner requires provisioned capacity and is not serverless, while Firestore's auto-scaling and pay-per-use model directly address the startup's requirements for minimizing operational overhead and handling sudden spikes.
How to eliminate wrong answers
Option B is wrong because Cloud Spanner is a globally distributed, strongly consistent relational database designed for high-throughput OLTP workloads, but it requires upfront capacity planning and incurs costs for provisioned nodes, not a pay-per-use model, making it unsuitable for a startup wanting to minimize overhead and pay only for usage. Option C is wrong because Cloud SQL is a managed relational database (MySQL, PostgreSQL, SQL Server) that does not auto-scale for sudden spikes; it requires manual or scheduled scaling of read replicas and has a fixed instance size billing model, not a consumption-based model. Option D is wrong because Cloud Bigtable is a wide-column NoSQL database optimized for large-scale analytical and operational workloads (e.g., time-series, IoT) with high throughput, but it requires manual cluster sizing and pays for provisioned nodes per hour, not a serverless pay-per-use model, and lacks real-time data synchronization features.
A developer is setting up a Memorystore for Redis instance and needs to restrict access to only a specific Compute Engine VM in the same VPC network. Which configuration should they use?
Correct. Firewall rules can be applied to the VPC to restrict inbound traffic to the Memorystore instance's IP range from only the VM's IP.
Why this answer
Memorystore for Redis uses Private Service Access and requires authorizing a VPC network to access the instance. After authorizing the VPC network, you can restrict access to a specific Compute Engine VM by applying a firewall rule in that VPC that allows traffic from only that VM's internal IP to the Memorystore instance. This is the most granular control available without using additional authentication like AUTH.
You are designing a disaster recovery plan for a Cloud Bigtable instance. The instance has a single cluster in us-east1. You need to ensure that if the cluster becomes unavailable, the database can still serve read and write requests with minimal downtime. Which THREE steps should you take? (Choose three.)
Bigtable replication is asynchronous, so occasional stale reads are possible.
Why this answer
Cloud Bigtable uses eventual consistency for replication across clusters. When you add a second cluster and enable replication, data is replicated asynchronously, so writes to one cluster are not immediately visible in the other. The application must be designed to handle eventual consistency to avoid reading stale data after a failover.
Option C is correct: adding a second cluster in a different zone (within the same region or a different region) and enabling replication provides redundancy. If the primary cluster fails, the secondary cluster can serve requests. Option D is correct: the application must be configured to route traffic to the secondary cluster in case of primary failure.
This can be achieved by using Cloud Bigtable's built-in failover mechanism or by implementing client-side routing logic. Without this routing, traffic would still be directed to the failed primary cluster, causing downtime.
Exam trap
Google Cloud often tests the misconception that synchronous replication is available in Cloud Bigtable, but the service only supports asynchronous replication. Candidates may also incorrectly think that daily backups are sufficient for high availability instead of using multi-cluster replication.
Your Cloud Bigtable instance is experiencing high latency for certain row key ranges. You suspect a hotspot is developing. Which Google Cloud tool should you use to visualize and diagnose the hotspot?
Key Visualiser is the correct tool for detecting hotspots in Bigtable.
Why this answer
Key Visualiser is a tool specifically designed for Bigtable to identify hotspots and access patterns by visualizing row key distribution and traffic. It helps pinpoint uneven load distribution.
A company is using Cloud Spanner and wants to back up a database to Cloud Storage for long-term retention. They also need to restore the database to a specific point in time within the last 7 days. Which two features should they use? (Choose TWO.)
Spanner allows restoring to a specific time within the retention period.
Why this answer
Spanner supports creating backups and restoring from them. Backups can be stored in Cloud Storage (as part of the backup process) and can be used for point-in-time recovery within a configurable retention period (up to 7 days by default).
A Cloud SQL for PostgreSQL instance is running low on disk space. The database size is 500 GB and the current storage is 600 GB. The engineer needs to increase storage to 800 GB without downtime. What should they do?
The patch command can increase storage online without downtime.
Why this answer
Cloud SQL for PostgreSQL supports online storage increases using the `gcloud sql instances patch` command, which resizes the disk without requiring an instance restart or downtime. The storage can be increased up to the maximum allowed for the instance tier, and the change takes effect immediately while the instance remains available.
Exam trap
A common mistake in Google exams is to assume that storage changes require downtime. In Cloud SQL, storage can be increased online using the gcloud command, so choosing the shutdown option (A) is incorrect.
How to eliminate wrong answers
Option A is wrong because shutting down the instance causes downtime, which violates the requirement for zero downtime; Cloud SQL allows storage increases without stopping the instance. Option C is wrong because creating a new instance and migrating with pg_dump involves significant downtime during the dump and restore process, and is unnecessarily complex when a simple online resize is available. Option D is wrong because auto-storage increase only triggers when storage usage reaches a threshold (typically 90% or more), and it increases storage by a fixed increment (e.g., 10 GB or 15% of current size), not to a specific target like 800 GB; it also may not activate immediately and does not guarantee the exact desired size.
A Memorystore for Redis instance is running out of memory. The application uses Redis as a cache with key expiration. You want to prevent data loss for keys that have not reached their TTL. Which eviction policy should you configure?
volatile-lru evicts keys with an expire set (TTL) using LRU, preserving keys without TTL. This prevents data loss for keys that have no TTL.
A company wants to monitor Cloud SQL database latency for read replicas and set up an alert if the replica lag exceeds 30 seconds. Which metric should be used?
This metric directly reports the lag in seconds.
Why this answer
The 'replication_lag' metric in Cloud SQL measures the lag between primary and read replica. It is the correct metric to set alerts for replica lag.
You are building a global application that requires strong consistency across regions. The application needs to support SQL queries and horizontal scaling. Which database service should you choose?
Spanner provides global strong consistency, SQL support, and automatic horizontal scaling across regions.
A developer needs to connect to a Memorystore for Redis instance from a Compute Engine VM in the same VPC network. The Redis instance has AUTH enabled. What must the developer provide in the connection string?
AUTH requires a password to access the instance.
Why this answer
When AUTH is enabled on a Memorystore for Redis instance, the client must provide the AUTH password in the connection string (e.g., `redis://:password@host:6379`) or via the `AUTH` command after connecting. This password is set during instance creation and is required for authentication before any data commands can be executed. Without it, the Redis server will reject the connection with a `NOAUTH Authentication required` error.
Exam trap
A common pitfall is selecting an IAM role (e.g., Memorystore User) instead of the Redis AUTH password because both are authentication mechanisms, but they operate at different layers: IAM controls access to the API, while AUTH controls data-plane access to Redis.
How to eliminate wrong answers
Option B is wrong because Memorystore for Redis does not use IAM roles for authentication; IAM is used for control-plane access (e.g., creating instances), not for data-plane Redis connections. Option C is wrong because Memorystore for Redis does not support TLS client certificate authentication by default; it uses AUTH password or, if in-transit encryption is enabled, server-side TLS with optional client certificates, but the question specifies AUTH enabled, not TLS. Option D is wrong because service account key files are used for authenticating Google Cloud API calls (e.g., via gcloud or client libraries), not for Redis protocol-level authentication.
A company uses Memorystore for Redis and wants to ensure data is preserved in case of a node failure. They cannot afford any data loss. What should they do?
Enabling AOF persistence (or RDB) ensures that writes are written to disk and can survive a node failure. With appropriate fsync settings, data loss is minimal or zero.
Why this answer
To guarantee no data loss during a node failure, Memorystore for Redis should have persistence enabled. Standard Tier instances support both RDB and AOF persistence. AOF persistence, especially with an fsync policy of 'always' or 'everysec', ensures that writes are durably stored, minimizing data loss to at most one second.
Periodic exports to Cloud Storage are backups that occur at scheduled intervals, so any data written between the last export and the failure would be lost, violating the zero-data-loss requirement. Increasing maxmemory only controls eviction, not durability. Cross-region replication provides high availability but does not persist data to disk on its own and can lose recently written data due to replication lag.
A company uses Cloud Spanner and needs to capture real-time changes from a table for downstream processing. They want to avoid writing custom application code to track changes. Which THREE components should they use? (Choose three.)
Change Streams can publish to Pub/Sub for downstream consumption.
Why this answer
Cloud Spanner Change Streams (option C) capture real-time changes (inserts, updates, deletes) from a table. These changes are automatically published to a Pub/Sub topic (option B). A subscriber can then use Dataflow (option E) to process the change stream messages for downstream transformations or loading.
Cloud Bigtable (option A) is a different database service not involved in this scenario. The Cloud Spanner API (option D) is not needed because Change Streams already integrate with Pub/Sub.
An e-commerce application uses Firestore in Native mode. The team needs to run a query that filters on two fields and orders by a third field. What is the correct approach to ensure this query runs efficiently?
Composite indexes must be created manually for queries that filter on multiple fields and order by another.
Why this answer
Firestore requires a composite index for queries that filter on multiple fields and order by a different field, because single-field indexes cannot satisfy the combined filtering and ordering constraints. Creating a composite index on the three fields (the two filter fields and the order field) allows Firestore to efficiently execute the query without scanning all documents.
Exam trap
A common misconception is that single-field indexes are sufficient for multi-field queries, or that index exemptions can optimize queries, when in fact composite indexes are mandatory for such queries in Firestore.
How to eliminate wrong answers
Option B is wrong because automatic single-field indexes only support simple equality filters on one field or range filters on one field with an order on the same field; they cannot handle filtering on two fields and ordering by a third. Option C is wrong because an index exemption is used to exclude fields from automatic indexing, not to enable complex queries; it would prevent the query from running efficiently. Option D is wrong because switching to Datastore mode does not solve the indexing requirement—Datastore mode also requires composite indexes for similar multi-field queries, and the question specifies Firestore in Native mode, so changing modes is unnecessary and introduces other differences.
An organization needs to run a disaster recovery drill for its Cloud SQL for MySQL instance by promoting a read replica to a standalone instance. The replica is in the same region as the primary. After the drill, they want the original primary to resume serving writes. What should they do?
Promotion is irreversible; to restore replication, you must recreate the replica.
Why this answer
Promoting a read replica in Cloud SQL for MySQL breaks the replication link, making the replica a standalone primary. After the drill, you must delete the promoted replica and create a new read replica from the original primary to re-establish replication. This is the only supported method because Cloud SQL does not allow reversing the promotion or re-attaching a promoted instance as a replica.
Exam trap
The trap here is that candidates assume you can simply re-attach the promoted replica or use a failover command to reverse the roles, but Cloud SQL's architecture treats promotion as an irreversible operation that requires deleting and recreating the replica.
How to eliminate wrong answers
Option B is wrong because stopping replication does not make the original primary a replica; Cloud SQL does not support converting a primary into a replica of another instance. Option C is wrong because there is no gcloud command to switch roles between a primary and a replica; promotion is a one-way operation. Option D is wrong because performing a failover on the original primary would attempt to promote it again, but it is already the primary and failover is designed for high-availability configurations, not for reversing a replica promotion.
A company uses Bigtable for real-time analytics. They notice that writes to a specific row range are significantly slower. The Key Visualizer shows a hotspot. What is the most likely cause and recommended action?
A well-distributed row key spreads writes across tablet servers, eliminating hotspots.
Why this answer
Hotspots occur when a single tablet server is overloaded due to high write traffic to a contiguous key range. The solution is to redesign the row key to distribute writes.
A company runs a Memorystore for Redis cluster with standard tier (for replication). They need to ensure high durability of session data and be able to recover from a complete zone failure. Which three actions should they take? (Choose THREE.)
Exports can be done via the gcloud redis instances export command (or using the console) to create backups in Cloud Storage.
Why this answer
To ensure high durability and recovery from a complete zone failure for a Memorystore for Redis cluster with standard tier (replication enabled): Option A: Regular exports to Cloud Storage provide point-in-time backups that can be restored in a different zone if needed. Option B: Cross-region replication creates a replica in another region, allowing failover if the primary zone fails. Option E: Setting up a second instance in a different zone with client-side replication allows the application to switch to the replica if the primary zone fails.
Option C is incorrect because Redis Cluster with multiple shards is for horizontal scaling and does not inherently provide zone failure recovery or durability beyond what replication provides. Option D is incorrect because RDB persistence, while supported in Memorystore for Redis, only provides local recovery and does not protect against a complete zone failure; you need cross-zone or cross-region replication for that.
A company wants to use Cloud SQL for MySQL to serve a read-heavy application. They need to ensure high availability and offload read traffic. Which TWO steps should they take? (Choose two.)
Same-region read replicas offload read traffic and are low-latency.
Why this answer
To ensure high availability, create a Cloud SQL HA configuration (regional instance with standby). To offload read traffic, create read replicas. Cross-region replicas are for disaster recovery but add latency.
On-demand backups are for data protection, not availability. Auto-storage increase is for storage management.
Ready to test yourself?
Try a timed practice session using only Manage a solution that can span multiple database technologies questions.