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

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Pod with ConfigMap volume mount

Given the following Pod YAML snippet mounting a ConfigMap as a volume, what will be the content of the file /etc/config/app.properties inside the container?

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: configmap-volume-pod
spec:
  containers:
  - name: test-container
    image: busybox
    command: ["cat", "/etc/config/app.properties"]
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    key1=value1
    key2=value2

A Error: file not found

B

app.properties

C

key1=value1
key2=value2
app.properties

D

key1=value1
key2=value2

💡 Hint

Remember that mounting a ConfigMap as a volume creates files named after the keys with their content as the file content.

When a ConfigMap is mounted as a volume, each key becomes a file with the key's content as the file content. Here, the key is 'app.properties' with the content 'key1=value1\nkey2=value2'. So the file '/etc/config/app.properties' contains those lines.

🧠 Conceptual

intermediate

Behavior of ConfigMap volume updates in running Pods

If a ConfigMap used as a mounted volume in a running Pod is updated, what happens to the files inside the Pod's volume?

A The files inside the Pod update automatically within a few seconds.

B The files inside the Pod never update until the Pod is restarted.

C The files update only if the Pod's container is manually restarted.

D The files update only if the ConfigMap is deleted and recreated.

💡 Hint

Think about how Kubernetes syncs ConfigMap volumes with the cluster state.

Kubernetes automatically updates the files in the mounted ConfigMap volume within a few seconds after the ConfigMap changes, without needing to restart the Pod. This is because the volume uses a special mechanism to watch for changes.

❓ Configuration

advanced

Correct YAML for mounting multiple ConfigMap keys as files

Which YAML snippet correctly mounts only the keys config1 and config2 from a ConfigMap named multi-config as files inside /etc/config in a Pod?

A

volumes:
- name: config-volume
  configMap:
    name: multi-config
    items:
    - path: config1
    - path: config2
containers:
- name: app
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config

B

volumes:
- name: config-volume
  configMap:
    name: multi-config
    keys:
    - config1
    - config2
containers:
- name: app
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config

C

volumes:
- name: config-volume
  configMap:
    name: multi-config
    items:
    - key: config1
      path: config1
    - key: config2
      path: config2
containers:
- name: app
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config

D

volumes:
- name: config-volume
  configMap:
    name: multi-config
    keys:
    - key: config1
    - key: config2
containers:
- name: app
  volumeMounts:
  - name: config-volume
    mountPath: /etc/config

💡 Hint

Look for the correct use of the 'items' field with 'key' and 'path' under configMap.

The 'items' field under configMap allows specifying which keys to mount and their file names. Each item must have a 'key' and a 'path'. Options A, B, and D use incorrect fields or missing keys causing errors or ignoring keys.

❓ Troubleshoot

advanced

Troubleshooting missing ConfigMap files in Pod

A Pod mounts a ConfigMap as a volume, but inside the container the expected files are missing. Which is the most likely cause?

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

B The container image does not support ConfigMap volumes.

C The Pod's service account lacks permissions to read ConfigMaps.

D The volumeMount path is not an absolute path.

💡 Hint

Check if the ConfigMap name matches exactly and exists in the same namespace.

If the ConfigMap does not exist or the name is wrong, Kubernetes cannot mount it, so the files won't appear. Container image or permissions do not affect mounting ConfigMap volumes. VolumeMount paths must be absolute, but if not, Kubernetes throws an error preventing Pod creation.

🔀 Workflow

expert

Steps to update ConfigMap data and apply changes to running Pods

What is the correct sequence of commands to update a ConfigMap named app-config with new data from a file new-config.properties and ensure running Pods using it get the updated content?

A 2,1,3,4

B 1,2,3,4

C 1,3,2,4

D 3,1,2,4

💡 Hint

First generate updated ConfigMap YAML, then apply it, then restart Pods to pick changes.

You first create an updated ConfigMap manifest with the new file (step 1), then apply it to update the ConfigMap in the cluster (step 2). Since mounted ConfigMap volumes update automatically, restarting Pods is optional but recommended to reload app config (step 3). Finally, check Pod status (step 4).