CKAD Questions and Answers

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

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

ssh ckad00029

You must modify the existing Deployment store-deployment in namespace grubworm so that its containers:

run as user ID 10000

have Linux capability NET_BIND_SERVICE added

And you’re told to use the manifest file at:

/home/candidate/daring-moccasin/store-deplovment.vaml (note: the filename looks misspelled; follow it exactly on the host)

1) Inspect the current Deployment and locate the manifest file

kubectl -n grubworm get deploy store-deployment

ls -l /home/candidate/daring-moccasin/

Open the manifest:

sed -n '1,200p' "/home/candidate/daring-moccasin/store-deplovment.vaml"

2) Edit the manifest to add SecurityContext

Edit the file:

vi "/home/candidate/daring-moccasin/store-deplovment.vaml"

2.1 Set Pod-level runAsUser = 10000

Under:

spec.template.spec add:

securityContext:

runAsUser: 10000

2.2 Add NET_BIND_SERVICE capability at container-level

Under the container spec (for each container in containers:), add:

securityContext:

capabilities:

add: ["NET_BIND_SERVICE"]

A complete example of what it should look like (mind indentation):

apiVersion: apps/v1

kind: Deployment

metadata:

name: store-deployment

namespace: grubworm

spec:

template:

spec:

securityContext:

runAsUser: 10000

containers:

- name: store

image: someimage

securityContext:

capabilities:

add: ["NET_BIND_SERVICE"]

Important notes:

runAsUser can be set at Pod level (applies to all containers) or per-container. Pod-level is cleanest if all containers should run as 10000.

Capabilities must be set per-container (that’s where Kubernetes supports it).

Save and exit.

3) Apply the updated manifest

kubectl apply -f "/home/candidate/daring-moccasin/store-deplovment.vaml"

4) Ensure the Deployment rolls out

kubectl -n grubworm rollout status deploy store-deployment

5) Verify the settings are in effect

Check the rendered pod template:

kubectl -n grubworm get deploy store-deployment -o jsonpath='{.spec.template.spec.securityContext}{"\n"}'

kubectl -n grubworm get deploy store-deployment -o jsonpath='{.spec.template.spec.containers[0].securityContext}{"\n"}'

Verify on a running pod:

kubectl -n grubworm get pods

kubectl -n grubworm describe pod | sed -n '/Security Context:/,/Containers:/p'

kubectl -n grubworm describe pod | sed -n '/Containers:/,/Conditions:/p'

If there are multiple containers

Repeat the container-level securityContext.capabilities.add block for each container under spec.template.spec.containers.

Solution:

Solution:

Solution:

Solution:

ssh ckad00028

You’re seeing RBAC errors like:

User "system:serviceaccount:gorilla:default" cannot list resource "pods" … in namespace "gorilla"

That means the Pod is running as the default ServiceAccount and needs permission to list pods (and possibly also get/watch).

You must fix it by updating the Deployment (via its manifest file) and giving it the proper RBAC.

1) Confirm the error in logs

kubectl -n gorilla get deploy honeybee-deployment

kubectl -n gorilla logs deploy/honeybee-deployment --tail=200

If it’s CrashLooping and you need previous logs:

POD=$(kubectl -n gorilla get pods -l app=honeybee -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || kubectl -n gorilla get pods -o jsonpath='{.items[0].metadata.name}')

kubectl -n gorilla logs "$POD" --previous --tail=200

You should see the “cannot list resource pods” line.

2) Create a dedicated ServiceAccount for the app

(Using a dedicated SA is standard practice; the task wants you to “resolve the errors”.)

kubectl -n gorilla create serviceaccount honeybee-sa

kubectl -n gorilla get sa honeybee-sa

3) Create RBAC: Role + RoleBinding (namespaced)

This will allow listing pods in namespace gorilla.

cat <<'EOF' > honeybee-rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: honeybee-pod-reader

namespace: gorilla

rules:

- apiGroups: [""]

resources: ["pods"]

verbs: ["get", "list", "watch"]

---

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

name: honeybee-pod-reader-binding

namespace: gorilla

subjects:

- kind: ServiceAccount

name: honeybee-sa

namespace: gorilla

roleRef:

apiGroup: rbac.authorization.k8s.io

kind: Role

name: honeybee-pod-reader

EOF

Apply it:

kubectl apply -f honeybee-rbac.yaml

Quick verification (optional but very useful):

kubectl auth can-i list pods -n gorilla --as=system:serviceaccount:gorilla:honeybee-sa

Should return yes.

4) Update the Deployment manifest to use the new ServiceAccount

The manifest is at:

/home/candidate/prompt-escargot/honey bee-deployment.yaml

Because there’s a space in the filename, quote it.

4.1 Edit the file

cd /home/candidate/prompt-escargot

ls -l

vi "honey bee-deployment.yaml"

In the Deployment YAML, add (or set) this under:

spec.template.spec:

serviceAccountName: honeybee-sa

Example location:

spec:

template:

spec:

serviceAccountName: honeybee-sa

containers:

- name: ...

Save and exit.

4.2 Apply the updated manifest

kubectl apply -f "/home/candidate/prompt-escargot/honey bee-deployment.yaml"

5) Ensure rollout succeeds and errors are gone

kubectl -n gorilla rollout status deploy honeybee-deployment

kubectl -n gorilla logs deploy/honeybee-deployment --tail=200

Also confirm the pods now run with the right ServiceAccount:

kubectl -n gorilla get pods -o jsonpath='{range .items[*]}{.metadata.name}{" sa="}{.spec.serviceAccountName}{"\n"}{end}'

You should no longer see the RBAC “cannot list pods” errors.

Solution: