Using Secrets as environment variables in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Pod Environment Variable from Secret

Given the following Kubernetes Pod YAML snippet, what will be the output of the command echo $API_KEY inside the container?

Pod YAML snippet:

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: test-container
    image: busybox
    command: ["sh", "-c", "echo $API_KEY && sleep 3600"]
    env:
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: mysecret
          key: api_key

A The value of 'api_key' stored in the 'mysecret' Secret

B An empty string because environment variables cannot come from Secrets

C The literal string '$API_KEY'

D A runtime error because the Secret is not mounted as a volume

💡 Hint

Secrets can be referenced as environment variables using valueFrom.secretKeyRef.

Kubernetes allows you to inject Secret values as environment variables using valueFrom.secretKeyRef. The container will have the environment variable API_KEY set to the Secret's 'api_key' value.

❓ Configuration

intermediate

Correct Secret Reference in Pod Spec

Which of the following environment variable configurations correctly injects the Secret key password from Secret db-secret into the container environment variable DB_PASS?

A

env:
- name: DB_PASS
  secretKeyRef:
    name: db-secret
    key: password

B

env:
- name: DB_PASS
  valueFrom:
    configMapKeyRef:
      name: db-secret
      key: password

C

env:
- name: DB_PASS
  value: db-secret:password

D

env:
- name: DB_PASS
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

💡 Hint

Use valueFrom.secretKeyRef to reference Secrets in environment variables.

Option D correctly uses valueFrom.secretKeyRef with the Secret name and key. Option D is invalid syntax. Option D treats the Secret as a string literal. Option D incorrectly uses configMapKeyRef instead of secretKeyRef.

❓ Troubleshoot

advanced

Why is the Secret environment variable empty?

A developer created a Secret named app-secret with key token. The Pod YAML references it as an environment variable APP_TOKEN using valueFrom.secretKeyRef. However, inside the container, echo $APP_TOKEN prints an empty line. What is the most likely cause?

A The Secret <code>app-secret</code> does not exist in the same namespace as the Pod

B The container image does not support environment variables

C The Pod spec must mount the Secret as a volume to use it as an environment variable

D The key <code>token</code> is misspelled in the Secret data

💡 Hint

Secrets are namespace-scoped and must be in the same namespace as the Pod.

If the Secret is missing or in a different namespace, Kubernetes cannot inject its value, resulting in an empty environment variable. The container image supports env vars by default. Mounting as a volume is not required for env vars. Misspelling the key would cause a different error or empty value but the most common cause is namespace mismatch.

🔀 Workflow

advanced

Steps to Update a Secret Used as Environment Variable

You updated the value of a Kubernetes Secret api-keys used as an environment variable in a running Pod. What is the correct workflow to apply the new Secret value so the Pod sees the updated environment variable?

A Update the Secret, then patch the Pod to reload environment variables automatically

B Update the Secret, then delete the Pod to let the controller recreate it with the new Secret value

C Update the Secret, then exec into the Pod and export the new environment variable manually

D Update the Secret, then restart the container inside the Pod without deleting the Pod

💡 Hint

Pods do not automatically reload environment variables from updated Secrets.

Kubernetes does not update environment variables in running containers when Secrets change. The common practice is to update the Secret and then delete the Pod so the controller recreates it with the new Secret values. Manually exporting env vars or patching the Pod does not work. Restarting containers inside a Pod is not supported.

✅ Best Practice

expert

Secure Handling of Secrets as Environment Variables

Which practice is the most secure when using Kubernetes Secrets as environment variables in Pods?

A Embed Secrets directly in Pod YAML files to avoid external dependencies

B Store Secrets in plain text ConfigMaps and reference them as environment variables

C Use Secrets for sensitive data and restrict RBAC permissions to limit Secret access

D Use environment variables for Secrets only in development, and hardcode them in production containers

💡 Hint

Kubernetes Secrets are designed for sensitive data and access control is important.

Option C follows best security practices by using Secrets and controlling access via RBAC. Option C is insecure because ConfigMaps are not encrypted. Option C exposes Secrets in YAML files which can be checked into source control. Option C is insecure and not recommended.

Practice

1. What is the main purpose of using Kubernetes Secrets as environment variables in a Pod?

easy

A. To keep sensitive data like passwords out of the container image and code

B. To speed up container startup time

C. To increase the size of the container image

D. To make the container logs more detailed

Solution

1. Step 1: Understand what Secrets store

   Kubernetes Secrets store sensitive data such as passwords or tokens securely.

2. Step 2: Understand environment variables usage

   Using Secrets as environment variables keeps sensitive data out of code and container images, improving security.

3. Final Answer:

   To keep sensitive data like passwords out of the container image and code -> Option A

4. Quick Check:

   Secrets protect sensitive data = A [OK]

Hint: Secrets keep sensitive data safe outside code [OK]

Common Mistakes:

• Thinking Secrets speed up container startup
• Believing Secrets increase container size
• Assuming Secrets add logging details

2. Which of the following is the correct syntax to use a Kubernetes Secret named mysecret as an environment variable API_KEY in a Pod spec?

easy

A. "env": [{"secretKeyRef": {"name": "mysecret", "key": "api_key"}}]

B. "env": [{"name": "API_KEY", "value": "mysecret"}]

C. "env": [{"name": "API_KEY", "valueFrom": {"secretKeyRef": {"name": "mysecret", "key": "api_key"}}}]

D. "env": [{"name": "API_KEY", "secretRef": {"name": "mysecret"}}]

Solution

1. Step 1: Identify correct env var syntax for Secrets

   The correct syntax uses valueFrom.secretKeyRef with name and key fields.

2. Step 2: Match syntax to options

   "env": [{"name": "API_KEY", "valueFrom": {"secretKeyRef": {"name": "mysecret", "key": "api_key"}}}] matches the correct structure exactly, specifying the secret name and key.

3. Final Answer:

   "env": [{"name": "API_KEY", "valueFrom": {"secretKeyRef": {"name": "mysecret", "key": "api_key"}}}] -> Option C

4. Quick Check:

   Use valueFrom.secretKeyRef with name and key = D [OK]

Hint: Use valueFrom.secretKeyRef with secret name and key [OK]

Common Mistakes:

• Using value instead of valueFrom
• Missing the key field inside secretKeyRef
• Using secretRef instead of secretKeyRef

3. Given this Pod spec snippet, what will be the value of environment variable DB_PASSWORD inside the container?

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: password

Assuming the Secret db-secret has the key password with value supersecret123.

medium

A. db-secret

B. DB_PASSWORD

C. password

D. supersecret123

Solution

1. Step 1: Understand valueFrom.secretKeyRef usage

   The environment variable gets its value from the Secret named db-secret and key password.

2. Step 2: Check Secret key value

   The Secret key password holds the value supersecret123, so that is assigned to DB_PASSWORD.

3. Final Answer:

   supersecret123 -> Option D

4. Quick Check:

   Env var gets Secret key's value = B [OK]

Hint: Env var equals Secret's key value, not name or key name [OK]

Common Mistakes:

• Using Secret name as value
• Using key name as value
• Confusing env var name with Secret key

4. You created a Secret named app-secret with key token. You try to use it in a Pod environment variable but get an error: secret "app-secret" not found. What is the most likely cause?

medium

A. The Secret was created in a different namespace than the Pod

B. The Secret key name is misspelled in the Pod spec

C. The Pod spec uses value instead of valueFrom

D. The container image does not support environment variables

Solution

1. Step 1: Understand Secret scope in Kubernetes

   Secrets are namespace-scoped. If the Pod is in a different namespace, it cannot access the Secret.

2. Step 2: Analyze error message

   The error secret "app-secret" not found usually means the Secret does not exist in the Pod's namespace.

3. Final Answer:

   The Secret was created in a different namespace than the Pod -> Option A

4. Quick Check:

   Secret must be in same namespace as Pod = C [OK]

Hint: Check Secret and Pod namespaces match [OK]

Common Mistakes:

• Ignoring namespace differences
• Assuming key name typo causes 'not found' error
• Blaming container image for env var errors

5. You want to mount multiple keys from a Secret named config-secret as environment variables in a Pod. Which is the best way to do this efficiently?

hard

A. Mount the Secret as a volume and read files inside the container

B. List each key separately under env with individual valueFrom.secretKeyRef entries

C. Create multiple Secrets, one per key, and reference each in env

D. Encode all keys into one string and store as a single Secret key

Solution

1. Step 1: Understand environment variable mapping from Secrets

   You can map each Secret key to an environment variable by listing them separately under env with valueFrom.secretKeyRef.

2. Step 2: Compare alternatives

   Mounting as volume is valid but not environment variables. Multiple Secrets or encoding keys complicate management.

3. Final Answer:

   List each key separately under env with individual valueFrom.secretKeyRef entries -> Option B

4. Quick Check:

   Map each key to env var individually = A [OK]

Hint: Map each Secret key individually in env list [OK]

Common Mistakes:

• Mounting Secret as volume when env vars needed
• Creating many Secrets instead of one
• Combining keys into one encoded string