Linux Foundation CKAD Practice Exam Questions & Answers

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:

Solution:

Solution:

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