Pass the Linux Foundation Kubernetes Application Developer CKAD Questions and answers with Dumpstech

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.

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.

Do this on ckad00027 and edit the given manifest file (that’s what the task expects).

0) Connect to correct host

ssh ckad00027

1) Open the manifest and identify the container + port

cd /home/candidate/spicy-pikachu

ls -l

sed -n '1,200p' app-deployment.yaml

Confirm the container port is 8081 in the YAML (usually under ports:).

2) Edit the YAML to add a readinessProbe

Edit the file:

vi app-deployment.yaml

Inside the Deployment, locate:

spec:

template:

spec:

containers:

- name: ...

image: ...

Add this under the container (same indentation level as image, ports, etc.):

readinessProbe:

httpGet:

path: /healthz

port: 8081

initialDelaySeconds: 6

periodSeconds: 3

Notes:

Use port: 8081 (because the app runs on 8081).

Ensure indentation is correct (2 spaces per level commonly).

Save and exit.

3) Apply the updated manifest

kubectl apply -f /home/candidate/spicy-pikachu/app-deployment.yaml

4) Ensure the Deployment rolls out successfully

kubectl -n prod rollout status deploy app-deployment

5) Verify the readiness probe is set

Check the probe from the live object:

kubectl -n prod get deploy app-deployment -o jsonpath='{.spec.template.spec.containers[0].readinessProbe}{"\n"}'

And confirm pods are becoming Ready:

kubectl -n prod get pods -l app=app-deployment

If the label selector differs, just:

kubectl -n prod get pods

kubectl -n prod describe pod | sed -n '/Readiness:/,/Conditions:/p'

That completes the task: readiness probe on /healthz, initialDelaySeconds: 6, periodSeconds: 3.

ssh ckad00043

You have two deliverables here:

Figure out what RBAC permissions the scraper Deployment needs (the logs will usually show “Forbidden” with the missing verb/resource).

Create a ServiceAccount named scraper in namespace cute-panda (and in practice, you then bind the needed permissions to it and use it in the Deployment so it actually works).

Below is the exact CKAD-style workflow.

1) Find the missing RBAC permissions (use logs + events)

1.1 Identify the pods for the Deployment

kubectl -n cute-panda get deploy scraper

kubectl -n cute-panda get pods -l app=scraper 2>/dev/null || kubectl -n cute-panda get pods

Pick one pod name and check logs:

kubectl -n cute-panda logs deploy/scraper --tail=100

If the pod is crashlooping and logs are short:

POD=$(kubectl -n cute-panda get pods -o jsonpath='{.items[0].metadata.name}')

kubectl -n cute-panda logs "$POD" --previous --tail=200

1.2 Look specifically for “Forbidden” lines

Most apps print errors like:

... is forbidden: User "system:serviceaccount:cute-panda:default" cannot list resource "pods" in API group "" in the namespace "cute-panda"

or cannot get resource "configmaps"...

or cannot watch ...

If you don’t see it in logs, check events:

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

1.3 Extract verb/resource/apiGroup from the error

From a typical Kubernetes RBAC “forbidden” message, capture:

verb: get/list/watch/create/update/patch/delete

resource: pods, configmaps, secrets, deployments, etc.

apiGroup: "" (core), apps, batch, etc.

namespace: cute-panda (this is a namespaced permission if it’s a Role)

You may have multiple “cannot …” lines → you need to allow all of them.

2) Create the ServiceAccount scraper (required by the task)

kubectl -n cute-panda create serviceaccount scraper

kubectl -n cute-panda get sa scraper

3) Create the RBAC objects to grant the needed permissions

The task says “A Deployment needs specific RBAC permissions” — in CKAD, that usually means: Role + RoleBinding (namespaced) bound to your new ServiceAccount.

3.1 Create a Role (template you fill from the log output)

Create scraper-role.yaml:

cat <<'EOF' > scraper-role.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: scraper-role

namespace: cute-panda

rules:

# EXAMPLE ONLY: replace these rules with what your logs show

- apiGroups: [""]

resources: ["pods"]

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

EOF

Apply it:

kubectl apply -f scraper-role.yaml

3.2 Bind the Role to the ServiceAccount

kubectl -n cute-panda create rolebinding scraper-rb \

--role=scraper-role \

--serviceaccount=cute-panda:scraper

Verify:

kubectl -n cute-panda get role scraper-role

kubectl -n cute-panda get rolebinding scraper-rb -o yaml

4) Update the Deployment to use the new ServiceAccount (so it actually works)

Check current SA (likely default):

kubectl -n cute-panda get deploy scraper -o jsonpath='{.spec.template.spec.serviceAccountName}{"\n"}'

Patch it to use scraper:

kubectl -n cute-panda patch deploy scraper -p '{"spec":{"template":{"spec":{"serviceAccountName":"scraper"}}}}'

Rollout:

kubectl -n cute-panda rollout status deploy scraper

Re-check logs to confirm RBAC errors are gone:

kubectl -n cute-panda logs deploy/scraper --tail=100

Solution:

To find the broken pod and store its name and namespace to /opt/KDOB00401/broken.txt, you can use the kubectl get pods command and filter the output by the status of the pod.

kubectl get pods --field-selector=status.phase=Failed -o jsonpath='{.items[*].metadata.namespace}/{.items[*].metadata.name}' > /opt/KDOB00401/broken.txt

This command will list all pods with a status of Failed and output their names and namespaces in the format /. The output is then written to the /opt/KDOB00401/broken.txt file.

To store the associated error events to a file /opt/KDOB00401/error.txt, you can use the kubectl describe command to retrieve detailed information about the pod, and the grep command to filter the output for error events.

kubectl describe pods --namespace | grep -i error -B5 -A5 > /opt/KDOB00401/error.txt

Replace and with the name and namespace of the broken pod you found in the previous step.

This command will output detailed information about the pod, including error events. The grep command filters the output for lines containing "error" and also prints 5 lines before and after the match.

To fix the issue, you need to analyze the error events and find the root cause of the issue.

It could be that the application inside the pod is not running, the container image is not available, the pod has not enough resources, or the liveness probe configuration is incorrect.

Once you have identified the cause, you can take appropriate action, such as restarting the application, updating the container image, increasing the resources, or modifying the liveness probe configuration.

After fixing the issue, you can use the kubectl get pods command to check the status of the pod and ensure

create deploy hello-deploy --image=nginx --dry-run=client -o yaml > hello-deploy.yaml

Update deployment image to nginx:1.17.4:                                       kubectl set image deploy/hello-deploy nginx=nginx:1.17.4