Pass the Linux Foundation Kubernetes Application Developer CKAD Questions and answers with ValidTests

Solution:

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 ckad00023

You need two outcomes in moose:

At most 10 Pods total (across both Deployments).

About 20% of chipmunk-service traffic goes to canary-chipmunk-deployment.

In Kubernetes Services, traffic distribution is (roughly) proportional to the number of ready endpoints behind the Service. So the standard canary trick is:

total endpoints = 10

canary endpoints = 2

current endpoints = 8That gives ~20% to canary.

1) Inspect what exists

kubectl -n moose get deploy

kubectl -n moose get svc chipmunk-service -o wide

kubectl -n moose describe svc chipmunk-service

Get the Service selector (important):

kubectl -n moose get svc chipmunk-service -o jsonpath='{.spec.selector}{"\n"}'

Check current replicas:

kubectl -n moose get deploy current-chipmunk-deployment -o jsonpath='{.spec.replicas}{"\n"}'

kubectl -n moose get deploy canary-chipmunk-deployment -o jsonpath='{.spec.replicas}{"\n"}'

List pods + labels (to confirm both Deployments’ pods match the Service selector):

kubectl -n moose get pods --show-labels

2) Ensure both Deployments are behind the Service

This is the key: the pods from BOTH deployments must match the Service selector.

If the Service selector is something like app=chipmunk, then both Deployments’ pod templates must include app: chipmunk.

If one Deployment doesn’t match, patch its pod template labels to match the selector.

2A) Example: selector is app=chipmunk

(Only do this if you see the Service selector contains app=chipmunk and one of the deployments is missing it.)

kubectl -n moose patch deploy current-chipmunk-deployment \

-p '{"spec":{"template":{"metadata":{"labels":{"app":"chipmunk"}}}}}'

kubectl -n moose patch deploy canary-chipmunk-deployment \

-p '{"spec":{"template":{"metadata":{"labels":{"app":"chipmunk"}}}}}'

Wait for rollouts if patches triggered new ReplicaSets:

kubectl -n moose rollout status deploy current-chipmunk-deployment

kubectl -n moose rollout status deploy canary-chipmunk-deployment

Verify endpoints now include pods from both deployments:

kubectl -n moose get endpoints chipmunk-service -o wide

3) Set replicas to enforce “max 10 pods” and “20% canary”

Set:

current = 8

canary = 2Total = 10.

kubectl -n moose scale deploy current-chipmunk-deployment --replicas=8

kubectl -n moose scale deploy canary-chipmunk-deployment --replicas=2

Wait until ready:

kubectl -n moose rollout status deploy current-chipmunk-deployment

kubectl -n moose rollout status deploy canary-chipmunk-deployment

Confirm total pods is 10 (or less) and all are Running/Ready:

kubectl -n moose get pods

kubectl -n moose get pods | tail -n +2 | wc -l

Confirm endpoints count matches 10:

kubectl -n moose get endpoints chipmunk-service -o jsonpath='{.subsets[*].addresses[*].ip}' | wc -w

4) Test load balancing via NodePort 30000

Run several times:

for i in $(seq 1 30); do curl -s http://localhost:30000/; echo; done

You should see canary responses appear roughly ~20% of the time (not exact every run).

If you want a clearer signal, check which pods are endpoints and ensure 2 belong to canary and 8 to current:

kubectl -n moose get pods -l app=chipmunk -o wide

kubectl -n moose get endpoints chipmunk-service -o wide

Solution:

Solution:

Solution:

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:

ssh ckad00018

You cannot create/modify/delete any NetworkPolicy.

So the only way to make the existing policies “take effect” is to ensure the right Pods have the labels/selectors those policies expect.

The task: in namespace charming-macaw, configure things so the target Pod can send + receive traffic ONLY to/from Pods front and db.

1) Inspect what NetworkPolicies already exist (don’t change them)

kubectl -n charming-macaw get netpol

kubectl -n charming-macaw get netpol -o wide

Dump them to see the selectors they use:

kubectl -n charming-macaw get netpol -o yaml

You are looking for policies that:

select the restricted pod via spec.podSelector

and allow ingress/egress only with selectors that match front and db

often there’s also a “default deny” policy.

2) Identify the Pods and their current labels

kubectl -n charming-macaw get pods -o wide

kubectl -n charming-macaw get pods --show-labels

Specifically inspect labels for front and db:

kubectl -n charming-macaw get pod front --show-labels

kubectl -n charming-macaw get pod db --show-labels

(If they’re Deployments instead of single Pods, do:)

kubectl -n charming-macaw get deploy --show-labels

kubectl -n charming-macaw get pods -l app=front --show-labels

kubectl -n charming-macaw get pods -l app=db --show-labels

3) Figure out which pod is “the Pod” to restrict

Usually there’s a third pod (e.g., backend, api, app) besides front and db.

List pods again and identify the “other” one:

kubectl -n charming-macaw get pods

Let’s assume the pod to restrict is called app (replace as needed):

TARGET=

4) Match the existing NetworkPolicy selectors by labeling pods (allowed)

Because you can’t edit NetworkPolicies, you must make labels on Pods (or their controllers) match the policies’ selectors.

4.1 Determine the label required on the TARGET pod

From the YAML, find the policy that selects the restricted pod, e.g.:

spec:

podSelector:

matchLabels:

role: restricted

Extract podSelector from each policy quickly:

kubectl -n charming-macaw get netpol -o jsonpath='{range .items[*]}{.metadata.name}{" => "}{.spec.podSelector}{"\n"}{end}'

Pick the selector that is meant for the restricted pod, then apply it to the TARGET pod (example: role=restricted):

kubectl -n charming-macaw label pod $TARGET role=restricted --overwrite

Best practice (if the pod is managed by a Deployment): label the Deployment template instead, so it persists.

Find the owner:

kubectl -n charming-macaw get pod $TARGET -o jsonpath='{.metadata.ownerReferences[0].kind}{" "}{.metadata.ownerReferences[0].name}{"\n"}'

If it’s a ReplicaSet, find its Deployment:

RS=$(kubectl -n charming-macaw get pod $TARGET -o jsonpath='{.metadata.ownerReferences[0].name}')

kubectl -n charming-macaw get rs $RS -o jsonpath='{.metadata.ownerReferences[0].kind}{" "}{.metadata.ownerReferences[0].name}{"\n"}'

Then label the Deployment (example):

kubectl -n charming-macaw label deploy role=restricted --overwrite

4.2 Ensure front and db match what the allow-rules reference

Look inside the allow policy ingress.from / egress.to. You might see something like:

from:

- podSelector:

matchLabels:

name: front

- podSelector:

matchLabels:

name: db

So you must ensure:

front pod has name=front

db pod has name=db

Apply labels (examples—use what the policy expects):

kubectl -n charming-macaw label pod front name=front --overwrite

kubectl -n charming-macaw label pod db name=db --overwrite

Again, if they’re Deployments, label the Deployment instead:

kubectl -n charming-macaw label deploy front name=front --overwrite

kubectl -n charming-macaw label deploy db name=db --overwrite

5) Verify the NetworkPolicies now “select” the right pods

Check which labels each pod has now:

kubectl -n charming-macaw get pods --show-labels

Confirm the restricted pod matches the NetPol podSelector:

kubectl -n charming-macaw get netpol -o jsonpath='{.spec.podSelector}{"\n"}'

kubectl -n charming-macaw get pod $TARGET --show-labels

6) Functional verification (quick network tests)

Exec into the restricted pod and try to reach:

front ✅ allowed

db ✅ allowed

anything else ❌ blocked

If busybox has wget:

kubectl -n charming-macaw exec -it $TARGET -- sh -c 'wget -qO- http://front 2 >/dev/null || true'

kubectl -n charming-macaw exec -it $TARGET -- sh -c 'wget -qO- http://db 2 >/dev/null || true'

Test something that should be blocked (example: kubernetes service DNS name):

kubectl -n charming-macaw exec -it $TARGET -- sh -c 'wget -qO- https://kubernetes.default.svc 2 >/dev/null || echo "blocked"'

Also test inbound (from front to target, and from db to target) if the target listens on a port; otherwise inbound testing may be limited.

What you’re doing conceptually

Existing NetPols are already correct.

Your job is to make pod labels match the NetPol selectors so:

default deny applies to the target

allow rules apply only between target ↔ front and target ↔ db