Using Secrets as mounted volumes in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the volume type as a secret in the pod spec.

Kubernetes

volumes:
  - name: secret-volume
    [1]:
      secretName: mysecret

Drag options to blanks, or click blank then click option'

AconfigMap

Bsecret

CemptyDir

DpersistentVolumeClaim

Attempts:

3 left

💡 Hint

Common Mistakes

Using configMap instead of secret for secret volumes.

Using emptyDir which is for temporary storage.

To mount a secret as a volume, the volume type must be secret.

2fill in blank

medium

Complete the container volumeMounts to mount the secret volume at the correct path.

Kubernetes

containers:
- name: app
  image: myapp
  volumeMounts:
  - name: secret-volume
    mountPath: [1]

Drag options to blanks, or click blank then click option'

A/etc/secret-volume

B/etc/config

C/etc/secret

D/var/secrets

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated paths like /etc/config which is for configMaps.

Using paths that do not match the volume name.

The common convention is to mount secrets under /etc/secret or a similar path.

3fill in blank

hard

Fix the error in the volumeMounts section to correctly mount the secret volume.

Kubernetes

containers:
- name: app
  image: myapp
  volumeMounts:
  - name: [1]
    mountPath: /etc/secret

Drag options to blanks, or click blank then click option'

Asecret-volume

Bdata-volume

Cconfig-volume

Dcache-volume

Attempts:

3 left

💡 Hint

Common Mistakes

Using a different volume name than defined in volumes.

Typos in the volumeMount name.

The volumeMount name must match the volume name defined in the pod spec, which is secret-volume.

4fill in blank

hard

Fill both blanks to create a pod spec that mounts a secret named 'db-secret' at '/etc/db'.

Kubernetes

volumes:
- name: [1]
  secret:
    secretName: [2]

Drag options to blanks, or click blank then click option'

Adb-secret-volume

Bdb-secret

Cmy-secret

Dsecret-volume

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up volume name and secretName.

Using incorrect secret names.

The volume name can be any valid name, here db-secret-volume. The secretName must be the actual secret, db-secret.

5fill in blank

hard

Fill all three blanks to complete the container spec that mounts the secret volume 'db-secret-volume' at '/etc/db'.

Kubernetes

containers:
- name: app
  image: myapp
  volumeMounts:
  - name: [1]
    mountPath: [2]
    readOnly: [3]

Drag options to blanks, or click blank then click option'

Adb-secret-volume

B/etc/db

Ctrue

Dfalse

Attempts:

3 left

💡 Hint

Common Mistakes

Setting readOnly to false which is insecure.

Using wrong mountPath or volume name.

The volumeMount name must match the volume name db-secret-volume. The mountPath is /etc/db. Secrets should be mounted as read-only, so true.

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