Google Cloud ACE: Planning and configuring a cloud solution Practice Questions

GKE Standard is the correct choice. It provides full Kubernetes API compatibility, including CRDs and DaemonSets, full node-level control required for GPU node pools, and the flexibility to configure different scaling policies per deployment — including scale-to-zero with KEDA or custom HPA configurations. Cloud Run supports scale-to-zero and GPU (in preview), but it does not support Kubernetes-native constructs like CRDs or DaemonSets since it is not a Kubernetes platform. GKE Autopilot manages the underlying node infrastructure for you and supports most Kubernetes workloads, but it restricts certain privileged operations and DaemonSets are managed by Google, not users — making it incompatible with the requirement for custom DaemonSets. App Engine Flexible runs containerized workloads but does not expose Kubernetes primitives and has no support for CRDs, DaemonSets, or GPU node pools.

Cloud Spanner is correct because it is Google's globally distributed, strongly consistent, ACID-compliant relational database purpose-built for horizontally scalable, multi-region transactional workloads — exactly the described requirements. Cloud SQL for PostgreSQL with read replicas improves read scalability but write operations remain limited to a single primary instance, and it does not natively provide multi-region strong consistency at millions of TPS. Firestore in Datastore mode is a NoSQL document database; while it supports transactions, it is not relational and is not designed for the high-volume financial transaction use case described. BigQuery is an analytics data warehouse optimized for OLAP queries, not OLTP transactional workloads.

3-year Commitment (option 2) saves the most (~52% compared to on-demand). Given consistent 24/7 year-round usage and known infrastructure plans, maximizing discount depth is optimal. However, option 1 is also a valid answer; 1-year commitments (~25%) are safer if plans are uncertain. For this scenario, option 2 maximizes savings given predictable, continuous usage. Option 0 (sustained use discounts alone) applies automatically but is minimal (10-30%) compared to commitments. Option 3 (preemptible) requires architecture changes and is unsuitable for 24/7 services (not mentioned as interruptible). Note: Options 1 and 2 both use commitments; 3-year is deeper savings if commitment risk is acceptable.

Database Migration Service (DMS) with Cloud SQL and binary log replication (option 0) is correct. DMS automates schema conversion, full data transfer, and ongoing replication without downtime. Binary log replication enables rollback to on-premises if issues occur post-migration. Option 1 is infeasible; Cloud SQL does not support on-premises read replicas (replication is one-direction: on-prem to Cloud). Option 2 (pg_dump) requires stopping the source database, violating the zero-downtime requirement. Option 3 confuses tools; Cloud Spanner is not a drop-in PostgreSQL replacement (requires schema redesign for distributed architecture), and DMS doesn't automatically handle Spanner's different data model.

Firestore is the correct choice. It is a fully managed, serverless NoSQL document database that natively stores semi-structured data with nested fields, scales horizontally to support tens of millions of documents, provides single-digit millisecond lookups by document ID, and supports multi-document ACID transactions. BigQuery is an analytical data warehouse optimized for batch SQL queries over large datasets — not for low-latency, per-user lookups in an operational serving context. Cloud Bigtable is a petabyte-scale, low-latency key-value/wide-column store that excels at time-series and high-throughput analytical workloads; it does not natively support ACID transactions across multiple rows and is operationally more complex for this use case. Cloud SQL for MySQL is a fully managed relational database that supports ACID transactions but uses a fixed schema and scales vertically (with limited horizontal read scaling), making it less suitable for semi-structured, horizontally scalable profile storage at the scale described.