Compute Engine instances with deletion protection turned off
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-148 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_deletion_protection.go |
Where it applies
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:
gcloud compute instances update my-vm --zone us-central1-a --deletion-protectionThe 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
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.