A workload needs its ServiceAccount token, a ConfigMap, and a Secret presented together under one mount path for identity and config. Which volume type fits?
Select an answer to reveal the explanation.
Short Explanation
Projected volumes are the “one binder, three tabs” pattern—token, ConfigMap, and Secret land under one mount. You don’t stash identity files on the node or invent a PVC just to glue sources together.
Full Explanation
When a workload needs its ServiceAccount token, a ConfigMap, and a Secret presented together under one mount path for identity and config, use a projected volume that combines those sources. Projected volumes let municipal apps read token, config, and credential files from a single directory tree without multiple mounts at conflicting paths.
hostPath pointing at /var/run/secrets on the node is unsafe and non-portable. Three separate emptyDir volumes with medium Memory do not populate Kubernetes API credentials or ConfigMap keys by themselves. A single PVC formatted with all three objects at create time is not how tokens and ConfigMaps are projected.
Exam caveat: projected sources include secret, configMap, downwardAPI, and serviceAccountToken. Token expiration/rotation behaviors matter for long-lived apps.
Operational check: define projected volume with three sources; kubectl exec -- ls the mount path; renew ConfigMap data and observe projection updates where supported; confirm token files exist without hostPath. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.