A municipal SRE needs an operational inventory of which Helm-managed cluster components are installed and their status. Which Helm commands provide that release inventory?
Select an answer to reveal the explanation.
Short Explanation
helm list is the city garage’s clipboard of installed vehicles; helm status is the deeper inspection sheet for one car. Together they tell you which Helm releases exist and how a given release looks. Node metrics, kubeadm tokens, and crictl alone are not Helm inventories.
Full Explanation
A municipal SRE inventories Helm-managed components with helm list for releases and helm status for details on a named release. helm list is the garage clipboard; helm status is the deeper inspection sheet for one vehicle in the civic fleet. kubectl top nodes lists resource metrics, not Helm chart repositories or releases by design. kubeadm reset token list enumerates bootstrap tokens, not Helm revisions cluster-wide. crictl ps filtered by a fictional helm.io/inventory label is not a Helm inventory tool. Exam caveat: Use Helm’s own list/status for release inventory across namespaces as needed. Operational check: helm list -A, helm status <release> -n <ns>, and reconcile the inventory with the city’s addon catalog during audit. In municipal platform operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the cluster’s current minor version and addon revisions used by the civic platform team. Keep the verification evidence—command output or config snippets—with the municipal runbook so audits can prove the control was applied as designed.