Environment variables and secrets in GCP - Commands & Configuration

Introduction

Sometimes your app needs secret keys or settings that should not be visible to everyone. Environment variables and secrets help keep these safe and easy to use without hardcoding them in your code.

When you want to store API keys safely without putting them in your code files

When you need to change configuration settings without changing your app code

When you want to share secrets securely between your cloud services

When you want to keep passwords or tokens hidden from public view

When you want to update sensitive data without redeploying your app

Config File - cloudbuild.yaml

cloudbuild.yaml

steps:
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['secrets', 'versions', 'access', 'latest', '--secret=my-secret']
  id: 'access-secret'
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-app', '.']
  env:
  - 'MY_SECRET=$(access-secret)'
images:
- 'gcr.io/my-project/my-app'

This Cloud Build config file shows how to access a secret named my-secret from Google Secret Manager during a build. The secret value is retrieved and set as an environment variable MY_SECRET for the Docker build step. This keeps the secret safe and separate from the code.

Commands

This command creates a new secret named 'my-secret' in Google Secret Manager using the contents of the file 'secret.txt'. It stores your sensitive data securely.

Terminal

gcloud secrets create my-secret --replication-policy=automatic --data-file=secret.txt

Expected Output

Created secret [my-secret].

→

--replication-policy=automatic - Automatically replicates the secret across Google Cloud regions for availability.

→

--data-file=secret.txt - Specifies the file containing the secret data to store.

This command retrieves the latest version of the secret 'my-secret' so you can use it in your app or scripts.

Terminal

gcloud secrets versions access latest --secret=my-secret

Expected Output

my-super-secret-value

→

--secret=my-secret - Specifies which secret to access.

This deploys your app to Cloud Run and injects the secret 'my-secret' as an environment variable named 'API_KEY' inside the running container.

Terminal

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

Expected Output

Deploying container to Cloud Run service [my-app] in project [my-project] region [us-central1]

Deploying...done.

Service [my-app] revision [my-app-00001-abc] has been deployed and is serving 100 percent of traffic.

URL: https://my-app-xyz.a.run.app

→

--set-secrets=API_KEY=my-secret:latest - Maps the secret to an environment variable inside the container.

This command shows the environment variables set for the deployed Cloud Run service, confirming the secret is injected.

Terminal

gcloud run services describe my-app --format='value(spec.template.spec.containers[0].env)'

Expected Output

[{name: API_KEY, valueFrom: {secretKeyRef: {name: my-secret, key: latest}}}]

→

--format='value(...)' - Formats the output to show only environment variables.

Key Concept

If you remember nothing else from this pattern, remember: keep secrets out of your code by storing them securely and injecting them as environment variables at runtime.

Common Mistakes

Hardcoding secrets directly in application code or config files.

This exposes sensitive data to anyone who can see the code, risking security breaches.

Store secrets in a secure service like Google Secret Manager and inject them as environment variables.

Not granting the app permission to access the secret in Secret Manager.

The app will fail to retrieve the secret and may crash or behave unexpectedly.

Assign the correct IAM role (Secret Manager Secret Accessor) to the app's service account.

Using environment variables for secrets but committing .env files with secrets to public repositories.

This leaks secrets publicly, defeating the purpose of secure storage.

Never commit files containing secrets; use secret management services instead.

Summary

Create secrets securely in Google Secret Manager using gcloud commands.

Access secrets when needed without exposing them in code.

Inject secrets as environment variables into cloud services like Cloud Run.

Verify environment variables are set correctly after deployment.

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