Exam Professional Cloud Architect topic 1 question 163 discussion

I think it's B. If you use a tool like GCFUSE it will write immediatly to GCS which is a cost benefit because you don't need intermediate storage. In this case however "Quickly as possible" key for understanding. GCFUSE will write to GCS which is much slower than writing directly to an added SSD. During the write to GCS it would also execute reads for a longer period on the production database. Therefor writing to the extra SSD would be my recommended solution. Offloading from the SSD to GCS would not impact the running database because the data is already separated.

Ans: B Persistent Disk snapshot not required: "They need to take backups of a specific database at regular intervals." "The backup activity needs to complete as quickly as possible and cannot be allowed to impact disk performance." This can be achieved by using both Local SSD & GCS Fuse (mounting GCS as directory), but as the question stats needs to complete as quickly as possible. General Rule: Any addition of components introduce a latency. I could not get write throughput of GCS & Local SSD, even if we consider both provides same throughput, streaming data through network to GCS Bucket introduce latency. Attached Local SSD has advantage in this case, since there is no network involved. From Local SSD to GCS bucket - copy job does not impact the mysql data disk.

Local SSDs can only be attached when the VM is being created.

"A" is the only one which gives an automated way to do it. All the rest involves a person action

I'll go with B

B,https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up

It says a specific database, not all of it. Otherwise, why not just use the snapshots? They are no cost.

You can only add local ssd to a VM during creation.Hence going with option C

Option B would be the best choice for this scenario. Mounting a Local SSD volume as the backup location would ensure high performance and minimal impact on disk performance, while also allowing for quick backups. After the backup is complete, using gsutil to move the backup to Google Cloud Storage would provide a reliable and secure storage location for the backups. This approach is also cost-effective, as Local SSD volumes are less expensive than persistent disks.

B is incorrect. The Local SSD volumes are only available on certain instance types, and they are not suitable for long-term storage as they are ephemeral and are deleted when the instance is deleted or stopped. For long-term storage, it is recommended to use persistent disks or Google Cloud Storage.

Option B is the most appropriate solution in this case. Mounting a Local SSD volume as the backup location will allow the backups to be taken quickly and efficiently, as Local SSDs have very high I/O performance and low latencies. Additionally, using gsutil to move the backups to Google Cloud Storage after they have been taken will provide a secure and durable storage location for the backups. A, configuring a cron job to use the gcloud tool to take regular backups using persistent disk snapshots, may not be the most efficient option because persistent disks have relatively lower I/O performance compared to Local SSDs. C, using gcsfuse to mount a Google Cloud Storage bucket as a volume directly on the instance and writing the backups to the mounted location using mysqldump, may not be the most efficient option because the backups would need to be transferred over the network, which could impact the performance of the backups.

Gcsfuse needs local storage for caching, usually local/non-persistent disks are used for this purpose. With gcsfuse you can have the backend storage mounted as a filesystem on the server. Mysqldump allows for hot database backups. Option C provides the automated solution needed to backup and store the database. Option B is the manual version where you need to mount the local SSD, run the backup and then transfer it to a bucket manually.

I will go with B

B is the answer. https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket.

https://cloud.google.com/compute/docs/instances/sql-server/best-practices#backing_up When taking regular database backups, be careful not to consume too many persistent disk IOPS. Use the local SSD to stage your backups and then push them to a Cloud Storage bucket. Though it is mentioned for SQL Server, the best practices are common for most of the databases. Also it is assumed that the Local SSD are already mounted while creating the VM

>backups of a specific database

B - I think this will clear things up. Local SSD is ATTACHED when CREATING the VM. The local SSDs are just LOCATED (on the physical host) where the VM is running. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#create_local_ssd You can have a VM with locally attached SSD in an unformatted and unmounted state or just not mounted! Maybe it was umounted and now needs to be re-mounted? Answer B says to MOUNT the local SSD. MOUNTING the SSD is done when the VM is RUNNING! We need to assume the VM was built with locally attached SSD but not formatted and mounted yet. See here. https://cloud.google.com/compute/docs/disks/add-local-ssd#format_and_mount_a_local_ssd_device!