Google ACE Practice Question: You need persistent shared file storage for 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.

• ✗

  Cloud Storage FUSE mounted on each VM

  Why it's wrong here

  Cloud Storage FUSE exposes Cloud Storage buckets as a local file system, but it does not implement full POSIX semantics. It lacks support for file locking, atomic directory operations, and accurate metadata like inode numbers, and each operation incurs the latency of an HTTP API call to Cloud Storage. This makes it unsuitable for legacy applications that depend on strict locking and consistent read-after-write behavior; it is better suited for read-heavy workloads or data that tolerates eventual consistency.

• ✓

  Cloud Filestore (NFS)

  Why this is correct

  Cloud Filestore is a fully managed NFS service that provides a POSIX-compliant file system with proper file locking, consistent metadata, and low-latency access over the network. Multiple Compute Engine instances can mount the same Filestore file system concurrently in read/write mode, giving true shared storage without the need to manage your own NFS server. Its performance tiers (standard, premium, and high-performance SSD) deliver consistent throughput and IOPS, making it ideal for legacy applications that require coherent shared access and strong consistency across a cluster of VMs.

• ✗

  Persistent Disk attached in ReadWriteMany mode to all VMs

  Why it's wrong here

  Standard zonal Persistent Disks are ReadWriteOnce and can be attached to only one instance at a time. Although a multi-writer persistent disk feature exists, it is limited to two instances, requires the use of specific file systems like XFS (not ext4), and only runs on Linux VMs, making it far too restrictive for a typical multi-VM shared-storage scenario. For a shared POSIX file system across many VMs, Filestore is the only managed service that provides the required semantics without these constraints.

• ✗

  Local SSD on each VM with rsync synchronization between VMs

  Why it's wrong here

  Local SSDs are physically attached to the host of each Compute Engine instance, so they are not shared storage; they are ephemeral and data disappears when the instance is deleted or live-migrated. Using rsync to replicate files between VMs introduces asynchronous, eventually consistent synchronization, which cannot provide a single coherent namespace or real-time read-after-write consistency. This approach also lacks any file locking mechanism and will result in conflicts and data divergence if multiple VMs modify the same files, making it completely inadequate for shared write access.

Go deeper

Related to this question