New Year Sale 2026! Hurry Up, Grab the Special Discount - Save 25% - Ends In 00:00:00 Coupon code: SAVE25
Welcome to Pass4Success

- Free Preparation Discussions

Google Professional Cloud DevOps Engineer Exam - Topic 3 Question 83 Discussion

Actual exam question for Google's Professional Cloud DevOps Engineer exam
Question #: 83
Topic #: 3
[All Professional Cloud DevOps Engineer Questions]

You are deploying an application to Cloud Run. The application requires a password to start. Your organization requires that all passwords are rotated every 24 hours, and your application must have the latest password. You need to deploy the application with no downtime. What should you do?

Show Suggested Answer Hide Answer
Suggested Answer: B

The correct answer is B, Store the password in Secret Manager and mount the secret as a volume within the application.

Secret Manager is a service that allows you to securely store and manage sensitive data such as passwords, API keys, certificates, and tokens. You can use Secret Manager to rotate your secrets automatically or manually, and access them from your Cloud Run applications1.

There are two ways to use secrets from Secret Manager in Cloud Run:

As environment variables: You can set environment variables that point to secrets in Secret Manager. Cloud Run will resolve the secrets at runtime and inject them into the environment of your application. However, this method has some limitations, such as:

The environment variables are cached for up to 10 minutes, so you may not get the latest version of the secret immediately.

The environment variables are visible in plain text in the Cloud Console and the Cloud SDK, which may expose sensitive information.

The environment variables are limited to 4 KB of data, which may not be enough for some secrets.2

As file system volumes: You can mount secrets from Secret Manager as files in a volume within your application. Cloud Run will create a tmpfs volume and write the secrets as files in it. This method has some advantages, such as:

The files are updated every 30 seconds, so you can get the latest version of the secret faster.

The files are not visible in the Cloud Console or the Cloud SDK, which provides better security.

The files can store up to 64 KB of data, which allows for larger secrets.3

Therefore, for your use case, it is better to use the second method and mount the secret as a file system volume within your application. This way, you can ensure that your application has the latest password, and you can deploy it with no downtime.

To mount a secret as a file system volume in Cloud Run, you can use the following command:

gcloud beta run deploy SERVICE --image IMAGE_URL --update-secrets=/path/to/file=secretName:version

where:

SERVICE is the name of your Cloud Run service.

IMAGE_URL is the URL of your container image.

/path/to/file is the path where you want to mount the secret file in your application.

secretName is the name of your secret in Secret Manager.

You can also use the Cloud Console to mount secrets as file system volumes. For more details, see Mounting secrets from Secret Manager.


1: Overview | Secret Manager Documentation | Google Cloud

2: Using secrets as environment variables | Cloud Run Documentation | Google Cloud

3: Mounting secrets from Secret Manager | Cloud Run Documentation | Google Cloud

Contribute your Thoughts:

0/2000 characters
Britt
3 months ago
I thought secrets should never be exposed like that, right?
upvoted 0 times
...
Audra
3 months ago
B could work too, but it might complicate things a bit.
upvoted 0 times
...
Sunshine
3 months ago
Wait, isn't storing passwords in code a huge no-no?
upvoted 0 times
...
Felicitas
4 months ago
Totally agree, environment variables are the way to go!
upvoted 0 times
...
Joesph
4 months ago
A is the best option for security and ease of use.
upvoted 0 times
...
Hermila
4 months ago
I vaguely remember that using Cloud Build to inject secrets at build time could lead to issues with password updates. I’m leaning towards option A or B.
upvoted 0 times
...
Alishia
4 months ago
I feel like storing the password directly in the code is a bad idea, but I can't recall why. It seems risky to me.
upvoted 0 times
...
Ena
4 months ago
I think option B sounds familiar because we practiced a similar question about mounting secrets. It might help with the password rotation requirement.
upvoted 0 times
...
Kattie
5 months ago
I remember we discussed using Secret Manager for sensitive information, but I'm not sure if environment variables or mounting as a volume is better for this case.
upvoted 0 times
...
Arthur
5 months ago
I'm feeling pretty confident about this one. The Secret Manager solution seems like the most reliable and secure way to handle the password rotation requirement while also ensuring no downtime. I'll make sure to explain that in my answer.
upvoted 0 times
...
Caitlin
5 months ago
I'm not sure I like the idea of storing the password directly in the code and rebuilding the container every time it changes. That seems like it could lead to a lot of downtime and potential issues. I think the Secret Manager approach is probably the way to go.
upvoted 0 times
...
Vivan
5 months ago
Okay, I've got an idea. We could use Cloud Build to add the password to the container at build time, and then make sure the Artifact Registry is secured so that the password isn't accessible to the public. That seems like a pretty straightforward solution.
upvoted 0 times
...
Margo
5 months ago
Hmm, I'm a bit confused on this one. I'm not sure if mounting the secret as a volume is the best way to go, since that might introduce some complexity. I'll need to think this through a bit more.
upvoted 0 times
...
Arlen
5 months ago
I think the best approach here is to use Secret Manager to store the password and send it to the application as an environment variable. That way, we can easily rotate the password without having to rebuild the container.
upvoted 0 times
...
Linsey
1 year ago
But storing the password directly in the code is not secure. Option A ensures better security and compliance with our organization's policies.
upvoted 0 times
...
Tora
1 year ago
I disagree, I believe option D is more efficient as it eliminates the need for additional services like Secret Manager.
upvoted 0 times
...
Jani
1 year ago
C seems like a lot of extra work. Why complicate things when A gives you the same result with less hassle?
upvoted 0 times
...
Louvenia
1 year ago
Haha, D is just asking for trouble! Putting the password in the code and rebuilding the app every day? No thanks, I'll pass on that one.
upvoted 0 times
Avery
1 year ago
C) Use Cloud Build to add your password into the application container at build time. Ensure that Artifact Registry is secured from public access.
upvoted 0 times
...
Joye
1 year ago
B) Store the password in Secret Manager and mount the secret as a volume within the application.
upvoted 0 times
...
Beckie
1 year ago
A) Store the password in Secret Manager and send the secret to the application by using environment variables.
upvoted 0 times
...
...
Linsey
1 year ago
I think option A is the best choice because it allows us to securely store the password and easily update it without downtime.
upvoted 0 times
...
Valentine
1 year ago
I agree, A is the right choice. Mounting the secret as a volume could cause issues during updates.
upvoted 0 times
Lynette
1 year ago
User 4: Using Cloud Build to add the password at build time seems like a secure option.
upvoted 0 times
...
Yesenia
1 year ago
User 3: Mounting the secret as a volume could definitely cause issues during updates.
upvoted 0 times
...
Clement
1 year ago
User 2: I agree, storing the password in Secret Manager and sending it via environment variables is the way to go.
upvoted 0 times
...
Rebeca
1 year ago
User 1: I think A is the best option.
upvoted 0 times
...
...
Xuan
1 year ago
A is the way to go! Rotating the password in Secret Manager and passing it as an environment variable is the most secure and seamless approach.
upvoted 0 times
Carri
1 year ago
User 4: That could work too, but A seems more straightforward and secure.
upvoted 0 times
...
Nada
1 year ago
User 3: B) Store the password in Secret Manager and mount the secret as a volume within the application.
upvoted 0 times
...
Luisa
1 year ago
User 2: That sounds like a secure way to handle password rotation without downtime.
upvoted 0 times
...
Julio
1 year ago
User 1: A) Store the password in Secret Manager and send the secret to the application by using environment variables.
upvoted 0 times
...
...

Save Cancel