Sample questions
K8s Config SecretsDifficulty 1
A ConfigMap can be exposed to a Pod's container in two common ways. What is the key structural difference between using it as environment variables (envFrom/valueFrom.configMapKeyRef) versus mounting it as a volume?
- aEnvironment variables only work for numeric values, volumes only work for text values
- bEnv vars inject values into the process environment; a volume exposes each key as a file✓
- cEnv vars require a separate Secret object, volumes require a separate ConfigMap object
- dEnvironment variables are namespaced, volume mounts are cluster-scoped
Explanation:envFrom/valueFrom.configMapKeyRef sets each ConfigMap key as an environment variable visible to the container's process. Mounting the same ConfigMap as a volume instead creates a directory where each key becomes a file, with the key's value as file content. Both reference the same underlying ConfigMap data, just delivered through a different mechanism.
K8s Config SecretsDifficulty 2
A running Pod has a container that reads APP_MODE as an environment variable, set via envFrom.configMapRef from ConfigMap app-config. You update app-config with kubectl patch to change APP_MODE from debug to production, wait two minutes, then exec into the container and print $APP_MODE. What do you see?
- a
production, because the kubelet always restarts containers on ConfigMap changes - bAn empty value, because the container's environment is cleared once the source ConfigMap changes
- cStill
debug — env vars are read once at container start, not re-injected on ConfigMap changes✓ - d
production, because environment variables are re-read from the ConfigMap on every process syscall
Explanation:Environment variables from a ConfigMap are resolved once, when the container process starts. Kubernetes has no mechanism to push new values into an already-running process's environment, so the container keeps printing debug no matter how long you wait. Picking up the new value requires the Pod to be recreated (e.g. a rollout restart).
K8s Config SecretsDifficulty 2
Same setup, but this time the same ConfigMap key is also mounted as a volume file at /etc/config/APP_MODE (not using subPath). After patching the ConfigMap and waiting roughly a minute for kubelet's sync period, you run kubectl exec pod -- cat /etc/config/APP_MODE. What happens?
- aThe file eventually shows the new value, once the kubelet's next periodic sync happens✓
- bThe command fails with a file-not-found error until the Pod is manually deleted and recreated
- cThe file keeps the old value forever, identically to how env vars behave
- dThe file updates only if the container process explicitly calls a Kubernetes API to refresh it
Explanation:Volume-mounted ConfigMap data (without subPath) is periodically synced by the kubelet, so the file content eventually reflects the updated ConfigMap without any Pod restart — typically within its sync period (around a minute). This is the key practical contrast with env vars, which never update without a Pod recreation.
K8s Config SecretsDifficulty 3
volumeMounts:
- name: cfgvol
mountPath: /etc/config/app_mode.txt
subPath: APP_MODE
volumes:
- name: cfgvol
configMap:
name: app-config
The ConfigMap
app-config is then updated so that
APP_MODE changes value. You wait several minutes and check
/etc/config/app_mode.txt inside the container. What do you observe?
- aThe file is deleted, since
subPath mounts are removed whenever the source ConfigMap changes - bThe file updates on the same sync cycle as a non-
subPath mount - cThe mount switches to read-only mode and further reads fail with a permission error
- dThe file keeps its original content —
subPath volume mounts don't receive ConfigMap updates✓
Explanation:When a volume is mounted with subPath, the kubelet bind-mounts that single file path directly instead of using the symlinked ..data directory it uses for whole-directory mounts. That symlink swap is exactly the mechanism that makes normal ConfigMap volume updates propagate, so a subPath mount never sees the updated value until the Pod is recreated.
K8s Config SecretsDifficulty 1
A Secret's data field stores values that are base64-encoded strings. What does this base64 encoding actually provide?
- aStrong encryption, so anyone with
kubectl get secret -o yaml cannot read the value - bAutomatic rotation of the value on a fixed schedule
- cA safe way to represent binary/text data in a manifest, not confidentiality✓
- dCompression of the value to reduce etcd storage size
Explanation:Base64 is an encoding, not an encryption scheme. It exists so binary or special-character data can be represented safely inside a text-based manifest. Anyone who can run kubectl get secret -o yaml and decode base64 (base64 -d) can read the plaintext value; real confidentiality depends on RBAC, etcd encryption at rest, or an external secrets store.
K8s Config SecretsDifficulty 1
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
stringData:
DB_PASSWORD: "s3cr3t"
After applying this manifest, what does
kubectl get secret app-secret -o yaml show under the
data field for
DB_PASSWORD?
- aThe literal plaintext string
s3cr3t, since stringData bypasses encoding - bA base64-encoded string stored under the Secret's
data field✓ - cNothing, because
stringData and data cannot both exist on the same Secret - dAn error, because
type: Opaque does not support the stringData field
Explanation:stringData is a write-only convenience field: on apply, the API server merges its entries into data, base64-encoding them in the process. So reading the object back afterward always shows the encoded form under data, never the original stringData field.