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.

• ✗

  Google Kubernetes Engine (GKE)

  Why it's wrong here

  GKE manages Kubernetes clusters that require a minimum of one worker node, and even if you scale your application's replicas to zero, the worker nodes and the cluster control plane continue to run and incur compute and management costs. Autoscaling in GKE cannot reduce the cluster below a single node, so achieving zero cost while idle would require manually deleting or recreating the entire cluster, which is neither automatic nor practical for event-driven workloads.

• ✗

  Compute Engine

  Why it's wrong here

  Compute Engine provides raw infrastructure-as-a-service VMs that run continuously from the moment they are created until they are explicitly stopped, with per-second billing based on allocated vCPU and memory regardless of actual utilization. It has no built-in mechanism to pause execution or scale to zero when HTTP requests stop, meaning an idle VM still accrues full runtime costs. This makes it a poor fit for a containerized application that should cost nothing when no users are interacting with it.

• ✗

  App Engine Flexible Environment

  Why it's wrong here

  App Engine Flexible Environment executes your container inside VMs managed by Google, but it deliberately mandates a minimum of one running instance per service to host your container, so the platform never scales down to zero. The min_instances configuration, which defaults to 1, ensures that you pay for at least one idle machine even during periods of zero traffic. Unlike the App Engine Standard environment, Flexible does not offer true zero-instance scaling, making it unsuitable for a cost-conscious, serverless container deployment that expects to scale to zero.

• ✓

  Cloud Run

  Why this is correct

  Cloud Run is a fully managed serverless container platform that automatically scales your container from zero instances up to a number sufficient to handle incoming HTTP requests, and then back down to zero when traffic disappears. You are billed only for the exact time spent processing a request, with a minimum granularity of 100 milliseconds, so when there is no request traffic there are zero compute charges. This gives the developer exactly what they asked for: a containerized application that scales to zero, eliminating infrastructure costs during idle periods.

Go deeper

Related to this question