KCNA Helm and Package Management 2 — Questions and Answers
Question 1: What is the purpose of the `helm dependency update` command?
- Upgrades all installed releases to their latest chart versions
- Downloads and updates the chart dependencies listed in Chart.yaml (Correct answer)
- Updates the Helm binary to the latest version
- Refreshes the cached repository index files
Correct answer: Downloads and updates the chart dependencies listed in Chart.yaml
`helm dependency update` resolves and downloads chart dependencies declared in the `dependencies` section of Chart.yaml into the `charts/` directory.
Question 2: Which Helm built-in object provides access to Kubernetes cluster version information in templates?
- .Release
- .Chart
- .Capabilities (Correct answer)
- .Values
Correct answer: .Capabilities
The `.Capabilities` object exposes information about the Kubernetes cluster, including API versions and the Kubernetes version.
Question 3: What does a `helm rollback` command do when given a release name and revision number?
- Deletes the release and reinstalls from scratch
- Restores the release to the specified previous revision (Correct answer)
- Reverts the chart source files to an earlier version
- Rolls back the Helm binary to a prior version
Correct answer: Restores the release to the specified previous revision
`helm rollback <release> <revision>` restores a Helm-managed release to a previously deployed revision stored in the release history.
Question 4: In Helm, what is the function of the `_helpers.tpl` file inside a chart's `templates/` directory?
- Defines default values for the chart
- Stores Kubernetes manifest files for direct deployment
- Contains reusable named templates and helper functions (Correct answer)
- Specifies chart dependencies and their versions
Correct answer: Contains reusable named templates and helper functions
`_helpers.tpl` is a convention file prefixed with an underscore so Helm skips rendering it as a manifest; it holds reusable named templates called via `template` or `include`.
Question 5: Which command would you use to see the actual Kubernetes manifests Helm would generate without deploying them?
- helm simulate
- helm template (Correct answer)
- helm dry-run
- helm render
Correct answer: helm template
`helm template` renders chart templates locally and prints the resulting Kubernetes manifests without contacting the cluster.
Question 6: What flag must be passed to `helm install` or `helm upgrade` to perform a dry run that also validates against the Kubernetes API server?
- --dry-run=server (Correct answer)
- --validate
- --simulate
- --preview
Correct answer: --dry-run=server
`--dry-run=server` sends manifests to the API server for validation without persisting them, catching issues that local rendering cannot detect.
Question 7: How does Helm store release state by default in a Kubernetes cluster?
- In a local SQLite database on the Helm client machine
- As ConfigMaps or Secrets in the release namespace (Correct answer)
- In etcd directly via the Kubernetes API
- In a dedicated Helm namespace as a StatefulSet
Correct answer: As ConfigMaps or Secrets in the release namespace
By default Helm 3 stores release information as Secrets (encoded) in the release's namespace, allowing multi-user access and cluster-side persistence.
KCNA Helm and Package Management 2
What is the purpose of the `helm dependency update` command?