Helm & Kustomize for the CKA Exam: Charts, Overlays & kubectl Integration

Introduction

For years the CKA exam was almost entirely about raw YAML and kubectl. That changed with the 2025 curriculum refresh. Under the Cluster Architecture, Installation & Configuration domain — worth 25% of the Certified Kubernetes Administrator (CKA) exam — CNCF added an explicit competency: “Use Helm and Kustomize to install cluster components.” Suddenly the two most common manifest-management tools in the cloud-native world are fair game on a hands-on, performance-based exam.

This trips up a lot of candidates. If you’ve only ever written plain manifests, Helm’s templating and Kustomize’s overlay model feel like a different language. The good news: the exam doesn’t expect you to author a production Helm chart from scratch or memorize every Kustomize transformer. It expects you to use these tools — install a chart, override a value, apply an overlay, render output for inspection — quickly and correctly under time pressure.

This guide takes a practitioner’s view of exactly what the CKA tests. We’ll cover Kustomize bases and overlays, the most common patches, Helm charts and releases, the kubectl integration that ties Kustomize into the exam terminal, and a side-by-side of when each tool wins. Every section includes the commands you’ll actually run. Pair it with the CKA exam changes for 2025-2026 to see where this fits among the other curriculum updates.

Why Helm & Kustomize Are on the CKA Now

Real clusters are rarely managed with a folder of static YAML applied by hand. Teams need to deploy the same application to dev, staging, and production with small differences — a replica count here, an image tag there, a different ConfigMap value. They also need to install off-the-shelf components — ingress controllers, monitoring stacks, CNI plugins — without hand-editing thousands of lines. Two tools dominate that space:

Kustomize — a template-free way to customize plain YAML using overlays. It’s built into kubectl, so there’s nothing extra to install.
Helm — a package manager for Kubernetes. Applications are bundled as charts with templated manifests and a values.yaml you override at install time.

The CKA added them because an administrator who can’t use these tools can’t realistically install or manage cluster components the way the job demands. Expect a task that hands you a chart or a kustomization and asks you to deploy it with a specific override. For the full domain map, see the CKA exam domains breakdown.

Kustomize Fundamentals: Bases and Overlays

Kustomize’s core idea is don’t template — patch. You keep a set of valid, plain Kubernetes manifests (the base) and layer environment-specific changes on top (the overlays). The glue is a file named kustomization.yaml.

A minimal base looks like this:

# base/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml

The deployment.yaml and service.yaml are ordinary manifests — they’d apply fine on their own. An overlay then references the base and modifies it:

# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namePrefix: prod-
commonLabels:
  environment: production
replicas:
  - name: web
    count: 5
images:
  - name: nginx
    newTag: 1.27.0

Applying the production overlay gives you the base resources, renamed with a prod- prefix, labeled environment: production, scaled to 5 replicas, and pinned to nginx:1.27.0 — without editing a single line of the base. The dev overlay can do something completely different from the same source of truth.

The built-in fields you should know cold for the exam:

Field	What it does
`resources`	List of manifests or other kustomizations to include
`namePrefix` / `nameSuffix`	Prepend/append a string to every resource name
`commonLabels` / `commonAnnotations`	Add labels/annotations to every resource
`namespace`	Set the namespace for all resources
`images`	Override image `newName` and/or `newTag`
`replicas`	Override replica counts by resource name
`configMapGenerator` / `secretGenerator`	Generate ConfigMaps/Secrets from literals or files
`patches`	Apply strategic-merge or JSON 6902 patches

Applying Kustomize with kubectl

This is the part that matters most on exam day, because Kustomize is built into kubectl — no separate binary required. Two commands do almost everything:

# Render the result to stdout WITHOUT applying it (inspect first!)
kubectl kustomize overlays/production

# Build AND apply in one step
kubectl apply -k overlays/production

# Delete everything a kustomization produced
kubectl delete -k overlays/production

The -k flag points at a directory containing a kustomization.yaml. A reliable exam habit: run kubectl kustomize <dir> first to see the generated YAML, confirm the override landed (right tag, right replica count), then kubectl apply -k <dir>. That two-step check catches mistakes before they cost you points.

If a task gives you the standalone kustomize CLI instead, the equivalent is kustomize build overlays/production | kubectl apply -f -. Both produce the same output; the kubectl form is faster to type, which matters when the clock is running. Keep your imperative reflexes sharp with the CKA kubectl cheat sheet.

Kustomize Patches: Strategic Merge vs JSON 6902

When the built-in fields aren’t enough, you reach for patches. The CKA may ask you to change something a simple field can’t express — adding an environment variable, tweaking a probe, setting resource limits. Two patch styles exist.

Strategic merge patch — write a partial manifest that Kubernetes merges into the target by matching structure:

# overlays/production/kustomization.yaml (excerpt)
patches:
  - target:
      kind: Deployment
      name: web
    patch: |-
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: web
      spec:
        template:
          spec:
            containers:
              - name: web
                resources:
                  limits:
                    memory: "256Mi"

JSON 6902 patch — surgical operations (add, replace, remove) against an explicit path:

patches:
  - target:
      kind: Deployment
      name: web
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 4
      - op: add
        path: /spec/template/spec/containers/0/env
        value:
          - name: LOG_LEVEL
            value: debug

Rule of thumb the exam rewards: use a strategic merge patch when you’re adding or changing whole blocks of YAML (it reads like the manifest itself), and a JSON 6902 patch when you need precise, single-value edits by path. Both go under the patches: field in modern Kustomize.

ConfigMap and Secret Generators

A small but frequently tested feature: Kustomize can generate ConfigMaps and Secrets and automatically append a content hash to their names, so a config change rolls the Pods that consume it.

configMapGenerator:
  - name: app-config
    literals:
      - LOG_LEVEL=info
      - FEATURE_FLAG=true
    files:
      - app.properties
secretGenerator:
  - name: db-credentials
    literals:
      - password=s3cr3t

By default the generated name becomes something like app-config-2gk8d9f7tc (the hash suffix). If a task expects a fixed name, add generatorOptions: { disableNameSuffixHash: true }. Knowing this behavior explains the otherwise-confusing renamed resources you’ll see in the rendered output.

Helm Fundamentals: Charts, Releases & Repositories

Helm is the other half of the objective and the de facto package manager for Kubernetes. Three concepts anchor everything:

Term	Meaning
Chart	A packaged application — templates, default `values.yaml`, and a `Chart.yaml`
Release	A specific installation of a chart into a cluster, with a name and revision history
Repository	A collection of charts you can search and pull (e.g., a vendor’s Helm repo)
Values	The configuration inputs that fill in a chart’s templates

The exam workflow usually starts by adding a repo and installing a chart:

# Add and refresh a chart repository
helm repo add bitnami https://charts.example.com/bitnami
helm repo update

# Search for a chart
helm search repo nginx

# Install a chart as a named release into a namespace
helm install my-web bitnami/nginx --namespace web --create-namespace

Managing the lifecycle of that release:

helm list -n web                 # list releases in a namespace
helm status my-web -n web        # show release status
helm upgrade my-web bitnami/nginx -n web --set replicaCount=3
helm rollback my-web 1 -n web    # roll back to revision 1
helm uninstall my-web -n web     # remove the release

Overriding Helm Values

Most Helm tasks come down to changing a value. You have two ways, and the exam may specify one:

# Inline override with --set (good for one or two values)
helm install my-web bitnami/nginx --set service.type=NodePort --set replicaCount=2

# File-based override with -f / --values (good for many values)
helm install my-web bitnami/nginx -f my-values.yaml

To discover what you can override, dump a chart’s defaults:

helm show values bitnami/nginx > defaults.yaml

And — the single most useful exam command — render the templates without installing so you can verify the output before touching the cluster:

helm template my-web bitnami/nginx --set replicaCount=2 | less

helm template is to Helm what kubectl kustomize is to Kustomize: a dry run you should use to confirm an override produced the manifest you expected. When a task says “deploy this chart with X set to Y,” render first, eyeball the result, then helm install or helm upgrade.

Helm vs Kustomize: When to Use Which

The exam won’t usually ask you to compare them in the abstract, but understanding the trade-off helps you pick the right approach when a task leaves it open:

Dimension	Kustomize	Helm
Approach	Template-free overlays on plain YAML	Templated charts with a values file
Installation	Built into `kubectl` (`-k`)	Separate `helm` binary
Best for	Environment variants of your own manifests	Packaging and distributing apps; installing third-party components
Configuration	Patches and overlays	`values.yaml` / `--set`
Release tracking	None (it just renders YAML)	Yes — named releases with revision history and rollback
Learning curve	Lower; it’s still just YAML	Higher; templating language and chart structure

A practical heuristic: Kustomize shines when you maintain the manifests yourself and need per-environment tweaks; Helm shines when you’re consuming a packaged application or need install/upgrade/rollback lifecycle management. Many teams use both — Helm to install components, Kustomize to patch the rendered output.

Exam-Day Workflow & Speed Tips

The CKA is timed and hands-on, so technique matters as much as knowledge:

Render before you apply. kubectl kustomize <dir> and helm template <release> <chart> are free dry runs. Use them every time.
Read the task for the exact override. “Set replicas to 4” or “image tag 1.27.0” — get the specific value right; a near-miss scores zero.
Mind the namespace. Both kubectl apply -k and helm install act on a namespace. Pass -n <ns> (and --create-namespace for Helm) when the task names one.
Verify after applying. kubectl get all -n <ns>, helm list -n <ns>, and helm status confirm the deployment actually rolled out.
Don’t hand-edit generated output. If a config is generated by Kustomize or templated by Helm, change it at the source (overlay or values), not in the live object.
Use bookmarked docs. The exam allows the official Kubernetes, Helm, and Kustomize documentation. Know where the kustomization reference and helm command pages live before exam day.

These habits compound. Combined with a solid imperative kubectl foundation, they keep you moving. If your overall pacing needs work, the CKA 30-day study plan builds these reflexes session by session.

Common Pitfalls

A handful of mistakes account for most lost points on this objective:

Applying the base instead of the overlay. Point -k at the overlay directory, not base/, or your environment-specific changes won’t apply.
Forgetting the hash suffix. A configMapGenerator renames the ConfigMap with a hash; references inside the same kustomization are rewired automatically, but external references break. Use disableNameSuffixHash when a fixed name is required.
Installing a Helm release without a namespace. It lands in default and a later helm list -n web shows nothing — looking like the install failed.
Confusing helm template with helm install. Template only prints manifests; it doesn’t deploy. If nothing showed up in the cluster, you may have only rendered.
Wrong patch style. Trying to remove a field with a strategic merge patch, or restructuring a whole block with a fiddly JSON 6902 path, wastes time. Match the style to the change.

Practice in Realistic Exam Conditions

Helm and Kustomize are muscle-memory skills. Reading about kubectl apply -k is not the same as typing it correctly, against a real cluster, with the clock running. The fastest way to internalize the workflow is to repeat it on realistic, exam-style tasks until rendering, overriding, and applying becomes automatic.

Sailor.sh’s Certified Kubernetes Administrator (CKA) Mock Exam Bundle runs on actual Kubernetes clusters, not multiple-choice quizzes — so you practice the same hands-on tasks the real exam uses, including manifest-management scenarios like the ones above, with detailed explanations for every solution. It’s the most efficient way to find the gaps in your Helm and Kustomize fluency before they cost you points.

Pair the practice with focused reading: the CKA cluster upgrade guide and RBAC hands-on guide cover other high-weight pieces of the same Cluster Architecture domain, and the kubectl cheat sheet keeps your imperative speed sharp.

Conclusion

Helm and Kustomize are no longer optional trivia for the CKA — they’re an explicit competency in the Cluster Architecture domain, and they reflect how real administrators actually deploy and customize cluster components. The exam doesn’t demand chart authorship or Kustomize wizardry; it demands fluent use. Learn the Kustomize overlay model and kubectl apply -k, learn the Helm install/upgrade/rollback lifecycle and value overrides, and build the reflex to render before you apply. Drill those workflows on real clusters until they’re automatic, and a task that once looked like a foreign language becomes a quick, confident win on exam day. From there, round out the rest of the CKA curriculum and you’ll walk in prepared for everything the 2025 blueprint can throw at you.

Frequently Asked Questions

Are Helm and Kustomize really on the CKA exam?

Yes. The 2025 CKA curriculum refresh added “Use Helm and Kustomize to install cluster components” to the Cluster Architecture, Installation & Configuration domain (25% of the exam). You should be comfortable installing a Helm chart, overriding values, and applying a Kustomize overlay. See the CKA exam changes for 2025-2026 for the full list of updates.

Do I need to install Kustomize separately for the exam?

No. Kustomize is built directly into kubectl. You apply a kustomization with kubectl apply -k <dir> and render it with kubectl kustomize <dir>. A standalone kustomize CLI also exists, but the kubectl integration is all you need on the exam.

What’s the difference between Helm and Kustomize?

Kustomize customizes plain YAML using template-free overlays and patches; it’s built into kubectl and has no release tracking. Helm is a package manager that installs templated charts as named releases with upgrade and rollback history. Kustomize suits per-environment variants of your own manifests; Helm suits packaging apps and installing third-party components.

How do I override a value in a Helm chart?

Use --set key=value for one or two values, or -f values.yaml for many. Discover available keys with helm show values <chart>, and preview the result with helm template <release> <chart> --set key=value before installing.

Should I apply Kustomize output before or after checking it?

Always inspect first. Run kubectl kustomize <overlay-dir> to see the generated manifests, confirm your overrides (image tag, replica count, labels) are correct, then deploy with kubectl apply -k <overlay-dir>. The same applies to Helm: render with helm template before helm install.

Is it worth getting the CKA in 2026?

For anyone working with Kubernetes in operations, platform, or DevOps roles, yes — it remains one of the most respected hands-on cloud-native credentials. See is the CKA certification worth it in 2026 for a full breakdown of cost, effort, and career return.