A parks reservation API needs different feature flags and log levels in test versus production on OKE. Where should those non-secret settings live so retargeting an environment does not require rebuilding the OCIR image?
Select an answer to reveal the explanation.
Short Explanation
Feature flags and log levels are settings, not passwords—park them in a ConfigMap and inject them. Baking them into the OCIR image means a rebuild just to point at another environment. Secrets are for credentials.
Full Explanation
Feature flags and log levels for a parks reservation API differ between test and production and are non-secret settings. They belong in a ConfigMap injected as environment variables or a mounted file so retargeting an environment does not require rebuilding the OCIR image. The same image digest can run in multiple environments with different ConfigMaps attached to the Pod template. Dockerfile ENV lines baked into every layer freeze environment-specific values into the artifact, forcing a rebuild and retag just to flip a flag or log verbosity. A Kubernetes Secret is for credentials and sensitive material; putting ordinary feature flags there blurs secret hygiene, auditing, and access patterns. Hard-coded literals in the compiled binary with no cluster object make every configuration change a code change and a new image. Exam caveat: ConfigMaps are not secret—anyone who can read the namespace can often read the flags—so do not park database passwords or API tokens there even if injection looks similar. Operational check: deploy one image digest to test and production, attach different ConfigMaps, restart or reload as the app requires, and confirm log level and flags differ without a new OCIR build.