Free Practice Questions for Linux Foundation CKAD Exam

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

Solution:

0) SSH to the correct host

ssh ckad00044

(Optional sanity)

kubectl config current-context

kubectl get ns | grep rapid-goat

1) Inspect the Deployment and current container name

kubectl -n rapid-goat get deploy busybox

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

kubectl -n rapid-goat get deploy busybox -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'

Note the current container name (likely something like busybox). We need to rename it to musl.

2) Edit the Deployment (best for renaming container)

Renaming a container is easiest with edit:

kubectl -n rapid-goat edit deploy busybox

In the editor, find:

spec:

template:

spec:

containers:

- name:

image:

Change it to:

- name: musl

image: busybox:musl

Save and exit.

3) Ensure the rollout happens and completes

kubectl -n rapid-goat rollout status deploy busybox

4) Verify the new Pod template is correct

Check the Deployment template:

kubectl -n rapid-goat get deploy busybox -o jsonpath='{.spec.template.spec.containers[0].name}{"\n"}{.spec.template.spec.containers[0].image}{"\n"}'

Check running Pods and the image actually used:

kubectl -n rapid-goat get pods -o wide

POD=$(kubectl -n rapid-goat get pods -l app=busybox -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true)

If you don’t have that label selector, just pick a pod name from kubectl get pods and:

kubectl -n rapid-goat describe pod | sed -n '/Containers:/,/Conditions:/p'

Solution:

Solution:

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.