Explanation:
Phase 1 (Cost Optimization): A zonal instance of Cloud SQL for PostgreSQL is the most economical choice for relational databases on Google Cloud, perfectly suited for your initial single-region (Asia) requirements. This approach minimizes costs during the early growth phase.
Phase 2 (Global Presence and Performance): Upon securing funding, migrating to Cloud Spanner is advisable. Cloud Spanner is designed for globally distributed applications needing high availability, strong consistency, and scalability. It's a managed, globally distributed database service that aligns with your global presence and performance optimization needs using a native JDBC driver.
Why Other Options Are Less Suitable:
Ultimate access to all questions.
You are managing a web application that currently serves customers from a single region in Asia. With plans to expand globally, your initial focus is on cost optimization. After securing funding, the goal shifts to optimizing for global presence and performance using a native JDBC driver. Which strategy should you adopt?
A
Begin with a zonal instance of Cloud SQL for PostgreSQL, then transition to Cloud Spanner after securing funding.
B
Start with a highly available instance of Cloud SQL for PostgreSQL, then switch to Bigtable with replication across US, Europe, and Asia post-funding.
C
Configure a single region instance of Cloud Spanner initially, then expand to multi-region Cloud Spanner instances after securing funding.
D
Initiate with a zonal instance of Cloud SQL for PostgreSQL, then upgrade to a highly available configuration of Cloud SQL for PostgreSQL after funding.
No comments yet.