# GCP VM Missing Snapshot Schedule

> Compute Engine instances without an attached snapshot schedule are flagged by ZopNight rule RC-1200 as a medium-severity compliance gap. Detection fires only on the discoverer's explicit snapshot_schedule=false stamp and abstains otherwise. Remediation is a resource policy attached to each persistent disk; the finding clears automatically on the next discovery pass.

Source: https://zop.dev/integrations/gcp/recommendations/gcp-vm-missing-snapshot-schedule
Updated: 2026-08-19

---

## When the disk is gone and there is nothing to restore from

The incident this rule exists for is mundane: a persistent disk deleted along with its instance, a bad deploy that corrupts a data directory, a fat-fingered `rm` inside the guest. On a VM with a snapshot schedule, recovery is "create a disk from last night's snapshot." On a VM without one, recovery is archaeology: hunting for an old manual snapshot, a machine image somebody took months ago, or a copy of the data on another system. The gap only becomes visible on the worst possible day.

## A disk policy, not a VM setting

Snapshot schedules in GCP are resource policies that attach to persistent disks, not to the instance itself. That distinction matters for remediation: fixing a flagged VM means attaching a schedule to each of its disks, and a VM with a boot disk on a schedule but a data disk without one is only half covered.

```bash
gcloud compute disks describe my-disk --zone us-central1-a \
  --format='value(resourcePolicies)'
```

An empty result means no schedule is attached to that disk.

## How ZopNight decides to fire

Rule RC-1200 reads the discoverer-stamped `snapshot_schedule` signal from the resource's metadata sink, falling back to the legacy tags mirror only when metadata is absent. The gate is fail-closed and fires solely on an explicit `false`: a VM whose snapshot state the discoverer could not confirm is never flagged, so absence of evidence never turns into a finding. The check is configuration-only. No snapshot content, size, or age is examined, and the rule cannot tell a tested restore path from an untested one.

## Closing the finding

Create a schedule once per region and attach it to every disk that carries state:

```bash
gcloud compute resource-policies create snapshot-schedule daily-snaps \
  --region us-central1 --max-retention-days 14 \
  --daily-schedule --start-time 04:00
gcloud compute disks add-resource-policies my-disk \
  --zone us-central1-a --resource-policies daily-snaps
```

Retention length is your call. The rule checks for the schedule's existence, not its generosity. Once the discoverer observes the attached schedule, the recommendation clears on its own; there is nothing to acknowledge manually.