Google ACE Planning and Configuring a Cloud Solution Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use the 'gcloud compute disks update' command to change the storage class while the disk is attached to a running VM

  Why it's wrong here

  The gcloud compute disks update command does not support modifying a persistent disk's storage class after creation; storage class is an immutable property set when you provision the disk. In-place changes to disk type or encryption are not available, so this approach is invalid regardless of whether the VM is running. You must instead create a new disk from a snapshot and migrate your data.

• ✗

  Create a new disk with the new storage class and use rsync to copy data from the old disk while both are attached to the same VM

  Why it's wrong here

  You can attach a second persistent disk to a running VM, but attaching it does not automatically mount it at the same path as the existing disk, and manually mounting it at the same mount point would cause filesystem conflicts and data corruption. An rsync copy performed while your stateful application is actively writing to the old disk will not produce a consistent point-in-time replica, because there is no quiescing mechanism; the copied files may be half-written or out of order. The proper migration path uses a snapshot to capture a consistent disk state, not a live rsync of a running filesystem.

• ✓

  Take a snapshot of the disk, create a new disk from the snapshot with the new storage class, then detach the old disk and attach the new disk to the same VM

  Why this is correct

  Take a snapshot of the disk while the VM is running to obtain a crash-consistent image of the filesystem; persistent disk snapshots are computed online and do not require stopping the instance. From that snapshot, create a new persistent disk with the desired storage class (for example, pd-balanced or pd-ssd). Then unmount the old disk, detach it from the VM, attach the newly created disk, and remount it at the same mount point; this limits downtime to the brief unmount/detach/attach/remount window rather than the entire snapshot and disk creation time.

• ✗

  Stop the VM, take a snapshot, create a new disk with the new storage class, and start the VM with the new disk

  Why it's wrong here

  This approach will successfully change the storage class, but it forces a complete VM stop before taking the snapshot, and the VM remains stopped while the snapshot is created and while the new disk is provisioned from that snapshot. The correct procedure takes the snapshot while the instance is still running, so the only interruption is the detach/attach step; stopping the VM first adds unnecessary downtime without any consistency benefit over a crash-consistent snapshot. For a stateful application that must remain highly available, this is the least efficient of the two working migration strategies.

Go deeper

Related to this question