Public-health wants every key from a ConfigMap loaded as environment variables on a stats API Pod without listing each key. Which consumption pattern does that?
Select an answer to reveal the explanation.
Short Explanation
envFrom is the bulk pour—tip the whole ConfigMap into the container's environment in one go instead of wiring each key by hand.
Full Explanation
Public-health wanting every key from a ConfigMap loaded as environment variables on a stats API Pod without listing each key should use envFrom referencing the ConfigMap. envFrom imports all keys from the referenced ConfigMap (or Secret) into the container environment in one declaration, which is the concise pattern when the stats API consumes a whole bag of non-sensitive settings rather than a handful of individually named env entries. That keeps municipal manifests shorter and reduces missed keys when the ConfigMap grows.
hostNetwork: true alone only shares the node network namespace; it does not load ConfigMap keys as environment variables. nodeSelector alone only constrains which nodes may run the Pod; it is scheduling, not configuration injection. imagePullPolicy: Always alone only affects when images are pulled from the registry; it does not populate environment variables from a ConfigMap.
Exam caveat: envFrom can collide on key names across multiple sources, and sensitive keys still belong in Secrets via secretRef rather than configMapRef. Operational check: define envFrom.configMapRef on the stats container, apply the change, then kubectl exec and printenv (or describe the Pod) to confirm every ConfigMap key appears for the public-health API workload.