Exam Professional Cloud Developer topic 1 question 175 discussion

A is incorrect, because Cloud Storage FUSE does not support concurrency and file locking. B is incorrect, because a persistent disk PersistentVolume is not read-write-many. It can only be read-write once or read-many. C is correct, because it’s the only managed, supported read-write-many storage option available for file-system access in Google Kubernetes Engine. D is incorrect, because the ConfigMap cannot be written to from the Pods. https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes https://cloud.google.com/filestore/docs/accessing-fileshares https://cloud.google.com/storage/docs/gcs-fuse

ConfigMaps are Kubernetes objects that allow you to store configuration data in a key-value format. ConfigMaps are immutable, which means that they cannot be changed once they are created. This makes them ideal for storing configuration data that needs to be shared between multiple Pods.

ConfigMap is the usual way to store application configurations those runs under the cluster. I donot understand why many of you are saying C. The question is asking us to how we are going to manage configuration data in a GKE environment.

C is the correct answer instead. https://kubernetes.io/docs/concepts/storage/volumes/#nfs An nfs volume allows an existing NFS (Network File System) share to be mounted into a Pod. Unlike emptyDir, which is erased when a Pod is removed, the contents of an nfs volume are preserved and the volume is merely unmounted. This means that an NFS volume can be pre-populated with data, and that data can be shared between pods. NFS can be mounted by multiple writers simultaneously.

Answer C An nfs volume allows an existing NFS (Network File System) share to be mounted into a Pod. Unlike emptyDir, which is erased when a Pod is removed, the contents of an nfs volume are preserved and the volume is merely unmounted. This means that an NFS volume can be pre-populated with data, and that data can be shared between pods

Generally ConfigMaps (D) are the right choice to store pod config-files, but: They are read-only, which does not match what is asked for here. If, as stated in the question, the application-parts need to be able to also write to that Configfile that should be on a shared file system, the only valid choice is a NFS PV.

D is the answer. https://cloud.google.com/kubernetes-engine/docs/concepts/configmap ConfigMaps bind non-sensitive configuration artifacts such as configuration files, command-line arguments, and environment variables to your Pod containers and system components at runtime. A ConfigMap separates your configurations from your Pod and components, which helps keep your workloads portable. This makes their configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications.