SIMULATION
Create an nginx pod and list the pod with different levels of verbosity
Answer : A
// create a pod
kubectl run nginx --image=nginx --restart=Never --port=80
// List the pod with different verbosity
kubectl get po nginx --v=7
kubectl get po nginx --v=8
kubectl get po nginx --v=9
SIMULATION
Score: 5%

Task
Monitor the logs of pod bar and:
* Extract log lines corresponding to error file-not-found
* Write them to /opt/KUTR00101/bar
Answer : A
Solution:
kubectl logs bar | grep 'unable-to-access-website' > /opt/KUTR00101/bar
cat /opt/KUTR00101/bar
SIMULATION
Create a busybox pod that runs the command ''env'' and save the output to ''envpod'' file
Answer : A
kubectl run busybox --image=busybox --restart=Never ---rm -it -- env > envpod.yaml
SIMULATION

Task
Create a new HorizontalPodAutoscaler (HPA ) named apache-server in the autoscale
namespace. This HPA must target the existing Deployment called apache-server in the
autoscale namespace.
Set the HPA to aim for 50% CPU usage per Pod . Configure it to have at least 1 Pod and no more than 4 Pods . Also, set the downscale stabilization window to 30 seconds.
Answer : A, A
Task Summary
Create an HPA named apache-server in the autoscale namespace.
Target an existing deployment also named apache-server.
CPU target: 50%
Pod range: min 1, max 4
Downscale stabilization window: 30 seconds
Step-by-Step Answer
Step 1: Connect to the correct host
This is critical, as shown in the warning image.
ssh cka000050
Skipping this may result in zero for this question!
Step 2: Verify the deployment exists
kubectl get deployment apache-server -n autoscale
Make sure it's there before creating the HP
SIMULATION
You must connect to the correct host.
Failure to do so may result in a zero score.
[candidate@base] $ ssh Cka000059
Context
A kubeadm provisioned cluster was migrated to a new machine. It needs configuration changes to
run successfully.
Task
Fix a single-node cluster that got broken during machine migration.
First, identify the broken cluster components and investigate what breaks them.
The decommissioned cluster used an external etcd server.
Next, fix the configuration of all broken cluster
Answer : A
Task Summary
SSH into node: cka000059
Cluster was migrated to a new machine
It uses an external etcd server
Identify and fix misconfigured components
Bring the cluster back to a healthy state
Step-by-Step Solution
Step 1: SSH into the correct host
ssh cka000059
Step 2: Check the cluster status
Run:
kubectl get nodes
If it fails, the kubelet or kube-apiserver is likely broken.
Check kubelet status:
sudo systemctl status kubelet
Also, check pod statuses in the control plane:
sudo crictl ps -a | grep kube
or:
docker ps -a | grep kube
Look especially for failures in kube-apiserver or kube-controller-manager.
Step 3: Inspect the kube-apiserver manifest
Since this is a kubeadm-based cluster, manifests are in:
ls /etc/kubernetes/manifests
Open kube-apiserver.yaml:
bash
CopyEdit
sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml
Look for the --etcd-servers= flag. If the external etcd endpoint has changed (likely, due to migration), this needs to be fixed.
Example of incorrect configuration:
--etcd-servers=https://192.168.1.100:2379
If the IP has changed, update it to the correct IP or hostname of the external etcd server.
Also ensure the correct client certificate and key paths are still valid:
--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
If the files are missing or the path is wrong due to migration, correct those as well.
Step 4: Save and exit, and let static pod restart
Static pod changes will be picked up automatically by the kubelet (watch for /etc/kubernetes/manifests changes).
Check again:
docker ps | grep kube-apiserver
# or
crictl ps | grep kube-apiserver
Step 5: Confirm API is healthy
Once kube-apiserver is up, try:
kubectl get componentstatuses
kubectl get nodes
If these commands work and return valid statuses, the control plane is functional again.
Step 6: Check controller-manager and scheduler (optional)
If still broken, check the other static pods in /etc/kubernetes/manifests/ and correct paths if necessary.
Also verify that /etc/kubernetes/kubelet.conf and /etc/kubernetes/admin.conf are present and valid.
Command Summary
ssh cka000059
# Check system and kubelet
sudo systemctl status kubelet
docker ps -a | grep kube # or crictl ps -a | grep kube
# Check manifests
ls /etc/kubernetes/manifests
sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml
# Fix --etcd-servers and certificate paths if needed
# Watch pods restart and confirm:
kubectl get nodes
kubectl get componentstatuses
SIMULATION
Get list of all pods in all namespaces and write it to file ''/opt/pods-list.yaml''
Answer : A
kubectl get po --all-namespaces > /opt/pods-list.yaml
SIMULATION
Score: 7%

Task
Create a new NetworkPolicy named allow-port-from-namespace in the existing namespace echo. Ensure that the new NetworkPolicy allows Pods in namespace my-app to connect to port 9000 of Pods in namespace echo.
Further ensure that the new NetworkPolicy:
* does not allow access to Pods, which don't listen on port 9000
* does not allow access from Pods, which are not in namespace my-app
Answer : A
Solution:
#network.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-port-from-namespace
namespace: internal
spec:
podSelector:
matchLabels: {
}
policyTypes:
- Ingress
ingress:
- from:
- podSelector: {
}
ports:
- protocol: TCP
port: 8080
#spec.podSelector namespace pod
kubectl create -f network.yaml