Deal of The Day! 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

Posted by Brendan on Nov 12, 2024 at 11:10 PM

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?

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

Get Premium Professional Cloud DevOps Engineer Questions as Interactive Web-Based Practice Test or PDF Real Exam Format Detailed Explanations Instant Access Get Your Practice Test
32 comments · newest first
BR
Britt 11 months ago
I thought secrets should never be exposed like that, right?
AU
Audra 11 months ago
B could work too, but it might complicate things a bit.
SU
Sunshine 11 months ago
Wait, isn't storing passwords in code a huge no-no?
FE
Felicitas 11 months ago
Totally agree, environment variables are the way to go!
JO
Joesph 12 months ago
A is the best option for security and ease of use.
HE
Hermila 12 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.
AL
Alishia 1 year 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.
EN
Ena 1 year ago
I think option B sounds familiar because we practiced a similar question about mounting secrets. It might help with the password rotation requirement.
KA
Kattie 1 year 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.
AR
Arthur 1 year 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.
CA
Caitlin 1 year 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.
VI
Vivan 1 year 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.
MA
Margo 1 year 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.
AR
Arlen 1 year 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.
LI
Linsey 2 years ago
But storing the password directly in the code is not secure. Option A ensures better security and compliance with our organization's policies.
TO
Tora 2 years ago
I disagree, I believe option D is more efficient as it eliminates the need for additional services like Secret Manager.
JA
Jani 2 years ago
C seems like a lot of extra work. Why complicate things when A gives you the same result with less hassle?
LO
Louvenia 2 years 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.
AV
Avery 2 years ago
↳ replying to Louvenia
C) Use Cloud Build to add your password into the application container at build time. Ensure that Artifact Registry is secured from public access.
JO
Joye 2 years ago
↳ replying to Louvenia
B) Store the password in Secret Manager and mount the secret as a volume within the application.
BE
Beckie 2 years ago
↳ replying to Louvenia
A) Store the password in Secret Manager and send the secret to the application by using environment variables.
LI
Linsey 2 years ago
I think option A is the best choice because it allows us to securely store the password and easily update it without downtime.
VA
Valentine 2 years ago
I agree, A is the right choice. Mounting the secret as a volume could cause issues during updates.
LY
Lynette 2 years ago
↳ replying to Valentine
User 4: Using Cloud Build to add the password at build time seems like a secure option.
YE
Yesenia 2 years ago
↳ replying to Valentine
User 3: Mounting the secret as a volume could definitely cause issues during updates.
CL
Clement 2 years ago
↳ replying to Valentine
User 2: I agree, storing the password in Secret Manager and sending it via environment variables is the way to go.
RE
Rebeca 2 years ago
↳ replying to Valentine
User 1: I think A is the best option.
XU
Xuan 2 years 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.
CA
Carri 2 years ago
↳ replying to Xuan
User 4: That could work too, but A seems more straightforward and secure.
NA
Nada 2 years ago
↳ replying to Xuan
User 3: B) Store the password in Secret Manager and mount the secret as a volume within the application.
LU
Luisa 2 years ago
↳ replying to Xuan
User 2: That sounds like a secure way to handle password rotation without downtime.
JU
Julio 2 years ago
↳ replying to Xuan
User 1: A) Store the password in Secret Manager and send the secret to the application by using environment variables.
0/2000 characters

Save Cancel