Courseiva

Cloud Digital Leader Why Cloud Technology Can Transform Business Practice Question

A company is migrating a legacy application to Google Cloud. The application has variable traffic and requires reliable, low-latency database access. The team wants to minimize operational overhead. Which TWO services should they consider for the database tier? (Choose two.)

⚠ Common exam trap

The trap is treating 'minimize operational overhead' as compatible with self-managed options — candidates sometimes pick Compute Engine-hosted MySQL thinking it gives more control, but the question explicitly penalizes operational burden.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Cloud SQL

Cloud SQL (A) is correct because it is a fully managed relational database service that supports MySQL, PostgreSQL, and SQL Server, offering automatic backups, patching, replication, and scaling with minimal operational overhead, making it suitable for a legacy application needing low-latency access. Cloud Spanner (B) is correct because it is a fully managed, horizontally scalable relational database that provides strong consistency and high availability with low latency even under variable traffic, and it removes operational burden such as sharding and replication management. Cloud Bigtable (C) is not ideal because it is a NoSQL wide-column store optimized for large analytical and high-throughput workloads, not general legacy relational applications. Firestore (D) is a NoSQL document database better suited for mobile, web, and serverless apps rather than a legacy relational workload. Self-managed MySQL on Compute Engine (E) is incorrect because it requires the team to handle patching, backups, replication, and scaling themselves, which increases operational overhead rather than minimizing it.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Cloud SQL

    Why this is correct

    Cloud SQL is a fully managed relational database service that supports MySQL, PostgreSQL, and SQL Server with the same SQL dialects and schema capabilities as typical on-premises legacy databases. It automates backups, patch management, and high availability, which dramatically reduces operational overhead. For a legacy relational application, Cloud SQL provides the least-friction migration path because your application code can remain largely unchanged while you hand off infrastructure management to Google Cloud.

  • ✓

    Cloud Spanner

    Why this is correct

    Cloud Spanner is also a fully managed relational database, but it is horizontally scalable, globally distributed, and offers strong consistency across regions. It uses SQL and supports transactions, so it can technically serve as a migration target for a legacy relational application that must scale far beyond what a single node can handle. However, for most legacy applications with modest scale, Cloud Spanner introduces unnecessary complexity and higher cost, making Cloud SQL the more appropriate choice.

  • ✗

    Cloud Bigtable

    Why it's wrong here

    Cloud Bigtable is a fully managed NoSQL wide-column database designed for high-throughput, low-latency read and write operations on massive, time-series-like datasets. It does not support relational schemas, joins, or SQL, so a legacy relational application cannot be migrated to it without a complete data model redesign. Because it is both NoSQL and optimized for different access patterns, it is not a suitable target for a typical transactional application.

  • ✗

    Firestore

    Why it's wrong here

    Firestore is a NoSQL document database built for mobile, web, and real-time applications. It stores data as flexible documents, which cannot represent normalized relational schemas with foreign keys and joins. A legacy application expecting SQL and ACID transactions would need significant re-architecture to run on Firestore, making it a poor fit for a simple lift-and-shift migration.

  • ✗

    Self-managed MySQL on Compute Engine

    Why it's wrong here

    Self-managing MySQL on Compute Engine preserves the exact runtime and configuration of your on-premises database, so the application might work unchanged. However, you must personally handle operating system patching, MySQL updates, backups, replication, and failover, which adds a significant operational burden. Given that Cloud SQL offers the same database engine with these tasks automated, a self-managed VM is generally the less efficient and riskier migration choice.

Quick reference

Cloud Service Model Comparison

ModelYou ManageProvider ManagesExamples
IaaSOS, runtime, apps, dataHardware, hypervisor, networkingEC2, Azure VMs, GCP Compute Engine
PaaSApps and dataOS, runtime, middleware, hardwareElastic Beanstalk, Azure App Service
SaaSData and settings onlyEverything elseMicrosoft 365, Salesforce, Workday
FaaS / ServerlessFunction code onlyInfra, scaling, runtimeLambda, Azure Functions, Cloud Run
CaaSContainers and appsKubernetes, OS, hardwareEKS, AKS, GKE

About these practice questions

One of 848 original GCDL practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official Google Cloud exam blueprint

This GCDL practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the GCDL exam.