Certified Kubernetes Application Developer (CKAD) Program CKAD Exam Questions with Experts Answers Updated Recently

ssh ckad00026

Your job is to edit /home/candidate/credible-mite/web.yaml so it uses APIs supported on Kubernetes 1.29+, then deploy it into namespace garfish.

Because I can’t see your file from here, the most reliable exam approach is:

run a server-side dry-run to reveal the exact deprecated/removed APIs and schema errors

edit the manifest to the modern API versions/fields

re-run dry-run until it passes

apply for real and verify rollout

1) Go to the manifest and run a server-side dry-run

cd /home/candidate/credible-mite

ls -l

sed -n '1,200p' web.yaml

Make sure the namespace exists:

kubectl get ns garfish || kubectl create ns garfish

Now run a server-side dry-run (this catches removed APIs on the cluster):

kubectl apply -n garfish -f web.yaml --dry-run=server

Whatever errors you get here tell you exactly what to fix.

2) Fix the common v1.15 → v1.29 API deprecations

Edit the file:

vi web.yaml

Below are the most common objects from older manifests and how to update them for 1.29+.

A) Deployments / DaemonSets / StatefulSets

Old (v1.15 often used):

extensions/v1beta1 or apps/v1beta1 or apps/v1beta2

New:

apiVersion: apps/v1

Also in apps/v1, .spec.selector is required and must match the pod template labels.

Example conversion:

apiVersion: apps/v1

kind: Deployment

metadata:

name: web

spec:

replicas: 2

selector:

matchLabels:

app: web

template:

metadata:

labels:

app: web

spec:

containers:

- name: web

image: nginx

Key rule:

spec.selector.matchLabels must exactly match spec.template.metadata.labels (at least for the keys you select on).

B) Ingress

Old:

apiVersion: extensions/v1beta1 (or networking.k8s.io/v1beta1)

New:

apiVersion: networking.k8s.io/v1

Required changes:

spec.rules.http.paths[].pathType is required (usually Prefix)

backend format changes from serviceName/servicePort to service.name/service.port.number (or .name for named ports)

Old backend:

backend:

serviceName: web

servicePort: 80

New backend:

backend:

service:

name: web

port:

number: 80

Full path example:

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web

spec:

rules:

- host: example.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web

port:

number: 80

C) CronJob

Old:

apiVersion: batch/v1beta1

New:

apiVersion: batch/v1

Most fields stay the same; just update apiVersion.

D) PodDisruptionBudget

Old:

policy/v1beta1

New:

policy/v1

spec.selector/minAvailable/maxUnavailable remain, but apiVersion changes.

E) RBAC

Usually already:

rbac.authorization.k8s.io/v1 (this is fine)

F) Removed APIs you must delete/replace

If you see these in a v1.15-era manifest, they are removed in modern clusters:

PodSecurityPolicy (policy/v1beta1) is removed. You cannot deploy it on 1.29+. Remove it from the manifest (or replace with whatever your environment uses, but for CKAD tasks you usually delete PSP sections from the file).

Some old admission/alpha resources also removed.

If dry-run complains “no matches for kind … in version …”, that’s your cue.

3) Re-run dry-run until it succeeds

After you edit:

kubectl apply -n garfish -f web.yaml --dry-run=server

Keep iterating until there are no errors.

4) Deploy for real

kubectl apply -n garfish -f /home/candidate/credible-mite/web.yaml

5) Verify everything in namespace garfish

List what was created:

kubectl -n garfish get all

kubectl -n garfish get ingress 2>/dev/null || true

If there is a Deployment, verify rollout:

kubectl -n garfish get deploy

kubectl -n garfish rollout status deploy --all

Check pods/events if something fails:

kubectl -n garfish get pods -o wide

kubectl -n garfish describe pod

kubectl -n garfish get events --sort-by=.lastTimestamp | tail -n 30

Solution:

ssh ckad00025

You need to expose the existing app “web-app” externally at:

Host: external.sterling-bengal.local

Path: / (and anything starting with /) → route to web-app

In CKAD labs, this is almost always done with an Ingress pointing to the Service web-app.

1) Find where web-app Service lives (namespace + port)

kubectl get svc -A | grep -w web-app

You’ll get something like:

web-app ClusterIP ... /TCP

Set the namespace:

NS=

Check the service port(s):

kubectl -n $NS get svc web-app -o yaml

Note the service port number (commonly 80).

Also verify it has endpoints (so it actually routes to pods):

kubectl -n $NS get endpoints web-app -o wide

If endpoints are empty, the Service selector doesn’t match pods — tell me and I’ll give the exact fix. But usually it’s fine.

2) Create the Ingress to route / to web-app

Create a manifest (use the service port you saw; I’ll assume 80 below):

cat <<'EOF' > web-app-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web-app-ingress

spec:

rules:

- host: external.sterling-bengal.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web-app

port:

number: 80

EOF

Apply it:

kubectl -n $NS apply -f web-app-ingress.yaml

Verify:

kubectl -n $NS get ingress web-app-ingress

kubectl -n $NS describe ingress web-app-ingress

If your Service port is not 80, change number: 80 to the correct value and re-apply.

3) Test external reachability (as instructed)

Run exactly:

curl -i http://external.sterling-bengal.local/

If curl still fails (quick checks)

A) Is there an ingress controller running?

kubectl get pods -A | egrep -i 'ingress|nginx'

kubectl get svc -A | egrep -i 'ingress|nginx'

B) Does Ingress show an address?

kubectl -n $NS get ingress web-app-ingress -o wide

C) Do we have endpoints?

kubectl -n $NS get endpoints web-app -o wide

Below are the exact steps/commands you can run.

1) Locate the Deployment and its namespace

kubectl get deploy -A | grep nginx-resources

You should see output like:

nginx-resources ...

Set a variable (replace with what you see):

NS=

Confirm replicas:

kubectl -n $NS get deploy nginx-resources -o jsonpath='{.spec.replicas}{"\n"}'

2) Check if there is a ResourceQuota in that namespace

kubectl -n $NS get resourcequota

kubectl -n $NS describe resourcequota

If there is a quota, note these fields (common ones):

requests.cpu

requests.memory

limits.cpu

limits.memory

3) Decide requests/limits for the Deployment (example values)

If the question (in your environment) provides specific values, use those.

If it doesn’t, a typical safe pair is:

requests: cpu: 100m, memory: 128Mi

limits: cpu: 200m, memory: 256Mi

I’ll proceed with these example values. If your lab specifies different numbers, just swap them in.

4) Update the existing Deployment (DO NOT DELETE)

Option A (fastest): kubectl set resources

Assuming the container name is the first container (we’ll detect it):

kubectl -n $NS get deploy nginx-resources -o jsonpath='{.spec.template.spec.containers[*].name}{"\n"}'

If it prints a single container name, set it like this:

kubectl -n $NS set resources deploy nginx-resources \

--requests=cpu=100m,memory=128Mi \

--limits=cpu=200m,memory=256Mi

Verify the Deployment now has resources

kubectl -n $NS get deploy nginx-resources -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'

5) Compute the total resources requested by the Deployment

Get replicas:

REPLICAS=$(kubectl -n $NS get deploy nginx-resources -o jsonpath='{.spec.replicas}')

echo $REPLICAS

6) Ensure the namespace quota matches (or exceeds) those totals

This is the part the question warns about: if the quota is too low, the Deployment update will fail to roll out.

6.1 If a ResourceQuota already exists

Patch it to allow at least the totals you calculated.

First, identify quota name:

RQ=$(kubectl -n $NS get resourcequota -o jsonpath='{.items[0].metadata.name}')

echo $RQ

Then patch (example: replicas=2 → requests.cpu=200m, requests.memory=256Mi):

kubectl -n $NS patch resourcequota $RQ --type='merge' -p '{

"spec": {

"hard": {

"requests.cpu": "200m",

"requests.memory": "256Mi",

"limits.cpu": "400m",

"limits.memory": "512Mi"

}

}

}'

Adjust those numbers to your replicas × request, and replicas × limit (if your quota also enforces limits).

6.2 If there is NO ResourceQuota

Create one that matches the Deployment max request totals.

Example for replicas=2 with our sample requests/limits:

cat <

apiVersion: v1

kind: ResourceQuota

metadata:

name: nginx-resources-quota

spec:

hard:

requests.cpu: "200m"

requests.memory: "256Mi"

limits.cpu: "400m"

limits.memory: "512Mi"

EOF

7) Verify rollout succeeds

kubectl -n $NS rollout status deploy nginx-resources

kubectl -n $NS get pods

Verify the running pods actually have the requests/limits:

kubectl -n $NS get pod -l app=nginx-resources -o jsonpath='{range .items[*]}{.metadata.name}{" "}{.spec.containers[0].resources}{"\n"}{end}'

(If the label selector app=nginx-resources doesn’t exist, just pick a pod name from kubectl get pods and run:)

kubectl -n $NS describe pod | sed -n '/Limits:/,/Requests:/p'

Common reasons this fails (and the fix)

Rollout stuck / pods pending with “exceeded quota”Check:

kubectl -n $NS describe pod

kubectl -n $NS describe resourcequota

Fix: increase ResourceQuota hard values to match required totals.

You set requests higher than quota allowsFix: either reduce requests or raise quota.

kubectl get deploy -A | grep nginx-resources

kubectl -n get deploy nginx-resources -o jsonpath='{.spec.replicas}{"\n"}{.spec.template.spec.containers[0].name}{"\n"}'

kubectl -n describe resourcequota