Compute Engine VMs with no snapshot schedule on their disks
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1200 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | vm_backup.go |
Where it applies
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.
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:
gcloud compute resource-policies create snapshot-schedule daily-snaps \ --region us-central1 --max-retention-days 14 \ --daily-schedule --start-time 04:00gcloud compute disks add-resource-policies my-disk \ --zone us-central1-a --resource-policies daily-snapsRetention 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.