Google ACE Practice Question: A team wants to create a consistent backup of a…

Answer analysis

Option-by-option breakdown

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

• ✗

  Create a custom VM image from the running instance using `gcloud compute images create`

  Why it's wrong here

  Running `gcloud compute images create` from a running instance's disk without stopping the VM can produce an image with an inconsistent filesystem state because writes are ongoing during the image capture. Open file locks, in-flight writes, and cached data may not be flushed, leading to a corrupt or non-bootable image. While images are useful for creating VM templates, for backup you should stop the VM or take a disk snapshot to guarantee consistency.

• ✓

  Create a persistent disk snapshot using `gcloud compute disks snapshot`

  Why this is correct

  Creating a persistent disk snapshot with `gcloud compute disks snapshot` captures the exact state of the disk at a point in time, including the boot sector, partition table, and all system files. For best consistency, you should stop the VM before taking the snapshot to flush caches and avoid changes during the operation, though `--guest-flush` (where available) can coordinate with the guest OS. Snapshots are stored incrementally in Cloud Storage and can be used to create a new disk or VM, making them a reliable backup mechanism.

• ✗

  Copy all files to a Cloud Storage bucket using gsutil rsync

  Why it's wrong here

  Copying files with `gsutil rsync` to a Cloud Storage bucket is a file-level backup, not a disk-level one. It cannot replicate the boot sector, partition table, MBR/GPT, or OS-specific system files that are outside the normal file tree, so the resulting copy cannot be easily made into a bootable VM. It also misses open file handles, device nodes, and running configuration state, making it unsuitable for a complete VM recovery.

• ✗

  Enable live migration for the VM — it automatically backs up state before migrations

  Why it's wrong here

  Live migration is an infrastructure feature that moves a running VM from one physical host to another during maintenance or hardware failure—it does not create any backup artifact or persistent copy. It merely transfers the VM's memory and disk state to a new host to minimize downtime, and once completed, no snapshot or restorable image exists. Therefore, it does not provide a point-in-time recovery option for data loss or corruption scenarios.

Go deeper

Related to this question