Solution:

Understood — I’ll redo Question 13 without using any ✅ (or similar) icons.

ssh ckad00033

This task is only about building and exporting a container image.

You must not push it, run it, or consume it in any way.

You may use any image builder. Below are clean, correct solutions. Use one of them.

Option A: Using Docker

1) Go to the Dockerfile location

cd /home/candidate/build

ls -l Dockerfile

2) Build the image

Image name: macaque

Tag: 1.2

docker build -t macaque:1.2 .

Verify:

docker images | grep macaque

3) Export the image to a tar file

Docker image format is acceptable.

docker save macaque:1.2 -o /home/candidate/macaque-1.2.tar

Verify the file exists:

ls -lh /home/candidate/macaque-1.2.tar

Do not load or run the image.

Option B: Using Podman (rootless alternative)

1) Build the image

cd /home/candidate/build

podman build -t macaque:1.2 .

Verify:

podman images | grep macaque

2) Export the image

podman save macaque:1.2 -o /home/candidate/macaque-1.2.tar

Verify:

ls -lh /home/candidate/macaque-1.2.tar

Option C: Using Buildah (OCI format)

cd /home/candidate/build

buildah bud -t macaque:1.2 .

buildah push macaque:1.2 oci-archive:/home/candidate/macaque-1.2.tar

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

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.

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: