A municipal chart needs different database URLs per environment without forking the upstream chart. Which Helm approach customizes the release correctly?
Select an answer to reveal the explanation.
Short Explanation
Same cake mix, different frosting per party—don’t fork the bakery. Pass a values file or --set so each environment gets its DB URL without rewriting the upstream chart.
Full Explanation
A municipal chart that needs different database URLs per environment should keep one upstream chart and supply environment-specific overrides with a values file and/or --set on install/upgrade. That preserves upgrade paths from the community chart while letting staging and production point at different databases—standard Helm customization for city platforms that refuse to fork every upstream repository.
Why the other options fail by concept: Editing and force-pushing upstream public templates for every environment is unsustainable and hostile to upgrades. Renaming kubeconfig contexts does not override chart values. kubectl edit on random Pods after install drifts live state from the release and is wiped on the next upgrade; values files do affect rendered Deployments when templates reference them.
Exam caveat: Merge order matters—later --set can override file values depending on how you invoke Helm. Some values are maps/lists that need careful --set syntax; prefer values files for complex municipal config. Do not put production secrets in git-tracked values without sealing/SOPS patterns appropriate to your org.
Operational check: Maintain values-staging.yaml and values-prod.yaml with different database URLs, helm upgrade --install <release> <chart> -n <ns> -f values-<env>.yaml, then kubectl get deploy,cm,secret -n <ns> and confirm rendered env/config matches the intended environment without chart forks.