What's the difference between a Helm library chart and a regular chart, and when would you build one?
Quick Answer
A library chart (type: library in Chart.yaml) provides reusable template snippets (via named templates/_helpers.tpl) that other charts import, but it cannot be installed on its own and produces no Kubernetes resources or release by itself. Regular (application) charts produce deployable resources and can be installed directly. You build a library chart when multiple application charts across teams need to share common templating logic (standard labels, common Deployment/Service boilerplate, security context defaults) without copy-pasting it into every chart.
Detailed Answer
In Chart.yaml, type: application (the default) means the chart is meant to be installed and produces a release with real resources; type: library means the chart contains only named templates (typically defined in templates/_helpers.tpl-style files) meant to be imported by other charts via {{ include "mylib.deploymentSpec" . }} — a library chart is never installed by itself and Helm will refuse to helm install one directly.
This is the mechanism platform teams use to enforce consistency across many microservice charts without a fragile copy-paste convention: a shared library chart might define standard labels/annotations, common resource limit defaults, a standardized liveness/readiness probe block, or security context boilerplate, and every team's application chart declares it as a dependency in Chart.yaml and calls its named templates. When the platform team needs to roll out a new required label or a security context change across dozens of services, they update the library chart once and each consuming chart picks it up on its next helm dependency update + version bump, rather than requiring a coordinated edit across every individual chart's templates.
The tradeoff is indirection: debugging a rendered manifest now requires understanding both the consuming chart and the library chart's templates, so helm template output review becomes more important as library charts get adopted more broadly.
Interview Tip
Give the concrete platform-team scenario (rolling out a required label across dozens of services) — that's the answer that shows you understand WHY library charts exist, not just what the type field does.