# Preemptible VM

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/preemptible-vm

## Quick definition

A preemptible VM is a virtual machine that costs much less than a regular VM but can be shut down by the cloud provider at any time. It is ideal for batch jobs, data processing, and other non-critical workloads that can tolerate interruptions. Because of this trade-off, you get significant cost savings if you design your applications to handle sudden stops and restarts.

## Simple meaning

Imagine you need a car for a one-day road trip. Renting a car from a typical agency costs a fixed price per day, and you are guaranteed to have that car for the whole day. That is like a regular virtual machine (VM) in the cloud, you pay a set rate, and the car (the VM) is yours for the time you reserved. Now imagine a rideshare service that offers a deeply discounted ride. The catch is that the driver might drop you off early if they get a better paying passenger. You still get to your destination, but you might have to switch rides partway. That deeply discounted, but interruptible, ride is like a preemptible VM.

Preemptible VMs are offered by cloud providers such as Google Cloud (where they are called preemptible VMs), AWS (where similar offerings are called Spot Instances), and Azure (where they are called Low-Priority VMs or Spot VMs). The cloud provider has spare computing capacity that is not being used. Instead of letting that capacity sit idle, they offer it at a steep discount, often 60% to 90% cheaper than regular VMs. In return, the provider can reclaim that capacity at any time, with only a short warning window (typically 30 seconds). This means your VM can be terminated without notice if the provider needs the resources for a higher-priority customer.

Because preemptible VMs can be shut down at any moment, they are not suitable for all workloads. Critical production systems, databases, and interactive user-facing applications should not run on preemptible VMs. However, they are excellent for tasks that are fault-tolerant and can be broken into small, checkpointable units. Examples include batch data processing, rendering video frames, running large simulations, performing scientific computations, and testing or development environments. By using preemptible VMs, you can accomplish enormous amounts of compute work at a fraction of the normal cost.

## Technical definition

A preemptible VM is a compute instance type offered by cloud infrastructure providers that provides compute capacity at a reduced price in exchange for the provider's ability to terminate the instance at any time. The core technical concept is that the cloud provider manages a pool of spare compute capacity, servers that are idle or underutilized. Rather than leaving this capacity unused, the provider makes it available as preemptible instances, allowing customers to run workloads that are tolerant of interruption.

The termination process works as follows: When the cloud provider needs to reclaim the physical resources backing a preemptible VM, it sends a soft shutdown signal to the instance. In Google Cloud, this is an ACPI G2 (soft-off) signal, which is the same as a graceful shutdown request via the operating system. The VM is given a 30-second grace period during which it can handle cleanup, save state, and stop processes. After 30 seconds, the instance is forcibly terminated. This behavior is consistent across different providers, though the exact grace period may vary by provider, AWS Spot Instances, for example, give a two-minute interruption notice when capacity needs to be reclaimed.

The pricing model for preemptible VMs is dynamic in some cases and fixed in others. Google Cloud uses a fixed price that is generally stable, while AWS uses a spot market where prices fluctuate based on supply and demand. Preemptible VMs typically do not offer the same service-level agreements (SLAs) as standard VMs, for instance, there is no guarantee of uptime or availability.

From an implementation perspective, preemptible VMs are identical to regular VMs in terms of operating system, networking, storage, and other configuration options. They can be attached to persistent disks, have static IP addresses (though these are not retained after termination), and can be configured with startup and shutdown scripts. However, because the instance may be terminated without warning, best practices dictate that applications running on preemptible VMs should be stateless or save state externally (e.g., to a database or cloud storage). They should also be designed to handle being stopped and restarted gracefully.

In IT certification exams, you may be tested on scenarios where you need to choose the right compute option for a given workload. Preemptible VMs are contrasted with regular VMs, dedicated hosts, and reserved instances. The key exam points are: (1) preemptible VMs are low-cost, (2) they can be terminated at any time, (3) they are ideal for batch and fault-tolerant workloads, (4) they have no SLA, and (5) they are not recommended for production databases or stateful applications.

## Real-life example

Think about a busy coffee shop that makes fresh pastries every morning. The baker uses the main commercial oven to bake croissants, muffins, and scones for the storefront. That oven is always reserved for the store's primary orders. Now imagine the baker has a second, smaller oven in the back that they only use when the main oven is free. This second oven costs much less to run but it can be turned off at any moment if the main oven needs to be used for a bigger, more profitable batch. The baker uses this spare oven to bake experimental pastries, ones that do not have to be served at a specific time. If the spare oven shuts off, the baker can simply restart later with the leftover dough.

In this analogy, the main oven is a regular VM, always on, reliable, and used for critical tasks like serving customers. The spare oven is a preemptible VM, cheap, but can be turned off without notice. The experimental pastries are batch jobs or data processing tasks that do not need to finish at an exact moment. If the spare oven shuts off, the baker loses some work, but it is not a disaster because the dough can be saved and the work can resume later. This is exactly how preemptible VMs work in the cloud: you get cheap compute capacity for tasks that can tolerate interruptions.

This analogy also highlights the cost aspect. Running the main oven costs a certain amount per hour. Running the spare oven costs far less because it is only used when the main oven does not need it. Similarly, cloud providers offer preemptible VMs at a steep discount because they are using otherwise idle server capacity.

## Why it matters

Preemptible VMs matter enormously in practical IT because they dramatically reduce the cost of running compute-heavy workloads. In many organizations, the biggest cloud expense is compute. By using preemptible VMs for appropriate tasks, you can cut costs by 60-90% compared to regular on-demand instances. For example, a company that processes terabytes of data daily for machine learning model training could save thousands of dollars per month by running those jobs on preemptible VMs instead of regular instances.

Beyond cost savings, preemptible VMs also enable new classes of applications that were previously too expensive. Large-scale scientific simulations, Monte Carlo risk analysis in finance, genome sequencing, and 3D rendering farm operations become financially viable when you can use cheap, interruptible compute resources. This democratizes access to high-performance computing, allowing startups, academic researchers, and small businesses to run massive workloads without breaking their budgets.

However, the trade-off is that you must architect your systems to handle interruptions gracefully. This means implementing checkpointing, distributing work into small independent units, using durable storage for partial results, and designing idempotent processes that can be restarted safely. Many modern frameworks, such as Apache Spark, Hadoop, and TensorFlow, can take advantage of preemptible VMs by automatically recovering from interruptions. This shift toward fault-tolerant design is actually a best practice for cloud-native applications in general.

Finally, understanding preemptible VMs is important for cloud cost optimization strategies. Cloud architects and DevOps engineers regularly use preemptible VMs as part of a mixed-instance strategy: running the critical baseline of a workload on regular or reserved instances, then scaling out additional capacity with preemptible VMs to handle spikes in demand. This approach maximizes reliability while minimizing cost.

## Why it matters in exams

Preemptible VMs appear frequently in cloud certification exams, particularly those that focus on compute, cost optimization, and architecture design. The most relevant exams include:

Google Cloud Associate Cloud Engineer and Professional Cloud Architect: In these exams, preemptible VMs are a core compute option. You will see questions about when to use preemptible VMs versus regular VMs, how to design fault-tolerant workloads, and how to combine preemptible VMs with managed instance groups for high availability. The Google Cloud documentation explicitly lists use cases for preemptible VMs, and exam questions often present a scenario where you need to choose the most cost-effective compute solution.

AWS Certified Solutions Architect Associate and Professional: While AWS uses the term 'Spot Instances' instead of preemptible VMs, the concept is identical. You will be tested on the pricing model (spot market with fluctuating prices), the interruption behavior (two-minute notice), and best practices for using Spot Instances in a launch template or Auto Scaling group. Questions may ask you to design a cost-optimized architecture for a batch processing job or to identify which workloads are suitable for Spot Instances.

Azure Administrator and Azure Solutions Architect: Azure calls these 'Spot VMs' or 'Low-Priority VMs' (in batch pools). Exam objectives include understanding eviction policies, pricing, and supported regions. You may encounter questions about configuring Azure Batch with low-priority nodes or choosing the right compute option for a serverless application.

CompTIA Cloud+ and CompTIA Cloud Essentials: These certifications cover cloud concepts broadly, including cost optimization and instance types. Preemptible VMs may appear as a feature of cloud infrastructure that allows cost savings when workloads can tolerate interruptions.

Exam questions typically assess your ability to: (1) identify the scenario where preemptible VMs are appropriate, (2) understand the trade-offs (lower cost versus potential termination), (3) design applications that are interruption-tolerant, (4) select the right instance type for a given workload, and (5) explain how pricing differs from reserved or on-demand instances. You will likely see multiple-choice questions with a scenario and cost constraints, as well as case studies where you must choose the best compute solution.

## How it appears in exam questions

In certification exams, preemptible VM questions generally fall into three categories: scenario-based selection, configuration understanding, and troubleshooting.

Scenario-based selection questions present a use case and ask you to pick the most appropriate compute option. For example: 'A company needs to run a large-scale data processing job every night. The job can be stopped and resumed, and cost is the primary concern. Which compute option should they choose?' The correct answer is preemptible VMs (or Spot Instances/Low-Priority VMs). Another scenario might describe a time-sensitive, stateful application like a web server fronting a database. Here, preemptible VMs would be a bad choice because the application cannot tolerate being stopped.

Configuration questions test your knowledge of how to set up preemptible VMs. In Google Cloud, you might be asked: 'When creating a VM instance, where do you select the preemptible option?' or 'What happens when a preemptible VM is terminated after 24 hours?' (Google Cloud preemptible VMs have a maximum runtime of 24 hours). On AWS, you might be asked about the maximum runtime for Spot Instances or how to configure a spot request with a valid duration. On Azure, questions may focus on the eviction policy settings or how to use Spot VMs with an availability set.

Troubleshooting questions assess your ability to diagnose issues caused by preemptible VM terminations. For instance: 'A data processing job that runs on preemptible VMs fails intermittently. What is the most likely cause?' The answer is that the VMs were terminated by the provider. The follow-up might ask: 'How should you redesign the job to handle this?' The solution involves checkpointing, using persistent storage for intermediate results, and retrying logic.

Some questions combine preemptible VMs with other services. For example, you might be asked about using preemptible VMs inside a managed instance group that has autoscaling and instance redistribution. The question could be: 'How can you minimize cost while ensuring the application stays available?' The answer might involve using a mix of regular and preemptible VMs, with the autoscaler adding preemptible instances during demand spikes.

Another common question pattern: 'A startup wants to run a machine learning training job that takes 48 hours. The job does not require persistent storage and can resume from checkpoints. What is the most cost-effective compute option?' The correct answer is preemptible VMs, taking into account the 24-hour max runtime on Google Cloud (which may require using multiple instances or a checkpointing strategy).

## Example scenario

You work for a video streaming company that needs to transcode thousands of hours of video content from raw footage into multiple formats and resolutions (4K, 1080p, 720p). This is a compute-intensive batch process that runs every night. The transcoding job can be divided into many small independent chunks, each video file can be processed separately. If any chunk fails, you can simply rerun that chunk the next night. The company wants to minimize cloud costs because transcoding is not time-critical, and they are willing to accept occasional delays if a job gets interrupted.

You decide to use preemptible VMs for this workload. You create a pool of preemptible virtual machines that each take a video file, transcode it, and upload the output to cloud storage. You configure each VM to save its progress to a shared persistent disk or a database every few minutes. If a VM is terminated suddenly, the transcoding job for that particular video file stops. However, because you saved checkpoints, when another preemptible VM picks up the same file, it can resume from the last saved checkpoint rather than starting from scratch.

Over the course of a month, the company saves 70% on compute costs compared to using regular VMs. Occasionally, during peak cloud usage hours, some VMs are terminated, causing a few video files to take longer to process. But because the transcoding is not urgent, the delays are acceptable. In fact, the cost savings allow the company to transcode more content and offer higher-quality streams to their users.

This scenario highlights the perfect use case for preemptible VMs: a workload that is batch-oriented, fault-tolerant, checkpointable, and not time-critical. The trade-off between lower cost and potential interruption is clearly beneficial here.

## How Preemptible VM Cost Works and Saves Money

Preemptible Virtual Machines are a cornerstone of cost optimisation in cloud computing, particularly within Google Cloud Platform (GCP). Unlike standard VM instances that run at a fixed hourly or per-second rate, preemptible VMs offer a drastically reduced price-often 60-80% less than on-demand instances. This cost advantage comes with a critical trade-off: the cloud provider can terminate (preempt) these instances at any time, typically when it needs to reclaim the underlying hardware for higher-priority workloads. Understanding the cost mechanism is essential for any IT certification exam, as questions frequently test your grasp of when to use preemptible VMs versus on-demand or reserved instances.

The core pricing model for preemptible VMs is dynamic but capped. In GCP, the price is set by Google and varies by machine type and region, but it never exceeds the preemptible cap. For example, an n1-standard-1 instance might cost around $0.01 per hour as preemptible compared to $0.05 per hour on-demand. The low cost stems from the fact that these VMs use spare compute capacity. Because they can be terminated at any moment with a 30-second notice, they are not suitable for mission-critical, stateful, or time-sensitive applications. However, for batch processing, fault-tolerant workloads, and large-scale data analysis, the cost savings are enormous. In AWS, the equivalent is the Spot Instance, which has a similar cost model but uses a bidding system based on current spot price. For certification exams, the key distinction is that preemptible VMs in GCP have a fixed lower price, whereas AWS Spot Instances fluctuate.

It is critical to note that preemptible VMs cannot be migrated to regular VMs, and they cannot be live migrated. They also have a maximum run time of 24 hours before automatic termination, even if the provider does not preempt them earlier. This 24-hour limit is a common exam trap. Preemptible VMs are not covered by any Service Level Agreement (SLA), because they can be terminated at any time. Architects must design applications to handle interruptions gracefully, often using checkpointing, job queues, and stateless processing. The cost optimisation benefit is best realised when you can distribute work across many preemptible instances, knowing that some may be reclaimed but the overall job completes at a fraction of the cost. This section is core to the cost optimisation domain in certifications like the Google Cloud Associate Engineer or Professional Cloud Architect.

the cost mechanism of preemptible VMs provides a powerful lever for reducing compute expenses, but it demands careful workload selection. For exam success, remember the 60-80% discount, the 24-hour maximum lifetime, the lack of SLA, and the 30-second preemption notice. These details are frequently tested in cost optimisation scenarios, and understanding them is non-negotiable for cloud efficiency.

## Preemptible VM Lifecycle States and Graceful Handling

The lifecycle of a Preemptible VM is defined by its ephemeral nature, and mastering its states is crucial for passing cloud certification exams. A preemptible VM starts in the same way as a regular VM-it transitions through provisioning, staging, and running states. However, the key difference lies in the termination process. When GCP decides to preempt the instance, it does not instantly destroy it. Instead, it sends an ACPI G2 soft-off signal, which gives the VM a 30-second preemption notice. During this window, the operating system can perform a graceful shutdown. If the instance does not shut down on its own, it is forcibly terminated after 30 seconds. This lifecycle is a frequent exam topic, as it tests your understanding of how to handle preemption in application design.

The preemption event triggers a change in the instance's status. When a VM is preempted, GCP moves it from RUNNING to TERMINATED state. Importantly, the attached persistent disks (if any) are not automatically deleted, but the VM instance itself is terminated. After a terminated state, you can restart the instance, but it may not start again as a preemptible VM if capacity is unavailable. This is different from a standard VM where you can restart at any time. The 30-second notice is the window your application can use to save state, flush data, or signal to a job manager that it has been interrupted. In exam questions, they often present a scenario where a batch job fails because the developer did not implement checkpointing, and you must identify the correct fix-using start scripts or shutdown scripts to handle the preemption signal.

Shutdown scripts are a vital tool. In GCP, you can define a shutdown script in the instance metadata that runs when the VM receives a preemption notice. This script can archive work, write results to persistent storage, or deregister the instance from a load balancer. For example, if you are running data processing tasks on preemptible VMs, you can use the shutdown script to save the last processed record to Cloud Storage, allowing the next instance to resume from that point. This technique is commonly tested in certification exams because it demonstrates practical resilience. You must understand that preemptible VMs do not support live migration or automatic restart policies that guarantee resumption after a preemption event. The lifecycle states-PROVISIONING, STAGING, RUNNING, STOPPING, TERMINATED-are the same as regular VMs, but the transition to TERMINATED can happen at any time due to preemption.

Another important aspect is the maximum run duration of 24 hours. Even if not preempted by the provider, the instance is automatically stopped after 24 hours of continuous runtime. This is a unique lifecycle constraint not present in regular VMs. Exam questions often include this point as a distractor, so remember that preemptible VMs cannot run indefinitely. The lifecycle also includes the possibility of the instance being unable to start due to lack of capacity. When you attempt to create or restart a preemptible VM, it may fail if there is no spare capacity in the zone. You must then retry or use a different zone. This capacity limitation is another exam favourite. Knowing the states, the 30-second grace period, the use of shutdown scripts, and the 24-hour hard limit will prepare you for any lifecycle-related question in the cloud cost optimisation domain.

## Common mistakes

- **Mistake:** Using preemptible VMs for a production database
  - Why it is wrong: Databases are stateful and require high availability. If the VM is terminated, you lose data or face significant downtime.
  - Fix: Use regular VMs, or managed database services (like Cloud SQL, RDS) that provide automatic replication and failover.
- **Mistake:** Thinking preemptible VMs are cheaper than reserved instances
  - Why it is wrong: Reserved instances offer a discount for a one-year or three-year commitment, but they guarantee availability. Preemptible VMs are cheaper per hour but offer no availability guarantee.
  - Fix: For steady-state workloads that run 24/7, reserved instances are more cost-effective. Use preemptible VMs only for short-lived or batch workloads.
- **Mistake:** Assuming preemptible VMs will never be terminated
  - Why it is wrong: Preemptible VMs can be terminated at any time, with only a short warning. Relying on them for critical tasks can lead to application failure.
  - Fix: Design your application to handle interruptions using checkpointing, retries, and external state storage.
- **Mistake:** Not checking the maximum runtime limit
  - Why it is wrong: On Google Cloud, preemptible VMs have a 24-hour maximum runtime. If your job takes longer, the VM will be terminated even if the provider does not need the capacity.
  - Fix: Break long jobs into smaller chunks or use checkpointing to save progress before the 24-hour limit.
- **Mistake:** Using preemptible VMs for interactive user-facing applications
  - Why it is wrong: If a user is accessing an application and the backend VM is terminated, the user experiences an error or session loss. This harms user experience.
  - Fix: Use regular VMs or serverless compute for user-facing workloads.

## Exam trap

{"trap":"Preemptible VMs are always available if you are willing to pay the market price.","why_learners_choose_it":"Learners may confuse preemptible VMs with on-demand VMs and assume that higher bid prices guarantee availability.","how_to_avoid_it":"Remember that preemptible VMs do not offer any availability guarantee regardless of price. The cloud provider can terminate them at any time. This is a fundamental characteristic, not a configuration option."}

## Commonly confused with

- **Preemptible VM vs Reserved Instance:** A reserved instance is a long-term commitment (1 or 3 years) where you pay upfront or monthly for a significant discount compared to on-demand pricing. In return, the cloud provider guarantees availability of that instance type in a specific region. Preemptible VMs have no commitment and no guarantee of availability. (Example: Reserved instance: like leasing an apartment for a year. Preemptible VM: like using a hotel room that the hotel can reclaim at any time.)
- **Preemptible VM vs Dedicated Host:** A dedicated host gives you a physical server that is exclusively yours. You have full control and visibility over the underlying hardware. Preemptible VMs run on shared hardware that can be reclaimed. Dedicated hosts are used for compliance or licensing reasons, while preemptible VMs are used for cost savings. (Example: Dedicated host: your own private house. Preemptible VM: a shared taxi that can kick you out mid-route.)
- **Preemptible VM vs Burstable Instance:** Burstable instances (like AWS T2/T3 or Azure B-series) are regular VMs that can handle low-to-moderate baseline CPU usage and burst to higher performance when needed. They are not preemptible, they are not terminated by the provider. The trade-off is different: lower steady-state performance with occasional bursts, not risk of termination. (Example: A burstable instance is like a car that gets good gas mileage usually but can accelerate quickly when needed. A preemptible VM is a ride that might end early.)

## Step-by-step breakdown

1. **Provisioning the preemptible VM** — You choose a preemptible VM option during instance creation. The cloud provider allocates spare capacity from its unused compute pool. The VM boots up exactly like a regular VM, with the same OS and configuration.
2. **Application starts and runs** — After boot, your application begins executing its tasks. It should save progress regularly to external, durable storage (like cloud storage or a database). This checkpointing ensures minimal data loss if the VM is terminated.
3. **Provider decides to reclaim capacity** — When the provider needs the physical server for a higher-priority workload or when the spare capacity is exhausted, it sends a termination notice. In Google Cloud, this is a 30-second warning via an ACPI shutdown signal.
4. **Graceful shutdown initiated** — Your VM receives the shutdown signal. You have a brief window (e.g., 30 seconds) to run cleanup scripts, save final checkpoints, and close connections. The operating system performs a soft shutdown.
5. **VM is terminated and resources freed** — After the grace period, the VM is forcibly stopped and deallocated. Any data on the local (ephemeral) disk is lost. Persistent disks and other attached storage are retained, but the instance itself no longer exists.
6. **(Optional) Job resumes on another preemptible VM** — If you have configured a retry mechanism, another preemptible VM can be started to continue the interrupted job. It reads the checkpoint data from persistent storage and resumes from the last saved state.

## Practical mini-lesson

Preemptible VMs are a powerful tool for cost optimization, but they require a specific approach to application design. The core principle is that your application must tolerate interruption and recover gracefully. In practice, this means breaking your work into small, independent units. For example, if you are processing a large dataset, divide it into many small files or chunks. Each chunk can be processed by a separate VM, and if one VM is terminated, only that chunk is lost, not the entire job.

Checkpointing is another essential technique. Your application should periodically save its intermediate state, for instance, after processing every 1000 records, to durable storage such as cloud object storage (Google Cloud Storage, Amazon S3, Azure Blob Storage) or a database. When the job resumes on a new VM, it reads the last checkpoint and continues from there, avoiding reprocessing of all previous work.

When using managed instance groups or autoscaling groups with preemptible VMs, you can configure mixed-instance policies. For example, you can set the group to launch a certain percentage of preemptible VMs (e.g., 80%) and the rest as regular VMs. This provides a baseline of reliable capacity while achieving cost savings. You can use instance distribution strategies to spread preemptible VMs across multiple zones to reduce the risk of simultaneous termination.

What can go wrong? The most common issue is that all your preemptible VMs in a particular zone might be terminated simultaneously if the provider needs a large block of capacity. This can cause your entire batch job to stall until new VMs are provisioned. To mitigate this, you should spread your workload across multiple regions or zones, use a queuing system (like Cloud Tasks or AWS SQS) to manage job distribution, and design your application to tolerate temporary unavailability of compute resources.

Professionals should also monitor the termination rate and cost of preemptible VMs using cloud monitoring tools. Google Cloud provides 'preemptible VM termination' metrics in Cloud Monitoring. AWS offers Spot Instance interruption notices via CloudWatch Events. You can set up alerts to notify you if the termination rate exceeds a threshold, which may indicate that you should adjust your bidding strategy or switch to regular instances for critical workloads.

Finally, remember that preemptible VMs are not a 'set it and forget it' solution. You must design, test, and monitor your applications to ensure they handle interruptions correctly. But when done right, the cost savings are substantial, often making the difference between a project being financially viable or not.

## Commands

```
gcloud compute instances create preemptible-vm --zone=us-central1-a --preemptible --image-family=ubuntu-2204-lts --image-project=ubuntu-os-cloud
```
Creates a preemptible VM in GCP using the --preemptible flag. This is the default way to launch a low-cost, interruptible instance for batch workloads.

*Exam note: Tests knowledge of the --preemptible flag for instance creation. Remember that without this flag, the VM is on-demand and costs more. Also note the zone must have spare capacity.*

```
gcloud compute instances add-metadata preemptible-vm --metadata=shutdown-script='#!/bin/bash
echo "Preempted at $(date)" >> /var/log/preempt.log
/usr/bin/python3 /opt/save_checkpoint.py'
```
Adds a shutdown script to a preemptible VM. This script runs automatically during the 30-second preemption notice, allowing graceful state saving.

*Exam note: Shutdown scripts are crucial for preemptible VMs in exams. They test your ability to handle preemption gracefully. The script must be idempotent and fast.*

```
aws ec2 request-spot-instances --instance-count 10 --type one-time --spot-price "0.05" --launch-specification "{\"ImageId\":\"ami-0abcdef1234567890\",\"InstanceType\":\"t3.micro\"}"
```
Requests AWS Spot Instances using the CLI. These are the AWS equivalent of preemptible VMs, with a bid price and one-time request type.

*Exam note: Tests understanding of spot instance bidding. For certification, remember the difference between one-time and persistent requests, and that spot instances have no SLA.*

```
aws ec2 create-launch-template --launch-template-name my-spot-template --launch-template-data "{\"InstanceMarketOptions\":{\"MarketType\":\"spot\"}}"
```
Creates a launch template configured for spot instances. Useful for auto scaling groups that use spot instances to reduce costs.

*Exam note: Exams test the use of InstanceMarketOptions with MarketType set to 'spot'. This is how you enforce spot instance usage in launch templates and auto scaling.*

```
gcloud compute instances update preemptible-vm --no-preemptible
```
Attempts to change a preemptible VM to a regular (on-demand) VM. However, this operation may fail if the instance is running due to capacity constraints.

*Exam note: This command is a distractor. In reality, you cannot convert a running preemptible VM to non-preemptible-you must stop it first. Exams test this limitation.*

```
gcloud compute instances list --filter="status=RUNNING AND scheduling.preemptible=True"
```
Lists all running preemptible VMs in the current project. Useful for auditing cost-saving resources.

*Exam note: Filters are common in exams to test command fluency. Remember that preemptible VMs are identified by scheduling.preemptible attribute.*

```
aws ec2 describe-spot-price-history --instance-types t3.micro --start-time 2025-03-20T00:00:00Z --end-time 2025-03-21T00:00:00Z --product-description "Linux/UNIX"
```
Queries AWS spot price history for a specific instance type over a time range. Useful for cost analysis before launching spot fleets.

*Exam note: Tests ability to analyse spot pricing trends. Exams may ask about the importance of checking price history to optimise spot instance usage.*

## Memory tip

Think of 'preemptible' as 'pre-empted', the provider takes back the VM before you finish. Use only for jobs that can be interrupted.

## FAQ

**What happens to my data when a preemptible VM is terminated?**

Local (ephemeral) disk data is lost. However, persistent disks and data stored in external services (like cloud storage or databases) are retained. The VM itself is deleted.

**Can I use preemptible VMs for a web server?**

It is not recommended for production web servers because if the VM is terminated, the website goes down. However, you can use preemptible VMs in an autoscaling group with multiple instances to provide some resilience.

**How much can I save by using preemptible VMs?**

Typical savings range from 60% to 90% compared to on-demand VM pricing, depending on the cloud provider and instance type.

**What is the maximum runtime for a preemptible VM in Google Cloud?**

Google Cloud preemptible VMs have a maximum runtime of 24 hours. After that, the VM is automatically terminated.

**Are preemptible VMs available in all regions?**

Most cloud providers offer preemptible VMs in many regions, but availability can vary. Check the provider's documentation for the latest list of supported regions.

**Can I attach a GPU to a preemptible VM?**

Yes, many cloud providers allow attaching GPUs to preemptible VMs, which can significantly reduce costs for GPU-intensive workloads like machine learning training. However, GPU capacity is often limited, so you may face higher termination rates.

**Do preemptible VMs have a service-level agreement (SLA)?**

No. Preemptible VMs are offered without any SLA because the provider may terminate them at any time.

## Summary

A preemptible VM is a cost-effective compute option offered by cloud providers that allows you to use spare capacity at a steep discount, with the trade-off that the VM can be terminated at any time. This concept is critical for IT professionals who want to optimize cloud costs without sacrificing too much reliability. Preemptible VMs are ideal for batch processing, data analysis, rendering, testing, and other workloads that are fault-tolerant and can be interrupted.

In certification exams, preemptible VMs appear as a key compute option in cost optimization questions. You need to understand when to use them, how they differ from reserved and dedicated instances, and what application design patterns are required to handle interruptions. Common mistakes include using them for stateful or critical applications, and assuming they are always available.

The key takeaway for exam success is this: Preemptible VMs are a powerful cost-saving tool, but they demand a fault-tolerant architecture. Always ask yourself whether the workload can handle being stopped in the middle of processing. If yes, preemptible VMs can save your organization a lot of money. If no, stick with regular or reserved instances. Remember the 30-second grace period, the lack of SLA, and the importance of checkpointing. With this knowledge, you will be well-prepared to answer exam questions and make real-world design decisions.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/preemptible-vm