A permits API must start with a feature flag and listen port taken from a ConfigMap without baking those values into the image. Which approach parameterizes startup args from that ConfigMap?
Select an answer to reveal the explanation.
Short Explanation
Think of ConfigMap env vars as sticky notes the process can read when it boots. Wire the keys into the container environment, then let command or args expand those variables so startup stays image-clean. Changing the ConfigMap (and rolling the Pod) updates flags without rebuilding.
Full Explanation
A permits API that must start with a feature flag and listen port taken from a ConfigMap without baking those values into the image should expose ConfigMap keys as environment variables, then reference those variables in the container command or args using Kubernetes $(VAR) expansion. That parameterizes startup for municipal feature flags without rebuilding images when values change.
Baking the flag and port into a custom image tag and redeploying whenever either value changes fails the requirement to avoid baking values into the image. Storing the flag and port only in a hostPath file each node mounts at the same absolute path fails portability and couples the app to node filesystem layout. Putting the values in an Annotation on the Namespace and relying on kubelet to inject them as argv invents a mechanism the kubelet does not provide.
Exam caveat: $(VAR) substitution in command and args requires the variables to be defined on the container env; undefined references can break container starts. Operational check: wire configMapKeyRef or envFrom for the keys, set command or args to use $(FEATURE_FLAG) and $(PORT), deploy, and confirm process argv reflects the ConfigMap values. In CKAD scenarios involving q201, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.