Google ACE Planning and Configuring a Cloud Solution 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.

• ✗

  Compute Engine with managed instance group and autoscaling

  Why it's wrong here

  Compute Engine managed instance groups scale the number of VM instances horizontally, but each instance is a full-fledged virtual machine billed per second while it runs. Autoscaling policies can lower the group to its `minimum` size, but that minimum must be at least 1 to serve traffic, and you also manage the OS, patches, and application runtime. For an intermittent workload this causes continuous baseline cost and more operational overhead than a serverless option.

• ✗

  Google Kubernetes Engine (GKE) Standard

  Why it's wrong here

  In GKE Standard, the control plane is managed by Google but the worker nodes are Compute Engine VMs in your project, and those nodes are billed even when they sit idle. Cluster autoscaling can shed disposable node pools, but there must always be at least one node to host system pods such as kube-proxy and networking daemons, so the cluster can never scale to zero. You also own node image upgrades, taints, and pool autoscaling configuration, making it heavier than a zero-idle-cost serverless platform.

• ✗

  App Engine Standard with manual scaling

  Why it's wrong here

  Manual scaling in App Engine Standard pins a fixed number of instances to a service version, and reducing that number to zero would effectively stop the version/stop serving traffic—the engine does not automatically re-create instances to handle spikes. Additionally, App Engine Standard runs within a sandbox with a whitelist of supported runtimes and libraries, so a custom containerized web app may not satisfy those environment restrictions unless ported to a compatible language. This violates the need for a flexible container deployment and fails to deliver cost-efficient scaling for intermittent HTTP traffic.

• ✓

  Cloud Run

  Why this is correct

  Cloud Run executes stateless containers on a fully managed platform, where each instance only receives compute billing while actually processing a request and the service can scale down to zero when no traffic arrives. It automatically provisions instances based on concurrency and can start many instances to handle bursts, with optional min instances for latency-sensitive workloads. A containerized web application is an ideal fit because Cloud Run accepts any container image that listens on a port, and integrates directly with Cloud Build and Artifact Registry.

Go deeper

Related to this question