Using Secrets as mounted volumes in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of pod with secret mounted as volume

You have a Kubernetes pod that mounts a secret as a volume at /etc/secret-volume. The secret contains a key password with value mypassword. What will be the output of cat /etc/secret-volume/password inside the pod?

Kubernetes

kubectl exec pod-secret-volume -- cat /etc/secret-volume/password

A mypassword

B base64 encoded string of mypassword

C Error: file not found

D Empty output

💡 Hint

Secrets mounted as volumes are decoded automatically and stored as plain text files.

When a secret is mounted as a volume, Kubernetes decodes the base64 encoded data and writes the plain text content to files named after the secret keys. So the file /etc/secret-volume/password contains the plain text 'mypassword'.

❓ Configuration

intermediate

Correct secret volume mount configuration

Which of the following YAML snippets correctly mounts a secret named db-secret as a volume at /etc/db inside a pod?

A

volumes:
  - name: db-volume
    secret:
      secretName: db-secret
containers:
  - name: app
    volumeMounts:
      - name: db-volume
        path: /etc/db

B

volumes:
  - name: db-volume
    secret:
      secretName: db-secret
containers:
  - name: app
    volumeMounts:
      - name: db-volume
        mountPath: /etc/db

C

bd/cte/ :htaPtnuom        
emulov-bd :eman -      
:stnuoMemulov    
ppa :eman -  
:sreniatnoc
terces-bd :emaNterces      
:terces    
emulov-bd :eman -  
:semulov

D

volumes:
  - name: db-volume
    configMap:
      name: db-secret
containers:
  - name: app
    volumeMounts:
      - name: db-volume
        mountPath: /etc/db

💡 Hint

The secret volume must specify 'secretName' and volumeMount must use 'mountPath'.

Option B correctly uses 'secretName' under 'secret' and 'mountPath' under 'volumeMounts'. Option B uses configMap instead of secret. Option B uses 'secretName' correctly (fixed from 'name'). Option B uses 'path' instead of 'mountPath'.

❓ Troubleshoot

advanced

Reason for secret volume files missing in pod

You mounted a secret as a volume in your pod, but when you exec into the pod, the secret files are missing from the mount path. What is the most likely cause?

A The secret does not exist or has a different name than specified in the volume.

B The pod does not have permission to read the secret because of RBAC rules.

C The secret was mounted as environment variables, not as a volume.

D The pod's container image does not support volumes.

💡 Hint

Check if the secret name in the volume matches an existing secret.

If the secret name in the volume does not match any existing secret, Kubernetes cannot mount it, so the files will be missing. RBAC does not restrict secret volume mounts. Environment variables are different from volume mounts. Container images do not affect volume mounting.

🔀 Workflow

advanced

Steps to update a secret mounted as volume in a running pod

You updated a Kubernetes secret that is mounted as a volume in a running pod. What is the correct way to see the updated secret files inside the pod?

A Update the secret and wait 24 hours for automatic refresh inside the pod.

B Run 'kubectl exec' and the secret files update automatically without pod restart.

C Restart the container inside the pod using 'kubectl rollout restart'.

D Delete and recreate the pod to reload the secret volume with updated data.

💡 Hint

Secret volumes are mounted at pod start and do not update automatically.

Kubernetes mounts secret volumes at pod start. Updating the secret does not update the files inside running pods. You must delete and recreate the pod to see changes. Option D is incorrect because files do not update automatically. Option D is invalid because 'kubectl rollout restart' applies to deployments, not containers. Option D is false; no automatic refresh occurs.

✅ Best Practice

expert

Best practice for restricting secret volume file permissions

You want to mount a secret as a volume but restrict the file permissions so only the owner can read the secret files inside the pod. Which volume configuration option achieves this?

A Set 'fsGroup' to 0 in the pod security context.

B Set 'readOnly: true' under the volumeMount in the container spec.

C Set 'defaultMode: 0400' under the secret volume in the pod spec.

D Set 'defaultMode: 0777' under the secret volume in the pod spec.

💡 Hint

File permission modes control access rights; 0400 means read by owner only.

The 'defaultMode' field under the secret volume controls the permission bits of the mounted files. Setting it to 0400 makes files readable only by the owner. 'readOnly' only prevents writing but does not restrict read permissions. 'fsGroup' controls group ownership, not file permissions. 0777 gives full permissions to all, which is insecure.

Practice

1. What is the main benefit of mounting Kubernetes Secrets as volumes inside a pod instead of using environment variables?

easy

A. Environment variables are more secure than mounted volumes.

B. Mounted volumes require manual pod restart to update secrets.

C. Secrets mounted as volumes can be updated automatically without restarting the pod.

D. Secrets cannot be mounted as volumes in Kubernetes.

Solution

1. Step 1: Understand how secrets are exposed

   Secrets can be exposed as environment variables or mounted as files in volumes inside pods.

2. Step 2: Compare update behavior

   Mounted secrets update automatically when changed in Kubernetes, environment variables do not update without pod restart.

3. Final Answer:

   Secrets mounted as volumes can be updated automatically without restarting the pod. -> Option C

4. Quick Check:

   Mounted secrets auto-update = B [OK]

Hint: Mounted secrets auto-update; env vars need pod restart [OK]

Common Mistakes:

• Thinking environment variables update automatically
• Believing secrets cannot be mounted as volumes
• Assuming mounted volumes require pod restart

2. Which of the following is the correct YAML snippet to mount a secret named mysecret as a volume at path /etc/secret-volume inside a pod?

easy

A. volumes:\n - name: secret-volume\n secret:\n secretName: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n path: /etc/secret-volume

B. volumes:\n - name: secret-volume\n configMap:\n name: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

C. volumes:\n - name: secret-volume\n secret:\n name: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

D. volumes:\n - name: secret-volume\n secret:\n secretName: mysecret\ncontainers:\n - name: app\n volumeMounts:\n - name: secret-volume\n mountPath: /etc/secret-volume

Solution

1. Step 1: Check volume secret syntax

   The correct key to specify the secret is secretName, not name.

2. Step 2: Verify volumeMount path key

   The correct key to specify mount path is mountPath, not path.

3. Final Answer:

   Uses correct keys: secretName and mountPath. -> Option D

4. Quick Check:

   secretName + mountPath = A [OK]

Hint: Use secretName for secret, mountPath for volume mount [OK]

Common Mistakes:

• Using configMap instead of secret
• Using 'name' instead of 'secretName'
• Using 'path' instead of 'mountPath'

3. Given this pod spec snippet mounting a secret as a volume:

volumes:
  - name: secret-vol
    secret:
      secretName: mysecret
containers:
  - name: app
    volumeMounts:
      - name: secret-vol
        mountPath: /etc/secret

If the secret mysecret contains a key password with value abc123, what will be the content of the file /etc/secret/password inside the container?

medium

A. password

B. abc123

C. mysecret

D. The file will not exist

Solution

1. Step 1: Understand secret volume mounting

   Each key in the secret becomes a file inside the mounted path with the key as filename and value as file content.

2. Step 2: Identify file content for key 'password'

   The file /etc/secret/password will contain the secret value abc123.

3. Final Answer:

   abc123 -> Option B

4. Quick Check:

   Secret key value = file content [OK]

Hint: Secret keys become filenames; values become file contents [OK]

Common Mistakes:

• Confusing filename with secret name
• Expecting filename to contain key name instead of value
• Thinking file won't be created

4. You mounted a secret as a volume in your pod, but inside the container the secret files are empty. What is the most likely cause?

medium

A. The secret was created but has no data keys.

B. The pod spec used configMap instead of secret in volumes.

C. The volumeMount path is incorrect.

D. Secrets cannot be mounted as volumes.

Solution

1. Step 1: Check secret data content

   If the secret exists but has no keys or empty values, mounted files will be empty.

2. Step 2: Verify volume type and mount path

   Using secret in volumes and correct mountPath is required; wrong type or path causes missing files, not empty files.

3. Final Answer:

   The secret was created but has no data keys. -> Option A

4. Quick Check:

   Empty secret data = empty files [OK]

Hint: Empty secret data means empty files inside container [OK]

Common Mistakes:

• Confusing empty files with wrong mount path
• Assuming secrets can't be mounted
• Mixing configMap with secret volumes

5. You want to mount a secret as a volume in a pod, but only expose the key db-password as a file named password.txt inside the container at /etc/db. Which volume configuration achieves this?

hard

A. volumes:
- name: db-secret
secret:
secretName: mysecret
items:
- key: db-password
path: password.txt
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

B. volumes:
- name: db-secret
secret:
secretName: mysecret
items:
- key: password.txt
path: db-password
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

C. volumes:
- name: db-secret
secret:
secretName: mysecret
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db/password.txt

D. volumes:
- name: db-secret
configMap:
name: mysecret
items:
- key: db-password
path: password.txt
containers:
- name: app
volumeMounts:
- name: db-secret
mountPath: /etc/db

Solution

1. Step 1: Use secret volume with items to map keys to filenames

   The items field allows selecting specific keys and renaming files.

2. Step 2: Verify correct key and path mapping

   Key db-password mapped to password.txt with mountPath /etc/db matches volumes: - name: db-secret secret: secretName: mysecret items: - key: db-password path: password.txt containers: - name: app volumeMounts: - name: db-secret mountPath: /etc/db.

3. Final Answer:

   Correctly maps the secret key to the desired filename and mount path. -> Option A

4. Quick Check:

   Use items to rename secret keys in volume [OK]

Hint: Use items to rename secret keys as files [OK]

Common Mistakes:

• Swapping key and path in items
• Using configMap instead of secret
• Mounting secret directly without items for renaming