KCNA Cloud Native Application Delivery Practice Question
Which THREE of the following are features of Helm that facilitate release management? (Choose three.)
⚠ Common exam trap
KCNA often tests the misconception that Helm natively supports canary or blue/green deployments — it does not; those require external progressive delivery controllers, so candidates incorrectly select canary as a Helm release-management feature.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Rollback to a previous release revision
Helm facilitates release management through its revision-based model: option B is correct because Helm stores each install/upgrade as a numbered revision, and `helm rollback <release> <revision>` restores a prior revision, making recovery from a bad deployment straightforward. Option C is correct because Helm tracks release history and revision metadata (viewable via `helm history <release>` and stored in Kubernetes Secrets by default), which is the foundation for auditing and managing releases. Option E is correct because `helm upgrade <release> <chart> --set key=value` (or `-f values.yaml`) lets you apply new configuration values to an existing release, incrementing the revision while preserving release identity. Option A is not a Helm feature — canary deployment is a strategy implemented by tools such as Argo Rollouts, Flagger, or service meshes, not by Helm itself. Option D is not a Helm feature either; Horizontal Pod Autoscaling is a Kubernetes controller (the `autoscaling/v2` HPA resource) that scales pods based on metrics, independent of Helm's release management.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Canary deployment strategy
Why it's wrong here
Canary deployment is a workload rollout pattern implemented by service meshes or progressive delivery controllers, not a Helm release-management feature. It is tempting because Helm renders Kubernetes manifests, but Helm's release management covers revision history, rollback, atomic installs and release tracking.
- ✓
Rollback to a previous release revision
Why this is correct
Helm stores each release revision as a numbered snapshot, so rollback restores a prior revision's rendered Kubernetes manifests and configuration. This directly satisfies the release management requirement by enabling recovery from failed upgrades without manual re-editing, reverting both the deployed resources and Helm's stored release state.
- ✓
Release history and revision tracking
Why this is correct
Helm stores each release's revisions in Kubernetes Secrets, letting you inspect, diff and roll back to any prior revision. This revision tracking directly satisfies the stem's release-management requirement by preserving a full, queryable history of every deployed configuration.
- ✗
Horizontal pod autoscaling
Why it's wrong here
Horizontal pod autoscaling is a Kubernetes controller behaviour driven by metrics and replica targets, not a Helm release-management feature. It is tempting because Helm charts can declare autoscaling resources, but Helm itself manages packaged releases, revisions, upgrades and rollbacks rather than pod scaling.
- ✓
Upgrade a release with new values
Why this is correct
Helm's upgrade command merges a new values file over the chart's defaults and applies the resulting manifest, creating a fresh revision. This satisfies release management by letting operators evolve a running release without uninstalling it first.
Go deeper
Related to this question
Learn chapter
Pods and Workload Management
Key term
ReplicaSet and Replication
A ReplicaSet ensures a specified number of identical pod instances are running at all times in Kubernetes, using replication to maintain availability and stability.
Key term
Horizontal Pod Autoscaling
Horizontal Pod Autoscaling automatically adjusts the number of pod replicas in a Kubernetes cluster based on observed CPU, memory, or custom metrics.
About these practice questions
This KCNA question is part of Courseiva's 930-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This KCNA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the KCNA exam.