Environment variables and secrets in GCP - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

How does Cloud Run handle environment variables set from Secret Manager?

You deploy a Cloud Run service and configure an environment variable to pull a secret from Secret Manager. What happens if the secret is updated after deployment?

A The Cloud Run service automatically fetches the updated secret without redeployment.

B The service crashes because the secret value changes dynamically.

C The environment variable keeps the old secret value until the service is redeployed.

D The secret value is updated only if the Cloud Run service is manually restarted.

💡 Hint

Think about how environment variables are loaded during service startup.

Cloud Run loads environment variables at startup. If a secret changes in Secret Manager, the running service does not see the update until redeployed or restarted.

❓ security

intermediate

Which IAM role is required to allow a Cloud Function to access secrets from Secret Manager?

You want a Cloud Function to read secrets from Secret Manager securely. Which IAM role should you assign to the Cloud Function's service account?

A roles/secretmanager.admin

B roles/secretmanager.secretAccessor

C roles/secretmanager.viewer

D roles/secretmanager.secretVersionAdder

💡 Hint

Consider the least privilege principle for reading secrets.

The role roles/secretmanager.secretAccessor allows reading secret payloads. Admin and viewer roles have broader or different permissions. secretVersionAdder is for adding versions, not reading.

❓ Configuration

advanced

What is the correct way to inject a secret as an environment variable in a Cloud Run service using gcloud CLI?

You want to deploy a Cloud Run service and inject a secret named API_KEY from Secret Manager as an environment variable API_KEY. Which gcloud command is correct?

A gcloud run deploy my-service --image=gcr.io/my-project/my-image --set-secret-env API_KEY=API_KEY:latest

B gcloud run deploy my-service --image=gcr.io/my-project/my-image --set-env-vars API_KEY=projects/my-project/secrets/API_KEY/versions/latest

C gcloud run deploy my-service --image=gcr.io/my-project/my-image --update-secrets API_KEY=API_KEY:latest

D gcloud run deploy my-service --image=gcr.io/my-project/my-image --set-secrets API_KEY=API_KEY:latest

💡 Hint

Check the gcloud flag that specifically injects secrets as environment variables.

The flag --set-secrets injects secrets from Secret Manager as environment variables. The syntax is ENV_VAR=SECRET_NAME:VERSION. Other flags are invalid or do not exist.

❓ Architecture

advanced

Which architecture best protects secrets used by multiple microservices in GCP?

You have multiple microservices running on GKE and Cloud Run that need access to the same secrets. What is the best architecture to manage and secure these secrets?

A Use Secret Manager to centrally store secrets and grant each service's identity access to read them.

B Store secrets in environment variables directly in each service deployment manifest.

C Embed secrets in container images so services can read them locally.

D Store secrets in a shared Cloud Storage bucket with public read access.

💡 Hint

Think about central management and least privilege access.

Secret Manager provides a secure, centralized way to store secrets. Granting each service's identity access follows best security practices. Environment variables and container images are less secure. Public buckets expose secrets to everyone.

✅ Best Practice

expert

What is the recommended practice for rotating secrets used by Cloud Run services without downtime?

You want to rotate secrets used as environment variables in Cloud Run services without causing downtime. Which approach follows best practices?

A Deploy a new Cloud Run revision referencing the new secret version, then gradually shift traffic to it.

B Update the secret in Secret Manager and redeploy the Cloud Run service with the new secret version.

C Change the secret in Secret Manager and rely on Cloud Run to automatically refresh environment variables.

D Update the secret in Secret Manager and restart the Cloud Run service manually to pick up the new secret.

💡 Hint

Consider how Cloud Run handles revisions and traffic splitting.

Cloud Run does not automatically refresh environment variables from secrets. Deploying a new revision with the updated secret and shifting traffic gradually avoids downtime and allows rollback if needed.

Practice

1. What is the main purpose of environment variables in a Google Cloud application?

easy

A. To permanently save user data in the cloud

B. To create virtual machines automatically

C. To encrypt all data sent over the network

D. To store configuration values that the app can use at runtime

Solution

1. Step 1: Understand environment variables

   Environment variables hold configuration values like API URLs or feature flags that apps read when running.

2. Step 2: Eliminate distractor options

   Permanent data storage, network encryption, and VM creation are unrelated to environment variables.

3. Final Answer:

   To store configuration values that the app can use at runtime -> Option D

4. Quick Check:

   Environment variables = config values [OK]

Hint: Environment variables hold settings your app reads [OK]

Common Mistakes:

• Confusing environment variables with data storage
• Thinking environment variables encrypt data
• Mixing environment variables with cloud resource creation

2. Which of the following is the correct way to set an environment variable named API_KEY with value 12345 in a Google Cloud Run service YAML?

easy

A. env:
- name: API_KEY
value: '12345'

B. environment_variables:
API_KEY: 12345

C. variables:
API_KEY = '12345'

D. set_env:
API_KEY: '12345'

Solution

1. Step 1: Recall Cloud Run YAML env syntax

   Cloud Run uses the env list with name and value keys to set environment variables.

2. Step 2: Check options for correct YAML format

   env: - name: API_KEY value: '12345' matches the correct syntax. Other options use incorrect keys or formats not supported by Cloud Run.

3. Final Answer:

   env: - name: API_KEY value: '12345' -> Option A

4. Quick Check:

   Cloud Run env uses name and value keys [OK]

Hint: Look for 'env' with name and value keys in YAML [OK]

Common Mistakes:

• Using incorrect keys like environment_variables or variables
• Assigning values with '=' instead of colon
• Not using a list for env variables

3. Given this Python code snippet running in a Google Cloud Function:

import os
api_key = os.getenv('API_KEY')
print(f"Key: {api_key}")

If the environment variable API_KEY is not set, what will be printed?

medium

A. Key: API_KEY

B. Key:

C. Key: None

D. Error: Environment variable not found

Solution

1. Step 1: Understand os.getenv behavior

   When the environment variable is missing, os.getenv returns None by default.

2. Step 2: Analyze the print output

   The f-string converts None to the string 'None', so the output is 'Key: None'.

3. Final Answer:

   Key: None -> Option C

4. Quick Check:

   Missing env var returns None [OK]

Hint: os.getenv returns None if variable missing [OK]

Common Mistakes:

• Assuming empty string is returned
• Expecting an error to be raised
• Thinking variable name is printed

4. You deployed a Cloud Run service that uses a secret from Secret Manager, but the service fails to access the secret. Which is the most likely cause?

medium

A. The Cloud Run service account lacks permission to access the secret

B. The secret value is empty

C. The environment variable name is misspelled in the code

D. The secret was created in a different Google Cloud project

Solution

1. Step 1: Check permissions for Secret Manager access

   Cloud Run uses a service account that must have Secret Manager access roles to read secrets.

2. Step 2: Evaluate other options

   While empty secret values, misspelled variable names, or secrets in different projects can cause issues, the most common cause is missing permissions blocking secret access.

3. Final Answer:

   The Cloud Run service account lacks permission to access the secret -> Option A

4. Quick Check:

   Missing permissions block secret access [OK]

Hint: Check service account permissions first [OK]

Common Mistakes:

• Ignoring IAM roles for service accounts
• Assuming secret value is always the problem
• Not verifying project alignment for secrets

5. You want to securely provide a database password to a Google Cloud Run service without hardcoding it. Which approach follows best practices?

hard

A. Hardcode the password in the Cloud Run service YAML file

B. Store the password in Secret Manager and mount it as an environment variable in Cloud Run

C. Save the password in a public Google Cloud Storage bucket and read it at runtime

D. Send the password as a query parameter in API requests

Solution

1. Step 1: Identify secure secret storage

   Google Secret Manager is designed to store sensitive info like passwords securely.

2. Step 2: Use environment variables for app access

   Mounting secrets as environment variables in Cloud Run keeps secrets out of code and config files.

3. Step 3: Evaluate other options

   Hardcoding, public storage, or sending passwords in URLs expose secrets and are insecure.

4. Final Answer:

   Store the password in Secret Manager and mount it as an environment variable in Cloud Run -> Option B

5. Quick Check:

   Secret Manager + env vars = secure best practice [OK]

Hint: Use Secret Manager and env vars, never hardcode secrets [OK]

Common Mistakes:

• Hardcoding secrets in config files
• Using public storage for sensitive data
• Exposing secrets in URLs or logs