Courseiva

Google Professional Cloud Database Engineer (PCDE) — Questions 751–825

1446 questions total · 20pages · All types, answers revealed

Take a mock examExam hub
Page 10

Page 11 of 20

Page 12
751
Multi-Selecthard

An organization is migrating a 500 GB Oracle database to Cloud SQL for PostgreSQL using DMS with continuous CDC. The migration is in progress, and the team needs to ensure that if the migration fails, they can roll back with minimal data loss. Which two pre-migration steps should they take? (Choose 2)

Select 2 answers
A.Take a full backup of the source database before starting the migration.
B.Export the Cloud SQL for PostgreSQL schema before migration.
C.Configure DMS to allow writes to the source after promotion.
D.Set up an Oracle Data Guard replica on-premises.
E.Keep the source Oracle database running and accepting writes until cutover.
AnswersA, E

Backup ensures point-in-time recovery for rollback.

Why this answer

A rollback plan should include keeping the source running (read-only during cutover) and taking a full backup before migration. Exporting from the target is not helpful for rollback. Setting up a replica on-premises is unnecessary.

Full explanation →
752
Multi-Selecthard

In Cloud Spanner, which TWO strategies can help reduce read latency for globally distributed applications?

Select 2 answers
A.Enable follower reads
B.Use stale reads
C.Use a multi-region configuration with a default leader
D.Use database partitioning
E.Increase the number of nodes
AnswersA, B

Follower reads can serve reads from the nearest replica.

Why this answer

Follower reads allow read requests to be served by any replica in a Cloud Spanner multi-region configuration, not just the leader replica. This reduces read latency by enabling reads to be processed from a replica that is geographically closer to the client, without incurring the round-trip time to the leader. Follower reads are particularly effective for globally distributed applications where read consistency can be slightly relaxed.

Exam trap

Google Cloud often tests the misconception that any multi-region configuration automatically reduces read latency, when in fact you must explicitly enable follower reads or stale reads to avoid routing reads to the leader replica.

Full explanation →
753
MCQhard

A financial company uses Cloud SQL for PostgreSQL to store transaction data. They need to create a materialized view that aggregates daily sales for a BI dashboard. The underlying transaction table is updated continuously. Which approach ensures the materialized view remains up to date without manual intervention?

A.Use BigQuery federated query to directly query the Cloud SQL table
B.Use a Cloud SQL read replica and create the materialized view on the replica
C.Schedule a Cloud Function via Cloud Scheduler to run REFRESH MATERIALIZED VIEW periodically
D.Add a trigger on the base table to refresh the materialized view on each update
AnswerC

This provides automated periodic refreshes without manual effort.

Why this answer

Cloud SQL for PostgreSQL does not support automatic materialized view refresh. The only way to keep a materialized view up to date without manual intervention is to schedule a periodic refresh using Cloud Scheduler to invoke a Cloud Function that executes the REFRESH MATERIALIZED VIEW command. This approach balances freshness with resource cost, as refreshing on every transaction would be too expensive.

Exam trap

Google Cloud often tests the misconception that materialized views in PostgreSQL can be automatically refreshed via triggers or that read replicas support materialized view creation, leading candidates to pick options that ignore the fundamental write-lock and replication limitations of Cloud SQL for PostgreSQL.

How to eliminate wrong answers

Option A is wrong because BigQuery federated queries read the Cloud SQL table directly without creating a materialized view, so they do not provide the pre-aggregated, fast-query performance that a materialized view offers, and they still incur query-time overhead. Option B is wrong because a Cloud SQL read replica is a read-only copy of the database; you cannot create a materialized view on a replica because PostgreSQL does not support materialized views on replicas (they require write access to store the view data). Option D is wrong because adding a trigger to refresh the materialized view on each update would cause severe performance degradation and is not supported in Cloud SQL for PostgreSQL—triggers cannot execute REFRESH MATERIALIZED VIEW directly, and even if they could, the overhead of refreshing on every row change would be prohibitive.

Full explanation →
754
MCQhard

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?

A.gcloud sql instances patch my-instance --storage-size 250GB
B.gcloud sql instances patch my-instance --storage-size 250
C.gcloud sql instances update my-instance --storage-size 250
D.gcloud sql instances resize my-instance 250
AnswerB

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.

Full explanation →
755
MCQmedium

You are running a Memorystore for Redis instance with a high write volume. You notice that the eviction rate is high and the cache hit ratio has dropped significantly. Which configuration change would most directly reduce the eviction rate?

A.Use many small keys instead of a few large keys.
B.Decrease the maxmemory setting to force earlier eviction.
C.Set maxmemory-policy to noeviction.
D.Change maxmemory-policy to allkeys-lru.
AnswerD

LRU eviction removes least recently used keys, which can improve cache efficiency.

Why this answer

Setting `maxmemory-policy` to `allkeys-lru` tells Redis to evict the least recently used keys from the entire keyspace when memory is full. This directly reduces the eviction rate by ensuring that only the least accessed data is removed, preserving the most frequently accessed data and improving the cache hit ratio. In a high-write-volume scenario, this policy adapts to access patterns and minimizes unnecessary evictions of hot data.

Exam trap

The trap here is that candidates often confuse 'reducing eviction rate' with 'preventing eviction entirely' and choose `noeviction`, not realizing that `noeviction` causes write failures instead of reducing evictions, while `allkeys-lru` actively manages memory to keep evictions low by targeting only cold keys. In Google Cloud Memorystore for Redis, `allkeys-lru` is the recommended policy for high-write workloads to maintain a healthy cache hit ratio.

How to eliminate wrong answers

Option A is wrong because using many small keys instead of a few large keys does not reduce the eviction rate; it may actually increase memory overhead due to per-key metadata and does not address the root cause of memory pressure. Option B is wrong because decreasing the `maxmemory` setting forces earlier eviction, which would increase the eviction rate, not reduce it. Option C is wrong because setting `maxmemory-policy` to `noeviction` prevents any eviction, causing write operations to fail with an OOM error when memory is full, which does not reduce the eviction rate but instead breaks the application.

Full explanation →
756
MCQeasy

A financial BI application stores monetary values such as revenue and tax amounts. Which BigQuery data type should be used to ensure accuracy in calculations?

A.Use STRING and parse numbers as needed
B.Use INT64 and store amounts in cents
C.Use FLOAT64
D.Use NUMERIC or BIGNUMERIC
AnswerD

Exact numeric types guarantee precision for decimals, essential for financial data.

Why this answer

NUMERIC and BIGNUMERIC are exact numeric types with fixed precision and scale, designed to avoid floating-point rounding errors. In BigQuery, monetary calculations require exact decimal arithmetic, and these types provide up to 38 (NUMERIC) or 76 (BIGNUMERIC) digits of precision, ensuring accuracy for revenue and tax computations.

Exam trap

Google Cloud often tests the misconception that FLOAT64 is acceptable for financial data because it handles decimals, but the trap is that floating-point arithmetic is inherently imprecise for exact monetary calculations, leading to subtle rounding errors that fail audit requirements.

How to eliminate wrong answers

Option A is wrong because storing monetary values as STRING forces parsing on every query, introduces conversion overhead, and loses the ability to perform direct arithmetic operations without explicit casting, which is inefficient and error-prone. Option B is wrong because storing amounts in cents as INT64, while avoiding floating-point issues, requires manual scaling and can overflow for large values (e.g., billions of dollars in cents exceed INT64 max of ~9.2e18) and complicates tax calculations involving fractions of a cent. Option C is wrong because FLOAT64 is a floating-point type that introduces binary rounding errors (e.g., 0.1 + 0.2 != 0.3), which can cause cumulative inaccuracies in financial calculations and violate accounting standards.

Full explanation →
757
Drag & Dropmedium

Order the steps to perform a disaster recovery drill for a Cloud Spanner database using backups.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

The correct sequence for a Cloud Spanner disaster recovery drill using backups is: first create a backup, then restore it to another region. After restoration, verify data integrity, then update application configurations to point to the restored database, and finally test the application to ensure failover works. This order ensures data consistency and minimizes risk.

Full explanation →
758
MCQmedium

A global e-commerce platform expects 50,000 concurrent users during flash sales, each performing short transactions like adding to cart and checking out. The database must provide strong transactional consistency across regions. Which Google Cloud database is most appropriate?

A.Cloud Bigtable
B.Cloud Spanner
C.Firestore
D.Cloud SQL (MySQL)
AnswerB

Spanner provides global distribution, strong consistency, and ACID transactions, making it ideal for high-concurrency OLTP across regions.

Why this answer

Cloud Spanner is a globally distributed, strongly consistent relational database that can handle high-concurrency OLTP workloads with ACID transactions across regions. Cloud SQL is limited to single region and cannot meet global consistency requirements. Bigtable and Firestore are NoSQL and do not support strong ACID transactions natively.

Full explanation →
759
Multi-Selecthard

Which THREE methods are effective for improving query performance in BigQuery for BI workloads?

Select 3 answers
A.Clustering on frequently filtered columns
B.Replacing joins with subqueries
C.Partitioning on a date column
D.Using SELECT * in queries
E.Using pre-aggregated summary tables
AnswersA, C, E

Clustering allows BigQuery to skip reading blocks that don't match filter conditions.

Why this answer

Clustering on frequently filtered columns physically co-locates related data within blocks, significantly reducing the amount of data scanned for queries with filter predicates. This is especially effective for BI workloads that often filter on high-cardinality columns like customer ID or transaction type, as it avoids full table scans and improves query performance without additional storage costs.

Exam trap

Google Cloud often tests the misconception that subqueries are always more efficient than joins, but in BigQuery, joins are optimized for distributed processing while subqueries can cause performance degradation due to lack of parallelism.

Full explanation →
760
Multi-Selectmedium

A Cloud SQL for PostgreSQL instance is experiencing high replication lag between primary and read replica. Which TWO actions would reduce the lag?

Select 2 answers
A.Reduce the value of `max_wal_size`.
B.Increase the replica's machine size.
C.Place the replica in the same zone as the primary.
D.Use a higher number of read replicas.
E.Enable synchronous replication.
AnswersB, C

More CPU and memory on the replica help it apply WAL more quickly, reducing lag.

Why this answer

Increasing the replica's machine size (Option B) reduces replication lag by providing more CPU and memory resources to apply WAL changes faster. Placing the replica in the same zone as the primary (Option C) minimizes network latency between the instances, which directly reduces the time for WAL data to travel from primary to replica, thus lowering lag.

Exam trap

A common misconception is that reducing `max_wal_size` or adding more replicas will reduce replication lag. In Cloud SQL for PostgreSQL, reducing `max_wal_size` can cause more frequent WAL segment switches, potentially increasing I/O and lag. Adding more replicas does not speed up apply on the existing replica; it may even increase load on the primary.

The correct approaches are to increase replica resources or reduce network latency.

Full explanation →
761
Multi-Selectmedium

A DevOps team needs to set up alerting for a critical application that runs on Compute Engine. They want to be notified if the application process crashes (i.e., stops sending heartbeats) for more than 5 minutes. The application emits a custom metric 'app_heartbeat' as a GAUGE with value 1 every 60 seconds. Which TWO configurations should they use? (Choose 2)

Select 2 answers
A.Alignment period: 60 seconds
B.Duration: 5 minutes
C.Metric threshold condition: threshold < 1
D.Reducer: MEAN
E.Metric absent condition: for 'app_heartbeat' metric
AnswersB, E

The duration for which the metric must be absent (or condition met) before alerting.

Why this answer

To detect a crash, you need a metric absent condition (no data for 5 minutes) because the gauge value will stop reporting. Setting the duration to 5 minutes ensures timely notification. A threshold condition on the gauge value would not trigger if the value stays at 1.

The alignment period and reducer are not relevant for absent conditions.

Full explanation →
762
Multi-Selecthard

Which THREE techniques can improve query performance in BigQuery for BI workloads? (Choose three.)

Select 3 answers
A.Use approximate aggregation functions when exact results are not required.
B.Avoid SELECT * in production queries; select only needed columns.
C.Use SELECT * with LIMIT to preview data.
D.Use ORDER BY on large result sets without LIMIT.
E.Cluster the table on columns frequently used in WHERE clauses.
AnswersA, B, E

Approximate functions use less memory and are faster.

Why this answer

Approximate aggregation functions (Option A) improve performance by using algorithms like HyperLogLog++ to return near-exact results with lower resource consumption. Selecting only needed columns (Option B) reduces the amount of data scanned, lowering query costs and improving speed. Clustering tables on columns used in WHERE clauses (Option E) enables better data pruning and reduces the amount of data processed.

These three techniques are commonly tested in the Google Cloud Professional Data Engineer exam as performance optimizations for BI workloads.

Exam trap

Google Cloud often tests the misconception that SELECT * with LIMIT is a performance optimization, when in fact it still incurs full column scan costs, and that ORDER BY without LIMIT is acceptable for large datasets, ignoring BigQuery's requirement for a LIMIT clause to enable distributed sorting.

Full explanation →
763
MCQhard

A company uses Terraform with remote state stored in GCS. They want to prevent concurrent `terraform apply` runs for the same configuration to avoid state corruption. Which feature should they use?

A.Set the `-lock` flag to `true` in the Terraform CLI command.
B.Enable state locking in the GCS bucket by setting `force_destroy = false`.
C.Use Terraform workspaces to isolate runs.
D.State locking is automatically enabled when using a GCS backend; no additional configuration is needed.
AnswerD

GCS backend supports native state locking.

Why this answer

Terraform state locking is automatically enabled when using a backend that supports it, like GCS. GCS uses object versioning and a lock file to prevent concurrent modifications. Workspaces and remote execution are unrelated to locking.

Full explanation →
764
Multi-Selecthard

A financial services company needs to design a BigQuery data model for real-time fraud detection. Data arrives from multiple streaming sources and must be joined with historical customer profiles (10 TB) and transaction lookup tables (500 GB). Which TWO design considerations are most important to minimize query latency and cost?

Select 2 answers
A.Use time-based partitioning on the historical customer table and cluster on customer_id.
B.Partition streaming data by ingestion time and cluster by customer_id and transaction_type.
C.Schedule a nightly script to recluster tables based on query patterns.
D.Use a single table for all streaming data without partitioning to avoid partition management overhead.
E.Denormalize all historical and lookup data into a single wide table.
AnswersA, B

Time-based partitioning reduces scan for recent customers, and clustering on join key speeds up the join.

Why this answer

Time-based partitioning on the historical customer table (10 TB) allows BigQuery to prune irrelevant partitions during queries, reducing the amount of data scanned and thus lowering cost and latency. Clustering on customer_id further optimizes joins with streaming data by colocating related rows, minimizing shuffle overhead.

Exam trap

Google Cloud often tests the misconception that manual reclustering is required for performance, when in fact BigQuery's automatic reclustering handles it transparently, and that denormalization is always beneficial for joins, ignoring the storage and maintenance costs in large-scale systems.

Full explanation →
765
MCQmedium

You want to visualize the 99th percentile latency of a service on a dashboard. The metric is a distribution metric. Which reducer should you use in the chart configuration?

A.MEAN
B.SUM
C.99TH_PERCENTILE
D.COUNT
AnswerC

This reducer computes the 99th percentile.

Why this answer

The 99th percentile is a specific percentile, not a simple aggregation like MEAN, SUM, or COUNT. Cloud Monitoring charts can use percentile reducers. Among the options, '99TH_PERCENTILE' is the correct one.

Full explanation →
766
MCQhard

A company uses Cloud Spanner for a global application. They notice high write latency and occasional hotspotting on a table with a monotonically increasing integer primary key. Which schema design change would best prevent hotspotting while maintaining read performance?

A.Use a UUID as the primary key.
B.Create an interleaved table with the primary key as the parent.
C.Add a secondary index on the primary key.
D.Use bit-reversed indexes for the primary key.
AnswerD

Bit-reversed indexes spread sequential keys across the key space, avoiding hotspotting on a single split.

Why this answer

Using a hash prefix of the primary key distributes writes across different splits, preventing hotspots. UUIDs also work, but bit-reverse is better for sequential keys. Interleaved tables do not help with hotspotting.

Full explanation →
767
MCQhard

A company is migrating an on-premise PostgreSQL database to Cloud SQL. The current database has a connection pool with 200 connections and uses 64 GB RAM. According to Cloud SQL best practices, what is the maximum recommended max_connections setting?

A.200
B.64
C.4096
D.1024
AnswerC

64 GB RAM = 65536 MB, divided by 16 gives 4096 connections.

Why this answer

The formula for max_connections on Cloud SQL is RAM_MB / 16. 64 GB = 65536 MB. 65536 / 16 = 4096. However, the question asks for the maximum recommended setting based on RAM. Note: This formula is for Cloud SQL; the actual max_connections default may vary, but the formula is a best practice guide.

Full explanation →
768
MCQmedium

During an incident, the incident commander delegates tasks to multiple teams. Which communication model is MOST effective to reduce noise?

A.Use email for updates to avoid real-time noise.
B.Use a single incident channel where all teams post updates.
C.Each team communicates in separate channels.
D.All updates go through the incident commander only.
AnswerB

A single channel ensures everyone sees updates and reduces cross-talk.

Why this answer

The recommended approach is to use a single communication channel (e.g., a dedicated chat room) for all incident-related updates, and the incident commander coordinates via that channel.

Full explanation →
769
MCQeasy

A DevOps engineer wants to create a dashboard that shows the number of 5xx errors per service over time. The errors are logged in Cloud Logging. What is the most efficient way to create this dashboard?

A.Create a log-based counter metric for 5xx errors, then add a chart in Cloud Monitoring using that metric.
B.Write a custom application that sends the error count to Cloud Monitoring as a custom metric via API.
C.Export logs to BigQuery and use Data Studio to create a dashboard.
D.Use Cloud Logging's metrics explorer to create a chart and embed it in a dashboard.
AnswerA

Log-based metrics are efficient and can be used in dashboards directly.

Why this answer

First, create a log-based metric that counts log entries with severity ERROR and status code 5xx. Then, in Cloud Monitoring, create a dashboard with a chart using that metric, grouped by service. This avoids querying logs directly and provides a reusable metric.

Full explanation →
770
MCQeasy

A company needs to run complex analytical queries on large datasets (petabytes) with SQL support and high scalability. The data is stored in CSV files in Cloud Storage. Which Google Cloud service is MOST suitable?

A.BigQuery
B.Cloud Bigtable
C.Cloud SQL
D.Cloud Spanner
AnswerA

BigQuery is the correct service for large-scale analytical queries with SQL.

Why this answer

BigQuery is a serverless, highly scalable, and cost-effective data warehouse designed for running analytical queries on large datasets. It can query data directly in Cloud Storage using external tables.

Full explanation →
771
MCQmedium

A DBA notices high query cache lock contention on this Cloud SQL for MySQL instance. Which configuration change should be recommended?

A.Set query_cache_type=0
B.Decrease max_connections
C.Increase innodb_buffer_pool_size
D.Increase query_cache_size
AnswerA

Disabling query cache removes lock contention entirely.

Why this answer

Query cache lock contention occurs when multiple threads try to access the query cache simultaneously, causing serialization. Setting `query_cache_type=0` disables the query cache entirely, eliminating the lock contention. This is the recommended fix because MySQL 8.0 deprecated the query cache due to scalability issues, and Cloud SQL for MySQL instances benefit from removing this bottleneck.

Exam trap

Google Cloud often tests the misconception that increasing the size of a cache or buffer always improves performance, but here increasing `query_cache_size` exacerbates lock contention, making the problem worse.

How to eliminate wrong answers

Option B is wrong because decreasing `max_connections` reduces the number of concurrent connections but does not address the internal locking mechanism of the query cache; contention is a lock-level issue, not a connection-level one. Option C is wrong because increasing `innodb_buffer_pool_size` improves InnoDB data caching and reduces disk I/O, but it does not affect query cache locks, which are a separate memory structure. Option D is wrong because increasing `query_cache_size` only allocates more memory to the query cache, which can actually worsen contention by increasing the time spent scanning or invalidating cache entries under high concurrency.

Full explanation →
772
MCQmedium

Your Bigtable cluster is showing high read latency for row key lookups. The application accesses rows with keys in the format 'user_id#timestamp'. You notice that most reads are for recent timestamps. Which optimization should you implement?

A.Increase the number of nodes in the cluster
B.Reverse the row key order to start with the timestamp
C.Configure single cluster routing to reduce cross-cluster latency
D.Use a scan with a prefix filter instead of point reads
AnswerB

This distributes recent writes/reads across tablet servers.

Why this answer

High read latency for recent timestamps occurs because Bigtable stores rows in lexicographic order by row key. With the format 'user_id#timestamp', older timestamps appear first, causing recent data to be scattered across tablets and requiring more seeks. Reversing the row key to start with the timestamp (e.g., 'timestamp#user_id') groups recent data together in contiguous tablets, enabling faster point lookups and reducing latency.

Exam trap

Google Cloud often tests the misconception that scaling nodes (Option A) solves all performance issues, but the trap here is that row key design directly impacts data locality and latency, making key ordering the primary optimization for time-based access patterns.

How to eliminate wrong answers

Option A is wrong because increasing nodes improves throughput and load distribution but does not address the root cause of scattered recent data due to row key ordering; it may even increase latency due to additional network hops. Option C is wrong because single cluster routing reduces cross-cluster latency in multi-cluster setups, but the question does not mention multiple clusters; the latency issue is within a single cluster due to row key design. Option D is wrong because using a scan with a prefix filter is less efficient than point reads for known row keys; it scans unnecessary rows and increases latency, whereas the goal is to optimize point lookups for recent timestamps.

Full explanation →
773
MCQhard

A company uses Cloud Bigtable for their analytics pipeline. They set up replication with a primary cluster in us-central1 and a secondary in us-west1. They notice that during normal operation, queries always hit the primary cluster even if the secondary is closer. What should they change to route queries to the nearest cluster automatically?

A.Change the app profile routing policy to any-replica
B.Implement client-side logic to choose which cluster to query
C.Modify the primary cluster to be in us-west1
D.Update the app profile to use read-failover routing
AnswerA

any-replica routing sends queries to the closest cluster, reducing latency.

Why this answer

The default routing policy for Bigtable replication is single-cluster (to the primary). To route to the nearest healthy cluster, they need to enable the any-replica routing policy in their Bigtable app profile. read-failover is for DR failover, not for normal operations. Changing the primary cluster does not solve the routing issue.

Client-side logic is an option but not a built-in solution.

Full explanation →
774
Matchingmedium

Match each Cloud SQL high-availability feature to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Synchronous replication across two zones

Standby instance in a different zone for automatic failover

Asynchronous replica for read offloading

Promotion of standby on primary failure

Point-in-time recovery and disaster recovery

Why these pairings

Automatic failover switches to a standby zone on failure, read replicas provide read-only copies for scaling, and point-in-time recovery allows restoring to any time within retention. Common confusions mix automatic failover with read replicas.

Full explanation →
775
MCQeasy

An engineering team wants to automatically build a Docker image every time a developer pushes code to the main branch of their GitHub repository. They are using Cloud Build. Which configuration should they use?

A.Cloud Build trigger with manual invocation
B.Cloud Build trigger with push event and branch pattern 'main'
C.Cloud Build trigger with scheduled event
D.Cloud Build trigger with pull request event
AnswerB

This is the correct way to trigger builds on push to main branch.

Why this answer

Cloud Build build triggers can be configured to respond to push events on a branch. The trigger is created in the Cloud Console or via gcloud and specifies the repository and branch pattern.

Full explanation →
776
MCQhard

The query above fails with 'Resources exceeded: UDF out of memory' on a large table. What is the best way to fix this?

A.Rewrite the function as a SQL UDF to avoid JavaScript overhead
B.Add a GROUP BY clause to reduce the number of rows processed
C.Convert the temporary UDF to a persistent UDF
D.Increase the memory allocation for JavaScript UDFs
AnswerA

SQL UDFs run natively in BigQuery's execution engine and do not have the same memory constraints.

Why this answer

JavaScript UDFs in BigQuery run in a sandbox with limited memory (typically 6 MB per UDF instance). When processing a large table, the UDF may exceed this memory due to per-row overhead or large intermediate results. Rewriting the function as a SQL UDF eliminates JavaScript overhead and runs natively within BigQuery's distributed execution engine, which can handle larger datasets without memory constraints.

Exam trap

Google Cloud often tests the misconception that memory errors in UDFs can be fixed by increasing resources or changing UDF persistence, when the real limitation is the fixed JavaScript sandbox memory that can only be avoided by using SQL UDFs.

How to eliminate wrong answers

Option B is wrong because adding a GROUP BY clause does not reduce the number of rows processed by the UDF; it only aggregates results after the UDF runs, so the memory issue persists. Option C is wrong because converting a temporary UDF to a persistent UDF does not change the execution environment or memory limits; both types of JavaScript UDFs share the same sandbox memory constraints. Option D is wrong because BigQuery does not allow users to increase memory allocation for JavaScript UDFs; the sandbox memory is fixed and cannot be adjusted.

Full explanation →
777
Multi-Selecteasy

A company is building a microservices architecture and needs to choose a database per service. Which THREE factors should they consider?

Select 3 answers
A.Consistency requirements
B.Preferred programming language
C.Expected query patterns
D.Data size and growth rate
E.Number of developers
AnswersA, C, D

Different services may need strong or eventual consistency, affecting database choice (e.g., Spanner vs. Bigtable).

Why this answer

Consistency requirements are critical because different databases offer varying consistency models (e.g., ACID vs. BASE). For example, a financial transaction service requiring strong consistency would need a relational database like PostgreSQL, while a social media feed could tolerate eventual consistency with a NoSQL database like Cassandra.

Choosing based on consistency ensures data integrity aligns with business needs.

Exam trap

Google Cloud often tests the misconception that programming language or team size should drive database choice, but the correct focus is on data-specific factors like consistency, query patterns, and scalability.

Full explanation →
778
MCQeasy

An engineer wants to trigger a Cloud Build pipeline whenever a new pull request(PR) is opened against the 'main' branch of a repository. Which type of build trigger should they configure?

A.Pull Request trigger
B.Manual trigger
C.Scheduled trigger (cron)
D.Push trigger on branch
AnswerA

Pull Request triggers automatically run builds when a PR is created or updated.

Why this answer

Cloud Build supports pull request triggers that automatically run a build when a PR is created or updated. This is specifically called a 'Pull Request' trigger.

Full explanation →
779
MCQhard

A BI team is designing a BigQuery table for a sales dashboard that queries daily sales by product category and region. The dashboard often filters on a specific date range and a specific region. Which combination of partitioning and clustering should be used?

A.Partition by region, cluster by date
B.Use only clustering on date and region without partitioning
C.Partition by date, cluster by region
D.Partition by month, cluster by date
AnswerC

Partitioning by date fine-tunes the scan to the date range; clustering by region organizes data to skip irrelevant blocks.

Why this answer

Partitioning by date (e.g., on a DATE or TIMESTAMP column) allows BigQuery to prune entire partitions when the dashboard filters on a specific date range, reducing the amount of data scanned. Clustering by region then sorts the data within each partition by region, enabling efficient block-level pruning when the dashboard filters on a specific region. This combination optimizes both the date range and region filters, which are the most common query patterns for this sales dashboard.

Exam trap

Google Cloud often tests the misconception that partitioning can be applied to any column type (like region) or that clustering alone is sufficient for date range filtering, leading candidates to overlook the mandatory requirement that partitioning must be on a DATE, TIMESTAMP, or integer column and that clustering complements but does not replace partitioning for range-based pruning.

How to eliminate wrong answers

Option A is wrong because partitioning by region is not supported in BigQuery (partitioning only supports DATE, TIMESTAMP, or integer columns, not string columns like region), and clustering by date would not provide the same pruning benefit for date range filters as partitioning by date does. Option B is wrong because using only clustering without partitioning means every query must scan all partitions (i.e., the entire table), even when filtering on a date range, leading to higher costs and slower performance compared to a partitioned table. Option D is wrong because partitioning by month is too coarse for a dashboard that often filters on a specific date range (e.g., a few days or weeks), resulting in scanning entire monthly partitions even when only a few days are needed, and clustering by date within a monthly partition is redundant since date is already the partition key.

Full explanation →
780
MCQmedium

An organization is migrating a MySQL database to Cloud SQL using DMS with continuous replication. After promoting the destination, they need a rollback plan. Which approach should they use to enable a quick rollback if issues arise?

A.Delete the source database immediately after promotion.
B.Take a snapshot of the source database before promotion.
C.Keep the source database running in read-only mode for a few days.
D.Enable binary logging on the Cloud SQL instance after promotion.
AnswerC

Read-only source allows validation and rollback if issues occur.

Why this answer

A rollback plan should keep the source database running but read-only for a validation window. This allows switching back if needed without data loss.

Full explanation →
781
MCQhard

Your organization uses Cloud SQL for PostgreSQL for a reporting application with read-heavy workloads. Queries are slow and you need to reduce load on the primary instance. You also need to ensure that all read queries from the reporting tool are isolated from the primary. What should you do?

A.Create a Cloud SQL read replica, and configure the reporting tool to connect to the replica's IP address.
B.Create a Cloud SQL clone and point the reporting tool to the clone.
C.Enable connection pooling using Cloud SQL Auth Proxy and PgBouncer on the primary instance.
D.Configure the reporting tool to use the primary instance with a lower priority.
AnswerA

Read replicas offload read traffic and isolate reporting queries from the primary.

Why this answer

Cloud SQL read replicas serve read traffic and offload the primary. For isolation, the reporting tool must connect to the replica's IP. Cloud SQL Auth Proxy is a secure tunnel, but does not provide connection pooling.

PgBouncer can be used with proxies for connection pooling, but the question asks for isolation, which is achieved by pointing the reporting tool to the replica. The best answer is to create a read replica and configure the reporting tool to connect to it.

Full explanation →
782
MCQhard

A company uses Cloud Build to build a multi-module Maven project. They want to run unit tests for module A and integration tests for module B in parallel. In cloudbuild.yaml, how should they configure the steps to run in parallel?

A.steps: - id: 'unit' waitFor: ['-'] ... - id: 'integration' waitFor: ['-'] ...
B.steps: - id: 'unit' ... - id: 'integration' waitFor: ['-'] ...
C.steps: - id: 'unit' waitFor: ['previous'] ... - id: 'integration' waitFor: ['unit'] ...
D.Steps run sequentially by default; parallelism is not supported.
AnswerA

Both steps with waitFor: ['-'] start simultaneously (parallel).

Why this answer

In Cloud Build, setting `waitFor: ['-']` on a step makes it start immediately without waiting for any other step, effectively allowing both the 'unit' and 'integration' steps to run in parallel. This configuration meets the requirement to run unit tests for module A and integration tests for module B concurrently.

Exam trap

The Google Cloud exam often tests the misconception that Cloud Build does not support parallelism or that `waitFor: ['-']` is only for the first step, leading candidates to choose sequential execution options or invalid syntax like `waitFor: ['previous']`.

How to eliminate wrong answers

Option B is wrong because the 'unit' step does not have `waitFor: ['-']`, so it will wait for the default previous step (if any) or run sequentially, preventing true parallelism. Option C is wrong because `waitFor: ['previous']` is not a valid Cloud Build syntax; the correct way to reference the previous step is by its ID, and here the 'integration' step waits for 'unit', forcing sequential execution. Option D is wrong because Cloud Build does support parallel execution by using `waitFor: ['-']` on multiple steps, so the claim that parallelism is not supported is incorrect.

Full explanation →
783
MCQmedium

A DevOps engineer is setting up CI/CD for a microservice application. They want to use Cloud Build to deploy to Google Kubernetes Engine (GKE) only if the build passes tests. Which Cloud Build configuration approach should they use?

A.Use two separate Cloud Build triggers: one for testing and one for deployment, and manually trigger the deployment after tests pass.
B.Create a cloudbuild.yaml with a test step that fails the build if tests fail, and a subsequent deploy step that runs only if all previous steps succeed.
C.Configure a single Cloud Build trigger that runs test and deploy steps in parallel.
D.Use Cloud Functions to orchestrate testing and deployment via separate Cloud Build API calls.
AnswerB

Cloud Build executes steps sequentially; if a step fails, the build fails and subsequent steps are skipped, ensuring only successful tests lead to deployment.

Why this answer

Cloud Build triggers can be configured to run a build config (cloudbuild.yaml) that includes steps for testing and deployment. Conditional deployment can be handled by the build steps themselves.

Full explanation →
784
MCQhard

A global gaming company uses Spanner to store player profiles and scores. The most common query is 'Get the top 10 players by score' across all regions. The 'Players' table has millions of rows. Which schema design and query approach provides the best performance?

A.Add a generated column storing the score as a string and index it.
B.Use a STORING clause to store additional columns in the index.
C.Use a parent-child interleaving between a 'Leaderboard' parent table and 'Players' child table.
D.Add a secondary index on score column and query 'SELECT * FROM Players ORDER BY score DESC LIMIT 10'.
AnswerD

The index allows the database to find the top 10 without scanning all rows.

Why this answer

A secondary index on the `score` column allows Spanner to perform an index scan in descending order, retrieving only the top 10 rows without scanning the entire `Players` table. The `ORDER BY score DESC LIMIT 10` query leverages the index's sorted structure, making it the most efficient approach for this common query pattern in a globally distributed database.

Exam trap

Many candidates mistakenly think that interleaving (Option C) is a universal performance solution, but it actually optimizes for hierarchical joins, not global top-N queries, leading candidates to overlook the simplicity and efficiency of a well-placed secondary index with `ORDER BY` and `LIMIT`.

How to eliminate wrong answers

Option A is wrong because storing the score as a string would require lexicographic sorting, which does not match numeric ordering and would produce incorrect results; additionally, indexing a string column does not improve performance for numeric range or top-N queries. Option B is wrong because a `STORING` clause in a secondary index stores extra columns to avoid fetching from the base table, but it does not change the fact that the index must still be scanned; the key performance issue is the index scan itself, not the column retrieval. Option C is wrong because parent-child interleaving is designed for hierarchical data access (e.g., retrieving all children of a parent), not for global top-N queries across all regions; interleaving would scatter the data across splits, making a full scan necessary.

Full explanation →
785
MCQmedium

A data engineer runs a BigQuery query that joins a large fact table with a small lookup table. The query processes 1 TB of data and takes 30 seconds. The engineer wants to reduce the amount of data processed. Which optimization technique is MOST effective?

A.Increase the number of slots available for the query.
B.Use a WITH clause to pre-filter the fact table before joining.
C.Cluster the lookup table on the join key.
D.Materialize the lookup table as a separate table with the same data.
AnswerB

Pre-filtering reduces the amount of data from the fact table that needs to be joined.

Why this answer

Pre-filtering the fact table with a WITH clause (CTE) reduces the amount of data scanned and processed before the join occurs. Since the fact table is large (1 TB), applying filters early minimizes the data shuffled and joined, directly reducing the bytes billed in BigQuery. This is a form of predicate pushdown that leverages BigQuery's columnar storage and dynamic query optimization.

Exam trap

The trap here is that candidates confuse query performance (speed) with data processed (cost), often choosing to increase slots (Option A) which only reduces elapsed time but does not lower the bytes billed.

How to eliminate wrong answers

Option A is wrong because increasing slots only speeds up query execution (reduces elapsed time) but does not reduce the amount of data processed; the query still scans 1 TB. Option C is wrong because clustering the lookup table on the join key improves join performance by reducing shuffle, but the lookup table is already small, so the impact on data processed is negligible; the bottleneck is the large fact table. Option D is wrong because materializing the lookup table as a separate table with the same data does not change the amount of data processed; it only duplicates storage without reducing the fact table scan.

Full explanation →
786
Multi-Selectmedium

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.)

Select 2 answers
A.Pub/Sub integration to consume change stream data
B.Cloud SQL for PostgreSQL logical replication
C.Datastream
D.Bigtable replication
E.Spanner change streams
AnswersA, E

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.

Full explanation →
787
MCQmedium

An organization uses Artifact Registry to store Docker images. They want to enforce that only images that have passed vulnerability scanning and are signed can be deployed to GKE. Which two services should they use together?

A.Cloud Deploy and Cloud Run
B.Cloud Build and Artifact Registry
C.Binary Authorization and Container Scanning API
D.Security Command Center and Cloud Asset Inventory
AnswerC

Binary Authorization enforces signing; Container Analysis provides vulnerability scanning.

Why this answer

Binary Authorization enforces that only signed and verified container images can be deployed to GKE, while the Container Scanning API (now part of Artifact Analysis) performs vulnerability scanning on images stored in Artifact Registry. Together, they ensure that only images that have passed vulnerability scanning and are cryptographically signed can be deployed, meeting the organization's requirements.

Exam trap

Google often tests the distinction between services that perform an action (like scanning or signing) versus services that enforce a policy based on that action, so candidates mistakenly pick Cloud Build and Artifact Registry (Option B) because they handle scanning and storage, but they lack the enforcement mechanism that Binary Authorization provides.

How to eliminate wrong answers

Option A is wrong because Cloud Deploy is a continuous delivery service for deploying to GKE, Cloud Run, or GKE clusters, but it does not enforce vulnerability scanning or image signing; Cloud Run is a serverless compute platform, not a security enforcement service. Option B is wrong because Cloud Build is a CI/CD service that can build and push images to Artifact Registry, but it does not provide the enforcement of signed images or vulnerability scanning policies at deployment time; Artifact Registry is the storage repository, not a policy enforcement service. Option D is wrong because Security Command Center is a security and risk management platform for threat detection and compliance, and Cloud Asset Inventory provides asset metadata and history, but neither enforces image signing or vulnerability scanning policies on GKE deployments.

Full explanation →
788
MCQmedium

Your team uses Cloud Monitoring to alert on high CPU usage for Compute Engine instances. You want to be notified via email and Slack. You have created a notification channel for email. What must you do to also notify Slack?

A.Create a second email notification channel with the Slack email integration address.
B.Create a Cloud Pub/Sub notification channel and set up a subscription to post messages to Slack via webhook.
C.Use Cloud Logging to forward logs to Slack directly.
D.Install the Stackdriver Slack app and configure it to receive alerts via Cloud Monitoring API.
AnswerB

This is the correct approach as described.

Why this answer

While Cloud Monitoring supports a direct Slack notification channel via webhook, it is also possible to use Cloud Pub/Sub to send notifications to Slack. This involves creating a Pub/Sub notification channel and configuring a subscription to post messages to Slack via webhook. Option B correctly describes this alternative method.

Full explanation →
789
MCQmedium

A Cloud SQL for MySQL instance requires a patch update. How can you minimize downtime during the update?

A.Apply the patch without restart
B.Use database migration to a new instance
C.Failover to a read replica during the update
D.Schedule the maintenance during a maintenance window
AnswerD

Scheduling maintenance allows Cloud SQL to perform rolling updates with minimal downtime, especially with HA enabled.

Why this answer

Cloud SQL for MySQL uses a maintenance window to schedule patching during a period of low traffic, minimizing user impact. While a restart is typically required for patch application, the maintenance window allows you to control when that restart occurs, reducing downtime exposure. This is the standard recommended approach for managed database patching in Google Cloud.

Exam trap

Google Cloud often tests the misconception that read replicas can be used for failover during patching, but in Cloud SQL for MySQL, read replicas do not support automatic failover for patching—only regional failover replicas in a high-availability configuration can, and even then, the maintenance window is the key to minimizing downtime.

How to eliminate wrong answers

Option A is wrong because Cloud SQL for MySQL patch updates typically require a restart of the instance to apply system-level changes, and there is no 'apply without restart' feature for such updates. Option B is wrong because database migration to a new instance involves creating and copying data to a fresh instance, which incurs significant downtime during the migration process and is not a minimal-downtime approach for a simple patch. Option C is wrong because Cloud SQL for MySQL read replicas are not used for failover during patching; they are for read scaling and high availability, but the primary instance must still be patched, and failover to a replica does not eliminate the need for a restart on the primary.

Full explanation →
790
Multi-Selectmedium

A Cloud Database Engineer is designing a schema for an e-commerce application on Cloud Spanner. The application requires high read throughput for product queries by category and price range, and must support global scale with strong consistency. The team is considering primary key design and interleaved tables. Which TWO design considerations should the engineer apply? (Choose TWO.)

Select 2 answers
A.Define secondary indexes on price and category columns to support range queries without considering the primary key design.
B.Use a timestamp as the first part of the primary key to enable time-based partitioning and efficient range scans.
C.Define interleaved tables for all related entities, even if they are not always accessed together, to reduce joins.
D.Use a primary key that starts with the category column to colocate product data for efficient queries by category.
E.Create an interleaved table for product variants under the product table, since variants are always queried with the parent product.
AnswersD, E

Leading with category allows Spanner to distribute rows by category, improving locality for queries filtering by category.

Why this answer

Colocating product data by category in the primary key enables efficient range scans on category and price, as Cloud Spanner stores rows in sorted order by primary key. This design minimizes cross-node fan-out for queries filtering by category, directly supporting high read throughput at global scale with strong consistency.

Exam trap

Google Cloud often tests the misconception that secondary indexes are a universal solution for query performance, ignoring that primary key design and interleaved tables are critical for colocation and avoiding cross-node fan-out in globally distributed databases like Cloud Spanner.

Full explanation →
791
Multi-Selecthard

A team uses Skaffold for local development and CI/CD. They want to run integration tests against the deployed application before releasing to production. Which THREE Skaffold features can they use?

Select 3 answers
A.Port forwarding to access the application locally
B.Custom test via the 'test' config section
C.Skaffold deploy with --status-check to verify rollout
D.Skaffold run for end-to-end pipeline
E.Skaffold debug for interactive debugging
AnswersB, C, D

Skaffold supports custom test commands in the 'test' phase.

Full explanation →
792
MCQeasy

In BigQuery, a BI analyst wants to store financial data with high precision and avoid rounding errors. Which data type should be used for currency columns?

A.NUMERIC
B.FLOAT64
C.INT64
D.STRING
AnswerA

NUMERIC is a fixed-point decimal type designed for financial precision.

Why this answer

NUMERIC (also known as DECIMAL) is the correct choice because it stores exact numeric values with up to 38 digits of precision and a user-defined scale, making it ideal for financial data where rounding errors from binary floating-point representation are unacceptable. In BigQuery, NUMERIC uses fixed-point arithmetic, ensuring that calculations like tax or interest accruals remain exact to the specified decimal places.

Exam trap

Google Cloud often tests the misconception that FLOAT64 is acceptable for currency because it 'has enough precision,' but the trap is that binary floating-point types inherently cannot represent many decimal fractions exactly, causing cumulative rounding errors in financial data.

How to eliminate wrong answers

Option B is wrong because FLOAT64 is a binary floating-point type that approximates values, leading to rounding errors in financial calculations due to its base-2 representation (e.g., 0.1 cannot be represented exactly). Option C is wrong because INT64 stores only whole integers, losing the fractional cents required for currency columns. Option D is wrong because STRING stores text, not numeric values, and would require costly and error-prone conversions for any arithmetic operations.

Full explanation →
793
MCQmedium

You are configuring a Cloud Build pipeline that builds a Docker image, pushes it to Artifact Registry, and deploys to Cloud Run. The build requires network access to a private VPC to download dependencies. Which approach should you use to provide VPC access?

A.Add the VPC firewall rule to allow traffic from Cloud Build's default IP range.
B.Use the default Cloud Build pool and configure VPC peering in the build steps.
C.Create a Cloud Build private pool connected to the VPC, and run the build using that pool.
D.Use Cloud NAT to allow egress from the default pool to the VPC.
AnswerC

Private pools provide direct VPC connectivity.

Why this answer

Cloud Build private pools provide direct VPC connectivity by running worker VMs inside a customer-managed subnet within the specified VPC. This allows the build to access private resources (e.g., dependency mirrors, internal repositories) without traversing the public internet, meeting the requirement for network access to a private VPC.

Exam trap

Google PCDE often tests the distinction between default and private pools, trapping candidates who assume that firewall rules or NAT can bridge the network isolation of the default pool, when in fact only a private pool provides the necessary VPC integration.

How to eliminate wrong answers

Option A is wrong because Cloud Build's default pool uses ephemeral IPs from a Google-managed range that cannot be predicted or added to VPC firewall rules; moreover, VPC firewall rules control traffic to/from VM instances, not outbound access from Cloud Build workers. Option B is wrong because the default Cloud Build pool does not support VPC peering configuration in build steps; VPC peering is a network-level setup between VPCs, not a per-build configuration. Option D is wrong because Cloud NAT enables outbound internet access from private VMs, but the default Cloud Build pool's workers are not in your VPC, so Cloud NAT cannot provide egress from them to your private VPC.

Full explanation →
794
Multi-Selecteasy

A company is planning to migrate their on-premises Oracle database to Cloud SQL. Which THREE prerequisites must be satisfied?

Select 3 answers
A.Convert Oracle-specific syntax to PostgreSQL or MySQL
B.Purchase Cloud SQL Enterprise Plus edition for the target instance
C.Ensure the source database is compatible with Database Migration Service (DMS)
D.Set up VPC peering or VPN to connect on-premises to Google Cloud
E.Create a Cloud Storage bucket for staging migration data
AnswersA, C, D

Database Migration Service handles schema conversion, but manual tuning may be needed.

Why this answer

Cloud SQL does not support Oracle's proprietary PL/SQL syntax. When migrating from Oracle to Cloud SQL, you must convert Oracle-specific syntax (e.g., sequences, packages, hierarchical queries) to the target dialect—either PostgreSQL or MySQL—since Cloud SQL offers only these two engines. This conversion is a prerequisite to ensure the migrated database functions correctly after the move.

Exam trap

Google Cloud often tests the misconception that Cloud SQL supports Oracle as a native engine, leading candidates to overlook the mandatory syntax conversion, or that a staging bucket is always required when DMS can perform direct migration without intermediate storage.

Full explanation →
795
Multi-Selectmedium

A company is migrating a MySQL OLTP database to Bigtable for a time-series application. The current schema uses a relational model with normalized tables. Which two actions should the team take when designing the Bigtable schema? (Choose TWO.)

Select 2 answers
A.Denormalize the data into a single wide-column table.
B.Maintain transactional integrity using Bigtable transactions.
C.Salting the row key to distribute writes across nodes.
D.Create secondary indexes on timestamp columns.
E.Normalize the schema to reduce data duplication.
AnswersA, C

Denormalization is typical for Bigtable.

Why this answer

Bigtable is a NoSQL wide-column store optimized for time-series data. Denormalization (option A) is recommended because it avoids joins and creates a single wide table that enables efficient scans over time ranges. Salting the row key (option C) distributes writes across nodes, preventing hot spotting on heavily written time-series data.

Option B is incorrect because Bigtable only supports single-row transactions, not multi-row transactions. Option D is incorrect because Bigtable does not support secondary indexes; queries must rely on row key design. Option E is incorrect because normalization leads to multiple tables, which are inefficient in Bigtable.

Full explanation →
796
MCQeasy

A developer is designing a schema for Firestore to store user profiles. Each user has a unique ID and multiple addresses. Which data modeling approach is recommended for Firestore?

A.Store addresses as a string array in the user document.
B.Use a relational join between users and addresses collection.
C.Create a separate collection for addresses with a reference to user ID.
D.Store addresses as a nested map within the user document.
AnswerD

Nested maps are ideal for one-to-few relationships and minimize reads.

Why this answer

Firestore recommends denormalizing one-to-few relationships. Storing addresses as a nested map within the user document (Option D) preserves structure and is efficient for small, fixed sets. Option A (string array) loses key-value structure.

Option B is not possible because Firestore does not support relational joins. Option C (separate collection) is more appropriate for large or frequently changing lists, not for a few addresses per user.

Full explanation →
797
Multi-Selecthard

A company is migrating a stateful web application from on-premises to Google Kubernetes Engine (GKE). The application has variable traffic patterns, with occasional spikes. The team wants to optimize performance and availability while minimizing cost during spikes. The application is not fault-tolerant to instance restarts. Which TWO strategies should the team implement? (Choose TWO)

Select 2 answers
A.Use preemptible VMs to reduce cost during spikes
B.Configure pod disruption budgets to ensure a minimum number of pods remain available during node scaling
C.Use Vertical Pod Autoscaler in Auto mode to automatically adjust pod resources without restarts
D.Configure cluster autoscaler to add nodes when utilization is high
E.Set cluster autoscaler scale-down delay to 0 for immediate cost savings
AnswersB, D

Pod disruption budgets protect against voluntary disruptions (e.g., node scaling), ensuring availability during spikes.

Why this answer

Cluster autoscaler adds nodes during spikes, but to avoid disruption from node scaling activities, pod disruption budgets should be configured to protect critical pods. Preemptible VMs are not suitable because the application is not fault-tolerant to restarts. VPA with Auto mode can adjust resource requests without restarting pods, but may take time to react to spikes; HPA is better for handling spikes quickly.

Full explanation →
798
MCQeasy

An SLA guarantees 99.9% monthly uptime. The team's SLO is 99.95% and error budget is 0.05%. What is the maximum allowed downtime per month according to the SLA?

A.7.2 hours.
B.43.8 minutes.
C.21.9 minutes.
D.4.38 hours.
AnswerB

0.1% of 43,800 minutes = 43.8 minutes, which is the SLA allowance.

Why this answer

99.9% uptime allows 0.1% downtime. Per month (30 days = 43,800 minutes), 0.1% is 43.8 minutes. The SLO is stricter but the question asks for SLA allowance.

Full explanation →
799
MCQeasy

A team is migrating an on-premises MySQL database to Cloud SQL. The current schema usesMyISAM tables. What is the recommended approach?

A.Keep the schema as is; Cloud SQL supports MyISAM.
B.Convert MyISAM tables to InnoDB before migration.
C.Replicate the on-premises MySQL to Cloud SQL using Database Migration Service.
D.Export the database using mysqldump and import directly into Cloud SQL.
AnswerB

InnoDB is the default and recommended engine; conversion ensures compatibility and transactional support.

Why this answer

Cloud SQL for MySQL does not support MyISAM tables because MyISAM lacks transaction support, row-level locking, and crash recovery, which are essential for a managed database service. Converting MyISAM tables to InnoDB before migration ensures compatibility, data integrity, and performance. The recommended approach is to alter the table engine to InnoDB prior to export or use a migration tool that handles the conversion.

Exam trap

The trap here is that candidates assume Cloud SQL supports all MySQL storage engines, but it explicitly restricts to InnoDB and NDB, making MyISAM incompatible without prior conversion.

How to eliminate wrong answers

Option A is wrong because Cloud SQL does not support MyISAM; it only supports InnoDB and NDB Cluster (for high availability). Option C is wrong because Database Migration Service (DMS) can replicate data but does not automatically convert MyISAM tables to InnoDB; the schema must be compatible beforehand. Option D is wrong because a direct mysqldump import of MyISAM tables into Cloud SQL will fail or produce errors since Cloud SQL rejects unsupported storage engines.

Full explanation →
800
MCQmedium

A financial services company runs a global trading application on Cloud Spanner. They need the highest availability with 99.999% SLA and automatic failover with zero data loss. Which Spanner configuration should they choose?

A.Multi-region configuration nam-eur-asia1 (US, Europe, Asia)
B.Regional configuration in us-central1 with read replicas
C.Multi-region configuration nam6 (US, limited to North America)
D.Regional configuration with a cross-region standby using backup/restore
AnswerA

This three-continent configuration provides 99.999% SLA, automatic failover with RPO=0, and is designed for global availability.

Why this answer

Multi-region configurations provide 99.999% SLA. Among the options, nam-eur-asia1 spans three continents with read-write replicas in each continent, offering automatic failover with zero data loss (RPO=0). Regional configuration offers 99.99% SLA.

Multi-region with only read-only replicas in some regions does not achieve the same failover capability.

Full explanation →
801
MCQmedium

A team is migrating a relational database to Bigtable. The existing schema uses foreign keys to join orders, customers, and products. Which data model approach is most suitable for Bigtable?

A.Store each entity in a separate table and use secondary indexes.
B.Denormalize orders, customers, and products into a single table with a composite row key.
C.Use Cloud SQL as a lookup table for joins.
D.Keep the normalized structure and use MapReduce to perform joins.
AnswerB

Denormalization avoids joins and aligns with Bigtable's access patterns.

Why this answer

Bigtable is a wide-column NoSQL database optimized for high-throughput, low-latency access, and it does not support SQL-style joins or secondary indexes in the traditional relational sense. Denormalizing orders, customers, and products into a single table with a composite row key (e.g., customer_id#order_id#product_id) allows all related data to be co-located and retrieved with a single row scan, eliminating the need for joins and aligning with Bigtable's key-value access pattern.

Exam trap

The Google Professional Cloud Database Engineer exam often tests the misconception that relational concepts like normalization and joins can be directly applied to NoSQL databases, when in fact Bigtable requires denormalization and careful row key design to achieve performance.

How to eliminate wrong answers

Option A is wrong because Bigtable does not support secondary indexes natively; creating separate tables and relying on secondary indexes would require manual index management and multiple lookups, defeating the purpose of using Bigtable. Option C is wrong because using Cloud SQL as a lookup table for joins introduces a separate relational dependency, adding latency and complexity, and contradicts the goal of migrating to a NoSQL solution like Bigtable. Option D is wrong because keeping the normalized structure and using MapReduce for joins is inefficient for real-time or low-latency workloads; MapReduce is batch-oriented and would not provide the fast, single-key access that Bigtable is designed for.

Full explanation →
802
MCQhard

You are running a Cloud Spanner instance and notice that a secondary index is causing performance issues for write operations. The index includes all columns of the table. Which Spanner feature can reduce the storage and write overhead of the index?

A.Use a hash index instead of a secondary index
B.Use the STORING clause to include only the necessary columns
C.Drop the secondary index and rely on the primary key
D.Create a covering index without STORING
AnswerB

STORING clause allows you to define which columns are stored in the index, reducing size and write overhead.

Why this answer

The STORING clause in Spanner allows you to include additional columns in the index without storing them in the index, reducing write overhead. This is used in 'covering indexes' but the STORING clause specifically stores the column in the index? Actually, STORING stores the column in the index so that queries don't need to read the base table. However, writing to the table requires updating the index, and if the index includes all columns, it's essentially a copy.

To reduce overhead, you can use the STORING clause to only store necessary columns. The question asks to 'reduce the storage and write overhead' — using STORING with only needed columns reduces the index size, thus reducing write overhead. Alternatively, you could use a filtered index (partial index) but Spanner does not support filtered indexes.

The correct answer is to use the STORING clause with only the columns needed.

Full explanation →
803
MCQeasy

A company wants to implement a disaster recovery plan for their AlloyDB database. They need automatic failover with minimal data loss and RTO under 30 seconds. Which configuration should they use?

A.Configure a cross-region read replica and promote it manually during a disaster.
B.Enable high availability (HA) on the AlloyDB cluster, which provisions a standby in a different zone.
C.Deploy AlloyDB in a single zone without HA.
D.Use AlloyDB with multiple read pools and a custom failover script.
AnswerB

AlloyDB HA provides automatic failover within 30 seconds and minimal data loss.

Why this answer

AlloyDB provides automatic failover within 30 seconds when you enable high availability (primary + standby). This is zone-redundant within the same region.

Full explanation →
804
Multi-Selectmedium

A company is designing a landing zone in Google Cloud. They need to set up a shared VPC for multiple projects. Which TWO steps should they take? (Choose two.)

Select 2 answers
A.Create a VPC network in each service project and peer them with the host project.
B.Attach service projects to the host project using the Shared VPC admin.
C.Configure VPC peering between the host project and each service project.
D.Grant the compute.networkUser role on the host project to users who need to create resources in the shared VPC.
E.Create a host project and enable the Shared VPC API.
AnswersB, E

Service projects are attached to use the host project's VPC.

Why this answer

Attaching service projects to a host project is the fundamental step in setting up a Shared VPC. This allows the service projects to consume resources (like VMs and GKE clusters) from the shared VPC network in the host project, enabling centralized network management and isolation.

Exam trap

The trap here is confusing VPC peering with Shared VPC, as both involve multiple projects, but Shared VPC uses a host/service project model with centralized network ownership, while peering connects independent networks.

Full explanation →
805
MCQeasy

You are monitoring a Cloud SQL for PostgreSQL instance and notice that the CPU utilization is consistently above 90% during peak hours. What is the most cost-effective initial action to reduce CPU load?

A.Remove unnecessary indexes to reduce write overhead
B.Reduce the max_connections parameter to limit concurrent users
C.Add a read replica to offload read traffic
D.Increase the machine type (e.g., go to a higher vCPU count)
AnswerC

Read replicas handle read-only queries, reducing primary CPU load.

Why this answer

Adding a read replica is the most cost-effective initial action because it offloads read queries from the primary instance, reducing CPU contention without incurring the cost of upgrading the entire instance. Cloud SQL for PostgreSQL replicas use native streaming replication, so they handle read traffic while the primary focuses on writes, directly addressing high CPU utilization from read-heavy workloads.

Exam trap

Google Cloud often tests the misconception that vertical scaling (increasing machine type) is the default fix for high CPU, but the trap here is that adding a read replica is more cost-effective for read-heavy workloads, as it scales horizontally without upgrading the primary instance.

How to eliminate wrong answers

Option A is wrong because removing indexes typically reduces write overhead but does not significantly lower CPU utilization from read-heavy workloads; indexes often speed up reads, and removing them could increase CPU usage due to full table scans. Option B is wrong because reducing max_connections limits concurrent users but does not address the root cause of high CPU from read queries; it may cause application errors without reducing CPU load if queries are already queued. Option D is wrong because increasing the machine type (higher vCPU count) is a vertical scaling approach that is more expensive than adding a read replica and does not leverage the cost efficiency of distributing read traffic across multiple instances.

Full explanation →
806
MCQmedium

A data engineering team ingests JSON logs into BigQuery using a streaming pipeline. Queries need to extract specific fields from nested arrays. Which SQL construct should be used to efficiently transform the nested data into a flat table for BI?

A.ARRAY_AGG with STRUCT
B.STRUCT with nested field access
C.SELECT * EXCEPT with UNNEST
D.UNNEST with CROSS JOIN
AnswerD

UNNEST flattens arrays into rows, allowing access to nested fields.

Why this answer

`UNNEST` with `CROSS JOIN` is the standard SQL construct in BigQuery to flatten nested arrays (repeated fields) into a flat table. When JSON logs contain arrays of structs, `CROSS JOIN UNNEST(array_column)` expands each array element into its own row, allowing BI tools to access individual fields directly. This is the most efficient and idiomatic way to transform nested data into a relational format for querying.

Exam trap

Google Cloud often tests the confusion between aggregation (`ARRAY_AGG`) and unnesting (`UNNEST`), where candidates mistakenly think `ARRAY_AGG` can flatten data because it deals with arrays, but it actually does the reverse operation.

How to eliminate wrong answers

Option A is wrong because `ARRAY_AGG` with `STRUCT` does the opposite—it aggregates rows into nested arrays, not flattens them. Option B is wrong because `STRUCT` with nested field access only retrieves scalar values from a single struct, not from array elements, and cannot unnest multiple rows. Option C is wrong because `SELECT * EXCEPT` is used to exclude columns from a SELECT *, not to flatten arrays; it does not involve `UNNEST` in a meaningful way for array expansion.

Full explanation →
807
MCQmedium

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?

A.cloudsql.googleapis.com/database/replication/replica_lag
B.cloudsql.googleapis.com/database/postgresql/replication/replica_lag
C.cloudsql.googleapis.com/database/replication/lag_seconds
D.cloudsql.googleapis.com/database/postgresql/replication/lag
AnswerB

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'.

Full explanation →
808
Multi-Selectmedium

A company is planning a cutover from an on-premises MySQL database to Cloud SQL after a DMS continuous migration. To ensure minimal downtime and a successful cutover, which TWO actions should be part of the cutover procedure? (Choose TWO.)

Select 2 answers
A.Stop all writes to the source database.
B.Increase the source database's CPU.
C.Delete the DMS migration job immediately.
D.Enable binary logging on Cloud SQL.
E.Verify that DMS replication lag is zero.
AnswersA, E

Prevents new changes during cutover.

Why this answer

Before cutover, quiesce writes to source and confirm DMS lag is zero to avoid data loss.

Full explanation →
809
MCQhard

A team is migrating a 5 TB MySQL database to Cloud SQL using DMS. The full dump phase is taking longer than expected. They suspect network bandwidth is the bottleneck. Which action can they take to improve the dump speed within DMS?

A.Use a larger machine type for the source connection profile.
B.Enable parallel dump in the DMS migration job settings.
C.Increase the Cloud SQL instance storage size.
D.Switch to a one-time migration job instead of continuous.
AnswerB

Parallel dump uses multiple threads to export data faster, improving throughput.

Why this answer

DMS uses a single-threaded dump by default. Enabling parallel dump can improve speed for large databases.

Full explanation →
810
MCQhard

A company uses Bigtable for time-series analytics and needs to query the most recent data points first. The row key currently consists of a user ID followed by a timestamp (e.g., user123#2024-01-15T10:30:00). However, frequent queries filter by time range across all users. Which row key design change would optimize query performance for this access pattern?

A.Use the user ID as the only row key and store timestamps as column qualifiers.
B.Use a monotonically increasing integer as the row key.
C.Reverse the timestamp and place it at the beginning of the row key (e.g., 2024-01-15T10:30:00_rev#user123).
D.Use a hash of the user ID as a prefix (salting) to distribute writes evenly.
AnswerC

Reversed timestamp at the start allows scanning the most recent data first.

Why this answer

Reversing the timestamp and placing it at the beginning of the row key ensures that the most recent data points are stored first in lexicographic order. Bigtable stores rows sorted by row key, so queries filtering by a time range across all users can now scan a contiguous range of rows without needing to skip over user ID prefixes. This design avoids the hotspotting and inefficient scans that occur when the timestamp is not the leading part of the key for time-range queries.

Exam trap

Google often tests the misconception that salting or hashing is always the best solution for Bigtable row key design, but candidates must recognize that for time-range queries across all users, the row key must be ordered by time first to enable efficient range scans.

How to eliminate wrong answers

Option A is wrong because storing timestamps as column qualifiers does not change the row key order; queries filtering by time range across all users would still require scanning every row (by user ID) and then filtering columns, which is inefficient and does not leverage Bigtable's sorted row key structure. Option B is wrong because a monotonically increasing integer as the row key would cause all new writes to land on a single tablet server (hotspotting), severely limiting write throughput and not supporting efficient time-range queries across users. Option D is wrong because salting with a hash of the user ID distributes writes evenly but scatters related time-series data across the key space, making range scans for time-range queries impossible without scanning the entire table.

Full explanation →
811
MCQhard

A company runs a MySQL database on Cloud SQL for an e-commerce platform. They need to add a new column to a table with millions of rows without causing downtime. What is the recommended approach?

A.Use 'ALTER TABLE ... ADD COLUMN ... ALGORITHM=INPLACE, LOCK=NONE'.
B.Use a tool like pt-online-schema-change to perform the change with minimal impact.
C.Create a new table with the column, copy data manually, then swap tables.
D.Use 'ALTER TABLE ... ADD COLUMN' directly; Cloud SQL handles it online.
AnswerB

pt-online-schema-change uses triggers and a shadow table to avoid locks.

Why this answer

Pt-online-schema-change (or gh-ost) creates a shadow table with the new schema, incrementally copies rows using triggers or binary log replay, and then atomically swaps the tables. This avoids holding any locks on the original table, preventing downtime for an e-commerce platform with millions of rows. Cloud SQL's InnoDB does not support true online DDL for all ALTER TABLE operations, especially on large tables, making a dedicated online schema change tool the safest approach.

Exam trap

A common trap is assuming that Cloud SQL's managed service automatically makes all DDL operations online for large tables, but MySQL's native online DDL has limitations and does not eliminate downtime without using external tools like pt-online-schema-change or gh-ost.

How to eliminate wrong answers

Option A is wrong because while ALGORITHM=INPLACE, LOCK=NONE can allow concurrent DML, it still requires a brief metadata lock and may cause replication lag or table rebuilds that block writes on large tables; it is not guaranteed to be fully online for all column additions, and Cloud SQL may still experience performance degradation. Option C is wrong because manually creating a new table, copying data, and swapping tables introduces a high risk of data inconsistency, requires application downtime during the swap, and is error-prone without transactional guarantees. Option D is wrong because a direct ALTER TABLE ADD COLUMN on a table with millions of rows will lock the table for the duration of the operation (even with InnoDB), causing downtime for writes and potentially reads, and Cloud SQL does not automatically handle this as an online operation.

Full explanation →
812
MCQhard

You are configuring a dashboard-as-code using the Cloud Monitoring API. You want to create a dashboard that shows a heatmap of request latency distribution across all services. Which chart type and aggregation should you use?

A.Heatmap chart using a distribution metric
B.Stacked bar chart with mean aggregation
C.Line chart with 95th percentile aggregation
D.Scorecard chart with MAX aggregation
AnswerA

Correct. Heatmaps visualize the distribution of values across buckets over time.

Why this answer

Heatmaps in Cloud Monitoring are created using a 'heatmap' chart type, which displays the distribution of metric values over time. This requires a distribution metric (e.g., from OpenTelemetry or custom) that records a histogram. The heatmap visualizes percentiles or count per bucket over time.

Line, stacked bar, and scorecard cannot show distribution.

Full explanation →
813
MCQmedium

A company is migrating an on-premises PostgreSQL database to Cloud SQL. The database is 2 TB and must have minimal downtime during migration. Which migration strategy should the Database Engineer recommend?

A.Export the database using pg_dump and import into Cloud SQL using pg_restore during a maintenance window.
B.Set up PostgreSQL on Compute Engine and replicate data, then switch over to Cloud SQL.
C.Use Database Migration Service to set up continuous replication from the on-premises database to Cloud SQL, then perform a minimal-downtime cutover.
D.Use Cloud SQL's built-in replication feature to connect directly to the on-premises database.
AnswerC

Database Migration Service supports minimal-downtime migrations using continuous replication.

Why this answer

The Database Migration Service (DMS) supports continuous replication from an on-premises PostgreSQL database to Cloud SQL using logical replication (pglogical or native PostgreSQL logical replication). This allows the source database to remain operational during the migration, and the cutover to Cloud SQL can be performed with minimal downtime, typically seconds to minutes, meeting the 2 TB size and low-downtime requirements.

Exam trap

Google Cloud often tests the distinction between tools that require downtime (like pg_dump/pg_restore) and services that support continuous replication (like DMS), and the trap here is that candidates may assume Cloud SQL's built-in replication can connect to any external database, when in fact it is limited to inter-instance replication within Google Cloud.

How to eliminate wrong answers

Option A is wrong because using pg_dump and pg_restore for a 2 TB database would require a long maintenance window (potentially hours or days) to export, transfer, and import the data, which contradicts the minimal downtime requirement. Option B is wrong because setting up PostgreSQL on Compute Engine and replicating data adds an unnecessary intermediate step and does not directly migrate to Cloud SQL; it also introduces additional operational overhead and potential latency without leveraging Cloud SQL's managed service benefits. Option D is wrong because Cloud SQL's built-in replication feature (e.g., cross-region replication or read replicas) cannot connect directly to an on-premises database; it is designed for replication between Cloud SQL instances, not for external sources.

Full explanation →
814
MCQeasy

You want to automatically group and track similar errors in your application logs, and see trends over time. Which Google Cloud service should you use?

A.Error Reporting
B.Cloud Monitoring
C.Cloud Logging
D.Cloud Trace
AnswerA

Error Reporting automatically groups similar exceptions and tracks trends.

Why this answer

Error Reporting automatically groups exceptions by similarity, provides trend analysis, and links to logs and traces. Cloud Monitoring is for metrics, Cloud Logging for logs, and Cloud Trace for tracing.

Full explanation →
815
MCQeasy

The exhibit shows IAM policy for a BigQuery dataset. The BI team reports they can query tables but cannot create views. What is the missing role?

A.roles/bigquery.admin
B.roles/bigquery.metadataViewer
C.roles/bigquery.dataEditor
D.roles/bigquery.user
AnswerC

DataEditor includes permissions to create tables and views.

Why this answer

The BI team can query tables but cannot create views, which requires write access to the dataset. The `roles/bigquery.dataEditor` role grants permissions to read, create, update, and delete datasets, tables, and views, including the `bigquery.tables.create` and `bigquery.tables.update` permissions necessary for view creation. The existing query capability indicates they have at least `roles/bigquery.dataViewer`, but view creation demands the additional write permissions provided by `dataEditor`.

Exam trap

The trap here is that candidates confuse the ability to query tables (which only requires `dataViewer` or `user`) with the write permissions needed to create views, leading them to incorrectly select `roles/bigquery.user` or `roles/bigquery.metadataViewer`.

How to eliminate wrong answers

Option A is wrong because `roles/bigquery.admin` grants full control over BigQuery resources, including dataset deletion and IAM policy management, which is excessive and not the minimal missing role for view creation. Option B is wrong because `roles/bigquery.metadataViewer` only allows viewing dataset and table metadata (e.g., table names, schemas) but does not include the `bigquery.tables.create` permission needed to create views. Option D is wrong because `roles/bigquery.user` enables running queries and listing datasets but does not grant write permissions such as `bigquery.tables.create` or `bigquery.tables.update`, which are required for creating views.

Full explanation →
816
MCQmedium

You are a database engineer for an e-commerce platform running on Cloud SQL for PostgreSQL. The application team reports that a critical report query taking 5 seconds last week now takes over 30 seconds. The database CPU usage has increased from 40% to 85%. The query plan shows a sequential scan on the orders table. Which action should you take first to diagnose the problem?

A.Migrate the database to Cloud Spanner for better scaling.
B.Add a composite index on the orders table based on the query's WHERE clause.
C.Increase the machine type to add more vCPUs.
D.Enable pg_stat_statements and check the query's execution statistics.
AnswerD

Provides necessary metrics to diagnose the query performance degradation.

Why this answer

Enabling pg_stat_statements provides detailed execution statistics (e.g., total time, calls, rows, I/O) for each query, allowing you to identify the root cause of the performance regression without making speculative changes. Since the query plan shows a sequential scan and CPU is high, pg_stat_statements can reveal if the query is now reading more rows due to data growth or plan changes, guiding the next action (e.g., adding an index or tuning parameters).

Exam trap

Google Cloud often tests the principle of 'diagnose before you treat' — the trap here is that candidates jump to adding an index (Option B) or scaling resources (Option C) without first gathering evidence, which is a common mistake in performance troubleshooting.

How to eliminate wrong answers

Option A is wrong because migrating to Cloud Spanner is a drastic architectural change that does not diagnose the problem; it introduces new complexity and cost without addressing the immediate cause (e.g., missing index or stale statistics). Option B is wrong because adding a composite index is a potential solution, not a diagnostic step; you must first confirm the query's WHERE clause and execution pattern via pg_stat_statements to avoid creating an ineffective index. Option C is wrong because increasing vCPUs treats the symptom (high CPU) rather than the cause (sequential scan); it may temporarily reduce CPU but does not fix the underlying query performance issue and could be wasteful.

Full explanation →
817
MCQmedium

A DevOps engineer is building a CI/CD pipeline and needs to securely pass a database password to a Cloud Build step. The password is stored in Secret Manager. What is the correct way to access it in cloudbuild.yaml?

A.Use 'gcloud secrets versions access' directly in a step's entrypoint
B.Store the password in a Cloud Storage bucket and download it during build
C.Pass the password as a build substitution variable
D.Define the secret in 'availableSecrets' and reference it via 'secretEnv' in the step
AnswerD

This is the standard method: declare the secret in availableSecrets and use secretEnv to inject it as an environment variable.

Why this answer

Cloud Build can access secrets from Secret Manager using the 'availableSecrets' and 'secretEnv' configuration. The secret is then injected as an environment variable in the build step.

Full explanation →
818
MCQeasy

A Cloud SQL for PostgreSQL instance is used for an OLTP application. The database schema has many foreign key constraints. Which action improves write performance?

A.Create indexes on foreign key columns.
B.Drop all foreign key constraints.
C.Add more triggers to enforce integrity.
D.Increase the instance storage size.
AnswerA

Indexes on foreign key columns speed up lookups during INSERT/UPDATE/DELETE operations.

Why this answer

Creating indexes on foreign key columns prevents full table scans when checking referential integrity, reducing lock contention and improving write performance. Option B is wrong because dropping foreign key constraints sacrifices data integrity, but it could actually improve write performance; however, this is not a best practice and violates data consistency. Option C is wrong because adding triggers adds overhead to write operations, slowing performance.

Option D is wrong because increasing storage size does not address the performance bottleneck caused by missing indexes on foreign key columns.

Full explanation →
819
MCQhard

A team is designing a Cloud Spanner schema for a global social media application. The table 'Posts' has a primary key of (UserId, PostId) where PostId is a UUID. They notice write hotspots on the server with monotonically increasing UserId values. What is the most effective schema design change to distribute writes evenly?

A.Add a hash prefix to the UserId to create a composite primary key like (HashUserId, UserId, PostId)
B.Create a secondary index on PostId
C.Place PostId first in the primary key
D.Use a monotonically increasing integer for PostId instead of UUID
AnswerA

Hashing the UserId distributes writes across splits, reducing hotspots while allowing range scans on UserId after filtering.

Why this answer

Using a hash prefix on the first part of the primary key (e.g., hash of UserId) helps distribute writes across splits, avoiding hotspots. Using a UUID for PostId is good but UserId ordering still causes hotspots. Adding a timestamp as a second part doesn't help.

Interleaving with User is fine but doesn't fix the hotspot issue.

Full explanation →
820
MCQmedium

A team has an SLO of 99.9% availability over a 30-day period. How many minutes of downtime does the error budget allow per month?

A.4.32 minutes
B.43 minutes
C.432 minutes
D.4,320 minutes
AnswerB

Correct calculation: 43,200 * 0.001 = 43.2 minutes, approximately 43 minutes.

Why this answer

Error budget = 100% - SLO target = 0.1% of total time. 30 days = 43,200 minutes. 0.1% of 43,200 = 43.2 minutes. Rounding gives 43 minutes.

Full explanation →
821
MCQeasy

An engineer needs to monitor the replication lag of a Cloud SQL read replica. Which metric should they use in Cloud Monitoring?

A.replication_lag
B.sent_bytes_count
C.disk_bytes_used
D.cpu_utilization
AnswerA

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.

Full explanation →
822
Matchingmedium

Match each Google Cloud database service to its primary use case.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Relational databases (MySQL, PostgreSQL, SQL Server)

Globally distributed, strongly consistent relational database

Serverless NoSQL document database for mobile/web apps

High-throughput, low-latency NoSQL for large analytical workloads

In-memory data store for Redis or Memcached

Why these pairings

The correct matches are Cloud SQL for standard relational workloads, Cloud Spanner for globally distributed transactions, and Bigtable for analytical workloads. Firestore is for mobile/web apps, and Memorystore is for caching. Common mistakes include confusing the use cases of these services.

Full explanation →
823
Multi-Selecthard

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.)

Select 2 answers
A.Increase the maxmemory setting to reduce eviction frequency.
B.Enable RDB persistence by setting the persistence mode.
C.Configure a cross-region replica to provide failover in another region.
D.Create a standard tier instance with replication enabled for automatic failover.
E.Set up a Cloud Scheduler job to export the instance to Cloud Storage every hour.
AnswersB, D

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.

Full explanation →
824
MCQmedium

You are a database engineer at a retail company. The company uses BigQuery for BI, with a fact table 'sales_fact' partitioned by order_date and containing 100 million rows. There is a dimension table 'products' with 10,000 rows. The BI team reports that the following query takes over 5 minutes to run: SELECT p.category, SUM(s.amount) FROM sales_fact s JOIN products p ON s.product_id = p.product_id WHERE s.order_date >= '2024-01-01' AND s.order_date < '2024-04-01' GROUP BY p.category. The table 'products' is not partitioned or clustered. 'sales_fact' is partitioned by order_date but not clustered. The query only scans 3 months of data (about 25 million rows). However, the join seems slow. What is the most likely cause and what single action would you take to improve performance?

A.Cluster the 'sales_fact' table on product_id
B.Use a cross-join to avoid the join
C.Add an index on 'products.product_id'
D.Partition the 'products' table
AnswerA

Clustering on the join key reduces shuffle and speeds up join.

Why this answer

The query is slow because the join on `product_id` requires shuffling 25 million rows from `sales_fact` across nodes to match with `products`. Clustering `sales_fact` on `product_id` co-locates rows with the same `product_id` within each partition, reducing shuffle overhead and enabling more efficient broadcast or hash joins in BigQuery. This is the most impactful single action because it directly addresses the join performance bottleneck without changing the query logic.

Exam trap

Google Cloud often tests the misconception that indexes or partitioning small tables solve join performance issues, when the real solution in BigQuery is clustering the large fact table on the join key to minimize data shuffling.

How to eliminate wrong answers

Option B is wrong because a cross-join would produce a Cartesian product of 25 million × 10,000 rows, which is computationally prohibitive and would make the query far slower, not faster. Option C is wrong because BigQuery does not support traditional indexes; it uses columnar storage and clustering for data organization, so adding an index is not a valid action. Option D is wrong because partitioning the `products` table (only 10,000 rows) provides no benefit for a small dimension table; the bottleneck is the large fact table join, not the products table scan.

Full explanation →
825
MCQmedium

Which SQL function in BigQuery is best for replacing NULL values in a numeric column with a default value?

A.NULLIF
B.NVL
C.IFNULL
D.COALESCE
AnswerD

COALESCE is standard, flexible, and preferred for portability. It can handle multiple columns.

Why this answer

COALESCE, is correct because it returns the first non-NULL value from a list of expressions, making it ideal for replacing NULLs in a numeric column with a default value. In BigQuery, COALESCE is the standard, flexible function that can handle multiple arguments, unlike IFNULL which only accepts two. This aligns with SQL ANSI standards and is the recommended approach for NULL handling in numeric columns.

Exam trap

Google Cloud often tests the distinction between IFNULL and COALESCE, trapping candidates who think IFNULL is always the best choice because it's simpler, when COALESCE is more versatile and ANSI-compliant for multiple fallback values.

How to eliminate wrong answers

Option A is wrong because NULLIF returns NULL if two expressions are equal, not a default value for NULLs; it's used for conditional NULL creation, not replacement. Option B is wrong because NVL is not a valid function in BigQuery; it exists in Oracle and other databases but BigQuery does not support it, making it a distractor for candidates familiar with other SQL dialects. Option C is wrong because IFNULL, while valid in BigQuery and capable of replacing a single NULL with a default, is less flexible than COALESCE as it only accepts two arguments; the question asks for the 'best' function, and COALESCE is preferred for its ability to handle multiple fallback values and its ANSI compliance.

Full explanation →
Page 10

Page 11 of 20

Page 12

All pages

1234567891011121314151617181920

Practice PCDE by domain

Target a specific domain to shore up weak areas.

Design innovative, scalable, and highly available cloud database solutionsManage a solution that can span multiple database technologiesMigrate data solutionsDeploy scalable and highly available databases in Google CloudPlan and manage database infrastructureDesign and implement database schemasMonitor and optimize database performance
See all domains with question counts →