A city permits API needs non-sensitive feature flags injected as environment variables. Which object is the appropriate store for that configuration?
Select an answer to reveal the explanation.
Short Explanation
Feature flags that are not secrets are like the open bulletin board in city hall—ConfigMaps are that board for apps. Stick passwords elsewhere; put public-ish settings in the ConfigMap.
Full Explanation
A city permits API that needs non-sensitive feature flags injected as environment variables should store that configuration in a ConfigMap. ConfigMaps are the Kubernetes object type intended for non-confidential configuration data, consumable as environment variables (env/envFrom) or as mounted volumes. Feature flags, public endpoint names, and similar non-secret settings belong there so the permits workload can be reconfigured without rebuilding images—matching common CKA configuration practice for municipal apps.
A PersistentVolumeClaim holding only binary database files addresses durable storage claims, not lightweight key/value configuration injection for flags. A PriorityClass only influences Pod scheduling priority relative to other Pods; it does not store application configuration. A NetworkPolicy only allows or denies traffic between Pods at the network layer; it is not a configuration store for environment variables.
Exam caveat: ConfigMaps are not for credentials—use Secrets (and external secret managers in production) for confidential material even though Secrets are only base64-encoded by default in etcd. Operational check: create or update the ConfigMap, reference it from the Deployment via env or envFrom, roll or restart Pods as required by the consumption pattern, and confirm flags appear in the running permits container environment.