Cloud Digital Leader Fundamental Cloud Concepts Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Rehost the application on Compute Engine using a custom image of the current OS

  Why this is correct

  Rehosting on Compute Engine with a custom image of the current OS is a classic 'lift-and-shift' strategy that preserves the exact kernel, libraries, and configuration of the legacy environment. Because no code changes or architectural changes are required, this approach minimizes migration risk and time-to-completion, allowing the team to move the application as-is. The custom image ensures parity with the on-premises OS, avoiding issues with unsupported or altered system dependencies.

• ✗

  Rebuild the application from scratch on Cloud Run

  Why it's wrong here

  Rebuilding the application from scratch on Cloud Run is the most expensive and risky option because it involves rewriting the entire codebase, not just changing infrastructure. Cloud Run is a fully managed serverless container platform that requires the application to be containerized, adhere to stateless design principles, and scale independently, which a legacy monolithic application rarely satisfies. This approach effectively discards the existing investment and creates a new application, making it unsuitable for a quick migration.

• ✗

  Re-platform the application to a supported OS version

  Why it's wrong here

  Re-platforming to a supported OS version entails swapping the underlying operating system, which can break the application due to differences in system libraries, binary compatibility, and configuration file paths. Even if the code is portable, the application may rely on OS-specific utilities or versions that are not present in the newer OS, forcing middleware or runtime upgrades that introduce regression risk. This approach is also not a minimal-change migration because it requires re-testing and often reconfiguring the entire environment.

• ✗

  Refactor the application into microservices and deploy on GKE

  Why it's wrong here

  Refactoring the application into microservices and deploying on GKE requires decomposing the monolithic codebase into independently deployable services, which demands significant development resources and a fundamental architectural shift. The distributed nature introduces network latencies, data consistency challenges, and operational complexity around service discovery and inter-service communication. Since GKE is a Kubernetes platform, the team would also need to create Docker images and orchestrate containers, making this the most time-consuming and risky approach relative to the original goal.

Go deeper

Related to this question