Blog: Cleaning Up Orphaned GCP Persistent Disks with Neo

[kramhuber]

Summary

Short blog post (~750 words) on clearing orphaned GCP persistent disks with Neo, gated by a CrossGuard policy that blocks any delete without a fresh snapshot label. Workflow uses Read-Only Mode for discovery, Plan Mode to scope the destroy, a two-phase snapshot-then-delete execution, and an approval gate at each phase.

Post content

• Draft status: frontmatter has draft: true so the post does not render until a maintainer flips it.
• Author: mark-huber (byline can be reassigned).
• Path: content/blog/cleaning-up-orphaned-gcp-disks-with-neo/index.md.
• No meta_image / feature_image yet — add feature.png and meta.png to the post directory before publish.
• No social block yet — editorial can supply Twitter/LinkedIn/Bluesky copy.

Items flagged for author verification before publishing

These claims in the post should be confirmed against live product behavior:

• Read-Only Mode and Plan Mode behavior matches the post's description (references Read-Only Mode announcement and Plan Mode announcement).
• The CrossGuard policy example uses validateResourceOfType(gcp.compute.Disk, (disk, args) => ...). Confirm this signature and the disk.labels access path against the current @pulumi/policy and @pulumi/gcp packages.
• The Resources: - N to delete placeholder in the preview snippet — the post deliberately avoids a fabricated count.
• Exact fields recorded in the Pulumi Cloud audit log for Neo destroy operations against a CrossGuard-protected stack.
• Illustrative values in the preview snippet (disk name, zone, size, creation time) are intentional and not claimed as real.

Why a draft PR

Companion to the import post (#18617). Looking for editorial review on voice, accuracy, and framing before publishing.