A developer runs helm install for a parks recreation API and forgets to set a namespace flag, so the release lands in the wrong place. Which practice prevents that mistake?
Select an answer to reveal the explanation.
Short Explanation
Namespace flags are like putting the right address on a delivery label. Without -n/--namespace, Helm may drop the release somewhere you did not mean—often default—and your app team looks for it in the wrong building.
Full Explanation
If a developer runs helm install for a parks recreation API and omits the namespace flag, the release can land in the wrong namespace (often default). The preventive practice is always passing --namespace/-n so both the release metadata and rendered namespaced resources target the intended app namespace. Explicit namespace flags are basic hygiene on shared municipal clusters where default is rarely the right home for a parks API.
Why the other options fail by concept: Relying only on kubectl config current-context does not set a Helm release namespace and still risks default. HELM_DRIVER=memory changes storage backend for release records; it does not make namespace targeting irrelevant. Installing into kube-system dumps apps into the control-plane namespace—an anti-pattern for application workloads.
Exam caveat: --create-namespace helps when the target NS does not exist, but still requires the correct -n value. Some charts also embed namespace in templates inconsistently—review rendered output. Helm’s kubeconfig context and -n flag interact; be explicit in scripts used by city CI.
Operational check: Standardize install/upgrade scripts with -n parks-api (or similar) and fail CI if missing. After install, helm list -n parks-api and kubectl get all -n parks-api should show the release; helm list -n default should not unexpectedly own it.