Task 2.3: Configuring compute systems.

• AStandard VMs covered by a three-year resource-based commitment for the farm

  Incorrect

  Commitments discount steady usage but bill for three years, and they stay above Spot prices for interruptible work.

• BSole-tenant nodes sized for the peak number of render VMs

  Incorrect

  Sole tenancy buys physical isolation, which adds cost and does nothing for a render farm's price.

• CSpot VMs in a managed instance group that recreates preempted VMs

  Correct

  Spot VMs carry the deepest discounts, and a MIG keeps trying to recreate preempted VMs, which suits fault-tolerant, checkpointed batch work.

• DStandard VMs on a reservation sized for the peak render load

  Incorrect

  A reservation is billed at on-demand rates whether or not the farm is busy, so it adds cost instead of lowering it.

Compute volatility is a cost lever: when a workload checkpoints and can be retried, Spot capacity in a managed instance group gives the lowest price while the group restores capacity after preemptions.

• AVM Manager patch deployments for each window, with patch compliance reports

  Correct

  VM Manager Patch schedules patch jobs across Linux and Windows VMs and reports patch compliance and job results for each VM.

• BA startup script on every VM that installs available updates each time it boots

  Incorrect

  Startup scripts run only at boot, so they follow no maintenance window and produce no compliance report.

• CA monthly rebuild of every VM from the newest public OS image in its image family

  Incorrect

  Recreating VMs is disruptive for stateful servers and still leaves no record of patch status.

• DA monthly Cloud Asset Inventory export of every VM to BigQuery for the auditors

  Incorrect

  Asset Inventory lists resources and their metadata; it does not install patches.

Patch management is part of configuring compute systems at scale. VM Manager automates patch jobs on a schedule and gives the compliance view auditors ask for.

• AA Cloud NAT gateway in the service's region for its outbound traffic

  Incorrect

  Cloud NAT translates addresses; it does not route Cloud Run traffic into the VPC network.

• BPrivate Google Access on the subnet where the database instances live

  Incorrect

  Private Google Access is a subnet setting; it does not let Cloud Run reach internal IP addresses.

• CDirect VPC egress from the service into a subnet of that VPC network

  Correct

  Direct VPC egress sends the service's traffic into the VPC network without a Serverless VPC Access connector, so it reaches internal IP addresses.

• DExternal IP addresses on the Redis and Cloud SQL instances for Cloud Run

  Incorrect

  Exposing the databases publicly weakens security, and Memorystore for Redis is not reachable this way.

Serverless networking connects managed compute to private resources. For Cloud Run, Direct VPC egress places traffic into the VPC network with no connector to operate.

• AAn opportunistic update that applies the new template when VMs are recreated

  Incorrect

  Opportunistic updates wait for VMs to be recreated for other reasons, so the rollout may never finish in the window.

• BA proactive rolling update with maxUnavailable 0 and maxSurge of 3 or more

  Correct

  maxSurge creates new VMs above the target size before old ones are removed, and maxUnavailable 0 keeps every existing VM serving until replaced.

• CA proactive update with the default settings for surge and unavailability

  Incorrect

  The defaults allow one VM per zone to be unavailable, which drops capacity during the rollout.

• DDeleting the group and recreating it from the new template at noon

  Incorrect

  Recreating the group takes the web tier down during the change.

Infrastructure orchestration for VMs relies on MIG update policies. Surge plus zero unavailability trades a little extra cost for no capacity loss during a rollout.

• AA Cloud Run service invoked once by an HTTP request

  Incorrect

  A service is built to answer requests; a long batch tied to one request is fragile and needs a client to wait.

• BA Kubernetes CronJob on a GKE Standard cluster

  Incorrect

  A CronJob works, but it brings a cluster to run and pay for, which the team wants to avoid.

• CA Cloud Run job with one parallel task per file

  Correct

  A Cloud Run job runs its tasks to completion and exits, and it can split work into many independent tasks that run in parallel.

• DA Compute Engine VM started by a Cloud Scheduler job

  Incorrect

  A VM is a server the team would have to build, patch and shut down.

Serverless computing covers batch as well as request-driven work. Cloud Run jobs are the serverless option for containers that run to completion.

• AA Spot VM node pool with a taint, and a matching toleration on the batch Pods

  Correct

  The taint keeps other workloads off the Spot nodes, and the toleration lets only the batch Pods be scheduled there.

• BSpot VMs for every node pool, with PodDisruptionBudgets on the services

  Incorrect

  PodDisruptionBudgets do not stop Spot nodes from being reclaimed, so the services would still be disrupted.

• CNode auto-repair on the existing pool and a lower priority for the batch Pods

  Incorrect

  Auto-repair fixes unhealthy nodes; neither setting gives the batch Pods cheaper capacity.

• DA larger standard node pool with the cluster autoscaler set to scale down

  Incorrect

  Scaling down saves idle capacity but does not use the cheaper Spot pricing.

Compute volatility can be mixed within one cluster: run interruptible work on Spot nodes and use taints and tolerations to keep critical workloads on standard nodes.