An app team works only in namespace permitting-apps and needs to see Helm releases for their apps—not cluster-admin inventory. Which practice fits?
Select an answer to reveal the explanation.
Short Explanation
You’re stocking one department’s shelves, not auditing the whole warehouse. Scope helm list/status to the app namespace so you see your releases, not every team’s.
Full Explanation
An app team confined to namespace permitting-apps should use helm list and helm status scoped with -n permitting-apps (or equivalent namespace context) so they only see their application releases. Namespace-scoped inventory matches least-privilege municipal developer workflows and avoids treating cluster-wide helm list --all-namespaces as a daily habit without need.
Why the other options fail by concept: Always listing all namespaces is a cluster-admin style inventory, not an app-team default. kubectl get nodes lists nodes, not Helm releases. Reading /etc/kubernetes/manifests shows static pod manifests on control planes, unrelated to Helm release status in an app namespace.
Exam caveat: Helm storage may live as Secrets/ConfigMaps in the namespace—RBAC must allow the team to read them for list/status to work. A release installed without -n may sit in default while the team looks in permitting-apps—consistent namespace flags prevent “missing” releases. helm list --filter can further narrow busy namespaces.
Operational check: helm list -n permitting-apps and helm status <release> -n permitting-apps after installs. Compare against kubectl get deploy,svc -n permitting-apps to ensure the team’s operational view matches the releases they own.