# GCP VM Deletion Protection Disabled

> ZopNight rule RC-148 flags standalone Compute Engine instances whose discoverer-confirmed deletionProtection flag is false. VMs inside managed instance groups, GKE node pools, or Dataproc clusters are skipped, because GCP forbids the flag there. One gcloud command fixes a finding; the rule abstains whenever the flag was never observed.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-vm-deletion-protection-disabled
Updated: 2026-08-19

---

## The cheapest insurance in Compute Engine

Deletion protection is a single boolean on the instance. While it is on, every delete path (console, gcloud, Terraform, a scripted cleanup job) fails with an error until someone deliberately flips the flag off first. Turning it on costs nothing and takes one command:

```bash
gcloud compute instances update my-vm --zone us-central1-a --deletion-protection
```

The forced two-step delete is the whole point. Most accidental terminations are not malice; they are a wrong project in the active gcloud configuration, a stale Terraform state, or a cleanup script whose filter matched too broadly. The flag converts each of those from an outage into an error message.

## What RC-148 reads before it fires

The GCP discoverer stamps the `deletion_protection` state into resource metadata in both polarities, so the rule can prove the condition rather than infer it: a finding is raised only on a confirmed `false`, and the rule abstains whenever the flag is absent or unparseable. An instance the discoverer never enriched produces no finding at all. Discovery runs read-only, under `roles/cloudasset.viewer`.

## Managed group members are deliberately excluded

GCP refuses to set deletion protection on instances that belong to a managed instance group, which covers every GKE node and Dataproc worker. Those instances always surface with the flag false while also carrying a parent reference, and the rule skips anything whose parent field is populated. Without that gate it would raise an unactionable finding on every autoscaled node in the fleet. Standalone VMs, including members of unmanaged instance groups, are still evaluated, because the flag genuinely applies to them.

## Check an instance yourself

```bash
gcloud compute instances describe my-vm --zone us-central1-a \
  --format='value(deletionProtection)'
```

## Before you rely on it

Two caveats. Deletion protection guards the instance object, not its data: attached disks can still be deleted or corrupted independently, so pair this control with a snapshot schedule on the disks. And plan the eventual teardown: decommissioning a protected VM is a two-step operation by design, so put the flag flip into the decommission runbook rather than discovering it mid change window.