A transit agency’s Helm-managed addon starts failing after a bad release; ops needs the previous working revision back. Which Helm capability restores that earlier release revision?
Select an answer to reveal the explanation.
Short Explanation
Think of Helm revisions like save-points in a transit ops console—if the new build breaks the fare-gate addon, you roll back to the last good save. helm rollback puts that prior release revision back in play. Cordon, lint, or nuking kube-system do not restore a Helm revision.
Full Explanation
When a transit agency’s Helm-managed addon fails after a bad release, helm rollback restores a prior release revision—the save-point in the ops console. Rolling back puts the last good fare-gate addon configuration back in play without inventing unrelated cluster surgery. kubectl cordon every node only affects scheduling; it does not restore a Helm revision. helm lint validates charts; it does not rewrite live cluster objects to the last good state. Deleting the kube-system namespace to force a control-plane rebuild is catastrophic and unrelated to Helm rollback. Exam caveat: Rollback targets Helm release history, not node cordons or namespace deletion. Operational check: helm history, helm rollback <release> <revision>, helm status, and confirm the civic addon’s Pods and Service endpoints recover. 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.