Linux Foundation Certified Kubernetes Administrator CKA Exam Questions

Page: 1 / 14
Total 83 questions
Question 1

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


Question 2

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


Question 3

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


Question 4

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


Question 5

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


Question 6

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


Question 7

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


Page:    1 / 14   
Total 83 questions