Stage and production for the city grants portal should share one Helm chart but differ in image tag, replica count, and Service type. Where should those differences live?
Select an answer to reveal the explanation.
Short Explanation
Same recipe, different shopping list: values.yaml (or per-env values files) retarget image tag, replicas, and Service type without forking templates. Forking charts per environment is the anti-pattern for stage versus production.
Full Explanation
Environment differences for a shared Helm chart belong in values.yaml or environment-specific values files. Stage and production keep the same templates for the city grants portal while values retarget image tag, replica count, and Service type. That is the supported Helm pattern for one chart, many environments. Forking every template file per environment with hardcoded values duplicates maintenance: bug fixes must be copied everywhere, drift is inevitable, and you no longer have one chart. That is the anti-pattern the question is steering away from. Cluster DNS zone files are not Helm configuration. DNS may resolve Services after install, but it does not parameterize chart templates for image tags or replica counts, and Helm will not read environment differences from DNS zones. Dockerfile ENTRYPOINT configures container startup inside the image; Kubernetes and Helm still need chart values for Service type and replicas. Putting environment variance only in ENTRYPOINT does not retarget chart templates and confuses image build with release configuration. Exam caveat: keep secret material out of plaintext values committed to git—use sealed secrets, external secret operators, or install-time secret injection while still parameterizing non-sensitive differences via values files. Operational check: render or install the same chart with stage values and prod values, diff the output for image tag, replicas, and Service type only, and confirm templates themselves remain identical across environments.