Certified Kubernetes Application Developer (CKAD) Program Practice Test

Answer: See the Explanation below for complete solution.
Explanation:ssh ckad00026Your job is to edit /home/candidate/credible-mite/web.yaml so it uses APIs supported onKubernetes 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 andschema errorsedit the manifest to the modern API versions/fieldsre-run dry-run until it passesapply for real and verify rollout1) Go to the manifest and run a server-side dry-runcd /home/candidate/credible-mitels -lsed -n '1,200p' web.yamlMake sure the namespace exists:kubectl get ns garfish || kubectl create ns garfishNow run a server-side dry-run (this catches removed APIs on the cluster):kubectl apply -n garfish -f web.yaml --dry-run=serverWhatever errors you get here tell you exactly what to fix.2) Fix the common v1.15 v1.29 API deprecationsEdit the file:vi web.yamlBelow are the most common objects from older manifests and how to update them for1.29+.A) Deployments / DaemonSets / StatefulSetsOld (v1.15 often used):extensions/v1beta1 or apps/v1beta1 or apps/v1beta2New:apiVersion: apps/v1Also in apps/v1, .spec.selector is required and must match the pod template labels.Example conversion:apiVersion: apps/v1kind: Deploymentmetadata:name: webspec:replicas: 2selector:matchLabels:app: webtemplate:metadata:labels:app: webspec:containers:- name: webimage: nginxKey rule:spec.selector.matchLabels must exactly match spec.template.metadata.labels (at least forthe keys you select on).B) IngressOld:apiVersion: extensions/v1beta1 (or networking.k8s.io/v1beta1)New:apiVersion: networking.k8s.io/v1Required changes:spec.rules.http.paths[].pathType is required (usually Prefix)backend format changes from serviceName/servicePort toservice.name/service.port.number (or .name for named ports)Old backend:backend:serviceName: webservicePort: 80New backend:backend:service:name: webport:number: 80Full path example:apiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: webspec:rules:- host: example.localhttp:paths:- path: /pathType: Prefixbackend:service:name: webport:number: 80C) CronJobOld:apiVersion: batch/v1beta1New:apiVersion: batch/v1Most fields stay the same; just update apiVersion.D) PodDisruptionBudgetOld:policy/v1beta1New:policy/v1spec.selector/minAvailable/maxUnavailable remain, but apiVersion changes.E) RBACUsually already:rbac.authorization.k8s.io/v1 (this is fine)F) Removed APIs you must delete/replaceIf 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, butfor 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 succeedsAfter you edit:kubectl apply -n garfish -f web.yaml --dry-run=serverKeep iterating until there are no errors.4) Deploy for realkubectl apply -n garfish -f /home/candidate/credible-mite/web.yaml5) Verify everything in namespace garfishList what was created:kubectl -n garfish get allkubectl -n garfish get ingress 2>/dev/null || trueIf there is a Deployment, verify rollout:kubectl -n garfish get deploykubectl -n garfish rollout status deploy --allCheck pods/events if something fails:kubectl -n garfish get pods -o widekubectl -n garfish describe pod <pod-name>kubectl -n garfish get events --sort-by=.lastTimestamp | tail -n 30

Answer: See the Explanation below for complete solution.
Explanation:ssh ckad00029You must modify the existing Deployment store-deployment in namespace grubworm sothat its containers:run as user ID 10000have Linux capability NET_BIND_SERVICE addedAnd you’re told to use the manifest file at:/home/candidate/daring-moccasin/store-deplovment.vaml (note: the filename looksmisspelled; follow it exactly on the host)1) Inspect the current Deployment and locate the manifest filekubectl -n grubworm get deploy store-deploymentls -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 SecurityContextEdit the file:vi "/home/candidate/daring-moccasin/store-deplovment.vaml"2.1 Set Pod-level runAsUser = 10000Under:spec.template.spec add:securityContext:runAsUser: 100002.2 Add NET_BIND_SERVICE capability at container-levelUnder 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/v1kind: Deploymentmetadata:name: store-deploymentnamespace: grubwormspec:template:spec:securityContext:runAsUser: 10000containers:- name: storeimage: someimagesecurityContext:capabilities:add: ["NET_BIND_SERVICE"]Important notes:runAsUser can be set at Pod level (applies to all containers) or per-container. Podlevel 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 manifestkubectl apply -f "/home/candidate/daring-moccasin/store-deplovment.vaml"4) Ensure the Deployment rolls outkubectl -n grubworm rollout status deploy store-deployment5) Verify the settings are in effectCheck the rendered pod template:kubectl -n grubworm get deploy store-deployment -ojsonpath='{.spec.template.spec.securityContext}{"\n"}'kubectl -n grubworm get deploy store-deployment -ojsonpath='{.spec.template.spec.containers[0].securityContext}{"\n"}'Verify on a running pod:kubectl -n grubworm get podskubectl -n grubworm describe pod <pod-name> | sed -n '/Security Context:/,/Containers:/p'kubectl -n grubworm describe pod <pod-name> | sed -n '/Containers:/,/Conditions:/p'If there are multiple containersRepeat the container-level securityContext.capabilities.add block for each container underspec.template.spec.containers.

Answer: See the Explanation below for complete solution.
Explanation:ssh ckad00025You need to expose the existing app “web-app” externally at:Host: external.sterling-bengal.localPath: / (and anything starting with /) route to web-appIn 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-appYou’ll get something like:<NAMESPACE> web-app ClusterIP ... <PORT>/TCPSet the namespace:NS=<NAMESPACE>Check the service port(s):kubectl -n $NS get svc web-app -o yamlNote 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 wideIf endpoints are empty, the Service selector doesn’t match pods — tell me and I’ll give theexact fix. But usually it’s fine.2) Create the Ingress to route / to web-appCreate a manifest (use the service port you saw; I’ll assume 80 below):cat <<'EOF' > web-app-ingress.yamlapiVersion: networking.k8s.io/v1kind: Ingressmetadata:name: web-app-ingressspec:rules:- host: external.sterling-bengal.localhttp:paths:- path: /pathType: Prefixbackend:service:name: web-appport:number: 80EOFApply it:kubectl -n $NS apply -f web-app-ingress.yamlVerify:kubectl -n $NS get ingress web-app-ingresskubectl -n $NS describe ingress web-app-ingressIf 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 wideC) Do we have endpoints?kubectl -n $NS get endpoints web-app -o wide

Answer: See the Explanation below for complete solution.
Explanation:0) SSH to the correct hostssh ckad00044(Optional sanity)kubectl config current-contextkubectl get ns | grep rapid-goat1) Inspect the Deployment and current container namekubectl -n rapid-goat get deploy busyboxkubectl -n rapid-goat get deploy busybox -ojsonpath='{.spec.template.spec.containers[*].name}{"\n"}'kubectl -n rapid-goat get deploy busybox -ojsonpath='{.spec.template.spec.containers[*].image}{"\n"}'Note the current container name (likely something like busybox). We need to rename it tomusl.2) Edit the Deployment (best for renaming container)Renaming a container is easiest with edit:kubectl -n rapid-goat edit deploy busyboxIn the editor, find:spec:template:spec:containers:- name: <old-name>image: <old-image>Change it to:- name: muslimage: busybox:muslSave and exit.3) Ensure the rollout happens and completeskubectl -n rapid-goat rollout status deploy busybox4) Verify the new Pod template is correctCheck the Deployment template:kubectl -n rapid-goat get deploy busybox -ojsonpath='{.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 widePOD=$(kubectl -n rapid-goat get pods -l app=busybox -ojsonpath='{.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 <pod-name> | sed -n '/Containers:/,/Conditions:/p'

Answer: See the Explanation below for complete solution.
Explanation:ssh ckad00018You cannot create/modify/delete any NetworkPolicy.So the only way to make the existing policies “take effect” is to ensure the right Pods havethe 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 netpolkubectl -n charming-macaw get netpol -o wideDump them to see the selectors they use:kubectl -n charming-macaw get netpol -o yamlYou are looking for policies that:select the restricted pod via spec.podSelectorand allow ingress/egress only with selectors that match front and dboften there’s also a “default deny” policy.2) Identify the Pods and their current labelskubectl -n charming-macaw get pods -o widekubectl -n charming-macaw get pods --show-labelsSpecifically inspect labels for front and db:kubectl -n charming-macaw get pod front --show-labelskubectl -n charming-macaw get pod db --show-labels(If they’re Deployments instead of single Pods, do:)kubectl -n charming-macaw get deploy --show-labelskubectl -n charming-macaw get pods -l app=front --show-labelskubectl -n charming-macaw get pods -l app=db --show-labels3) Figure out which pod is “the Pod” to restrictUsually 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 podsLet’s assume the pod to restrict is called app (replace as needed):TARGET=<pod-to-restrict>4) Match the existing NetworkPolicy selectors by labeling pods (allowed)Because you can’t edit NetworkPolicies, you must make labels on Pods (or theircontrollers) match the policies’ selectors.4.1 Determine the label required on the TARGET podFrom the YAML, find the policy that selects the restricted pod, e.g.:spec:podSelector:matchLabels:role: restrictedExtract 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 --overwriteBest practice (if the pod is managed by a Deployment): label the Deployment templateinstead, so it persists.Find the owner:kubectl -n charming-macaw get pod $TARGET -ojsonpath='{.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 -ojsonpath='{.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 <DEPLOYMENT_NAME> role=restricted --overwrite4.2 Ensure front and db match what the allow-rules referenceLook inside the allow policy ingress.from / egress.to. You might see something like:from:- podSelector:matchLabels:name: front- podSelector:matchLabels:name: dbSo you must ensure:front pod has name=frontdb pod has name=dbApply labels (examples—use what the policy expects):kubectl -n charming-macaw label pod front name=front --overwritekubectl -n charming-macaw label pod db name=db --overwriteAgain, if they’re Deployments, label the Deployment instead:kubectl -n charming-macaw label deploy front name=front --overwritekubectl -n charming-macaw label deploy db name=db --overwrite5) Verify the NetworkPolicies now “select” the right podsCheck which labels each pod has now:kubectl -n charming-macaw get pods --show-labelsConfirm the restricted pod matches the NetPol podSelector:kubectl -n charming-macaw get netpol <POLICY_NAME> -ojsonpath='{.spec.podSelector}{"\n"}'kubectl -n charming-macaw get pod $TARGET --show-labels6) Functional verification (quick network tests)Exec into the restricted pod and try to reach:front alloweddb allowedanything else blockedIf 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 -qOhttps://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 conceptuallyExisting NetPols are already correct.Your job is to make pod labels match the NetPol selectors so: