A team must install a third-party packaged chart with rich values, while another team only needs light YAML overlays on first-party manifests. Which tool choice is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
Pick the right city vehicle: a tour bus with a dial-a-route brochure (Helm charts and values) versus a stamp-and-overlay print shop for your own forms (Kustomize). Third-party packages and first-party YAML overlays are different jobs.
Full Explanation
When one team must install a third-party packaged chart with rich values, while another only needs light YAML overlays on first-party manifests, the appropriate tool choice is Helm for the parameterized third-party chart and Kustomize for first-party base-plus-overlay customization. Matching the tool to the upstream delivery format and the team’s customization depth is pragmatic municipal platform guidance—and aligned with CKAD’s coverage of both.
Why the other options fail by concept: Always rewriting third-party charts into raw YAML and forbidding Helm ignores how vendors ship software. Using only Kustomize to parameterize a complex upstream that ships exclusively as Helm fights the package format. Avoiding both tools and kubectl-edit live in production is not a sustainable process.
Exam caveat: Teams can combine them (Helm render then Kustomize), but understand ownership boundaries. Neither tool replaces image promotion discipline or policy controls. CKAD expects familiarity with both install/upgrade/rollback (Helm) and base/overlay/apply -k (Kustomize).
Operational check: Document per-service: “vendor chart → Helm release” vs “in-house YAML → Kustomize overlay.” For a new city service, pick based on upstream format, then verify the chosen pipeline produces reviewable YAML before production apply.