An app expects configuration files under /etc/config inside the container. The data lives in ConfigMap portal-files. How should the Pod consume it as files?
Select an answer to reveal the explanation.
Short Explanation
Want files on disk? Mount the ConfigMap as a volume at /etc/config. Environment injection does not magically create that directory tree. imagePullSecrets are for registry auth, not config files.
Full Explanation
When an app expects configuration files under /etc/config and the data lives in ConfigMap portal-files, define a volumes entry of type configMap for portal-files and volumeMount it at /etc/config. Each ConfigMap key becomes a file in that directory unless items remaps specific keys. File-based configuration is common for municipal portals that already know how to read files from a fixed path.
Setting envFrom.configMapRef and assuming the process will find files under /etc/config automatically fails—envFrom creates environment variables, not files at that path. Using only configMapKeyRef environment variables does not also write companion files under /etc/config. Placing the ConfigMap name in imagePullSecrets fails because imagePullSecrets supply registry pull credentials, not application config materialization.
Exam caveat: whole-ConfigMap mounts can receive updates over time from the kubelet, but subPath mounts do not automatically refresh the same way. Operational check: add the volume and volumeMount, deploy, exec ls /etc/config, and confirm expected keys appear as files with the correct contents for the portal. In CKAD scenarios involving q197, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.