{"id":633,"date":"2026-04-14T20:07:08","date_gmt":"2026-04-14T20:07:08","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-persistent-disk-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/"},"modified":"2026-04-14T20:07:08","modified_gmt":"2026-04-14T20:07:08","slug":"google-cloud-persistent-disk-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-persistent-disk-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-compute\/","title":{"rendered":"Google Cloud Persistent Disk Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Compute<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Persistent Disk is Google Cloud\u2019s block storage service for Google Compute Engine (and other Compute-adjacent workloads) that provides durable, high-performance disks you can attach to virtual machines (VMs) as boot or data volumes.<\/p>\n\n\n\n<p>In simple terms: <strong>Persistent Disk is like a virtual hard drive in Google Cloud<\/strong>. You can create a disk, attach it to a VM, format it with a filesystem, mount it, and your data remains intact even if the VM stops, is deleted, or is re-created (as long as you keep the disk).<\/p>\n\n\n\n<p>Technically: Persistent Disk is <strong>network-attached block storage<\/strong> managed by Google Cloud. Disks are provisioned in a zone (zonal) or replicated across two zones in a region (regional). You attach a disk to a Compute Engine VM, and the VM reads\/writes blocks to the disk over Google\u2019s infrastructure. Performance and cost depend on the disk type and size, and some disk types support additional performance provisioning.<\/p>\n\n\n\n<p><strong>What problem it solves:<\/strong> Persistent Disk gives you <strong>durable, manageable, and scalable block storage<\/strong> for VM-based workloads without needing to manage physical disks, RAID, or SAN infrastructure. It also supports operational capabilities like snapshots, resizing, and encryption options to fit production requirements.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Persistent Disk?<\/h2>\n\n\n\n<p>Persistent Disk (often referred to in official docs as <strong>Compute Engine persistent disks<\/strong>) is the primary <strong>block storage<\/strong> offering for Compute Engine. It is designed to be attached to VMs as:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Boot disks<\/strong> (where the OS lives)<\/li>\n<li><strong>Data disks<\/strong> (databases, app state, logs, file storage at the block level)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Provide <strong>durable<\/strong> and <strong>highly available<\/strong> block storage for Compute Engine.<\/li>\n<li>Support <strong>zonal<\/strong> and <strong>regional<\/strong> durability models.<\/li>\n<li>Enable operational workflows like <strong>snapshots<\/strong>, <strong>resize<\/strong>, <strong>disk images<\/strong>, and <strong>encryption controls<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (high-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create and manage disks independently of VM lifecycle.<\/li>\n<li>Attach\/detach disks to VMs.<\/li>\n<li>Choose disk types for different price\/performance goals.<\/li>\n<li>Scale capacity up (and in some cases tune performance) without re-creating the disk.<\/li>\n<li>Protect and clone data via snapshots and images.<\/li>\n<li>Encrypt data at rest with Google-managed keys by default, with options for customer-managed encryption keys (CMEK).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Disk resource<\/strong>: The actual persistent disk object (zonal or regional).<\/li>\n<li><strong>Disk type<\/strong>: Determines performance and price characteristics (for example, balanced vs SSD vs HDD; extreme supports provisioned IOPS\u2014verify current availability and constraints in official docs).<\/li>\n<li><strong>Attachment<\/strong>: A disk attached to a VM via a device name.<\/li>\n<li><strong>Snapshots<\/strong>: Point-in-time, incremental backups of persistent disks.<\/li>\n<li><strong>Images<\/strong>: OS and custom images for boot disks (often built from disks or snapshots).<\/li>\n<li><strong>Snapshot schedules<\/strong>: Policy-based automated snapshot creation (supported for persistent disks\u2014verify constraints like region\/zone and retention policies in the docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed block storage<\/strong> (IaaS building block) in Google Cloud\u2019s <strong>Compute<\/strong> category.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: zonal \/ regional \/ project<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Zonal Persistent Disk<\/strong>: Created in a specific zone (for example, <code>us-central1-a<\/code>). Attachable to VMs in the same zone.<\/li>\n<li><strong>Regional Persistent Disk<\/strong>: Replicated across two zones within a region (for example, <code>us-central1<\/code>). Designed for higher availability; attachable to VMs in one of the replica zones (failover patterns depend on architecture).<\/li>\n<li><strong>Project-scoped management<\/strong>: Disk resources live inside a Google Cloud <strong>project<\/strong> and are governed by IAM, quotas, and organization policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Persistent Disk is a foundational storage primitive for:\n&#8211; <strong>Compute Engine<\/strong> VMs (primary consumer)\n&#8211; Many VM-based architectures (databases, stateful services)\n&#8211; Backup\/DR flows using <strong>snapshots<\/strong> (which are stored in Google-managed storage)\n&#8211; Security and governance using <strong>IAM<\/strong>, <strong>Cloud KMS<\/strong>, <strong>Cloud Audit Logs<\/strong>, and <strong>Cloud Monitoring<\/strong><\/p>\n\n\n\n<blockquote>\n<p>Note on naming and evolution: The service is actively used and documented as <strong>persistent disks<\/strong> under Compute Engine. Google Cloud also offers newer disk families (for example, <strong>Hyperdisk<\/strong>) that target different performance profiles and management models. This tutorial stays focused on <strong>Persistent Disk<\/strong> and calls out alternatives where relevant.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Persistent Disk?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower operational overhead<\/strong>: No storage arrays to manage; provisioning is self-service via API\/CLI\/console.<\/li>\n<li><strong>Right-sized cost<\/strong>: Multiple disk types allow cost\/performance tuning for each workload (dev\/test vs production).<\/li>\n<li><strong>Durability and availability options<\/strong>: Zonal for standard needs; regional replication for higher availability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Durable block storage<\/strong> independent of VM lifecycle.<\/li>\n<li><strong>Elastic capacity<\/strong>: Increase disk size without replacing the disk (with filesystem growth steps inside the OS).<\/li>\n<li><strong>Snapshots and cloning<\/strong>: Incremental snapshots for backup, restore, and rapid environment cloning.<\/li>\n<li><strong>Consistent integration<\/strong>: Works naturally with Compute Engine instance templates, managed instance group patterns (where disks are typically boot disks or separately managed state).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Detachable storage<\/strong>: Move data between VMs by detaching and attaching (within constraints like zone compatibility).<\/li>\n<li><strong>Automation<\/strong>: Manage via <code>gcloud<\/code>, Terraform, Deployment Manager (legacy), or APIs.<\/li>\n<li><strong>Monitoring<\/strong>: Performance and health can be monitored using Cloud Monitoring metrics for disks and instances.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Encryption at rest by default<\/strong>.<\/li>\n<li><strong>CMEK support<\/strong> using Cloud KMS for stronger key control and compliance posture.<\/li>\n<li><strong>IAM controls<\/strong> to restrict who can create, attach, snapshot, or delete disks.<\/li>\n<li><strong>Auditability<\/strong> via Cloud Audit Logs for administrative actions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Disk performance scales by disk type and size, and some types allow <strong>provisioned performance<\/strong> (for example, extreme disk IOPS provisioning\u2014verify current rules).<\/li>\n<li>Designed for production workloads that require consistent performance and durability.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Persistent Disk<\/h3>\n\n\n\n<p>Choose Persistent Disk when you need:\n&#8211; Durable block storage for VMs\n&#8211; Boot disks for Compute Engine\n&#8211; Stateful VM workloads (databases, queues, content processing pipelines)\n&#8211; Snapshot-based backup\/restore for VM volumes\n&#8211; Regional replication option for higher availability<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Persistent Disk<\/h3>\n\n\n\n<p>Avoid Persistent Disk when:\n&#8211; You need <strong>shared POSIX file storage<\/strong> mounted concurrently by many clients: consider <strong>Filestore<\/strong>.\n&#8211; You need <strong>object storage<\/strong> for unstructured data and global access: consider <strong>Cloud Storage<\/strong>.\n&#8211; You need <strong>very high local IOPS with low latency<\/strong> and can tolerate data loss on VM stop\/termination: consider <strong>Local SSD<\/strong>.\n&#8211; You need <strong>Kubernetes-native persistent volumes<\/strong> with different semantics: Persistent Disk can be used through GKE CSI drivers, but you should design using Kubernetes storage abstractions and verify supported features (for example, multi-attach modes).<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Persistent Disk used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and internet services (stateful app tiers)<\/li>\n<li>Financial services (VM-based databases, batch processing)<\/li>\n<li>Healthcare and life sciences (analysis pipelines, regulated workloads needing encryption controls)<\/li>\n<li>Media and entertainment (render farms, transcoding pipelines with durable scratch and output staging)<\/li>\n<li>Manufacturing\/IoT (ingestion, processing nodes storing local state)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams running standardized VM platforms<\/li>\n<li>SRE\/operations teams managing stateful services on VMs<\/li>\n<li>DevOps teams building CI\/CD environments and immutable infrastructure<\/li>\n<li>Security teams enforcing encryption and audit controls<\/li>\n<li>Data engineering teams running ETL on VMs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Relational databases on VMs (where managed databases aren\u2019t used)<\/li>\n<li>NoSQL databases or search clusters on VMs<\/li>\n<li>VM-based CI runners and build caches<\/li>\n<li>Stateful monolith applications<\/li>\n<li>Batch processing nodes needing durable intermediate state<\/li>\n<li>Logging\/metrics systems running on VMs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single-zone VM + zonal disk (dev\/test or non-critical workloads)<\/li>\n<li>Multi-zone HA app where data resides on a <strong>regional persistent disk<\/strong><\/li>\n<li>Snapshot-based backup\/DR across regions (restore snapshots in another region\u2014verify cross-region snapshot\/restore behavior and constraints)<\/li>\n<li>Immutable VM patterns with separate persistent data volumes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test<\/strong>: smaller zonal disks, fewer snapshots, cost-focused disk types.<\/li>\n<li><strong>Production<\/strong>: right-sized disks, defined snapshot schedules, CMEK where required, monitoring and alerting, and often regional disks for availability.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Persistent Disk is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Boot disk for Compute Engine VMs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> VMs need a durable OS volume to boot reliably.<\/li>\n<li><strong>Why Persistent Disk fits:<\/strong> Persistent Disk is the default boot disk for most Compute Engine instances.<\/li>\n<li><strong>Scenario:<\/strong> A web application VM uses a boot persistent disk with a hardened OS image and patching schedule.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Stateful database on a single VM<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A database needs durable storage with predictable performance.<\/li>\n<li><strong>Why it fits:<\/strong> SSD or balanced persistent disks provide durability, resizing, and snapshot backups.<\/li>\n<li><strong>Scenario:<\/strong> A MySQL VM uses a dedicated SSD persistent disk for <code>\/var\/lib\/mysql<\/code> and daily snapshots.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Highly available VM state using regional persistent disks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Zonal failure should not require restoring from backup to resume service.<\/li>\n<li><strong>Why it fits:<\/strong> Regional Persistent Disk replicates data across two zones in a region.<\/li>\n<li><strong>Scenario:<\/strong> A VM-based app stores critical state on a regional disk; a failover VM in the second zone can attach the disk during incident response (architecture must be designed carefully\u2014verify the recommended failover procedure in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Backup and point-in-time recovery with snapshots<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need fast backups and the ability to restore volumes after data corruption.<\/li>\n<li><strong>Why it fits:<\/strong> Snapshots are incremental and can be automated with schedules.<\/li>\n<li><strong>Scenario:<\/strong> A nightly snapshot schedule retains 14 days of backups; a corrupted volume is restored to a new disk within minutes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Environment cloning for QA\/staging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Creating realistic test environments takes too long.<\/li>\n<li><strong>Why it fits:<\/strong> Snapshots\/images can rapidly create new disks with the same data.<\/li>\n<li><strong>Scenario:<\/strong> A staging environment is created by snapshotting production data (after masking) and restoring to a staging disk.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Data processing worker with durable intermediate state<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Batch jobs must survive VM restarts and keep intermediate files.<\/li>\n<li><strong>Why it fits:<\/strong> Persistent Disk keeps data across VM lifecycle events.<\/li>\n<li><strong>Scenario:<\/strong> A nightly ETL pipeline writes intermediate artifacts to a data disk and resumes if the VM is restarted.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Application logs and artifacts separated from OS<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> OS disk fills up or must be rebuilt without losing logs.<\/li>\n<li><strong>Why it fits:<\/strong> Separate data disk reduces coupling and simplifies re-imaging.<\/li>\n<li><strong>Scenario:<\/strong> <code>\/var\/log\/app<\/code> is mounted on a dedicated disk; OS can be replaced while keeping log history (subject to retention and compliance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) VM migration \/ replacement while preserving data<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must upgrade machine types or rebuild instances without data loss.<\/li>\n<li><strong>Why it fits:<\/strong> Detach data disk, reattach to a new VM in the same zone.<\/li>\n<li><strong>Scenario:<\/strong> A legacy VM is replaced with a newer machine type; the data disk is attached to the new VM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Shared read-only content distribution<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Multiple VMs need the same static data set (reference datasets, golden files).<\/li>\n<li><strong>Why it fits:<\/strong> Persistent Disk can be attached read-only to multiple instances (verify limits and best practices in docs).<\/li>\n<li><strong>Scenario:<\/strong> A fleet of VMs attach a disk read-only containing ML model artifacts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Consistent baseline for golden images<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need standardized boot disks for compliance and repeatability.<\/li>\n<li><strong>Why it fits:<\/strong> Create an image from a disk\/snapshot and use it across instance templates.<\/li>\n<li><strong>Scenario:<\/strong> Security team publishes a hardened OS image monthly; app teams build VMs from it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) DR testing with snapshot restore<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You need periodic disaster recovery drills without complex replication setups.<\/li>\n<li><strong>Why it fits:<\/strong> Restore snapshots into a new project\/region (subject to IAM and constraints).<\/li>\n<li><strong>Scenario:<\/strong> Quarterly DR test restores snapshots and validates application startup runbooks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Stateful services in hybrid designs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A hybrid system needs VM nodes in cloud storing local state with managed encryption.<\/li>\n<li><strong>Why it fits:<\/strong> Persistent Disk integrates with Cloud KMS and IAM for centralized policy.<\/li>\n<li><strong>Scenario:<\/strong> A hybrid scheduler uses Compute Engine workers with persistent disks for queue state.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on commonly used, current capabilities of Persistent Disk as part of Google Cloud Compute.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Disk types (HDD\/SSD and variants)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Lets you choose performance and cost characteristics (for example, HDD for throughput-heavy, cost-sensitive workloads; SSD\/balanced for higher IOPS).<\/li>\n<li><strong>Why it matters:<\/strong> Your disk type is one of the biggest drivers of both <strong>performance<\/strong> and <strong>cost<\/strong>.<\/li>\n<li><strong>Practical benefit:<\/strong> You can run dev\/test cheaply and production with better performance where needed.<\/li>\n<li><strong>Caveats:<\/strong> Performance depends on disk type, disk size, and VM limits. Refer to official performance tables and limits: https:\/\/cloud.google.com\/compute\/docs\/disks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Zonal and regional disks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Zonal disks live in one zone; regional disks replicate across two zones in a region.<\/li>\n<li><strong>Why it matters:<\/strong> Regional disks are a key building block for higher availability for stateful VM services.<\/li>\n<li><strong>Practical benefit:<\/strong> Improved resilience to zonal failures compared to single-zone storage.<\/li>\n<li><strong>Caveats:<\/strong> Regional disks typically cost more (replication), and your failover design must be tested.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Boot disks and data disks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Persistent Disk can hold the OS (boot) or application data.<\/li>\n<li><strong>Why it matters:<\/strong> Separating OS and data disks improves maintainability.<\/li>\n<li><strong>Practical benefit:<\/strong> Rebuild\/patch OS without touching data volumes.<\/li>\n<li><strong>Caveats:<\/strong> Some OS images and features may have constraints on boot disk type\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Snapshots (incremental backups)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Point-in-time backups of persistent disks; snapshots are incremental after the first snapshot.<\/li>\n<li><strong>Why it matters:<\/strong> Backups and fast restores are essential for operational safety.<\/li>\n<li><strong>Practical benefit:<\/strong> Quick recovery from accidental deletion or corruption.<\/li>\n<li><strong>Caveats:<\/strong> Snapshot consistency depends on workload; for databases, coordinate with application-level quiescing (or use filesystem freeze) for best results.<\/li>\n<\/ul>\n\n\n\n<p>Official docs: https:\/\/cloud.google.com\/compute\/docs\/disks\/snapshots<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Snapshot schedules (policy-based automation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Automates snapshot creation and retention on a schedule.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces human error and makes backups consistent.<\/li>\n<li><strong>Practical benefit:<\/strong> Standard backup policy across environments.<\/li>\n<li><strong>Caveats:<\/strong> Verify schedule capabilities, retention limits, and regional constraints in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Resizing disks (capacity scaling)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Increase disk size without recreating it.<\/li>\n<li><strong>Why it matters:<\/strong> Storage needs grow; resizing avoids migrations.<\/li>\n<li><strong>Practical benefit:<\/strong> Scale capacity with minimal downtime (filesystem expansion may require commands but often no reboot).<\/li>\n<li><strong>Caveats:<\/strong> Decreasing size is generally not supported; plan carefully. You must also grow the filesystem\/partition inside the OS.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Disk attachment and detachment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Attach\/detach data disks to VMs.<\/li>\n<li><strong>Why it matters:<\/strong> Enables maintenance workflows and instance replacement.<\/li>\n<li><strong>Practical benefit:<\/strong> Move a data disk to a new VM in the same zone quickly.<\/li>\n<li><strong>Caveats:<\/strong> Standard mode is typically <strong>single-writer<\/strong> (one VM with read-write). Multi-attach behaviors depend on disk type and feature availability\u2014verify in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption at rest (default) + CMEK<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Encrypts disk data at rest; supports customer-managed keys via Cloud KMS.<\/li>\n<li><strong>Why it matters:<\/strong> Security and compliance requirements often require key control.<\/li>\n<li><strong>Practical benefit:<\/strong> Central key rotation, separation of duties, and auditability.<\/li>\n<li><strong>Caveats:<\/strong> CMEK introduces operational dependencies on Cloud KMS permissions and key availability.<\/li>\n<\/ul>\n\n\n\n<p>Docs: https:\/\/cloud.google.com\/compute\/docs\/disks\/customer-managed-encryption<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Performance tuning (type\/size and provisioned performance where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Some disk offerings allow tuning IOPS\/throughput (for example, extreme persistent disk uses provisioned IOPS\u2014verify).<\/li>\n<li><strong>Why it matters:<\/strong> Databases often need predictable performance.<\/li>\n<li><strong>Practical benefit:<\/strong> Match performance to workload without overprovisioning capacity.<\/li>\n<li><strong>Caveats:<\/strong> Provisioned performance increases cost and has per-zone availability constraints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with images<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Create custom images from disks\/snapshots for repeatable VM builds.<\/li>\n<li><strong>Why it matters:<\/strong> Standardization and immutable infrastructure practices.<\/li>\n<li><strong>Practical benefit:<\/strong> Faster fleet creation, consistent baseline, easier patching cycles.<\/li>\n<li><strong>Caveats:<\/strong> Images are separate resources with their own storage costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Labels and governance hooks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Apply labels for cost allocation and automation; use IAM and org policies for governance.<\/li>\n<li><strong>Why it matters:<\/strong> Large environments need consistent resource hygiene.<\/li>\n<li><strong>Practical benefit:<\/strong> Chargeback\/showback, automated cleanup, policy enforcement.<\/li>\n<li><strong>Caveats:<\/strong> Labels are not a security boundary; use IAM\/org policies for enforcement.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>Persistent Disk is a managed block storage layer that Compute Engine VMs access over Google\u2019s infrastructure:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: APIs and management operations (create disk, attach disk, snapshot disk).<\/li>\n<li><strong>Data plane<\/strong>: Actual block I\/O between VM and the disk service.<\/li>\n<\/ul>\n\n\n\n<p>A VM issues read\/write operations to its attached disk. Google Cloud handles disk replication (for regional disks), durability, and underlying storage maintenance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow (typical)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>You create a disk (zonal or regional) via Console, <code>gcloud<\/code>, Terraform, or API.<\/li>\n<li>You attach the disk to a VM (must be compatible zone\/region rules).<\/li>\n<li>Inside the guest OS, you partition\/format the disk and mount it.<\/li>\n<li>Applications perform I\/O; the VM routes block operations to Persistent Disk.<\/li>\n<li>You snapshot the disk (manually or via schedule) for backup.<\/li>\n<li>For restore, you create a new disk from a snapshot and attach it to a VM.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine<\/strong>: Primary attachment target.<\/li>\n<li><strong>Cloud Monitoring<\/strong>: Disk and instance performance metrics.<\/li>\n<li><strong>Cloud Logging \/ Cloud Audit Logs<\/strong>: Administrative activity (who created\/deleted disks\/snapshots).<\/li>\n<li><strong>Cloud KMS<\/strong>: CMEK for encryption key control.<\/li>\n<li><strong>IAM<\/strong>: Access control for disk operations.<\/li>\n<li><strong>VPC<\/strong>: Disks are not addressed on the network like NFS; attachment is a Compute resource relationship, not a routable endpoint.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine API<\/strong><\/li>\n<li><strong>IAM<\/strong><\/li>\n<li><strong>Cloud KMS<\/strong> (only if using CMEK)<\/li>\n<li><strong>Cloud Monitoring<\/strong> (for metrics\/alerting)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>API calls are authenticated via Google Cloud IAM identities (users, groups, service accounts).<\/li>\n<li>Authorization is via IAM roles\/permissions on projects (and sometimes on specific resources).<\/li>\n<li>VM-to-disk access is controlled by the fact that the disk is attached to the VM; OS-level access control is then enforced by the guest OS filesystem permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Persistent Disk is not exposed as an IP endpoint. It is attached at the hypervisor\/virtual device layer.<\/li>\n<li>Network egress charges are generally not about \u201cdisk traffic\u201d to the VM; disk I\/O uses Google\u2019s internal infrastructure. However, costs can arise from snapshots, cross-region restore patterns, or data movement at the application layer.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Monitoring<\/strong> dashboards\/alerts for disk throughput, IOPS, latency (where available).<\/li>\n<li>Use <strong>Cloud Audit Logs<\/strong> to track disk create\/delete\/attach\/detach\/snapshot operations.<\/li>\n<li>Use labels for cost allocation and automation (for example, <code>env=prod<\/code>, <code>app=billing<\/code>).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Admin \/ CI-CD] --&gt;|gcloud \/ API| CP[Compute Engine Control Plane]\n  CP --&gt; D[(Persistent Disk)]\n  CP --&gt; VM[Compute Engine VM]\n  VM &lt;--&gt;|Block I\/O| D\n  VM --&gt; APP[Application]\n  APP --&gt;|Reads\/Writes| VM\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<p>This illustrates a typical HA design using a regional disk, snapshot schedule, CMEK, and monitoring.<\/p>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[Google Cloud Organization]\n    subgraph Project[Project: prod-app]\n      subgraph Region[Region: us-central1]\n        subgraph ZoneA[Zone A]\n          VMA[Compute Engine VM A]\n        end\n        subgraph ZoneB[Zone B]\n          VMB[Compute Engine VM B (standby\/failover)]\n        end\n\n        RPD[(Regional Persistent Disk\\nreplicated across Zone A &amp; Zone B)]\n        VMA &lt;--&gt;|Attached RW (normal)| RPD\n        VMB -.-&gt;|Attach during failover| RPD\n\n        SS[Snapshot Schedule Policy]\n        RPD --&gt;|Automated snapshots| SNAP[(Snapshots\\nincremental)]\n      end\n\n      KMS[Cloud KMS Key (CMEK)]\n      RPD -.-&gt;|Encrypted with| KMS\n\n      MON[Cloud Monitoring]\n      VMA --&gt; MON\n      VMB --&gt; MON\n    end\n  end\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Important: Exact HA mechanics (how\/when to attach the disk to a standby VM, fencing to avoid split-brain, application-level clustering requirements) are workload-specific. Use Google\u2019s official HA guidance and test failover procedures.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before you start using Persistent Disk hands-on, ensure you have the following.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud account.<\/li>\n<li>A Google Cloud <strong>project<\/strong> with <strong>billing enabled<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum, for the lab you typically need:\n&#8211; Permissions to create and manage Compute Engine instances and disks.\n  &#8211; Common broad role: <code>roles\/compute.admin<\/code> (powerful; restrict in production).\n&#8211; Permissions to use Cloud Shell (if using it) and to create firewall rules (if needed).<\/p>\n\n\n\n<p>For a least-privilege production model, you would split duties (example concepts):\n&#8211; Disk admins: create\/resize\/snapshot disks\n&#8211; Instance admins: attach\/detach disks to instances\n&#8211; Security admins: manage KMS keys and IAM bindings<\/p>\n\n\n\n<p>Verify exact permissions in official IAM docs: https:\/\/cloud.google.com\/compute\/docs\/access\/iam<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Persistent Disk and snapshots are billable resources.<\/li>\n<li>Some new accounts have free credits; Always verify in Billing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<p>Choose one:\n&#8211; <strong>Cloud Shell<\/strong> (recommended for labs): comes with <code>gcloud<\/code>.\n&#8211; Local machine: install Google Cloud CLI: https:\/\/cloud.google.com\/sdk\/docs\/install<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Persistent Disk is available in most Compute Engine regions\/zones.<\/li>\n<li>Some disk types (and advanced performance options) may be limited to specific zones\/regions. <strong>Verify in official docs<\/strong> when choosing disk types.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>You may encounter:\n&#8211; Max total persistent disk GB per region\/project\n&#8211; Max number of disks per instance\n&#8211; Snapshot quotas\n&#8211; API request quotas<\/p>\n\n\n\n<p>Check quotas: Google Cloud Console \u2192 IAM &amp; Admin \u2192 Quotas, or docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine API<\/strong> enabled in the project.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Persistent Disk pricing is usage-based and depends primarily on:\n&#8211; Disk type\n&#8211; Provisioned capacity (GB-month)\n&#8211; Provisioned performance (for disk types that support it\u2014verify)\n&#8211; Snapshot storage (GB-month of snapshot data stored)\n&#8211; Image storage (if you store custom images)\n&#8211; Regional replication (regional disks typically cost more due to replication)<\/p>\n\n\n\n<p>Official pricing page (start here):\n&#8211; https:\/\/cloud.google.com\/compute\/disks-image-pricing<br\/>\nPricing calculator:\n&#8211; https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Disk capacity (GB-month)<\/strong>\n   &#8211; Charged per provisioned GB per month (prorated).\n   &#8211; Different SKUs for different disk types.<\/p>\n<\/li>\n<li>\n<p><strong>Disk type \/ performance class<\/strong>\n   &#8211; HDD vs SSD vs balanced typically have different rates.\n   &#8211; Some offerings support <strong>provisioned IOPS<\/strong> or throughput; these can add additional charges.<\/p>\n<\/li>\n<li>\n<p><strong>Snapshots (GB-month)<\/strong>\n   &#8211; Snapshots are incremental; billing is based on stored snapshot data size, not full disk size each time.\n   &#8211; Retention policies affect long-term cost.<\/p>\n<\/li>\n<li>\n<p><strong>Images<\/strong>\n   &#8211; Custom images incur storage costs. If you create many images, costs can accumulate.<\/p>\n<\/li>\n<li>\n<p><strong>Regional Persistent Disk<\/strong>\n   &#8211; You are paying for replicated storage across zones; pricing reflects that replication.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud free tier details change over time and vary by service and region. Persistent Disk is generally a paid resource.<\/li>\n<li>Always verify current free tier details: https:\/\/cloud.google.com\/free<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major cost drivers (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overprovisioning disk size \u201cjust in case\u201d.<\/li>\n<li>Using SSD where HDD\/balanced is sufficient.<\/li>\n<li>High snapshot retention with frequent schedules.<\/li>\n<li>Regional disks when zonal would meet requirements.<\/li>\n<li>Provisioned performance (where applicable).<\/li>\n<li>Orphaned disks (VM deleted but disk remains), and orphaned snapshots.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Backup sprawl<\/strong>: snapshots retained longer than needed.<\/li>\n<li><strong>Environment cloning<\/strong>: multiple restored disks from snapshots for staging\/testing.<\/li>\n<li><strong>Cross-region DR tests<\/strong>: repeated restores and temporary VMs.<\/li>\n<li><strong>CMEK operations overhead<\/strong>: not typically a direct cost driver, but adds operational complexity (permissions, key availability) that can impact incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Disk I\/O itself is not billed as network egress in the same way as VPC traffic, but DR patterns can create data movement costs:<\/li>\n<li>Restoring across regions or copying images\/snapshots may have costs. <strong>Verify current behavior and charges<\/strong> in official docs and the pricing page.<\/li>\n<li>Application-level replication between VMs across regions does incur network egress.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the <strong>lowest disk type<\/strong> that meets latency\/IOPS needs.<\/li>\n<li>Right-size capacity; increase size later if needed.<\/li>\n<li>Use snapshot schedules with sensible retention (for example, daily with 7\u201330 days, plus monthly).<\/li>\n<li>Clean up unused snapshots\/images.<\/li>\n<li>Use labels and billing export to track disk spend by app\/team.<\/li>\n<li>Prefer zonal disks for non-critical environments; reserve regional disks for workloads that truly need them.<\/li>\n<li>For performance, scale disk size (where performance scales with size) instead of jumping to the most expensive disk type\u2014verify performance characteristics in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (model, not a quote)<\/h3>\n\n\n\n<p>A typical low-cost lab setup might include:\n&#8211; 1 small VM (Compute cost)\n&#8211; 1 small zonal persistent disk (for example, 10\u201320 GB)\n&#8211; 0\u20132 snapshots<\/p>\n\n\n\n<p>Your monthly cost depends on:\n&#8211; Region\n&#8211; Disk type\n&#8211; Total GB provisioned\n&#8211; Snapshot stored size<\/p>\n\n\n\n<p>Use the calculator and select \u201cCompute Engine \u2192 Disks\u201d to estimate for your region:\n&#8211; https:\/\/cloud.google.com\/products\/calculator<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production, estimate:\n&#8211; Total disk GB across all VMs (boot + data)\n&#8211; Disk types per workload tier (HDD vs balanced vs SSD)\n&#8211; Regional disk premium (if used)\n&#8211; Snapshot frequency and retention (snapshot stored data growth is workload dependent)\n&#8211; Additional clones for staging\/analytics<\/p>\n\n\n\n<p>A good practice is to build a <strong>storage bill of materials<\/strong>:\n&#8211; By application: <code>app<\/code>, <code>env<\/code>, <code>owner<\/code>, <code>data_classification<\/code>\n&#8211; By SLA tier: <code>prod-ha<\/code> vs <code>dev<\/code>\n&#8211; By backup policy: retention days and schedule frequency<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab creates a VM, provisions a Persistent Disk, attaches it, formats and mounts it, writes data, snapshots it, and demonstrates a safe resize workflow. It is designed to be low-cost and easy to clean up.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create a <strong>zonal Persistent Disk<\/strong><\/li>\n<li>Attach it to a <strong>Compute Engine VM<\/strong><\/li>\n<li>Format + mount it<\/li>\n<li>Write test data<\/li>\n<li>Create a <strong>snapshot<\/strong><\/li>\n<li>Resize the disk and expand the filesystem<\/li>\n<li>Clean up all resources<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:\n&#8211; 1 VM (small)\n&#8211; 1 persistent disk (small)\n&#8211; 1 snapshot<\/p>\n\n\n\n<p>You will use:\n&#8211; Google Cloud Console <strong>or<\/strong> Cloud Shell with <code>gcloud<\/code> (commands below assume Cloud Shell)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set project, region, and zone<\/h3>\n\n\n\n<p>Open <strong>Cloud Shell<\/strong> in the Google Cloud Console.<\/p>\n\n\n\n<p>Set environment variables (choose a zone you have access to; example uses <code>us-central1-a<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"$(gcloud config get-value project)\"\nexport ZONE=\"us-central1-a\"\nexport REGION=\"us-central1\"\ngcloud config set compute\/zone \"$ZONE\"\ngcloud config set compute\/region \"$REGION\"\necho \"Project: $PROJECT_ID  Zone: $ZONE  Region: $REGION\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud Shell is configured to use your chosen zone\/region by default.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable the Compute Engine API (if not already enabled)<\/h3>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The Compute Engine API is enabled for the project.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a small VM<\/h3>\n\n\n\n<p>Create a small VM (choose a machine type available in your region; <code>e2-micro<\/code> may not be available in all projects\/regions\u2014if it fails, use <code>e2-small<\/code>).<\/p>\n\n\n\n<pre><code class=\"language-bash\">export VM_NAME=\"pd-lab-vm\"\n\ngcloud compute instances create \"$VM_NAME\" \\\n  --machine-type=\"e2-micro\" \\\n  --image-family=\"debian-12\" \\\n  --image-project=\"debian-cloud\" \\\n  --boot-disk-size=\"10GB\" \\\n  --boot-disk-type=\"pd-balanced\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A VM named <code>pd-lab-vm<\/code> is created and running.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name=($VM_NAME)\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create a Persistent Disk (data disk)<\/h3>\n\n\n\n<p>Create a separate data disk. Use <code>pd-balanced<\/code> for a good default cost\/performance balance.<\/p>\n\n\n\n<pre><code class=\"language-bash\">export DISK_NAME=\"pd-lab-data-disk\"\n\ngcloud compute disks create \"$DISK_NAME\" \\\n  --size=\"20GB\" \\\n  --type=\"pd-balanced\" \\\n  --zone=\"$ZONE\" \\\n  --labels=\"env=lab,service=persistent-disk\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A 20 GB zonal Persistent Disk exists.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute disks describe \"$DISK_NAME\" --zone=\"$ZONE\" \\\n  --format=\"table(name,sizeGb,type,zone,status)\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Attach the disk to the VM<\/h3>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances attach-disk \"$VM_NAME\" \\\n  --disk=\"$DISK_NAME\" \\\n  --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The disk is attached to the VM.<\/p>\n\n\n\n<p>Verify attachment:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances describe \"$VM_NAME\" --zone=\"$ZONE\" \\\n  --format=\"value(disks[].source)\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: SSH into the VM and format\/mount the disk<\/h3>\n\n\n\n<p>SSH:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>Inside the VM, list block devices:<\/p>\n\n\n\n<pre><code class=\"language-bash\">lsblk\n<\/code><\/pre>\n\n\n\n<p>Look for a new disk device (commonly <code>sdb<\/code> with Google Compute Engine, but <strong>do not assume<\/strong>\u2014confirm via <code>lsblk<\/code> size).<\/p>\n\n\n\n<p>Create an ext4 filesystem on the new disk (replace <code>DEVICE<\/code> accordingly, example <code>\/dev\/sdb<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkfs.ext4 -F \/dev\/sdb\n<\/code><\/pre>\n\n\n\n<p>Create a mount point and mount it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mkdir -p \/mnt\/data\nsudo mount \/dev\/sdb \/mnt\/data\ndf -h \/mnt\/data\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>\/mnt\/data<\/code> is mounted and shows ~20 GB capacity.<\/p>\n\n\n\n<p>Make the mount persistent across reboots using UUID:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo blkid \/dev\/sdb\n<\/code><\/pre>\n\n\n\n<p>Copy the UUID value, then edit <code>\/etc\/fstab<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo nano \/etc\/fstab\n<\/code><\/pre>\n\n\n\n<p>Add a line like (replace UUID with yours):<\/p>\n\n\n\n<pre><code class=\"language-bash\">UUID=YOUR_UUID_HERE  \/mnt\/data  ext4  defaults,nofail  0  2\n<\/code><\/pre>\n\n\n\n<p>Test fstab safely:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo umount \/mnt\/data\nsudo mount -a\ndf -h \/mnt\/data\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The disk mounts cleanly via <code>\/etc\/fstab<\/code>.<\/p>\n\n\n\n<p>Exit SSH:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Write data to the Persistent Disk<\/h3>\n\n\n\n<p>SSH back in:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>Write a test file:<\/p>\n\n\n\n<pre><code class=\"language-bash\">echo \"Hello from Persistent Disk at $(date)\" | sudo tee \/mnt\/data\/hello.txt\nsudo ls -l \/mnt\/data\nsudo cat \/mnt\/data\/hello.txt\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can read back <code>hello.txt<\/code> from the persistent disk.<\/p>\n\n\n\n<p>Exit:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a snapshot (backup)<\/h3>\n\n\n\n<p>Create a snapshot of the data disk:<\/p>\n\n\n\n<pre><code class=\"language-bash\">export SNAP_NAME=\"pd-lab-snap-1\"\n\ngcloud compute snapshots create \"$SNAP_NAME\" \\\n  --source-disk=\"$DISK_NAME\" \\\n  --source-disk-zone=\"$ZONE\" \\\n  --labels=\"env=lab,service=persistent-disk\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A snapshot resource is created.<\/p>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute snapshots describe \"$SNAP_NAME\" \\\n  --format=\"table(name,status,creationTimestamp,diskSizeGb,storageBytes)\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Note: <code>storageBytes<\/code> may not be immediately populated.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Resize the disk and grow the filesystem<\/h3>\n\n\n\n<p>Resize the disk from 20 GB to 30 GB:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute disks resize \"$DISK_NAME\" --size=\"30GB\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Disk size is updated at the platform level.<\/p>\n\n\n\n<p>Now expand the filesystem inside the VM.<\/p>\n\n\n\n<p>SSH in:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh \"$VM_NAME\" --zone=\"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>Confirm the block device size:<\/p>\n\n\n\n<pre><code class=\"language-bash\">lsblk\n<\/code><\/pre>\n\n\n\n<p>Expand the ext4 filesystem (example device <code>\/dev\/sdb<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo resize2fs \/dev\/sdb\ndf -h \/mnt\/data\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>\/mnt\/data<\/code> now shows ~30 GB.<\/p>\n\n\n\n<p>Exit:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Run the following checks:<\/p>\n\n\n\n<p>1) Disk exists and is correct size:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute disks describe \"$DISK_NAME\" --zone=\"$ZONE\" \\\n  --format=\"value(sizeGb)\"\n<\/code><\/pre>\n\n\n\n<p>2) Disk is attached to VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances describe \"$VM_NAME\" --zone=\"$ZONE\" \\\n  --format=\"value(disks[].deviceName)\"\n<\/code><\/pre>\n\n\n\n<p>3) Snapshot exists:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute snapshots list --filter=\"name=($SNAP_NAME)\"\n<\/code><\/pre>\n\n\n\n<p>4) Data persisted on disk:\n&#8211; SSH to VM and confirm <code>\/mnt\/data\/hello.txt<\/code> exists.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues and fixes:<\/p>\n\n\n\n<p><strong>Issue: <code>e2-micro<\/code> not available or quota exceeded<\/strong>\n&#8211; Fix: Use <code>--machine-type=e2-small<\/code> or another available type.\n&#8211; Also check quotas in the region.<\/p>\n\n\n\n<p><strong>Issue: Disk device name is not <code>\/dev\/sdb<\/code><\/strong>\n&#8211; Fix: Always use <code>lsblk<\/code> to identify the new disk by size and absence of partitions\/filesystem.<\/p>\n\n\n\n<p><strong>Issue: <code>mount -a<\/code> fails after editing <code>\/etc\/fstab<\/code><\/strong>\n&#8211; Fix:\n  &#8211; Ensure UUID is correct (<code>blkid<\/code>).\n  &#8211; Add <code>nofail<\/code> to avoid boot failures during testing.\n  &#8211; Check syntax: whitespace-separated fields.<\/p>\n\n\n\n<p><strong>Issue: Snapshot stuck or slow<\/strong>\n&#8211; Fix:\n  &#8211; Wait a few minutes; snapshots are asynchronous.\n  &#8211; Ensure Compute API is enabled and you have permissions.<\/p>\n\n\n\n<p><strong>Issue: <code>resize2fs<\/code> fails<\/strong>\n&#8211; Fix:\n  &#8211; Confirm filesystem is ext4.\n  &#8211; Ensure you resized the disk at the cloud layer first.\n  &#8211; For partitions, you might need <code>growpart<\/code> before <code>resize2fs<\/code> (this lab uses the whole disk without a partition to keep it simple).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete resources to stop charges.<\/p>\n\n\n\n<p>1) Delete the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete \"$VM_NAME\" --zone=\"$ZONE\" --quiet\n<\/code><\/pre>\n\n\n\n<p>2) Delete the snapshot:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute snapshots delete \"$SNAP_NAME\" --quiet\n<\/code><\/pre>\n\n\n\n<p>3) Delete the disk:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute disks delete \"$DISK_NAME\" --zone=\"$ZONE\" --quiet\n<\/code><\/pre>\n\n\n\n<p>Verify everything is removed:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances list --filter=\"name=($VM_NAME)\"\ngcloud compute disks list --filter=\"name=($DISK_NAME)\"\ngcloud compute snapshots list --filter=\"name=($SNAP_NAME)\"\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Separate boot and data disks<\/strong> for stateful applications.<\/li>\n<li>Use <strong>regional persistent disks<\/strong> only when you have a clear HA requirement and a tested failover plan.<\/li>\n<li>For databases, align disk selection with workload:<\/li>\n<li>OLTP often needs low latency and higher IOPS.<\/li>\n<li>Batch workloads may prefer throughput and cost efficiency.<\/li>\n<li>Design backups using <strong>snapshots + retention policy<\/strong>, and regularly test restores.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use least privilege:<\/li>\n<li>Separate roles for disk creation vs attachment vs snapshot deletion.<\/li>\n<li>Restrict who can delete disks\/snapshots (accidental deletion is common).<\/li>\n<li>Use <strong>CMEK with Cloud KMS<\/strong> when compliance requires customer-controlled keys.<\/li>\n<li>Consider organization policies to restrict:<\/li>\n<li>External IP usage on VMs (indirectly reduces data exfil risk)<\/li>\n<li>Resource locations (data residency)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Label disks and snapshots with <code>env<\/code>, <code>app<\/code>, <code>owner<\/code>, <code>cost_center<\/code>.<\/li>\n<li>Use snapshot schedules with realistic retention; delete unused snapshots\/images.<\/li>\n<li>Avoid orphaned disks:<\/li>\n<li>Review \u201cDisks\u201d periodically for unattached volumes.<\/li>\n<li>Use the pricing calculator for each region and disk type.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Right-size disk type and size:<\/li>\n<li>Many disk types scale performance with size; check the official performance tables.<\/li>\n<li>Match VM limits:<\/li>\n<li>VM families have max disk throughput\/IOPS ceilings; don\u2019t pay for disk performance the VM can\u2019t use.<\/li>\n<li>For write-heavy databases, consider:<\/li>\n<li>Separating data, logs, and temp areas (depending on DB best practices).<\/li>\n<li>Monitor latency and queue depth indicators (where available) and adjust disk type\/size.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Backups:<\/li>\n<li>Snapshot schedules + periodic restore tests.<\/li>\n<li>HA:<\/li>\n<li>If using regional disks, implement application-level fencing and failover logic to prevent split-brain.<\/li>\n<li>Change management:<\/li>\n<li>Use Infrastructure as Code to standardize disk configuration and labels.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create runbooks for:<\/li>\n<li>Restoring a snapshot to a new disk<\/li>\n<li>Attaching a disk to a recovery VM<\/li>\n<li>Resizing disks and filesystems<\/li>\n<li>Alert on:<\/li>\n<li>Disk nearing capacity<\/li>\n<li>Snapshot failures (where visible)<\/li>\n<li>Unattached disks older than N days (cost leak)<\/li>\n<li>Track disk inventory with asset exports (Cloud Asset Inventory\u2014verify best approach for your org).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use clear naming patterns:<\/li>\n<li><code>app-env-zone-role-01<\/code> (example: <code>orders-prod-uc1a-data-01<\/code>)<\/li>\n<li>Labels:<\/li>\n<li><code>env=prod|staging|dev<\/code><\/li>\n<li><code>app=orders<\/code><\/li>\n<li><code>owner=team-x<\/code><\/li>\n<li><code>data_class=confidential|internal|public<\/code><\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Persistent Disk is managed through <strong>Google Cloud IAM<\/strong>.<\/li>\n<li>Key permissions include:<\/li>\n<li>Create\/delete disks<\/li>\n<li>Attach\/detach disks to instances<\/li>\n<li>Create\/delete snapshots<\/li>\n<li>Use images<\/li>\n<li>Be careful with broad roles like <code>roles\/compute.admin<\/code>; prefer custom roles in mature environments.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data is encrypted at rest by default.<\/li>\n<li>For stronger control:<\/li>\n<li>Use <strong>Customer-Managed Encryption Keys (CMEK)<\/strong> with Cloud KMS.<\/li>\n<li>Ensure the right service accounts have permission to use the key.<\/li>\n<li>Plan for key availability:<\/li>\n<li>If key access is revoked, disks may become unusable until restored (design operational controls accordingly).<\/li>\n<\/ul>\n\n\n\n<p>Docs: https:\/\/cloud.google.com\/compute\/docs\/disks\/customer-managed-encryption<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Disks are not directly network-addressable.<\/li>\n<li>Risk is typically through:<\/li>\n<li>VM compromise (attacker accesses mounted filesystem)<\/li>\n<li>Snapshot\/image access (attacker restores sensitive data)<\/li>\n<li>Mitigations:<\/li>\n<li>Harden VMs, minimize SSH exposure, use OS Login and IAP where appropriate (verify your organization\u2019s standards).<\/li>\n<li>Restrict snapshot permissions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not store secrets unencrypted on disks unless you have a secrets management approach.<\/li>\n<li>Prefer <strong>Secret Manager<\/strong> for application secrets and rotate regularly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to track administrative actions on disks and snapshots.<\/li>\n<li>Monitor for:<\/li>\n<li>Snapshot deletions<\/li>\n<li>Disk deletions<\/li>\n<li>Changes to CMEK key bindings<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data residency: choose regions accordingly; enforce via org policies where available.<\/li>\n<li>Encryption key control: CMEK helps meet compliance requirements for key ownership and rotation.<\/li>\n<li>Retention: snapshot retention must align with regulatory requirements; implement lifecycle policies via schedules and periodic audits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overly broad IAM roles allowing anyone to snapshot\/restore sensitive data.<\/li>\n<li>Leaving snapshots\/images accessible across projects without governance.<\/li>\n<li>Using production snapshots in dev without data masking.<\/li>\n<li>Not protecting against accidental deletion (lack of approval workflows or restricted permissions).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use separate projects for prod vs non-prod.<\/li>\n<li>Enforce IAM boundaries:<\/li>\n<li>Only backup operators can restore production snapshots.<\/li>\n<li>Use CMEK for sensitive workloads and verify KMS permissions are correct.<\/li>\n<li>Regularly test restores in a controlled environment.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Persistent Disk is robust, but several common constraints matter in real deployments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations and constraints (verify exact values in docs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Zonal attachment<\/strong>: Zonal disks must be attached to VMs in the same zone.<\/li>\n<li><strong>Regional disk behavior<\/strong>: Requires architecture to handle failover and avoid split-brain.<\/li>\n<li><strong>Single-writer semantics<\/strong>: Typically, a disk can be attached read-write to only one VM at a time. Some multi-writer\/multi-attach capabilities may exist under specific conditions\/disk types\u2014<strong>verify in official docs<\/strong> before relying on them.<\/li>\n<li><strong>Disk resizing<\/strong>: Increasing size is supported; decreasing size typically is not. Filesystem growth is an OS-level step.<\/li>\n<li><strong>Performance ceilings<\/strong>: VM instances have max disk throughput\/IOPS; you can overpay for disk performance you can\u2019t use.<\/li>\n<li><strong>Snapshot consistency<\/strong>: Snapshots are crash-consistent unless you coordinate application quiescing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Total GB of disks per region\/project.<\/li>\n<li>Snapshot count and snapshot storage.<\/li>\n<li>Disks per instance.<\/li>\n<li>API rate limits.<\/li>\n<\/ul>\n\n\n\n<p>Check quotas in Console or docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all disk types are available in all zones.<\/li>\n<li>Some advanced performance capabilities are limited to specific locations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Regional disks cost more due to replication.<\/li>\n<li>Snapshot storage can grow over time if data changes frequently.<\/li>\n<li>Orphaned disks\/snapshots can silently accumulate cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OS-level tooling:<\/li>\n<li>You need the right filesystem tools (<code>resize2fs<\/code>, <code>xfs_growfs<\/code>, etc.).<\/li>\n<li>Application clustering:<\/li>\n<li>Do not assume shared-disk clustering works without careful configuration and fencing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deleting a VM may or may not delete attached disks depending on \u201cauto-delete\u201d settings; understand your configuration to avoid accidental data loss or unexpected costs.<\/li>\n<li>Snapshot sprawl: automated schedules without retention review can create long-term costs.<\/li>\n<li>CMEK misconfiguration can block VM boot or disk attachment if key permissions are missing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Moving a zonal disk to another zone typically involves snapshots\/restore (or other migration methods). Plan downtime and data consistency carefully.<\/li>\n<li>Cross-region DR requires tested procedures and may involve additional costs and time.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Persistent Disk is one option in Google Cloud\u2019s storage lineup and compares to similar services in other clouds.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in Google Cloud<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Local SSD<\/strong>: very high performance, but data is ephemeral (tied to VM lifecycle).<\/li>\n<li><strong>Filestore<\/strong>: managed NFS for shared file storage.<\/li>\n<li><strong>Cloud Storage<\/strong>: object storage for unstructured data and global access.<\/li>\n<li><strong>Hyperdisk<\/strong>: newer disk offerings aimed at specific performance and scaling characteristics (verify current positioning and availability in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Alternatives in other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS EBS<\/strong>: closest analog (block storage for EC2).<\/li>\n<li><strong>Azure Managed Disks<\/strong>: closest analog (block storage for VMs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Ceph \/ Rook-Ceph<\/strong>: self-managed distributed storage (higher operational overhead).<\/li>\n<li><strong>LVM on attached disks<\/strong>: VM-level volume management (still uses underlying disks).<\/li>\n<li><strong>DRBD<\/strong>: block replication between nodes (complex; usually replaced by managed replication\/HA designs).<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Comparison table<\/h4>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Persistent Disk (Google Cloud)<\/strong><\/td>\n<td>Durable block storage for VMs<\/td>\n<td>Managed, durable, snapshots, resizing, zonal\/regional options<\/td>\n<td>Not a shared filesystem; HA requires design<\/td>\n<td>Default choice for VM boot\/data disks<\/td>\n<\/tr>\n<tr>\n<td><strong>Regional Persistent Disk<\/strong><\/td>\n<td>Higher availability for VM state<\/td>\n<td>Replicated across two zones<\/td>\n<td>Higher cost; failover complexity<\/td>\n<td>When zonal failure tolerance is required<\/td>\n<\/tr>\n<tr>\n<td><strong>Local SSD (Google Cloud)<\/strong><\/td>\n<td>Ultra-low latency\/high IOPS scratch<\/td>\n<td>Very fast<\/td>\n<td>Data not persistent; operational constraints<\/td>\n<td>Caches, scratch space, temp processing<\/td>\n<\/tr>\n<tr>\n<td><strong>Filestore (Google Cloud)<\/strong><\/td>\n<td>Shared file storage (NFS)<\/td>\n<td>POSIX shared access, simpler for shared files<\/td>\n<td>Different pricing\/perf model; NFS semantics<\/td>\n<td>Shared web content, home dirs, shared app data<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud Storage (Google Cloud)<\/strong><\/td>\n<td>Object storage, global access<\/td>\n<td>Very durable, scalable, lifecycle policies<\/td>\n<td>Not block storage; different app patterns<\/td>\n<td>Data lakes, archives, static content<\/td>\n<\/tr>\n<tr>\n<td><strong>Hyperdisk (Google Cloud)<\/strong><\/td>\n<td>Specialized performance\/scaling needs<\/td>\n<td>Modern disk options (verify specifics)<\/td>\n<td>Different model; availability constraints<\/td>\n<td>When PD types don\u2019t meet performance targets<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS EBS<\/strong><\/td>\n<td>Block storage on AWS<\/td>\n<td>Mature ecosystem<\/td>\n<td>Provider lock-in<\/td>\n<td>When deploying on AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Managed Disks<\/strong><\/td>\n<td>Block storage on Azure<\/td>\n<td>Integrated with Azure VMs<\/td>\n<td>Provider lock-in<\/td>\n<td>When deploying on Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Ceph (self-managed)<\/strong><\/td>\n<td>Custom storage platform<\/td>\n<td>Flexible, portable<\/td>\n<td>High ops overhead<\/td>\n<td>When you must self-manage due to requirements<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Regulated billing system on Compute Engine<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A regulated enterprise runs a legacy billing platform on VMs. It needs strong encryption controls, backups, and a path to higher availability.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Compute Engine VMs for application and database tiers.<\/li>\n<li>Database data on <strong>SSD Persistent Disk<\/strong> (or balanced\/SSD based on testing).<\/li>\n<li><strong>Regional Persistent Disk<\/strong> for the most critical state (where HA requirements justify it).<\/li>\n<li><strong>Snapshot schedules<\/strong> with retention aligned to policy.<\/li>\n<li><strong>CMEK<\/strong> encryption via Cloud KMS for compliance.<\/li>\n<li>Monitoring alerts on disk utilization and performance metrics.<\/li>\n<li><strong>Why Persistent Disk was chosen:<\/strong><\/li>\n<li>Managed durability and snapshots reduce operational burden.<\/li>\n<li>CMEK satisfies key control requirements.<\/li>\n<li>Regional disks provide a building block for zonal resilience.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Improved recovery time (restore from snapshots).<\/li>\n<li>Reduced storage management overhead.<\/li>\n<li>Better audit posture for storage operations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: SaaS app with rapid iteration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team runs a VM-based monolith and needs reliable storage without a dedicated storage engineer.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Single Compute Engine VM (or small set) with boot Persistent Disk.<\/li>\n<li>Separate data Persistent Disk for uploads and app state.<\/li>\n<li>Weekly image + daily snapshot schedule.<\/li>\n<li>Labels for cost tracking.<\/li>\n<li><strong>Why Persistent Disk was chosen:<\/strong><\/li>\n<li>Simple operational model and predictable behavior.<\/li>\n<li>Easy resizing as the product grows.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster recovery from mistakes (snapshot restore).<\/li>\n<li>Simple upgrades (replace VM, keep data disk).<\/li>\n<li>Controlled costs by using balanced disks and modest snapshot retention.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is Persistent Disk the same as Cloud Storage?<\/h3>\n\n\n\n<p>No. Persistent Disk is <strong>block storage<\/strong> attached to VMs. Cloud Storage is <strong>object storage<\/strong> accessed over HTTP APIs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Can I use Persistent Disk as shared storage across multiple VMs?<\/h3>\n\n\n\n<p>Typically, a persistent disk is attached <strong>read-write to one VM<\/strong> at a time. Some read-only multi-attach patterns exist, and some multi-writer features may exist under specific constraints. <strong>Verify in official docs<\/strong> before designing shared-write architectures.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) What\u2019s the difference between zonal and regional Persistent Disk?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Zonal<\/strong>: lives in one zone.<\/li>\n<li><strong>Regional<\/strong>: replicated across two zones in a region for higher availability, generally at higher cost and with additional failover planning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Do I lose my data if I stop or delete a VM?<\/h3>\n\n\n\n<p>Stopping a VM does not delete the disk. Deleting a VM may delete attached disks if \u201cauto-delete\u201d is enabled for those disks. Always check disk auto-delete settings.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) How do snapshots work, and are they full copies each time?<\/h3>\n\n\n\n<p>Snapshots are <strong>incremental<\/strong> after the first snapshot. You pay for the stored snapshot data, which depends on how much data changes over time.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Are snapshots application-consistent for databases?<\/h3>\n\n\n\n<p>By default, snapshots are typically crash-consistent. For databases, best practice is to quiesce or freeze I\/O briefly (database tooling or filesystem freeze) before snapshotting, depending on your RPO\/RTO requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Can I resize a Persistent Disk without downtime?<\/h3>\n\n\n\n<p>You can generally <strong>increase<\/strong> disk size online. You must expand the partition\/filesystem in the guest OS. Some workloads might still require maintenance windows\u2014test with your application.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Can I reduce the size of a disk?<\/h3>\n\n\n\n<p>Usually no. Plan for growth; if you must shrink, you typically create a smaller disk, copy data, and cut over.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) How do I choose between HDD, balanced, and SSD disk types?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>HDD: cost-effective, good for sequential throughput and less latency-sensitive workloads.<\/li>\n<li>Balanced: general purpose.<\/li>\n<li>SSD: higher IOPS\/lower latency for demanding workloads.\nAlways validate with workload benchmarks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Does Persistent Disk support encryption?<\/h3>\n\n\n\n<p>Yes. Encryption at rest is default. CMEK with Cloud KMS is available for stronger key control.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) What happens if my Cloud KMS key is disabled?<\/h3>\n\n\n\n<p>If CMEK is used and the key becomes unavailable (disabled, permissions removed), disk operations and VM boot\/attach can fail. Treat KMS as a critical dependency and manage changes carefully.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) How do I back up a Persistent Disk automatically?<\/h3>\n\n\n\n<p>Use <strong>snapshot schedules<\/strong> (where supported) or automation (Cloud Scheduler + Cloud Functions\/Run calling APIs). Snapshot schedules are usually the simplest\u2014verify current capabilities in docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) Can I move a disk to another zone?<\/h3>\n\n\n\n<p>Zonal disks are tied to a zone. Common approach: snapshot the disk and create a new disk from the snapshot in the target zone (verify steps and constraints).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) What should I monitor for Persistent Disk?<\/h3>\n\n\n\n<p>Common signals:\n&#8211; Disk capacity usage (inside OS)\n&#8211; Throughput and IOPS (where available)\n&#8211; Latency trends\n&#8211; Snapshot failures\/backup gaps (via operational checks)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) Is Persistent Disk suitable for Kubernetes (GKE)?<\/h3>\n\n\n\n<p>Persistent Disk can be used via GKE\u2019s CSI integration, but design should follow Kubernetes primitives (StorageClasses, PVCs, access modes). Verify feature support (like multi-attach) in GKE documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) How do I prevent accidental deletion?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Restrict IAM permissions for delete operations.<\/li>\n<li>Use approval workflows for production changes.<\/li>\n<li>Implement backup policies and regular restore tests.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">17) What\u2019s the best way to restore from a snapshot?<\/h3>\n\n\n\n<p>Create a new disk from the snapshot, attach it to a recovery VM (or target VM), mount it, and validate data. For full restore, replace the original disk attachment after validation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Persistent Disk<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Compute Engine Disks overview<\/td>\n<td>Canonical reference for disk types, limits, and operations: https:\/\/cloud.google.com\/compute\/docs\/disks<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Snapshots<\/td>\n<td>Snapshot creation, restore, and best practices: https:\/\/cloud.google.com\/compute\/docs\/disks\/snapshots<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Regional persistent disks<\/td>\n<td>HA storage model and constraints: https:\/\/cloud.google.com\/compute\/docs\/disks\/regional-persistent-disk<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>CMEK for disks<\/td>\n<td>Encryption and key management guidance: https:\/\/cloud.google.com\/compute\/docs\/disks\/customer-managed-encryption<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Disks and images pricing<\/td>\n<td>Current SKUs by disk type and region: https:\/\/cloud.google.com\/compute\/disks-image-pricing<\/td>\n<\/tr>\n<tr>\n<td>Official calculator<\/td>\n<td>Google Cloud Pricing Calculator<\/td>\n<td>Region-specific estimates and scenario modeling: https:\/\/cloud.google.com\/products\/calculator<\/td>\n<\/tr>\n<tr>\n<td>Official getting started<\/td>\n<td>Compute Engine quickstarts<\/td>\n<td>VM basics that pair with disk management: https:\/\/cloud.google.com\/compute\/docs\/quickstarts<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center<\/td>\n<td>Patterns for HA, DR, and operations (search for Compute Engine storage topics): https:\/\/cloud.google.com\/architecture<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Google Cloud Tech YouTube<\/td>\n<td>Practical demos and explanations (verify the most current disk-related videos): https:\/\/www.youtube.com\/@googlecloudtech<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>gcloud compute disks<\/td>\n<td>Command reference for automation: https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/compute\/disks<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>gcloud compute snapshots<\/td>\n<td>Command reference for snapshots: https:\/\/cloud.google.com\/sdk\/gcloud\/reference\/compute\/snapshots<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following are external training providers. Verify the latest course outlines, delivery modes, and schedules on their websites.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, cloud engineers, platform teams\n   &#8211; <strong>Likely learning focus:<\/strong> Google Cloud operations, infrastructure automation, DevOps practices (verify specific Persistent Disk coverage)\n   &#8211; <strong>Mode:<\/strong> check website\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps practitioners, build\/release engineers, students\n   &#8211; <strong>Likely learning focus:<\/strong> DevOps tools, SCM, CI\/CD, cloud fundamentals (verify Google Cloud modules)\n   &#8211; <strong>Mode:<\/strong> check website\n   &#8211; <strong>Website:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> CloudOps, operations teams, junior-to-mid cloud engineers\n   &#8211; <strong>Likely learning focus:<\/strong> Cloud operations and administration (verify Google Cloud coverage)\n   &#8211; <strong>Mode:<\/strong> check website\n   &#8211; <strong>Website:<\/strong> https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> SREs, reliability engineers, operations leads\n   &#8211; <strong>Likely learning focus:<\/strong> SRE practices, reliability, monitoring\/alerting, incident management (verify Google Cloud content)\n   &#8211; <strong>Mode:<\/strong> check website\n   &#8211; <strong>Website:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> Ops teams, SREs, engineers exploring AIOps\n   &#8211; <strong>Likely learning focus:<\/strong> Automation, observability, AIOps concepts (verify Google Cloud applicability)\n   &#8211; <strong>Mode:<\/strong> check website\n   &#8211; <strong>Website:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These are trainer-related sites\/platforms. Verify current offerings and credentials directly.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> Cloud\/DevOps training content (verify current focus)\n   &#8211; <strong>Suitable audience:<\/strong> Beginners to intermediate learners\n   &#8211; <strong>Website:<\/strong> https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps training and mentoring (verify Google Cloud topics)\n   &#8211; <strong>Suitable audience:<\/strong> DevOps engineers, students, career switchers\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> Freelance DevOps services and training resources (verify current scope)\n   &#8211; <strong>Suitable audience:<\/strong> Teams seeking practical DevOps guidance\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps support and learning resources (verify offerings)\n   &#8211; <strong>Suitable audience:<\/strong> Ops\/DevOps teams needing hands-on help\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>These are external consulting providers. Verify service details, references, and statements of work directly.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> Cloud\/DevOps consulting (verify service catalog)\n   &#8211; <strong>Where they may help:<\/strong> VM migrations, storage planning, backup\/DR design, operational runbooks\n   &#8211; <strong>Consulting use case examples:<\/strong> Disk snapshot strategy, Compute Engine modernization, cost optimization reviews\n   &#8211; <strong>Website:<\/strong> https:\/\/cotocus.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> DevOps and cloud consulting (verify offerings)\n   &#8211; <strong>Where they may help:<\/strong> Platform engineering enablement, infrastructure automation, operational best practices\n   &#8211; <strong>Consulting use case examples:<\/strong> Standardizing Persistent Disk usage via IaC, implementing backup policies, IAM hardening\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> DevOps consulting services (verify scope)\n   &#8211; <strong>Where they may help:<\/strong> CI\/CD, cloud operations, reliability practices, cloud cost governance\n   &#8211; <strong>Consulting use case examples:<\/strong> Production readiness review for stateful VM workloads, monitoring\/alerting design for disk-heavy apps\n   &#8211; <strong>Website:<\/strong> https:\/\/www.devopsconsulting.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Persistent Disk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Google Cloud fundamentals:<\/li>\n<li>Projects, billing accounts, IAM basics<\/li>\n<li>Regions\/zones and resource hierarchy<\/li>\n<li>Compute Engine basics:<\/li>\n<li>Creating VMs, machine types, images<\/li>\n<li>SSH access, OS Login (if used in your org)<\/li>\n<li>Linux storage basics:<\/li>\n<li>Block devices, partitions, filesystems (ext4\/xfs)<\/li>\n<li>Mounting, <code>\/etc\/fstab<\/code>, basic troubleshooting<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Persistent Disk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Backup and DR design:<\/li>\n<li>Snapshot schedules, retention, restore testing<\/li>\n<li>Cross-project and cross-region DR patterns (verify official guidance)<\/li>\n<li>Advanced operations:<\/li>\n<li>Monitoring and SLOs for stateful services<\/li>\n<li>Incident response runbooks for storage and VM recovery<\/li>\n<li>Security hardening:<\/li>\n<li>CMEK with Cloud KMS<\/li>\n<li>Org policies and least-privilege IAM<\/li>\n<li>Alternatives and complementary services:<\/li>\n<li>Filestore, Cloud Storage, Local SSD<\/li>\n<li>Managed databases (Cloud SQL, AlloyDB, etc.) when VM-hosted databases become burdensome<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Persistent Disk<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Administrator<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Platform Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Security Engineer (for encryption\/IAM governance)<\/li>\n<li>Operations Engineer \/ Production Engineer<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>Persistent Disk knowledge is commonly relevant to:\n&#8211; Associate Cloud Engineer\n&#8211; Professional Cloud Architect\n&#8211; Professional Cloud DevOps Engineer<\/p>\n\n\n\n<p>Always verify the current exam guides:\n&#8211; https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Build an automated snapshot policy and test restores monthly.<\/li>\n<li>Benchmark disk types for a small database (balanced vs SSD) and document results.<\/li>\n<li>Implement CMEK for a disk and validate key access controls.<\/li>\n<li>Create a \u201cgolden image\u201d pipeline that updates monthly and uses Persistent Disk images.<\/li>\n<li>Design a two-zone failover runbook using regional persistent disk and test it in a non-prod project.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Block storage:<\/strong> Storage presented as raw blocks to an OS (like a disk), typically formatted with a filesystem.<\/li>\n<li><strong>Persistent Disk:<\/strong> Google Cloud managed block storage for Compute Engine.<\/li>\n<li><strong>Zonal disk:<\/strong> A disk resource that exists in a single zone.<\/li>\n<li><strong>Regional disk:<\/strong> A disk resource replicated across two zones in a region for higher availability.<\/li>\n<li><strong>Snapshot:<\/strong> Point-in-time backup of a persistent disk; incremental after the first snapshot.<\/li>\n<li><strong>Image:<\/strong> A reusable template (often bootable) used to create VM boot disks.<\/li>\n<li><strong>Boot disk:<\/strong> The disk a VM boots from; contains the operating system.<\/li>\n<li><strong>Data disk:<\/strong> Additional disk attached to a VM for application data.<\/li>\n<li><strong>CMEK:<\/strong> Customer-Managed Encryption Keys, stored in Cloud KMS, used to encrypt resources.<\/li>\n<li><strong>Cloud KMS:<\/strong> Key Management Service for creating and managing cryptographic keys.<\/li>\n<li><strong>IAM:<\/strong> Identity and Access Management, controlling who can do what in a Google Cloud project.<\/li>\n<li><strong>IOPS:<\/strong> Input\/Output Operations Per Second; a common storage performance measure.<\/li>\n<li><strong>Throughput:<\/strong> Data transfer rate (for example MB\/s) of storage reads\/writes.<\/li>\n<li><strong>RPO:<\/strong> Recovery Point Objective; acceptable data loss window.<\/li>\n<li><strong>RTO:<\/strong> Recovery Time Objective; acceptable downtime window.<\/li>\n<li><strong>Split-brain:<\/strong> A failure mode in clustered systems where two nodes think they are primary and both write, risking corruption.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Persistent Disk is Google Cloud\u2019s core <strong>Compute<\/strong> block storage service for Compute Engine, providing durable, managed disks for VM boot and data volumes. It matters because it gives teams a practical, production-ready way to run stateful VM workloads with essential capabilities like snapshots, resizing, and encryption controls (including CMEK).<\/p>\n\n\n\n<p>Architecturally, Persistent Disk fits best for VM-based applications that need durable storage, while alternatives like Filestore (shared NFS), Cloud Storage (object storage), and Local SSD (ephemeral high performance) serve different needs. From a cost perspective, the biggest levers are disk type, provisioned GB, snapshot retention, and whether you choose zonal or regional disks. From a security perspective, IAM boundaries, snapshot access control, and CMEK\/KMS operations are the key focus areas.<\/p>\n\n\n\n<p>Use Persistent Disk when you need durable VM block storage with operational tooling and governance. Next, deepen your skills by implementing snapshot schedules with restore testing, learning CMEK key management practices, and benchmarking disk types against your workload using official performance guidance: https:\/\/cloud.google.com\/compute\/docs\/disks<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Compute<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,51],"tags":[],"class_list":["post-633","post","type-post","status-publish","format-standard","hentry","category-compute","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=633"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/633\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}