This chapter covers Preemptible and Spot VMs on Google Cloud Platform (GCP), a critical topic for the ACE exam under Objective 1.2 (Selecting appropriate compute resources). These VMs offer substantial cost savings (60-91% off regular pricing) but are subject to termination by Google when capacity is needed elsewhere. Understanding their behavior, limitations, and appropriate use cases is essential for cost optimization and reliable workload design. Expect 3-5 exam questions on this topic, often testing your ability to distinguish between Preemptible and Spot VMs, their lifecycle, pricing, and integration with managed instance groups.
Jump to a section
Imagine you are booking a hotel room for a conference. You have two options: a standard room that costs $200 per night and is guaranteed to be yours until checkout, or a 'last-minute' room that costs only $60 per night but can be revoked at any time if a full-price guest arrives. The hotel uses a dynamic system: when occupancy is low, they sell last-minute rooms to maximize revenue. But if a standard guest shows up, they must evict you, giving you 30 seconds to vacate and refunding the night's cost. Your work is interruptible—you can save your progress periodically, but if evicted, you lose unsaved work. This mirrors Preemptible and Spot VMs: you get a huge discount (60-91% off) for compute capacity that can be reclaimed by Google with a 30-second warning when the resource is needed for higher-priority (regular) VMs. The mechanism is identical: Google sells idle capacity at a discount, but when demand for standard VMs rises, it preempts your VMs. The warning time is fixed at 30 seconds, and you must design your applications to handle this gracefully—saving state, checkpointing, or using managed instance groups to restart elsewhere.
What Are Preemptible and Spot VMs?
Preemptible VMs (introduced in 2016) and Spot VMs (2021) are short-lived, cost-effective compute instances that leverage Google's unused capacity. They are identical in behavior but differ in pricing model and lifecycle management. Both can be terminated at any time (preempted) with a 30-second warning, but Spot VMs offer additional features like no maximum runtime (preemptible VMs have a 24-hour limit) and optional proactive instance migration.
Why They Exist
Google operates massive data centers with fluctuating demand. To avoid wasting idle capacity, Google offers it at a deep discount. This allows users to run fault-tolerant, batch-oriented, or stateless workloads at a fraction of the cost. For Google, it's a revenue optimization strategy; for users, it's a cost-saving opportunity.
How Preemption Works
When Google needs to reclaim capacity (for standard VMs, maintenance, or resource constraints), it sends an ACPI G2 soft shutdown signal to the VM. The VM receives a 30-second warning before forced termination. The sequence:
1. Google decides to preempt the VM.
2. The VM receives an ACPI G2 signal, initiating a 30-second grace period.
3. The VM can run shutdown scripts or handle the preemption via the preemption_notification metadata key.
4. After 30 seconds, the VM is forcefully stopped (equivalent to gcloud compute instances stop).
5. The VM transitions to TERMINATED state. It can be restarted, but only as a regular (non-preemptible) VM unless you explicitly set preemptible again.
Key Differences: Preemptible vs Spot VMs
| Feature | Preemptible VM | Spot VM |
|---------|----------------|---------|
| Maximum runtime | 24 hours | No limit |
| Pricing discount | Fixed (60-91% off) | Dynamic (same range, but can vary) |
| Preemption notification | 30 seconds | 30 seconds |
| Can be set on creation | Yes (via --preemptible) | Yes (via --provisioning-model=SPOT) |
| Can be changed after creation | No | Yes (via update) |
| Supports instance migration | No | No (unless using --instance-termination-action=MIGRATE with specific configurations) |
| Default termination action | Stop | Stop (can be set to DELETE or MIGRATE) |
| Integration with MIGs | Yes (can use --preemptible in template) | Yes (can use --provisioning-model=SPOT in template) |
| Billing | Per second after 1 minute | Per second after 1 minute |
| Availability | Lower than Spot | Higher than Preemptible (due to dynamic pricing) |
Pricing Details
Preemptible VMs: Discount is fixed at 60-91% off regular price depending on machine type and region. For example, an n1-standard-1 in us-central1 costs $0.0232/hr regular, $0.0071/hr preemptible (69% off).
Spot VMs: Discount is dynamic but typically in the same range. Spot pricing can adjust based on supply and demand, but Google guarantees it will never exceed the regular price. Spot VMs also have no 24-hour cap, making them suitable for longer workloads.
Lifecycle States
PROVISIONING: VM is being created.
STAGING: Resources are being allocated.
RUNNING: VM is active.
STOPPING: Preemption initiated (30-second window).
TERMINATED: VM stopped after preemption or manual stop.
SUSPENDED: Not applicable for preemptible/Spot.
Configuring Preemptible VMs
Using gcloud:
gcloud compute instances create my-preemptible-vm --zone=us-central1-a --preemptibleUsing gcloud for Spot VM:
gcloud compute instances create my-spot-vm --zone=us-central1-a --provisioning-model=SPOTIn instance templates (for MIGs):
gcloud compute instance-templates create my-template --preemptibleor
gcloud compute instance-templates create my-template --provisioning-model=SPOTHandling Preemption Gracefully
Applications must be designed to handle preemption. Best practices:
Use shutdown-script metadata to save state or notify other services.
Use preemption_notification metadata key to detect preemption (set to TRUE during the 30-second window).
Implement checkpointing (e.g., save intermediate results to Cloud Storage).
Use managed instance groups (MIGs) with autohealing to restart VMs after preemption.
Use --instance-termination-action=DELETE for Spot VMs to automatically delete the instance upon preemption.
Integration with Managed Instance Groups (MIGs)
MIGs can use preemptible or Spot VMs in the instance template. This is a common exam scenario. Key points:
MIGs can maintain a target size even if VMs are preempted; they will automatically recreate them.
You can set --preemptible or --provisioning-model=SPOT in the instance template.
For stateful workloads, use --stateful configurations to preserve disks or metadata.
Autohealing works the same as regular VMs.
Limitations and Constraints
Preemptible VMs cannot be used with GPUs or TPUs (except for specific GPU types like K80, P4, T4, V100 in certain regions; check current restrictions).
Preemptible VMs cannot be used with sole-tenant nodes.
Preemptible VMs cannot be migrated (live migration) or have automatic restart enabled.
Preemptible VMs are not covered by any SLA (Service Level Agreement).
Spot VMs do not support committed use discounts (CUDs) but can be used with sustained use discounts.
Monitoring and Alerts
You can monitor preemption events via Cloud Logging with the compute.instances.preempted log entry.
Set up alerts using Cloud Monitoring for preemption rate or instance health.
Use gcloud compute operations list to see preemption operations.
Exam-Specific Details
The ACE exam expects you to know the 30-second warning time.
Know that preemptible VMs have a 24-hour max runtime; Spot VMs do not.
Understand that both types are billed per second after 1 minute.
Know that preemptible VMs cannot be changed to regular after creation; Spot VMs can be updated.
Be able to identify appropriate use cases: batch processing, data analysis, rendering, CI/CD, fault-tolerant web servers (with MIGs).
Recognize inappropriate use cases: stateful databases, production frontends (unless designed for preemption), long-running single-instance workloads.
Command Reference
# Create preemptible VM
gcloud compute instances create vm1 --preemptible
# Create Spot VM
gcloud compute instances create vm1 --provisioning-model=SPOT
# Update Spot VM to regular (cannot do with preemptible)
gcloud compute instances update vm1 --provisioning-model=STANDARD
# List preempted instances
gcloud compute operations list --filter='operationType=compute.instances.preempted'
# View preemption logs
gcloud logging read 'resource.type=gce_instance AND jsonPayload.event_subtype=compute.instances.preempted'Create Preemptible VM Instance
The user runs `gcloud compute instances create my-vm --preemptible` or selects 'Preemptibility' in the console. During creation, Google schedules the VM on available spare capacity. The VM enters PROVISIONING state, then STAGING, then RUNNING. The instance metadata includes `preemptible: TRUE`. Billing starts after the first minute, then per second. The VM is identical to a regular VM except for the preemptible flag. It can use any machine type, image, and disk type, but cannot use GPUs (with some exceptions) or sole-tenant nodes.
Run Workload with Checkpointing
The workload runs on the preemptible VM. To handle preemption, the application periodically saves state (e.g., to Cloud Storage or a persistent disk). The VM may have a shutdown script that runs on termination. The workload should be designed to resume from the last checkpoint. For batch jobs, frameworks like Apache Beam or Dataproc can automatically handle preemption. The VM has no SLA, so it may be preempted at any time, but typically preemptions happen during peak usage hours.
Receive Preemption Notification
When Google needs capacity, it sends a preemption notification. The instance metadata key `preemption_notification` is set to `TRUE`. The VM receives an ACPI G2 soft shutdown signal. The operating system initiates a shutdown sequence. If a shutdown script is configured (via `shutdown-script` metadata key), it starts executing. The VM has exactly 30 seconds to complete shutdown tasks. During this window, the VM is still RUNNING but with the preemption flag set. The user can observe the preemption via Cloud Logging or by polling the metadata server.
Execute Shutdown Script and Save State
The shutdown script runs within the 30-second window. It can save final state, notify other services (e.g., via Pub/Sub), deregister from load balancers, or clean up resources. For example, a script might copy data from a local SSD to Cloud Storage or update a database. If the script takes longer than 30 seconds, it may be killed. The script should be idempotent and fast. After the script completes or the 30-second timeout expires, the VM is forcefully stopped.
VM Transitions to TERMINATED State
After preemption, the VM enters the TERMINATED state. It is no longer running and billing stops. The VM can be restarted manually (but will become a regular VM unless you specify `--preemptible` again). If using a managed instance group (MIG) with autohealing, the MIG will detect the termination and create a new preemptible VM to restore the target size. The new VM is provisioned on available capacity. If capacity is insufficient, the MIG will retry. The old VM's persistent disks (if any) remain attached in TERMINATED state and can be reattached.
Scenario 1: Batch Data Processing at a Financial Analytics Firm
A financial analytics firm runs daily Monte Carlo simulations for risk assessment. The jobs are CPU-intensive, embarrassingly parallel, and can tolerate interruptions. They use Preemptible VMs with a Cloud Dataproc cluster to process terabytes of data. Each job splits into thousands of tasks; if a VM is preempted, Dataproc reschedules the failed tasks on other VMs. The firm saves 70% on compute costs compared to regular VMs. They configure a shutdown script that periodically checkpoints intermediate results to Cloud Storage. The cluster uses a mix of regular VMs for master nodes and preemptible VMs for worker nodes. During peak market volatility, preemption rates increase, but the design ensures no job fails completely. They monitor preemption rates with Cloud Monitoring and adjust the number of regular VMs if preemption exceeds 20%.
Scenario 2: Rendering Farm for a Game Studio
A game studio uses a managed instance group (MIG) with Spot VMs to render 3D animations. Each rendering frame is an independent task. They use --provisioning-model=SPOT with --instance-termination-action=DELETE to automatically delete preempted instances. The MIG is configured with autohealing to recreate VMs. They set a target CPU utilization of 80% and use a load balancer to distribute rendering jobs. Spot VMs allow unlimited runtime, so long renders are not interrupted by the 24-hour limit. The studio saves 80% on compute. They use a startup script to pull the next frame from a Cloud Storage queue. If a VM is preempted, the frame is re-queued. They also use committed use discounts for a baseline number of regular VMs to ensure minimum capacity.
Scenario 3: CI/CD Pipeline for a SaaS Company
A SaaS company runs its CI/CD pipeline on Google Cloud Build and uses self-hosted runners on Compute Engine. They use a MIG with Spot VMs to run build agents. The agents are stateless; each build job runs in a Docker container with ephemeral disks. They set --provisioning-model=SPOT and --instance-termination-action=STOP (default) to allow debugging. The MIG uses a preemptible instance template. When a VM is preempted, the build job fails and is retried by the CI system (e.g., Jenkins or GitLab). The company saves 60% compared to regular VMs. They monitor preemption events and have a fallback pool of regular VMs for critical builds.
Common Pitfalls
Not designing for preemption: A stateful database running on a single preemptible VM will lose data on preemption. Always use persistent disks with regular VMs or distributed databases.
Assuming no 24-hour limit for Preemptible VMs: Preemptible VMs are terminated after 24 hours regardless of capacity. Spot VMs avoid this.
Not using shutdown scripts: Without a shutdown script, applications may not gracefully terminate, leading to data corruption.
Over-relying on preemptible VMs for critical workloads: Even with MIGs, if capacity is unavailable, the MIG cannot recreate VMs. Always have a fallback.
The ACE exam tests Preemptible and Spot VMs under Objective 1.2 (Selecting appropriate compute resources). Key exam topics:
Differences between Preemptible and Spot VMs: You must know that Spot VMs have no maximum runtime (vs 24 hours for Preemptible), can be updated from Spot to regular (Preemptible cannot), and support dynamic pricing (Preemptible has fixed discount).
30-second preemption notice: This is a specific fact that appears verbatim. Know that the VM receives an ACPI G2 signal and has 30 seconds to shut down.
Pricing: Preemptible VMs are 60-91% off regular price. Spot VMs have dynamic pricing but similar discounts. Both are billed per second after 1 minute.
Use cases: Batch processing, fault-tolerant workloads, stateless applications, CI/CD, rendering. Not for stateful databases or production frontends.
Managed Instance Groups (MIGs): MIGs can use preemptible/Spot VMs in instance templates. Autohealing will recreate preempted VMs. This is a common exam scenario.
Limitations: No GPUs (except specific types), no sole-tenant nodes, no live migration, no SLA, no committed use discounts (for Preemptible; Spot VMs can use sustained use).
Common Wrong Answers
Choosing Preemptible VMs for long-running jobs: Candidates forget the 24-hour limit. Spot VMs are better.
Thinking both types can be changed to regular after creation: Only Spot VMs can be updated; Preemptible VMs cannot.
Assuming both have the same pricing model: Preemptible has fixed discount; Spot is dynamic.
Believing preemptible VMs are guaranteed to run for 24 hours: They can be preempted at any time; the 24-hour limit is a maximum, not a guarantee.
Selecting preemptible VMs for a database: Unless the database is designed for preemption (e.g., with replication), this is incorrect.
Edge Cases
Preemption during shutdown script: If the shutdown script takes longer than 30 seconds, the VM is forcefully terminated. Scripts must be efficient.
Preemptible VMs with GPUs: Only certain GPU types are allowed (e.g., K80, P4, T4, V100) and only in specific zones. Check current documentation.
Spot VMs with instance termination action MIGRATE: This feature is in preview and requires specific configurations (e.g., using --instance-termination-action=MIGRATE with --maintenance-policy=TERMINATE). The exam may not cover this deeply.
How to Eliminate Wrong Answers
If the question mentions a 24-hour runtime limit, the answer involves Preemptible VMs.
If the question mentions changing provisioning model after creation, it must be Spot VMs.
If the question mentions cost savings for fault-tolerant batch jobs, both are correct, but Spot VMs are more flexible.
If the question mentions an SLA, neither Preemptible nor Spot VMs have one.
If the question mentions committed use discounts, Preemptible VMs do not qualify; Spot VMs do not either, but sustained use discounts apply.
Preemptible VMs have a 24-hour maximum runtime; Spot VMs have no limit.
Both receive a 30-second preemption notice via ACPI G2 signal.
Preemptible VMs cannot be converted to regular; Spot VMs can be updated.
Neither type has an SLA; both are billed per second after 1 minute.
Use with managed instance groups for automatic recreation after preemption.
Design applications to be fault-tolerant: checkpoint state, use shutdown scripts.
Preemptible VMs cannot use most GPUs or sole-tenant nodes; Spot VMs have same restrictions.
Cost savings range from 60% to 91% off regular pricing.
These come up on the exam all the time. Here's how to tell them apart.
Preemptible VM
Fixed discount: 60-91% off regular price
Maximum runtime: 24 hours
Cannot be changed to regular after creation
Older feature (2016)
Use `--preemptible` flag
Spot VM
Dynamic pricing (same discount range)
No maximum runtime
Can be updated to regular (STANDARD) after creation
Newer feature (2021)
Use `--provisioning-model=SPOT` flag
Mistake
Preemptible VMs can run indefinitely as long as they are not preempted.
Correct
Preemptible VMs have a maximum runtime of 24 hours. After 24 hours, Google automatically terminates them, even if capacity is available. Spot VMs have no such limit.
Mistake
Spot VMs are more expensive than Preemptible VMs.
Correct
Spot VMs use dynamic pricing but are typically in the same discount range (60-91% off). They can be cheaper or slightly more expensive depending on demand, but they are never more than regular pricing. Preemptible VMs have a fixed discount.
Mistake
You can change a Preemptible VM to a regular VM without recreating it.
Correct
Preemptible VMs cannot be updated to regular. You must delete and recreate the instance. Spot VMs can be updated to regular using `gcloud compute instances update` with `--provisioning-model=STANDARD`.
Mistake
Preemptible and Spot VMs are covered by the Compute Engine SLA.
Correct
Neither Preemptible nor Spot VMs have any SLA. There is no guarantee of availability or uptime. Only regular VMs have an SLA.
Mistake
All GPU types are supported on Preemptible VMs.
Correct
Only certain GPU types (e.g., K80, P4, T4, V100) are allowed on Preemptible VMs, and availability varies by region. Check the documentation for current restrictions.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Preemptible VMs have a fixed discount and a 24-hour runtime limit, while Spot VMs have dynamic pricing and no runtime limit. Spot VMs can also be updated to regular VMs after creation, but Preemptible VMs cannot. Both provide a 30-second preemption notice and are suitable for fault-tolerant workloads.
Only certain GPU types (e.g., K80, P4, T4, V100) are supported on Preemptible VMs, and availability is region-specific. Check the official documentation for the current list. Most modern GPUs (like A100) are not supported.
Use a shutdown script (via `shutdown-script` metadata) to save state, notify other services, or clean up. Also, implement checkpointing in your application to save progress periodically. Managed instance groups can automatically recreate preempted VMs.
Persistent disks remain attached to the VM in TERMINATED state. You can reattach them to another VM or delete them. Boot disks are not deleted unless you set `--auto-delete` on creation.
Not necessarily. Preemptible VMs have a fixed discount, while Spot VMs have dynamic pricing that can be lower or slightly higher. In practice, both offer similar cost savings (60-91% off). Spot VMs may offer better availability because pricing adjusts to demand.
No. Committed use discounts (CUDs) are not available for Preemptible or Spot VMs. However, sustained use discounts apply to Spot VMs (but not Preemptible).
24 hours. After 24 hours, Google automatically terminates the VM regardless of capacity. Spot VMs have no such limit.
You've just covered Preemptible and Spot VMs on GCP — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?