Linux Foundation CKAD Dumps

Below is an exam-style, step-by-step solution (commands + verification). Follow exactly on host ckad000.

0) Connect to the right host

ssh ckad000

(Optional but good sanity check)

kubectl config current-context

kubectl get ns

1) Inspect the existing Deployment (to know its labels/ports)

kubectl -n prod get deploy nginx-deployment

kubectl -n prod get deploy nginx-deployment -o wide

Check what labels the Pod template already has (important for the Service selector):

kubectl -n prod get deploy nginx-deployment -o jsonpath='{.spec.template.metadata.labels}{"\n"}'

Check container ports (so we expose the correct targetPort):

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

If ports output is empty, it’s still often nginx on 80, but the safest is to confirm by describing a pod later.

2) Update Deployment to 2 replicas

Fastest:

kubectl -n prod scale deploy nginx-deployment --replicas=2

Verify:

kubectl -n prod get deploy nginx-deployment

3) Add label role=webFrontEnd to the Pod (Pod template label)

You must add it under:

spec.template.metadata.labels

Use a patch (quick + safe):

kubectl -n prod patch deploy nginx-deployment \

-p '{"spec":{"template":{"metadata":{"labels":{"role":"webFrontEnd"}}}}}'

Verify the Deployment template now includes it:

kubectl -n prod get deploy nginx-deployment -o jsonpath='{.spec.template.metadata.labels}{"\n"}'

Now verify the running Pods have the label (important!):

kubectl -n prod get pods --show-labels

If the label doesn’t show on pods immediately, wait for rollout:

kubectl -n prod rollout status deploy nginx-deployment

kubectl -n prod get pods --show-labels

4) Create a NodePort Service rover exposing the Deployment’s Pods

4.1 Get a reliable target port

Try to read containerPort:

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

If this prints a number (commonly 80), use it as --target-port.

If it prints nothing/empty, check a pod:

POD=$(kubectl -n prod get pod -l role=webFrontEnd -o jsonpath='{.items[0].metadata.name}')

kubectl -n prod describe pod "$POD" | sed -n '/Containers:/,/Conditions:/p' | sed -n '/Ports:/,/Environment:/p'

Assuming nginx is on 80 (most common), create the service:

kubectl -n prod expose deploy nginx-deployment \

--name=rover \

--type=NodePort \

--port=80 \

--target-port=80

If your nginx container port is different (e.g., 8080), change --target-port=8080 accordingly.

5) Verify Service + endpoints (critical)

kubectl -n prod get svc rover -o wide

kubectl -n prod describe svc rover

kubectl -n prod get endpoints rover -o wide

You should see 2 endpoints (matching 2 pods).

Also confirm the pods are Ready:

kubectl -n prod get pods -l role=webFrontEnd -o wide

Quick “CKAD checkpoints”

Deployment in prod has replicas=2

Pod template has label role=webFrontEnd

Service rover in prod is NodePort

Service endpoints point to the nginx pods

Solution:

Solution:

ssh ckad00021

Below is the clean, CKAD-friendly way (YAML + apply + verify + manual job).

1) Create the CronJob grep

Create a file (anywhere, e.g. in your home):

cat <<'EOF' > grep-cronjob.yaml

apiVersion: batch/v1

kind: CronJob

metadata:

name: grep

spec:

schedule: "*/30 * * * *"

successfulJobsHistoryLimit: 96

failedJobsHistoryLimit: 192

jobTemplate:

spec:

activeDeadlineSeconds: 8

template:

spec:

restartPolicy: Never

containers:

- name: busybox

image: busybox:stable

command: ["grep", "-i", "nameserver", "/etc/resolv.conf"]

EOF

Apply it:

kubectl apply -f grep-cronjob.yaml

Verify:

kubectl get cronjob grep

kubectl describe cronjob grep

Confirm the key fields quickly:

kubectl get cronjob grep -o jsonpath='{.spec.schedule}{"\n"}{.spec.successfulJobsHistoryLimit}{"\n"}{.spec.failedJobsHistoryLimit}{"\n"}'

kubectl get cronjob grep -o jsonpath='{.spec.jobTemplate.spec.activeDeadlineSeconds}{"\n"}{.spec.jobTemplate.spec.template.spec.restartPolicy}{"\n"}'

2) Manually create and execute the one-off Job grep-test from the CronJob

Create the Job from the CronJob:

kubectl create job --from=cronjob/grep grep-test

Watch it:

kubectl get jobs grep-test

kubectl get pods -l job-name=grep-test

Get logs (most important proof):

POD=$(kubectl get pods -l job-name=grep-test -o jsonpath='{.items[0].metadata.name}')

kubectl logs "$POD"

You should see one or more nameserver ... lines from /etc/resolv.conf.

To allow a pod to send and receive traffic only to and from specific pods, you can use network policies in Kubernetes.

First, you will need to create a network policy that defines the allowed traffic. You can create a network policy yaml file with the following rules:

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: newpod-network-policy

namespace: default

spec:

podSelector:

matchLabels:

app: kdsn00201-newpod

ingress:

- from:

- podSelector:

matchLabels:

app: web

- podSelector:

matchLabels:

app: storage

This policy will only allow incoming traffic to the pod with the label app=kdsn00201-newpod from pods with the label app=web or app=storage. If you have different labels on your web and storage pods please update the matchLabels accordingly.

Once you have created the network policy, you can apply it to the cluster by running the following command:

kubectl apply -f .yaml

This will apply the network policy to the cluster, and the newpod will only be able to send and receive traffic to and from the web and storage pods.

Please note that, NetworkPolicy resource is not available by default, you need to enable the NetworkPolicy feature on your Kubernetes cluster. This feature is enabled by default on some clusters and must be explicitly enabled on others. You can check if NetworkPolicy is available by running the command kubectl api-versions | grep networking

Also, you need to ensure that the pods that you want to allow traffic to and from are running on the same namespace.

Solution:

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.

Solution:

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

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:

Goal: fix nosql Deployment in haddock so the container stops OOM’ing by setting:

memory request = 128Mi

memory limit = half of the namespace’s maximum memory constraint

You must do this on the correct host.

0) Connect to the correct host

ssh ckad00032

1) Confirm the failing Deployment / Pods

kubectl -n haddock get deploy nosql

kubectl -n haddock get pods -l app=nosql 2>/dev/null || kubectl -n haddock get pods

If pods are crashing, check why (you’ll likely see OOMKilled):

kubectl -n haddock describe pod

2) Find the maximum memory constraint set for the haddock namespace

In CKAD labs, this is commonly enforced by a LimitRange (max memory per container). Sometimes it can also be a ResourceQuota.

2A) Check LimitRange (most likely)

kubectl -n haddock get limitrange

kubectl -n haddock get limitrange -o yaml

Extract the max memory value quickly:

MAX_MEM=$(kubectl -n haddock get limitrange -o jsonpath='{.items[0].spec.limits[0].max.memory}')

echo "Namespace max memory constraint: $MAX_MEM"

2B) If no LimitRange exists, check ResourceQuota

kubectl -n haddock get resourcequota

kubectl -n haddock describe resourcequota

If quota is used, you’re looking for something like limits.memory (but the question wording “maximum memory constraint” usually points to LimitRange max.memory).

3) Compute “half of the max memory constraint”

Run this small snippet to compute HALF in Mi (handles Mi and Gi):

HALF_MEM=$(python3 - <<'PY'

import os, re

q = os.environ.get("MAX_MEM","").strip()

m = re.fullmatch(r"(\d+)(Mi|Gi)", q)

if not m:

raise SystemExit(f"Cannot parse MAX_MEM='{q}'. Expected like 512Mi or 1Gi.")

val = int(m.group(1))

unit = m.group(2)

# convert to Mi

mi = val if unit == "Mi" else val * 1024

half_mi = mi // 2

print(f"{half_mi}Mi")

PY

)

echo "Half of max: $HALF_MEM"

Example: if MAX_MEM=512Mi → HALF_MEM=256Mi

Example: if MAX_MEM=1Gi → HALF_MEM=512Mi

4) Update the nosql Deployment (DO NOT delete it)

First, get the container name (Deployment may have a custom container name):

kubectl -n haddock get deploy nosql -o jsonpath='{.spec.template.spec.containers[*].name}{"\n"}'

Now set resources (this updates the Deployment in-place):

kubectl -n haddock set resources deploy nosql \

--requests=memory=128Mi \

--limits=memory=$HALF_MEM

5) Ensure the update rolls out successfully

kubectl -n haddock rollout status deploy nosql

6) Verify the pod has the right requests/limits

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

kubectl -n haddock get pods

Pick the new pod and confirm:

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

You should see:

Requests: memory 128Mi

Limits: memory

If rollout fails (common cause)

If you accidentally set a limit above the namespace max, pods won’t start. Check events:

kubectl -n haddock describe deploy nosql

kubectl -n haddock get events --sort-by=.lastTimestamp | tail -n 20

Solution:

To have Kubernetes automatically restart a pod when an endpoint returns an HTTP 500 on the /healthz endpoint, you will need to configure liveness and readiness probes on the pod.

First, you will need to create a livenessProbe and a readinessProbe in the pod's definition yaml file. The livenessProbe will check the /healthz endpoint, and if it returns an HTTP 500, the pod will be restarted. The readinessProbe will check the /started endpoint, and if it returns an HTTP 500, the pod will not receive traffic.

Here's an example of how you can configure the liveness and readiness probes in the pod definition yaml file:

apiVersion: v1

kind: Pod

metadata:

name: probe-pod

spec:

containers:

- name: probe-pod

image:

ports:

- containerPort: 8080

livenessProbe:

httpGet:

path: /healthz

port: 8080

initialDelaySeconds: 15

periodSeconds: 10

failureThreshold: 3

readinessProbe:

httpGet:

path: /started

port: 8080

initialDelaySeconds: 15

periodSeconds: 10

failureThreshold: 3

The httpGet specifies the endpoint to check and the port to use. The initialDelaySeconds is the amount of time the pod will wait before starting the probe. periodSeconds is the amount of time between each probe check, and the failureThreshold is the number of failed probes before the pod is considered unresponsive.

You can use kubectl to create the pod by running the following command:

kubectl apply -f .yaml

Once the pod is created, Kubernetes will start monitoring it using the configured liveness and readiness probes. If the /healthz endpoint returns an HTTP 500, the pod will be restarted. If the /started endpoint returns an HTTP 500, the pod will not receive traffic.

Please note that if the failure threshold is set to 3, it means that if the probe fails 3 times consecutively it will be considered as a failure.

The above configuration assumes that the application is running on port 8080 and the endpoints are available on the same port.