Task 3.1: Managing compute resources.

• ARestore the VM's boot disk from its most recent snapshot to a new disk and attach it

  Incorrect

  A restore discards changes made since the snapshot; logging in to fix one line is less disruptive when the console is available.

• BAdd a new SSH key to the project metadata and connect again from Cloud Shell with gcloud

  Incorrect

  The problem is not the key; the SSH service is not running because the boot did not finish.

• CEnable serial-port-enable in the VM's metadata and use the interactive serial console

  Correct

  The interactive serial console works even when networking and SSH are down, which lets you log in and repair the boot problem.

• DConnect with gcloud compute ssh using the --tunnel-through-iap flag

  Incorrect

  IAP still needs a working SSH server on the VM, and the boot is stopped before SSH starts.

When SSH is unavailable because the guest cannot finish booting, the interactive serial console is the way in. Enable it only while needed, because it is a separate access path to the VM.

• ACreate a machine image of the VM every night with a cron job on an administrator's workstation

  Incorrect

  This needs a script and a workstation that is always on, and it does not delete old images after 14 days.

• BAttach a second disk to the VM and copy the data to it with rsync every night

  Incorrect

  A second disk in the same zone is not a point-in-time backup and needs a script; it also keeps only the latest copy.

• CCreate a custom image from the disk and add it to an image family each night

  Incorrect

  Producing an image every night still needs automation and a cleanup process, which the requirement rules out.

• DAttach a snapshot schedule with a 02:00 daily start and 14-day retention to the disk

  Correct

  A snapshot schedule is a resource policy that takes snapshots automatically and deletes them when their retention period ends.

Snapshot schedules automate both halves of a backup policy: when to take snapshots and how long to keep them. Attach the schedule to each disk that needs it.

• Agcloud run deploy checkout --image IMAGE_URL --no-traffic --tag qa

  Correct

  --no-traffic creates the revision without routing users to it, and the tag gives it its own URL for testing.

• Bgcloud run services update-traffic checkout --to-latest after deploying the new image

  Incorrect

  --to-latest sends all traffic to the latest revision, which is the opposite of what is needed here.

• Cgcloud run deploy checkout --image IMAGE_URL, then roll back if QA finds a problem

  Incorrect

  By default a new revision receives all traffic once it is ready, so users would hit the untested version.

• Dgcloud run jobs deploy checkout-qa --image IMAGE_URL --tasks 1

  Incorrect

  Cloud Run jobs run tasks to completion and serve no HTTP URL for QA to test the service.

Deploying with --no-traffic separates release from rollout. Once the tagged revision passes testing, shift traffic to it gradually or all at once.

• ASet CPU requests on the Deployment's containers

  Correct

  A utilization target is a percentage of the requested CPU, so the autoscaler cannot act on a CPU percentage without requests.

• BCreate a VerticalPodAutoscaler in Auto mode that adjusts CPU for the same Deployment

  Incorrect

  This does not set a replica range at all, and combining it with horizontal scaling on the same CPU metric needs a special setup.

• CCreate a HorizontalPodAutoscaler for the Deployment with minimum 3, maximum 20 and a 60% CPU target

  Correct

  The HorizontalPodAutoscaler changes the replica count to keep the metric near its target, within the bounds you set.

• DRun kubectl scale to set the Deployment to 20 replicas before each busy period

  Incorrect

  Manual scaling keeps a fixed count and needs someone to change it; it does not track the CPU target.

• EEnable the cluster autoscaler on the node pool with 3 to 20 nodes

  Incorrect

  The cluster autoscaler adds and removes nodes for Pods that do not fit; it does not change how many replicas a Deployment runs.

Horizontal Pod autoscaling on resource utilization compares usage with each container's request. Without requests it takes no action, so set requests first and then define the autoscaler's bounds and target.

• ASet maximum instances to 20

  Correct

  Capping the service at 20 instances keeps it at or below 200 connections; extra requests wait for an instance instead of opening more connections.

• BRaise the request timeout to the maximum value

  Incorrect

  A longer timeout keeps slow requests open longer, which does nothing to limit how many connections reach the database.

• CSet minimum instances to 20

  Incorrect

  Minimum instances sets a floor, not a ceiling, so the service can still grow past 20 instances during a spike.

• DSet the container concurrency to 1

  Incorrect

  One request per instance makes Cloud Run start more instances for the same traffic, and so more connections.

Maximum instances is the lever for protecting a downstream system with a fixed capacity. Size it from the downstream limit divided by what one instance uses.

• AA nodeSelector for the L4 accelerator label, without any GPU resource request

  Incorrect

  GKE taints GPU nodes and adds the matching toleration only to Pods that request GPUs, so a Pod with just the selector cannot be scheduled there.

• BA resource limit for nvidia.com/gpu set to the number of GPUs each container needs

  Correct

  GPUs are requested as nvidia.com/gpu limits, and GKE then applies the toleration that lets these Pods run on the tainted GPU nodes.

• CA PriorityClass with a high value so the Pods can preempt work on the GPU nodes

  Incorrect

  Priority does not let a Pod past the GPU nodes' taint, which only Pods that request GPUs tolerate.

• DA CPU request so large that only the GPU nodes' machine type has room for it

  Incorrect

  A CPU request does not request a GPU, so the Pod gets no toleration for the GPU nodes and no GPU to use.

When a cluster also has non-GPU nodes, GKE taints its GPU nodes. Requesting nvidia.com/gpu in the container's limits is what gives a Pod both the GPU and the toleration to run there.

• Akubectl scale on each Deployment every evening

  Incorrect

  Scaling Deployments changes Pods, not nodes, and needs someone to do it.

• BA larger fixed node count of 15 for the pool

  Incorrect

  A fixed count pays for 15 nodes all night.

• CCluster autoscaling on the node pool, 3 to 15 nodes

  Correct

  The cluster autoscaler adds nodes for Pods that cannot be scheduled and removes underused nodes, within the limits you set.

• DNode auto-repair turned on for the node pool

  Incorrect

  Auto-repair fixes unhealthy nodes; it does not change how many nodes there are.

Pod autoscalers decide how many Pods run; the cluster autoscaler decides how many nodes they need.

• AMove the service to a GKE cluster

  Incorrect

  This adds a cluster to run instead of fixing a setting.

• BSet maximum instances to 1 for the service

  Incorrect

  With concurrency at 1, one instance could serve only one request at a time.

• CRaise the concurrency per instance

  Correct

  Higher concurrency lets each instance serve more requests at once, so fewer instances are needed.

• DLower the service's request timeout

  Incorrect

  Shorter timeouts cut off slow requests; they do not reduce the number of instances.

Concurrency is a key autoscaling knob for Cloud Run: set it to what the code can handle safely.

• AA minimum number of instances greater than zero

  Correct

  Minimum instances keep instances ready, reducing the latency of starting new ones.

• BA larger container image with more dependencies

  Incorrect

  Larger images usually make startup slower, not faster.

• CA shorter request timeout

  Incorrect

  The timeout ends long requests; it does not affect startup.

• DA lower maximum number of instances

  Incorrect

  This does nothing to keep instances ready for the morning.

Scaling to zero saves money but adds startup latency. Minimum instances trade a small idle cost for faster responses.

• Agcloud compute instance-templates create with --count=10

  Incorrect

  Templates describe VMs; they have no count and do not create VMs.

• Bgcloud compute instance-groups managed resize web-mig --size=10

  Correct

  resize sets the group's target size, and the group creates VMs from its template to reach it.

• Cgcloud compute instance-groups managed recreate-instances web-mig

  Incorrect

  This recreates existing VMs; it does not add new ones.

• Dgcloud compute instances create six times with the same template

  Incorrect

  Standalone VMs are not members of the group and are not managed by it.

A managed instance group's size is a target. Change the target and the group adds or removes VMs to match.

• ARaise the request timeout to its maximum

  Incorrect

  The timeout limits request duration; the work happens after the response.

• BSet the container concurrency to 1

  Incorrect

  Concurrency limits parallel requests, not CPU outside requests.

• CIncrease the maximum number of instances

  Incorrect

  More instances do not give each one CPU after its response.

• DSwitch the service to instance-based billing

  Correct

  With instance-based billing, instances keep CPU for their whole lifetime, which suits background tasks after a response.

With request-based billing, CPU is allocated while requests are processed. Background work after a response needs instance-based billing.