Application Deployment →mediumMultiple Select

CKAD Application Deployment Practice Question

Which TWO statements about Kustomize are true?

⚠ Common exam trap

CNCF often tests the misconception that Kustomize is a deployment strategy tool (like for canaries) rather than a configuration customization tool, and that it is tightly coupled to kubectl or Helm, when in fact it is a standalone declarative customization engine.

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

✓

Kustomize supports overlays that allow different configurations for different environments.

Kustomize supports overlays, which are layered patches applied on top of a base configuration. This allows you to define a common base set of Kubernetes resources and then use different overlay directories (e.g., dev, staging, prod) to customize settings like replicas, image tags, or namespaces for each environment without duplicating the entire manifest.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Kustomize can be used to perform canary deployments.
Why it's wrong here
Kustomize is a configuration management tool that generates resource manifests; it does not orchestrate traffic shifting or rollout strategies. Canary deployments require progressive delivery mechanisms like Argo Rollouts or Flagger, which manage weighted routing and automated analysis. Kustomize only renders YAML, so it lacks the control plane to adjust replica counts or traffic splits across versions.
✓
Kustomize supports overlays that allow different configurations for different environments.
Why this is correct
Kustomize's overlay mechanism layers environment-specific patches on top of a base kustomization, allowing you to modify replicas, images, or namespaces per environment. The base directory holds common resources, and overlays reference it via a `kustomization.yaml` with fields like `resources` and `patchesStrategicMerge`. This avoids duplicating manifests and keeps a single source of truth across dev, staging, and production.
✗
Kustomize requires Helm to manage dependencies.
Why it's wrong here
Kustomize is a standalone tool and does not depend on Helm for dependency management. It has its own mechanism for composing resources, such as referencing remote git bases or local directories in the `resources` field. Helm is an optional, separate package manager with its own charts; integrating them is possible but never required for kustomize to function.
✓
Kustomize uses a file named kustomization.yaml to define resources and customizations.
Why this is correct
The `kustomization.yaml` file is the central configuration for kustomize, listing all resources via the `resources` field and defining customizations through patches, configMap generators, and transformers. This file is processed by the `kustomize build` command (or `kubectl apply -k`) to produce the final manifests. Without this file, kustomize cannot determine which files to read or how to apply modifications.
✗
Kustomize can only be used with kubectl apply -k.
Why it's wrong here
Although `kubectl apply -k` is a common wrapper, kustomize operates as a standalone binary that outputs fully rendered YAML via `kustomize build`. That output can be piped to `kubectl apply -f`, checked into a repository, or consumed by CI/CD pipelines without kubectl involved. This flexibility makes kustomize usable in any GitOps workflow, not just kubectl commands.

Go deeper

CKAD Application Deployment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question