Cloud Digital Leader Why cloud technology is transforming business Practice Question
A mid-sized company runs a legacy inventory management system on a single on-premises server. The system uses a monolithic Java application and a PostgreSQL database. The server has reached 90% CPU usage during business hours, and the database is 800 GB. The company wants to migrate to Google Cloud to take advantage of autoscaling and reduce hardware costs. The migration must have minimal downtime and the application cannot be significantly rewritten. The team also wants to enable future scalability for peak seasons. The IT team includes experienced database administrators but limited application development resources. Given the constraints, which approach should the team take?
⚠ Common exam trap
Google Cloud often tests the misconception that containerization (GKE) is always the best path to scalability, but here the constraints (no rewrite, limited dev resources) make rehosting on MIGs with Database Migration Service the pragmatic choice, not the most architecturally 'modern' one.
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
✓
Use Database Migration Service to migrate the PostgreSQL database to Cloud SQL with continuous replication for minimal downtime. Simultaneously, rehost the application on a managed instance group with autoscaling. Have a rollback plan.
It combines Database Migration Service with continuous replication (CDC) to achieve near-zero downtime for the 800 GB PostgreSQL database, while rehosting the monolithic application on a managed instance group with autoscaling to address CPU spikes without code changes. This approach respects the constraint of limited app development resources by avoiding refactoring, and the rollback plan provides safety during migration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Containerize the entire monolithic application and deploy it on Google Kubernetes Engine with a persistent volume for the database, with horizontal pod autoscaling.
Why it's wrong here
Containerizing the monolith requires application packaging, health checks, and stateful considerations; even with HPA, the database persistent volume becomes a single point of failure and is not horizontally scalable. Persistent volumes are zonal resources, and scaling the database beyond one node would require sharding or a managed service. This adds development and operational overhead, making it a heavier lift than a simple rehost.
- ✓
Use Database Migration Service to migrate the PostgreSQL database to Cloud SQL with continuous replication for minimal downtime. Simultaneously, rehost the application on a managed instance group with autoscaling. Have a rollback plan.
Why this is correct
Database Migration Service with continuous replication uses PostgreSQL's logical replication to keep Cloud SQL synchronized, allowing cutover with minimal downtime. Rehosting the application on a managed instance group provides autoscaling and self-healing for stateless servers without code changes. A rollback plan ensures you can revert to the source database and old infrastructure if cutover issues arise, making this a low-risk lift-and-shift migration.
- ✗
Use Database Migration Service to migrate the PostgreSQL database to Cloud SQL with a one-time dump and restore, and rehost the application on a single Compute Engine instance.
Why it's wrong here
A one-time dump and restore is an offline migration that requires stopping writes or accepting inconsistency, causing significant downtime. Running the rehosted application on a single Compute Engine instance offers no autoscaling or high availability, so traffic spikes or hardware failures would take the system offline. This approach also lacks a rollback plan, making it riskier than a continuous-replication migration.
- ✗
Refactor the monolithic application into microservices, deploy on Cloud Run, and use Cloud Spanner for the database.
Why it's wrong here
Refactoring a monolithic inventory system into microservices is a major rewrite that changes architecture, data ownership, and deployment patterns, violating the constraint of minimal effort. Cloud Run requires stateless containers and a service-discovery approach, while Cloud Spanner, though highly scalable and strongly consistent, is overkill for a legacy PostgreSQL workload and requires redesigning the schema and data access layer. This option introduces complexity and cost far beyond the stated goal.
Go deeper
Related to this question
Learn chapter
Cloud Digital Transformation
Key term
Google Cloud
Google Cloud is a suite of cloud computing services offered by Google that provides infrastructure, platform, and software solutions over the internet.
Key term
Scalability
Scalability is the ability of a system, network, or process to handle a growing amount of work by adding resources, either by making the existing resources more powerful (vertical scaling) or by adding more resources (horizontal scaling).
About these practice questions
One of 829 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 →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
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.