Home › CKA practice tasks › Deploy a production Kustomize overlay
CKA · Cluster Architecture, Installation & Configuration

Build a Production Kustomize Overlay Without Editing the Base

The application team supplies a reusable Deployment in `/root/checkout/base`. The `checkout-prod` namespace already exists. Create the production overlay under `/root/checkout/overlays/prod` without changing any files in the base.

Live lab access

This scenario is included in Free Practice. Choose from 6 fixed labs with 5 shared sessions per week, automatic grading, hints, solutions, AI Lab Coach and saved progress.

Create an account for this free lab →

Explore the six free labs with AI Lab Coach →

Read the brief on any device. Use a desktop or laptop for the terminal lab. Nothing starts until you choose Start.

The task

The application team supplies a reusable Deployment in /root/checkout/base. The checkout-prod namespace already exists. Create the production overlay under /root/checkout/overlays/prod without changing any files in the base.

Requirements
1. Create a Kustomization that references ../../base and places the Deployment in checkout-prod.
2. Set the checkout Deployment to three replicas and change its nginx image to nginx:1.27.5 through the overlay.
3. Apply the overlay and ensure all three updated replicas are available.
4. Keep the base files unchanged and leave a working overlay that can reproduce the required Deployment.

Original Prepium guide · Written for Kubernetes v1.35 and checked against the official documentation on 6 October 2026. Use a disposable practice cluster. Everything below uses the Kustomize built into kubectl, so no extra binary is needed.

Kustomize bases and overlays: change an app per environment without touching the original YAML

Kustomize builds manifests from a kustomization.yaml. A base is a directory of plain resources that knows nothing about environments. An overlay is another kustomization that lists the base under resources and layers changes on top: a namespace, image tags, replica counts, patches. Because the base is never edited, several overlays can share it, and you can always rebuild exactly what was deployed.

ledger/
├── base/                 deployment.yaml + kustomization.yaml (resources only)
└── overlays/staging/     kustomization.yaml ──resources: ../../base
                          + namespace + images + replicas + patches ──→ kubectl kustomize / apply -k

1. Know which Kustomize you are running

kubectl version --client

The client output includes a Kustomize Version line. kubectl embeds its own copy, and that copy has moved over time (frozen at v2.0.3 until kubectl v1.21, v5 from kubectl v1.27), so check it before trusting a blog post. In current versions bases: is deprecated in favour of listing directories under resources:, and patchesStrategicMerge/patchesJson6902 are deprecated in favour of a single patches: list. The kubectl kustomize command also exposes flags such as --enable-helm, which you rarely need on the exam.

2. A base that stays generic

ledger/base/kustomization.yaml only lists files:

resources:
- deployment.yaml

Its deployment.yaml is an ordinary Deployment named ledger-api with one replica and a container image httpd:2.4, and no namespace set.

3. An overlay that changes four things

ledger/overlays/staging/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
namespace: prepium-tutorial
images:
- name: httpd
  newTag: 2.4-alpine
replicas:
- name: ledger-api
  count: 2
patches:
- path: memory-limit.yaml

Each field is a transformer with one job. namespace sets or overrides the namespace on every resource. images matches containers by image name and swaps the tag (or the name, with newName) without a patch. replicas matches by resource name and works for Deployments, ReplicaSets, ReplicationControllers and StatefulSets. patches handles anything else; here memory-limit.yaml is a small strategic-merge patch that names the Deployment and its container and adds a memory limit. The docs recommend small patches that do one thing each.

4. Render, compare, apply, verify

kubectl create namespace prepium-tutorial
kubectl kustomize ledger/overlays/staging          # print only, change nothing
kubectl diff -k ledger/overlays/staging            # compare with the live cluster
kubectl apply -k ledger/overlays/staging
kubectl -n prepium-tutorial rollout status deployment/ledger-api
kubectl -n prepium-tutorial get deploy ledger-api -o jsonpath='{.spec.replicas} {.spec.template.spec.containers[0].image}'

-k must point at a directory that contains a kustomization file. Rendering the base on its own (kubectl kustomize ledger/base) should still show one replica and the original tag: that proves the overlay did the work.

Common mistakes

Example checkEvidence
Overlay builds from the basekubectl kustomize on the overlay succeeds and shows the changed fields
Namespace appliedRendered resources carry namespace: prepium-tutorial
Live object matchesReplica count and image from the jsonpath query; rollout complete
Base untouchedRendering the base alone still shows its original values

Cleanup: kubectl delete -k ledger/overlays/staging, then kubectl delete namespace prepium-tutorial. References: Declarative Management of Kubernetes Objects Using Kustomize, Kustomization reference, kubectl kustomize. Next, try Kustomize for CKAD or rendering a Helm chart.

Difficulty
Medium · 7 minutes target
Domain
Cluster Architecture, Installation & Configuration
Grading
Live checks · partial credit

Practice scope

This additional curriculum lab is available in single-task practice with the existing 12-minute limit. Its alternate scenario also appears in one of the two mixed curriculum mocks. The first three 17-task mocks keep their original task sets. Hints, an explained solution and requirement-by-requirement feedback are available in the lab.

Browse CKA practice tasks →