ExamTopics Logo
Mail Us[email protected]
Menu
Google Discussions
exam questions

Exam Professional Cloud Developer All Questions

View all questions & answers for the Professional Cloud Developer exam
Go to Exam

Exam Professional Cloud Developer topic 1 question 175 discussion

Actual exam question from Google's Professional Cloud Developer
Question #: 175
Topic #: 1
[All Professional Cloud Developer Questions]

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?

  • A. Create a new Cloud Storage bucket, and mount it via FUSE in the container.
  • B. Create a new persistent disk, and mount the volume as a shared PersistentVolume.
  • C. Create a new Filestore instance, and mount the volume as an NFS PersistentVolume.
  • D. Create a new ConfigMap and volumeMount to store the contents of the configuration file.
Show Suggested Answer Hide Answer
Suggested Answer: C 🗳️
by zellck at Dec. 15, 2022, 1:51 p.m.

Comments

Chosen Answer:
This is a voting comment (?). It is better to Upvote an existing comment if you don't have anything to add.
Switch to a voting comment New
Submit Cancel
x_cath
Highly Voted 1 year, 11 months ago
Selected Answer: C
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
upvoted 12 times
root_1234
4 months, 2 weeks ago
That's correct. Configmap can not be written by application so D is not a correct solution.
upvoted 1 times
...
...
__rajan__
Most Recent 1 year, 2 months ago
Selected Answer: D
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.
upvoted 1 times
pico
6 months, 1 week ago
In this case the configuration file will be both read and written by the instances, so D is not the answer
upvoted 1 times
...
...
purushi
1 year, 4 months ago
Selected Answer: D
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.
upvoted 1 times
...
zellck
1 year, 12 months ago
Selected Answer: C
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.
upvoted 2 times
...
TNT87
1 year, 12 months ago
Selected Answer: C
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
upvoted 3 times
...
Underverse
1 year, 12 months ago
Selected Answer: C
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.
upvoted 3 times
zellck
1 year, 12 months ago
Agree with C that a NFS will be required.
upvoted 1 times
...
...
zellck
2 years ago
Selected Answer: D
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.
upvoted 2 times
...
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.

Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.

SaveCancel