Google ACE Practice Question: A company uses preemptible VMs for batch…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use persistent disks to store application state.

  Why it's wrong here

  Persistent disks do not solve the ephemerality of preemptible VMs; if the VM is terminated, a attached persistent disk can remain but you then have orphaned, still-billed storage. More importantly, application state should live in a durable, external service like Cloud Storage or Cloud SQL so that any new preemptible VM can resume work without relying on a specific disk that may not be cleaned up automatically. Relying on persistent disks for state couples your workload to a manually managed resource, which defeats the purpose of stateless, fault-tolerant batch processing.

• ✓

  Use instance metadata to pass configuration parameters.

  Why this is correct

  Instance metadata is a key-value store exposed by the metadata server to every VM, and it is the recommended way to pass configuration parameters to preemptible VMs without baking them into the image. Because preemptible VMs can be recreated at any time, metadata lets the same image serve many different configurations; startup scripts or agents can read those values at boot to adapt the workload. This keeps the image generic and enables dynamic, per-instance configuration even when thousands of ephemeral VMs are launched from one template.

• ✗

  Use Cloud Functions to monitor instance termination.

  Why it's wrong here

  Cloud Functions can react to instance lifecycle events, but simply monitoring termination is not a top best practice because preemptible VM termination is an expected, normal occurrence rather than a failure. A more robust approach is to rely on Cloud Audit Logs or state externalized to a queue so work is automatically retried, rather than building a separate monitoring function that just tells you something you already assume will happen. Monitoring does not make the workload more resilient; it only adds cost and complexity without addressing the root cause of how the application handles interruption.

• ✓

  Use startup scripts to prepare the instance environment.

  Why this is correct

  Startup scripts are essential for preemptible VMs because each new instance begins from the template image and has no persistent state; the script runs automatically every time the instance boots and can install packages, pull code, set up directories, and start the application. This ensures that a replacement VM is configured identically without requiring manual intervention or a custom image. Combining startup scripts with metadata lets you make the script read configuration from the metadata server, so the same script can handle varied workloads across many ephemeral instances.

• ✗

  Use persistent disk snapshots for backup.

  Why it's wrong here

  Persistent disk snapshots are designed to back up durable data on persistent disks, but preemptible VMs are intrinsically ephemeral compute resources; their local or attached disks are not a meaningful source of truth for a batch job because the VM may be terminated mid-run. Snapshots do not help you resume work on a different preemptible VM unless the state itself is already externalized, and they incur additional storage costs. For preemptible workloads, the correct pattern is to write output to Cloud Storage or another durable service and treat the VM as completely disposable.

Go deeper

Related to this question