Free lesson · CKAD Prep Program · Module 2: Application design and build

Validate Definitions Before Applying

The cheapest error is the one the cluster never sees. This lesson builds the validate-first loop: dry-run, explain, diff, then apply, with every step recorded.

10 min reading

Objectives

Catch schema errors with client-side dry-run before touching the cluster
Explain the apiVersion deprecation without guessing
Diff a live object against a file before overwriting it
Prove a definition is valid with recorded commands, not hope

Why this matters

Exam time is lost in two ways: applying broken YAML and debugging the wreckage, or hesitating over a field that kubectl explain answers in seconds. Validation commands are fast, free and composable, and the CKAD rewards the habit directly: several tasks are simply faster when the first apply already works.

Concepts

kubectl apply --dry-run=client -f file validates schema and fills defaults without contacting the cluster; --dry-run=server goes further and runs admission checks against live state, catching what the client cannot see (quotas, existing names, policy). kubectl explain <resource>[.field] prints the schema plus descriptions from the cluster itself, which beats memory for nested fields. kubectl diff -f file shows exactly what an apply would change against the live object, so overwrites stop being surprises.

Deprecated apiVersions deserve a deliberate step, not a guess: the cluster prints warnings on use, and kubectl explain on the current version shows the replacement shape. When a definition predates the cluster, convert first (dry-run the new version), diff second, apply last.

Worked example

A service file of unknown provenance, validated before it touches anything:

kubectl apply --dry-run=client -o yaml -f svc.yaml > /dev/null \
  && echo CLIENT-OK
kubectl explain svc.spec.ports | head -20
kubectl diff -f svc.yaml || true   # shows the delta or nothing to change
kubectl apply -f svc.yaml
kubectl get svc -o wide

Each command earns the next: schema, then schema meaning, then delta, then the write, then the read-back. If server dry-run is available, insert it between diff and apply for admission coverage.

Exam notes

Client dry-run never sees quotas or policies; a green client check plus a rejected apply means admission, and server dry-run would have caught it. kubectl diff needs a working kubeconfig against the target cluster or it compares against nothing. And record the validation commands in your notes: a pass you cannot show is a pass you cannot defend in review.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

Take any manifest you generated earlier and run the full loop on it: client dry-run, one explain query for a field you are unsure about, diff against the live cluster, apply, read back. Record all five commands and what each one proved.

Pass criteria

All five stages present in order with one line each on what the output showed; at least one stage caught or confirmed something specific.