Task 2.1: Planning and implementing compute resources.

• AAgent Runtime on Gemini Enterprise Agent Platform, deployed from the same image

  Incorrect

  Agent Runtime is a managed runtime for AI agents, not a general host for an existing REST API container.

• BA managed instance group of Compute Engine VMs running the container with autoscaling on CPU

  Incorrect

  A MIG scales VMs, but the team manages the VMs, their OS and the container runtime, and a group normally keeps at least one VM running.

• CA GKE Standard cluster with the cluster autoscaler enabled on its node pool

  Incorrect

  GKE would run the container, but the team would manage a cluster and keep at least some nodes running and paid for at night.

• DCloud Run, as a service deployed from the container image with default autoscaling

  Correct

  Cloud Run runs stateless containers that answer HTTP requests, scales the number of instances with traffic and can scale to zero, with no servers or clusters to manage.

For a stateless container behind HTTP, Cloud Run removes the cluster and VM layers entirely: it adds instances as requests arrive and removes them when traffic stops, so idle time costs little or nothing.

• APlace the VMs on sole-tenant nodes to avoid noisy neighbors

  Incorrect

  Sole-tenant nodes dedicate physical servers to a project for isolation or licensing; they add cost rather than reduce it.

• BUse a custom machine type with 6 vCPUs and 40 GB of memory

  Correct

  Custom machine types let you set the vCPU count and memory you need, so the job does not pay for unused vCPUs.

• CCreate the VMs as Spot VMs and let the job restart preempted frames

  Correct

  Spot VMs are much cheaper than standard VMs and suit fault-tolerant batch work that can survive preemption, which checkpointing allows.

• DBuy a three-year committed use discount for the 300 vCPUs

  Incorrect

  Commitments discount steady use, but they bill for the committed resources every hour of the term, including the 18 idle hours each day.

• EAttach a regional Persistent Disk to each VM so work survives a zone outage

  Incorrect

  A batch job that checkpoints and restarts gains nothing from a costlier disk type; the requirement is the lowest compute cost.

Match the pricing model to the workload: interruptible, restartable batch work is what Spot VMs are for, and a custom machine type removes the gap between what the job needs and what a predefined shape offers.

• AAn instance template, and a zonal managed instance group built from it with autoscaling turned on

  Incorrect

  A zonal MIG autoscales, but all its VMs sit in one zone, so a zone failure takes the whole tier down.

• BA single large VM with a regional Persistent Disk that can be attached in another zone after a failure

  Incorrect

  One VM, whatever its disk, cannot add capacity with load, and recovering it after a failure is a manual step.

• CAn instance template, and a regional managed instance group built from it with autoscaling turned on

  Correct

  A regional MIG spreads identical VMs from the template across zones of the region, and its autoscaler adds and removes VMs with load.

• DAn unmanaged instance group in each of two zones, with VMs created from the same machine image

  Incorrect

  Unmanaged instance groups do not autoscale; they only group VMs that you create and manage yourself, for load balancing.

Managed instance groups create every VM from an instance template, so the VMs are identical. Choosing a regional group rather than a zonal one is what protects the tier from losing a single zone.

• ATurn on the block-project-ssh-keys option on each VM so that only instance-level keys are accepted

  Incorrect

  Blocking project-wide keys narrows which metadata keys work, but access still depends on keys someone has to remove by hand.

• BSet enable-oslogin=TRUE in the project metadata and grant the engineers' group the Compute OS Login role

  Correct

  OS Login links Linux accounts to Google identities and checks IAM at login, so suspending the account or removing the role ends access; Compute OS Login grants login without administrator rights.

• CAdd each engineer's public key to the project metadata and remove it when the engineer leaves

  Incorrect

  Metadata-managed keys work, but someone must remember to remove each key, which is the manual step security wants to eliminate.

• DSet enable-oslogin=TRUE in the project metadata and grant the engineers' group the Compute OS Admin Login role

  Incorrect

  OS Admin Login adds administrator (sudo) rights on the VMs, which the engineers must not have.

OS Login replaces metadata-managed SSH keys with IAM-controlled access. Choose the login role by need: Compute OS Login for normal users, Compute OS Admin Login for users who need sudo.

• AAs Cloud Run services, one per microservice, instead of a cluster

  Incorrect

  Cloud Run removes cluster management, but it does not offer the Kubernetes Deployments, Services and Helm charts the team relies on.

• BAs a GKE Standard cluster with one node pool of Spot VMs to reduce cost

  Incorrect

  Spot nodes cut cost for tolerant workloads, but the team still picks machine types, manages node pools and pays per node.

• CAs a GKE Autopilot cluster that runs the existing Helm charts

  Correct

  In Autopilot, Google manages the nodes, scaling and security settings, and you pay mainly for the resources your Pods request.

• DAs a GKE Standard cluster with node auto-provisioning enabled

  Incorrect

  Node auto-provisioning helps size node pools, but in Standard mode the team still configures and pays for the nodes themselves.

GKE has two modes. Standard gives you control of the nodes and bills for them; Autopilot hands node operations to Google and bills by Pod requests, which fits a team that wants Kubernetes without node work.

• ACreate the trigger with --location=eu and keep the function in europe-west1

  Correct

  The bucket's location dictates the trigger's location and the two must match, so a bucket in the eu multi-region needs a trigger in eu; the trigger can still deliver to a service in another region.

• BCreate the trigger with --location=global so that it matches any bucket location

  Incorrect

  Cloud Storage triggers cannot be global; they are created in the single-region, dual-region or multi-region location of the bucket.

• CRedeploy the function to europe-west4 and create the trigger there instead

  Incorrect

  A trigger in europe-west4 still does not match the bucket's eu location, so the same error comes back.

• DGrant the Cloud Storage service agent Pub/Sub Publisher and retry in europe-west1

  Incorrect

  That role is a prerequisite for direct Cloud Storage events, but the trigger must still be created in the bucket's location.

For Cloud Storage events, the trigger lives where the bucket lives: a region, a dual-region or a multi-region such as eu. The destination service can run in a region of your choice.

• AA GKE Autopilot cluster with the agent in a Deployment

  Incorrect

  The team would still own the containers, Kubernetes objects and the agent's state handling.

• BA Compute Engine VM running the agent as a service

  Incorrect

  A VM runs the code but leaves hosting, scaling and state management to the team.

• CAgent Runtime on Gemini Enterprise Agent Platform

  Correct

  Agent Runtime is a managed runtime for deploying and scaling agents, with services such as Sessions and Memory Bank alongside it.

• DA Cloud Run function invoked for each user message

  Incorrect

  A function can run code per request, but the team would build session and memory handling itself.

For agents, a purpose-built runtime removes infrastructure work and adds agent-specific services such as sessions and memory.

• AA Cloud Run service with minimum instances set to 1

  Incorrect

  Services answer requests and would keep an instance running all day.

• BA Compute Engine VM with a cron entry

  Incorrect

  The VM must be managed and runs, and bills, between executions.

• CA Cloud Run job, started on a schedule

  Correct

  Cloud Run jobs run containers that do their work and exit, with no HTTP endpoint and nothing running between executions.

• DA GKE Deployment with one replica

  Incorrect

  A Deployment keeps its Pod running continuously, which does not fit run-to-completion work.

Cloud Run has two shapes: services for request-driven work and jobs for tasks that run to completion.

• ASole-tenant nodes for those VMs

  Correct

  Sole-tenant nodes are physical servers dedicated to your project, which supports bring-your-own-license requirements.

• BA custom machine type with the licensed core count

  Incorrect

  A custom shape still runs on shared hosts.

• CShielded VMs with Secure Boot enabled

  Incorrect

  Shielded VM hardens boot integrity; it does not dedicate hardware.

• DSpot VMs for those workloads

  Incorrect

  Spot VMs are cheaper preemptible capacity on shared hardware.

Dedicated hardware is a licensing and isolation choice, made with sole-tenant nodes, not with machine shapes or pricing models.

• AA regional Persistent Disk replicated across two zones

  Correct

  Regional disks replicate synchronously between two zones and can be attached to a VM in the other zone after a failure.

• BA Cloud Storage bucket mounted with Cloud Storage FUSE

  Incorrect

  Object storage through FUSE is not a block device for a database's writes.

• CLocal SSDs mirrored by the database software

  Incorrect

  Local SSD data lives on one host and does not survive the loss of that VM's zone.

• DA zonal Persistent Disk with hourly snapshots

  Incorrect

  Restoring from snapshots loses up to an hour of writes.

Synchronous replication across zones protects disk data from a zone failure; snapshots protect against other losses but with an RPO.

• AA Cloud Storage bucket mounted with Cloud Storage FUSE

  Incorrect

  Object storage adds network latency for small, frequent writes.

• BA Standard Persistent Disk

  Incorrect

  Standard Persistent Disk is durable but the slowest option.

• CAn SSD Persistent Disk

  Incorrect

  SSD Persistent Disk is durable network block storage, with higher latency than Local SSD that is physically attached to the host.

• DLocal SSD attached to the VM

  Correct

  Local SSD offers very low latency and high throughput, with data that may be lost when the VM stops, which suits scratch files.

Match durability to the data: scratch data can trade persistence for the speed of Local SSD.