CKAD Certified Kubernetes Application Developer (CKAD) Program Question and Answers

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.

ssh ckad00034c

You’re debugging an Ingress → Service → Deployment chain. The fastest way is:

reproduce the error with the right Host header

check Ingress rules (host/path/backend)

check Service (selector/port/targetPort)

check Endpoints (do we have ready pods?)

fix the manifest(s) under /home/candidate/content-marlin/

apply + re-test

Below are the exact commands + the most common fixes for this exact symptom.

1) Reproduce the failing request correctly

Even if DNS isn’t set up, you can test with a Host header:

curl -i -H "Host: content-marlin.local" http://127.0.0.1/content-marlin

If your ingress controller is not on localhost, find the NodePort/LoadBalancer IP. In these labs it’s often localhost via a local proxy, but if needed:

kubectl get svc -A | egrep -i 'ingress|nginx'

kubectl get nodes -o wide

(But start with the localhost curl above.)

2) Inspect the provided manifests (this is what you must edit)

cd /home/candidate/content-marlin/

ls -l

sed -n '1,200p' *.yaml

Also view what’s currently live in the cluster:

kubectl -n content-marlin get deploy,svc,ingress

kubectl -n content-marlin describe ingress content-marlin-ingress

kubectl -n content-marlin get ingress content-marlin-ingress -o yaml

What to look for in the Ingress:

spec.rules.host should be content-marlin.local

spec.rules.http.paths[].path should match /content-marlin

Backend service name must be your service

Backend service port must match the service port (name or number)

pathType should be Prefix (usually safest)

3) Validate Service → Pod wiring (most common real cause)

3.1 Check service selector and ports

kubectl -n content-marlin get svc -o wide

kubectl -n content-marlin describe svc content-marlin-deployment 2>/dev/null || true

kubectl -n content-marlin describe svc

Identify the service that the Ingress points to (from describe ingress).

Check if the Service selector matches pod labels:

kubectl -n content-marlin get pods --show-labels

kubectl -n content-marlin get svc -o jsonpath='{.spec.selector}{"\n"}'

3.2 Check endpoints (this tells you instantly if traffic can reach pods)

kubectl -n content-marlin get endpoints

kubectl -n content-marlin get endpoints -o wide

If ENDPOINTS is empty → Service selector doesn’t match Pods OR Pods aren’t Ready.

3.3 If endpoints empty, check pod readiness and labels

kubectl -n content-marlin get pods -o wide

kubectl -n content-marlin describe pod

4) Apply the most likely fix patterns

Fix pattern A: Ingress path needs rewrite

If your app serves / but you route /content-marlin, you often need rewrite.

Edit content-marlin-ingress manifest (in /home/candidate/content-marlin/) to include:

path: /content-marlin

pathType: Prefix

annotation: rewrite to / (common for nginx ingress)

Example (typical nginx-ingress):

metadata:

annotations:

nginx.ingress.kubernetes.io/rewrite-target: /

spec:

rules:

- host: content-marlin.local

http:

paths:

- path: /content-marlin

pathType: Prefix

backend:

service:

name:

port:

number: 80

If your ingress controller is not nginx, rewrite annotation may differ. But in CKAD labs, it’s very often nginx.

Fix pattern B: Ingress points to wrong Service port

If the Ingress backend says port 80 but your Service exposes 8080 (or uses a named port), align them:

Either change Ingress backend port.number

Or change Service spec.ports[].port / targetPort

Fix pattern C: Service selector mismatch (endpoints empty)

If pods have label app=content-marlin but service selector is app=content-marlin-deployment (or vice versa), fix the Service selector to match pod labels.

Service should have:

spec:

selector:

app:

Fix pattern D: Service targetPort wrong

If container listens on 8080 but service targetPort is 80, fix it:

spec:

ports:

- port: 80

targetPort: 8080

5) Apply the corrected manifests

After editing the YAMLs under /home/candidate/content-marlin/:

kubectl apply -f /home/candidate/content-marlin/

Wait for readiness:

kubectl -n content-marlin rollout status deploy content-marlin-deployment

kubectl -n content-marlin get endpoints

kubectl -n content-marlin describe ingress content-marlin-ingress

6) Re-test the URL

curl -i -H "Host: content-marlin.local" http://127.0.0.1/content-marlin

If you still get errors, also check ingress controller logs/events quickly:

kubectl -n content-marlin get events --sort-by=.lastTimestamp | tail -n 30

kubectl get pods -A | egrep -i 'ingress|nginx'

The fastest way for you to finish in 1 shot

Run these and paste the output (I’ll tell you exactly which line to change and what to change it to):

kubectl -n content-marlin describe ingress content-marlin-ingress

kubectl -n content-marlin get svc -o wide

kubectl -n content-marlin get endpoints -o wide

kubectl -n content-marlin get pods --show-labels

sed -n '1,200p' /home/candidate/content-marlin/*.yaml

But even without pasting, if you follow steps 2–4 above, you’ll find the broken link (Ingress rule, Service port, selector, or rewrite) and fix it cleanly.

Solution:

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.

Solution:

ssh ckad00025

You need to expose the existing app “web-app” externally at:

Host: external.sterling-bengal.local

Path: / (and anything starting with /) → route to web-app

In CKAD labs, this is almost always done with an Ingress pointing to the Service web-app.

1) Find where web-app Service lives (namespace + port)

kubectl get svc -A | grep -w web-app

You’ll get something like:

web-app ClusterIP ... /TCP

Set the namespace:

NS=

Check the service port(s):

kubectl -n $NS get svc web-app -o yaml

Note the service port number (commonly 80).

Also verify it has endpoints (so it actually routes to pods):

kubectl -n $NS get endpoints web-app -o wide

If endpoints are empty, the Service selector doesn’t match pods — tell me and I’ll give the exact fix. But usually it’s fine.

2) Create the Ingress to route / to web-app

Create a manifest (use the service port you saw; I’ll assume 80 below):

cat <<'EOF' > web-app-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web-app-ingress

spec:

rules:

- host: external.sterling-bengal.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web-app

port:

number: 80

EOF

Apply it:

kubectl -n $NS apply -f web-app-ingress.yaml

Verify:

kubectl -n $NS get ingress web-app-ingress

kubectl -n $NS describe ingress web-app-ingress

If your Service port is not 80, change number: 80 to the correct value and re-apply.

3) Test external reachability (as instructed)

Run exactly:

curl -i http://external.sterling-bengal.local/

If curl still fails (quick checks)

A) Is there an ingress controller running?

kubectl get pods -A | egrep -i 'ingress|nginx'

kubectl get svc -A | egrep -i 'ingress|nginx'

B) Does Ingress show an address?

kubectl -n $NS get ingress web-app-ingress -o wide

C) Do we have endpoints?

kubectl -n $NS get endpoints web-app -o wide

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: