Linux Foundation CKAD Dumps - Pass Certified Kubernetes Application Developer Exam in 2026

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.

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: