Cloud Digital Leader Google Cloud Products and Services 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.

• ✗

  Cloud Functions

  Why it's wrong here

  Cloud Functions is a serverless function-as-a-service platform that executes discrete code events in fixed runtimes such as Node.js, Python, Go, and Java. It does not accept arbitrary container images, and its execution model is event-driven and short-lived, with timeouts measured in minutes, which makes it fundamentally unsuitable for hosting a persistent, request-driven containerized web application. Even if you were to translate your app into functions, you would lose control over the HTTP server lifecycle and accumulate behavior penalties for long-running processes.

• ✓

  Cloud Run

  Why this is correct

  Cloud Run is the correct service because it directly executes any OCI-compliant container image on a fully managed, serverless infrastructure, eliminating the need to manage servers or clusters. It scales from zero to thousands of active instances in response to inbound HTTP requests, and charges only for the compute resources used while each request is being processed, plus a brief instance-startup window. This makes it ideal for a containerized web application: you retain portability and control over the runtime environment while benefiting from automatic TLS termination, revision traffic splitting, and the ability to scale down to literally zero when idle.

• ✗

  Compute Engine

  Why it's wrong here

  Compute Engine is a traditional infrastructure-as-a-service offering where you provision and maintain virtual machines with fixed vCPU, memory, and disk allocations that run continuously until you explicitly stop or delete them. You are billed by the second (or month for predefined VM types) for the entire lifetime of the VM, regardless of whether it is actively serving traffic or sitting completely idle, so it cannot scale to zero and offers no request-based cost model. Although you could theoretically install Docker and run your container on a Compute Engine VM, you would inherit the full burden of operating system patching, container runtime maintenance, and manual or custom autoscaling, making it operationally heavier and much less cost-efficient than Cloud Run for a simple web workload.

• ✗

  Google Kubernetes Engine (GKE)

  Why it's wrong here

  Google Kubernetes Engine runs containerized applications on top of a managed Kubernetes cluster, but that cluster is composed of a control plane and node pools that are essentially virtual machines you must pay for even when no workload is running. While Kubernetes can automatically scale the number of pods, the underlying nodes remain provisioned, so you cannot achieve a true zero-cost idle state; even in Autopilot mode, a flat per-cluster infrastructure fee is charged independently of pod usage, meaning it never scales to zero. For a single containerized web app that does not require advanced Kubernetes abstractions like custom deployments, service meshes, or targeted autoscaling policies, GKE introduces unnecessary architectural complexity and fixed overhead that Cloud Run simply eliminates.

Go deeper

Related to this question