Google Professional Cloud Database Engineer 1-10

表示モード
画像位置
文字位置
理解度の自動記録
STATUS FILTER

Choose confidence levels to display

Loading...
Q1Google Professional Cloud Database Engineer
Show answer
Correct answer: B. Adopt Bigtable.
Bigtable is a wide-column database well suited for storing financial time-series data such as trade histories and stock prices.
An SSD-based Bigtable supports up to 10,000 read/write operations per second per node and scans of up to 220 MB/s, and can scale to hundreds of TB with sub-second latency, so it meets these requirements.
Firestore and Cloud Spanner are oriented toward transactional processing and offer lower throughput for time-series scans, while BigQuery is designed for analytics and is not suited for low-latency online reads.
Overview of Bigtable (Google Cloud official documentation)
Q2Google Professional Cloud Database Engineer
Show answer
Correct answer: A. Run Cloud Spanner in a regional configuration.
Cloud Spanner can perform maintenance such as schema changes with no downtime, making it suitable for the 24/7 uptime requirement.
Since the pilot phase is limited to a single country, it is reasonable to start with the more cost-effective regional configuration.
With Spanner’s instance move capability, you can later expand to a multi-region configuration with no downtime, so it also flexibly supports future global expansion.
Move a Spanner instance (Google Cloud official documentation)
Q3Google Professional Cloud Database Engineer
Show answer
Correct answer: C. Build a multi-cluster Bigtable instance spanning multiple regions with replication.
A multi-cluster Bigtable instance spanning multiple regions provides fully managed replication and multi-cluster routing, delivering global, 24/7 availability.
Cross-region replication ensures mission-critical high availability, while autoscaling and a schema optimized for time-series data handle sudden traffic spikes, so it meets all the requirements.
A single cluster (A) is vulnerable to regional outages, and AlloyDB (D) is not suited for time-series workloads at this scale.
Overview of Bigtable replication (Google Cloud official documentation)
Q4Google Professional Cloud Database Engineer
Show answer
Correct answer: A. Build an Autoscaler-based architecture using linear scaling.
The Autoscaler tool for Cloud Spanner offers three scaling methods: stepwise, linear, and direct.
Stepwise is suited to multiple small peaks, and direct is suited to batch processing with a known start time.
For this case, which has a gradual upward trend plus occasional large peaks, linear scaling, which increases or decreases capacity proportionally to utilization, is the most suitable, so option A is correct.
Manual upgrades (C and D) do not meet the requirement for automation.
Autoscaler tool for Spanner (Google Cloud official documentation)
Q5Google Professional Cloud Database Engineer
Show answer
Correct answer: C. Use Query Insights to identify and address performance bottlenecks, and adjust the instance size based on its recommendations.
Query Insights continuously surfaces slow queries, resource-intensive workloads, and performance bottlenecks in Cloud SQL for PostgreSQL, enabling data-driven optimization.
Using these insights to right-size the instance lets you proactively optimize costs while meeting performance requirements, which is superior to mere budget alerts (A) or manual reviews (D).
Improve query performance using Query Insights (Google Cloud official documentation)
Q6Google Professional Cloud Database Engineer
Show answer
Correct answer: C. Increase the storage capacity, either manually or automatically.
When the out-of-disk recommender indicates a possible storage exhaustion, the fundamental and reliable response is to follow the recommendation and increase storage capacity.
In Cloud SQL, you can enable automatic storage increases or manually raise capacity to avoid disk exhaustion with no downtime, so option C is correct.
Normalization, compression, or adding a schema does not resolve the underlying capacity shortage.
Using the out-of-disk recommender (Google Cloud official documentation)
Q7Google Professional Cloud Database Engineer
Show answer
Correct answer: C. Use Cloud SQL for PostgreSQL with cross-region replicas.
The requirement for “open-source and SQL-compliant” rules out the proprietary-engine Spanner (D) and the NoSQL Bigtable (A) and Memorystore (B).
PostgreSQL is open-source and SQL-compliant, and Cloud SQL for PostgreSQL cross-region replicas can serve read-only access from around the world with low latency, so option C is the best choice.
The nightly batch updates are performed on the primary, while replicas in each region handle reads.
Cross-region replicas (Google Cloud official documentation)
Q8Google Professional Cloud Database Engineer
Show answer
Correct answer: D. Choose Cloud Spanner.
Cloud Spanner is a fully managed relational database with horizontal scaling via automatic sharding, combining global distribution with strong consistency (external consistency).
A multi-region Spanner configuration provides a 99.999% availability SLA and strong transactional consistency, meeting all the requirements of a global payment gateway, so option D is correct.
Cloud SQL does not support automatic sharding or 99.999% availability, and Bigtable does not satisfy the strong consistency of ACID transactions.
Spanner instance configurations and availability (Google Cloud official documentation)
Q9Google Professional Cloud Database Engineer
Show answer
Correct answer: C. Deploy 4 HA-enabled Cloud SQL instances in the us-central1 region, and create read replicas in us-central1, us-east1, and us-west1.
To handle 100 databases (8,000 tables total), you need enough instances to account for the per-instance limits on the number of databases and tables.
Four HA-enabled instances ensure availability, and placing read replicas in each region (us-central1, us-east1, and us-west1) satisfies both low-latency writes and geographically distributed reads, so option C is appropriate.
Configurations without HA (B and D) do not meet the availability requirement.
Cloud SQL high availability (Google Cloud official documentation)
Q10Google Professional Cloud Database Engineer
Show answer
Correct answer: A. Connect to the on-premises database with Database Migration Service and select continuous replication. After the migration completes, promote the Cloud SQL for MySQL instance and point the application to it.
To migrate MySQL while minimizing downtime and preserving transactions, the continuous replication of Database Migration Service (DMS) is the best option.
After the initial load, DMS keeps synchronizing changes in real time, and when ready you can promote the Cloud SQL instance to cut over, greatly reducing downtime.
Options C and D, which use mysqldump, require stopping the application and incur significant downtime, and Cloud Data Fusion (B) also requires planned downtime.
Database Migration Service (MySQL) (Google Cloud official documentation)