PROFESSIONAL-CLOUD-DEVELOPER · Question #192
Your organization has recently begun an initiative to replatform their legacy applications onto Google Kubernetes Engine. You need to decompose a monolithic application into microservices. Multiple in
The correct answer is C. Create a new Filestore instance, and mount the volume as an NFS PersistentVolume.. The legacy application expects a shared POSIX-compatible file system where multiple instances can simultaneously read and write the same file. Cloud Filestore is Google's managed NFS service. Mounting it as an NFS PersistentVolume with the ReadWriteMany access mode lets multiple
Question
Your organization has recently begun an initiative to replatform their legacy applications onto Google Kubernetes Engine. You need to decompose a monolithic application into microservices. Multiple instances have read and write access to a configuration file, which is stored on a shared file system. You want to minimize the effort required to manage this transition, and you want to avoid rewriting the application code. What should you do?
Options
- ACreate a new Cloud Storage bucket, and mount it via FUSE in the container.
- BCreate a new persistent disk, and mount the volume as a shared PersistentVolume.
- CCreate a new Filestore instance, and mount the volume as an NFS PersistentVolume.
- DCreate a new ConfigMap and volumeMount to store the contents of the configuration file.
How the community answered
(52 responses)- A25% (13)
- B6% (3)
- C58% (30)
- D12% (6)
Explanation
The legacy application expects a shared POSIX-compatible file system where multiple instances can simultaneously read and write the same file. Cloud Filestore is Google's managed NFS service. Mounting it as an NFS PersistentVolume with the ReadWriteMany access mode lets multiple pods on different nodes mount the same volume concurrently - exactly what the application already expects. No code changes are required. Option A (Cloud Storage FUSE) is eventually consistent, has higher latency, and is not a drop-in NFS replacement. Option B (a standard persistent disk) only supports ReadWriteOnce (single node at a time) or ReadOnlyMany - not concurrent multi-pod writes. Option D (ConfigMap) is read-only and is designed for static configuration injection, not shared mutable file I/O.
Topics
Community Discussion
No community discussion yet for this question.