Create a Kubernetes secret as follows: Name: super-secret password: bob Create a pod named pod-secrets-via-file, which mounts a secret named super-secret at /secrets. Create a second pod named…

Kubernetes Secrets: Mounting and Injecting into Pods Overall Goal Kubernetes Secrets store sensitive data (passwords, tokens, keys) separately from pod specs, so credentials aren't hardcoded into images or YAML. This question tests two consumption patterns: volume mounts…

Submitted by ashley.k· May 4, 2026Workloads and Scheduling

Question

Create a Kubernetes secret as follows: Name: super-secret password: bob
Create a pod named pod-secrets-via-file, which mounts a secret named super-secret at /secrets.
Create a second pod named pod-secrets-via-env, using the redis Image, which exports password as CONFIDENTIAL

Explanation

Kubernetes Secrets: Mounting and Injecting into Pods

Overall Goal

Kubernetes Secrets store sensitive data (passwords, tokens, keys) separately from pod specs, so credentials aren't hardcoded into images or YAML. This question tests two consumption patterns: volume mounts (secret as a file) and environment variables (secret as an env var).

Step 1: Create the Secret

kubectl create secret generic super-secret --from-literal=password=bob

Why necessary: The secret must exist before any pod that references it is scheduled. If a pod references a non-existent secret, it will fail with CreateContainerConfigError and stay in a pending/error state.

What it does: Creates a generic Secret named super-secret with one key password and value bob. Kubernetes base64-encodes the value internally (this is encoding, not encryption).

Step 2: Mount the Secret as a File (pod-secrets-via-file)

apiVersion: v1
kind: Pod
metadata:
  name: pod-secrets-via-file
spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeMounts:
    - name: secret-vol
      mountPath: /secrets
  volumes:
  - name: secret-vol
    secret:
      secretName: super-secret

Why necessary: The volumes section declares the secret as a volume source; the volumeMounts section attaches it to the container at /secrets. Both halves are required - one without the other is a validation error.

What it does: At /secrets/password inside the container, Kubernetes writes a file whose contents are bob. Each secret key becomes a separate file.

If skipped/wrong: Using the wrong secretName causes MountVolume.SetUp failed. Wrong mountPath means the app looks in the wrong directory.

Step 3: Inject the Secret as an Env Var (pod-secrets-via-env)

apiVersion: v1
kind: Pod
metadata:
  name: pod-secrets-via-env
spec:
  containers:
  - name: redis
    image: redis
    env:
    - name: CONFIDENTIAL
      valueFrom:
        secretKeyRef:
          name: super-secret
          key: password

Why necessary: secretKeyRef maps a specific secret key (password) to a specific env var name (CONFIDENTIAL). The env var name and the secret key name do not need to match - that's intentional here.

What it does: The process inside the redis container sees CONFIDENTIAL=bob in its environment.

If skipped/wrong: Using configMapKeyRef instead of secretKeyRef won't find the secret. Getting key: password wrong causes CreateContainerConfigError because Kubernetes can't resolve the reference.

Why This Approach Is Correct

Pattern	Use when
Volume mount	App reads config from files (e.g., TLS certs, `.env` files)
Environment variable	App reads `os.environ` or the framework expects env vars

Both patterns avoid baking secrets into the container image, satisfying the principle of least exposure.

Memory Tip

"Secret first, pod second - always." Think of the secret as a USB drive: you plug it in before the computer boots (pod starts). Volume mount = file on disk; env var = shell variable. The secret name is the drive, the key is the file on the drive.

Topics

#Kubernetes Secrets#Pod Configuration#Volume Mounting#Environment Variables

Community Discussion

No community discussion yet for this question.

Full CKA Practice