A Cloud Engineer needs to add an additional non-boot persistent disk to an existing running Linux Compute Engine VM instance named `analytics-vm`. The persistent disk `log-data-disk` has already been created in the same zone. Arrange the administrative steps in the correct chronological sequence to attach, format, mount, and configure persistent mounting across reboots for this disk.
- 1Attach the existing disk to the instance using `gcloud compute instances attach-disk analytics-vm --disk=log-data-disk`.
- 2Establish an SSH session to `analytics-vm` and locate the device path of the newly attached disk using `lsblk` or `/dev/disk/by-id/`.
- 3Format the raw disk device with an ext4 filesystem using `sudo mkfs.ext4 -F /dev/disk/by-id/google-log-data-disk`.
- 4Create a mount directory using `sudo mkdir -p /mnt/disks/log-data` and mount the formatted disk using `sudo mount -o discard,defaults /dev/disk/by-id/google-log-data-disk /mnt/disks/log-data`.
- 5Retrieve the disk's UUID using `sudo blkid` and append a configuration entry to `/etc/fstab` specifying automatic mount options.
Answer
The correct sequence begins with attaching the disk via gcloud, SSHing into the instance to identify the OS device path, formatting the raw disk with ext4, creating a directory to mount the filesystem, and appending an entry with the disk's UUID to /etc/fstab for reboot persistence.
To successfully provision and mount a secondary persistent disk on Compute Engine, infrastructure-level attachment (`gcloud compute instances attach-disk`) must happen first. Once attached, an SSH session allows inspecting device paths inside the Linux kernel, formatting the raw device with `mkfs.ext4`, mounting it to a newly created mount point directory, and lastly obtaining its UUID via `blkid` to update `/etc/fstab` so the mount configuration persists across VM reboots.
Step-by-Step Solution
Key Concept
Attaching, formatting, mounting, and configuring reboot persistence for secondary Compute Engine disks