Cloud Digital Leader Practice Question: Google Cloud products, services, and solutions
A company is planning to migrate a legacy monolithic Linux application to Google Cloud. They want to minimize changes initially but have the flexibility to modernize later. Which three approaches should they consider?
⚠ Common exam trap
Google Cloud often tests the distinction between 'minimal changes' (rehosting or container lift-and-shift) and 'modernization' (refactoring or replatforming), leading candidates to incorrectly select options that require significant code or architecture changes.
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 Cloud Run for stateless containers
Option A is correct because Cloud Run runs stateless containers, so the legacy Linux application can be packaged into a container with minimal code changes and then modernized incrementally later. Option C is correct because Migrate for Anthos converts existing VM-based workloads into containers running on GKE, allowing a lift-and-shift migration with a path to modernization. Option E is correct because rehosting on Compute Engine with a custom image is the classic lift-and-shift approach, requiring almost no application changes while preserving future modernization options. Option B is not marked correct because App Engine Flexible requires replatforming the application to fit its runtime and deployment model, which is more change than the scenario wants initially. Option D is not marked correct because refactoring to microservices on GKE is a major architectural change, not a minimal-change 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.
- ✓
Use Cloud Run for stateless containers
Why this is correct
If the legacy application is already containerized or can be containerized with minimal effort, Cloud Run executes stateless containers in a fully managed, serverless environment; it auto-scales to zero, requires no infrastructure administration, and only necessitates the container to listen on a port. Because it does not impose a specific application framework or force a rewrite, it qualifies as a minimal-change migration for a monolithic app that does not depend on persistent local state.
- ✗
Replatform to App Engine Flexible Environment
Why it's wrong here
Replatforming to App Engine Flexible Environment is misaligned with a minimal-change goal because App Engine dictates a specific execution model: the application must conform to the platform's runtime, health-check, and deployment conventions, and often requires rewiring to use App Engine-specific services or environmental expectations. Even a monolithic app would need code alterations for startup, session handling, or filesystem access, converting a supposedly simple rehosting into a platform-specific refit.
- ✓
Use Migrate for Anthos
Why this is correct
Migrate for Anthos is a dedicated tool that automatically converts an existing VM (including its operating system and applications) into a container image and runs it on Google Kubernetes Engine or Compute Engine. It is purpose-built for lift-and-shift containerization: it preserves the OS layers, partitions, and application semantics, so the team does not manually rearchitect the monolith; after migration, small adjustments may be needed, but the core work is automated—hence a minimal-change path.
- ✗
Refactor to microservices on GKE
Why it's wrong here
Refactoring the monolithic application into microservices on GKE is a re-architecture project, not a migration: it requires decomposing the codebase into separate services, redefining data ownership, reworking inter-process communication, and adopting service discovery and configuration mechanisms. That level of change is the opposite of minimal—it involves a substantial rewrite, new operational tooling, and a longer timeline, even though GKE can host the end result.
- ✓
Rehost on Compute Engine using a custom image
Why this is correct
Rehosting on Compute Engine using a custom image is the classic lift-and-shift move: the company snapshots or custom-images the legacy Linux VM and provisions it on Compute Engine, preserving the OS, installed packages, and app configuration. Since it involves no code modification and only changes the underlying hypervisor and networking, it delivers the fastest, lowest-risk migration while allowing future containerization or refactoring afterward.
Go deeper
Related to this question
Learn chapter
ML Lifecycle: Data, Training, Deployment
Key term
Container
A container is a lightweight, standalone software package that includes everything needed to run an application, such as code, runtime, system tools, and libraries.
Key term
Model
In IT and AI, a model is a trained mathematical representation that learns patterns from data to make predictions or decisions.
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 →
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.