CKA Practice Questions

Question 1

Which TWO components are part of the Kubernetes control plane? (Select 2)

Accepted Answer

etcd. etcd is a distributed key-value store that holds the cluster's state and configuration data. It is a core component of the Kubernetes control plane because the kube-apiserver reads from and writes to etcd to maintain cluster consistency, and without it the control plane cannot function.

Answer

kubelet

Answer

kube-proxy

Answer

container runtime

Question 2

A Pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient cpu.' Which of the following is the most likely combination of issues?

Accepted Answer

Three nodes have insufficient CPU for the pod's request, and one node has a taint not tolerated by the pod. The event message explicitly states that 1 node has a taint (node-role.kubernetes.io/control-plane) that the pod does not tolerate, and 3 nodes have insufficient CPU. This means the pod's CPU request cannot be satisfied on three nodes, and the remaining node is tainted, leaving no schedulable node. Option A correctly identifies this combination of issues.

Answer

The pod has a resource request that exceeds available CPU on all nodes

Answer

The pod does not tolerate any taints, and all nodes have taints

Answer

The cluster has only one node with sufficient CPU, but it is cordoned

Question 3

You have a cluster with multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0 using kubeadm. What is the correct sequence of steps?

Accepted Answer

Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.. The official kubeadm upgrade workflow requires upgrading kubeadm first on the control plane node, then using `kubeadm upgrade apply` to upgrade control plane components, and finally draining and upgrading each worker node by updating kubelet and kubectl. This sequence ensures the cluster's management plane is updated before worker nodes, maintaining control plane stability and API compatibility during the rolling upgrade.

Answer

Upgrade kubeadm on the control plane node, then upgrade kubelet and kubectl on worker nodes, then upgrade kubelet and kubectl on control plane node.

Answer

Drain all nodes, upgrade kubelet and kubectl on all nodes, then upgrade kubeadm on the control plane node.

Answer

Upgrade kubelet and kubectl on all nodes first, then upgrade kubeadm on the control plane node.

Question 4

A user needs to deploy a pod that requires access to the Kubernetes API server from within the pod. Which resource should be used to provide authentication credentials automatically?

Accepted Answer

ServiceAccount. A ServiceAccount is the correct resource because Kubernetes automatically mounts a projected volume containing a JWT token into pods that use the default or a specified ServiceAccount. This token is used by the pod to authenticate against the Kubernetes API server, enabling secure in-cluster communication without manual credential management.

Answer

Secret

Answer

ConfigMap

Answer

ClusterRoleBinding

Question 5

An administrator runs 'kubectl cordon node1' and then 'kubectl drain node1 --ignore-daemonsets'. What is the effect on node1?

Accepted Answer

Node1 is marked as unschedulable and all pods except DaemonSets are evicted. The `kubectl cordon node1` command marks node1 as unschedulable, preventing new pods from being scheduled onto it. The subsequent `kubectl drain node1 --ignore-daemonsets` command evicts all pods from node1 except DaemonSets (which are ignored because they are managed by the DaemonSet controller and typically need to run on every node). This combination makes node1 unschedulable and removes all non-DaemonSet pods, preparing the node for maintenance.

Answer

Node1 is marked as unschedulable but no pods are evicted

Answer

New pods are scheduled onto node1 and existing pods are evicted

Answer

Node1 is marked as schedulable and all pods are evicted

Question 6

Which command creates a ConfigMap named 'app-config' from a file 'config.properties'?

Accepted Answer

kubectl create configmap app-config --from-file=config.properties. `kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the specified file. The `--from-file` flag reads the file and stores its entire content as a key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content.

Answer

kubectl create cm app-config --file=config.properties

Answer

kubectl create configmap app-config --from-literal=config.properties

Answer

kubectl create configmap app-config --from-env-file=config.properties

Question 7

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. What command would you run to see the reason for the crash?

Accepted Answer

kubectl describe pod . B is correct because `kubectl describe pod ` provides detailed information about the pod, including the container state, restart count, and the last termination reason (e.g., 'Error' or 'OOMKilled') along with its exit code. To view the actual stdout/stderr logs of the crashed container, you would use `kubectl logs --previous`.

Answer

kubectl top pod <pod-name>

Answer

kubectl rollout status deployment <deployment-name>

Answer

kubectl get events --field-selector involvedObject.name=<pod-name>

Question 8

You need to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. After upgrading the control plane, what should you do on each worker node?

Accepted Answer

kubectl drain ; kubeadm upgrade node; kubectl uncordon . The standard kubeadm upgrade workflow for worker nodes requires first draining the node to safely evict all pods, then running 'kubeadm upgrade node' to upgrade the kubelet and kube-proxy configuration, and finally uncordoning the node to make it schedulable again. This sequence ensures minimal disruption to workloads and follows the official Kubernetes upgrade documentation.

Answer

kubeadm upgrade node config --kubelet-version v1.29.0

Answer

kubectl delete node <node>; kubeadm upgrade node

Answer

kubeadm upgrade node; kubectl uncordon <node>

Question 9

A user creates a PersistentVolumeClaim with a storage class 'ssd' that does not exist in the cluster. What will happen when the PVC is created?

Accepted Answer

The PVC will remain in Pending state.. When a PersistentVolumeClaim (PVC) references a StorageClass that does not exist in the cluster, the PVC cannot be dynamically provisioned because the provisioner associated with that StorageClass is missing. Without a matching StorageClass, the system cannot create a new PersistentVolume (PV) for the PVC, and since no existing PV matches the claim (or the PVC is set to use dynamic provisioning), the PVC will remain in a Pending state indefinitely until the StorageClass is created or the PVC is deleted.

Answer

The PVC will be deleted automatically after a timeout.

Answer

The PVC will be automatically bound to any available PV.

Answer

The cluster will create the storage class automatically.

Question 10

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

Accepted Answer

The next job starts immediately, running concurrently. By default, CronJobs in Kubernetes have a concurrencyPolicy of 'Allow'. This means that if a new job is scheduled while a previous job is still running, the new job starts immediately and runs concurrently with the previous one. Option C correctly describes this default behavior. If you want to prevent concurrent executions, you must explicitly set concurrencyPolicy to 'Forbid'.

Answer

The next job is queued and starts after the previous finishes

Answer

The next job is skipped

Answer

The CronJob is suspended

Question 11

Given the following YAML manifests in the same namespace:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: my-app
spec:
  containers:
  - name: app
    image: nginx
    ports:
    - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
```
A pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

Accepted Answer

The connection succeeds and reaches the pod on port 8080.. The Service my-service is configured with port: 80 and targetPort: 8080. Therefore, traffic sent to the Service on port 80 is forwarded to the pod's container port 8080, and the connection succeeds, reaching the pod on port 8080. If targetPort were not set, it would default to port 80, causing the connection to fail because the pod listens on 8080.

Answer

The connection succeeds but reaches the pod on port 80.

Answer

The connection fails because the endpoints list is empty.

Answer

The connection is randomly dropped due to missing port specification.

Question 12

Which subcommand of 'kubectl config' is used to switch between different contexts?

Accepted Answer

kubectl config use-context. 'kubectl config use-context' is the exact subcommand used to switch the current context in a kubeconfig file. This command updates the 'current-context' field in the kubeconfig, directing all subsequent kubectl commands to the specified cluster, namespace, and user combination.

Answer

kubectl config switch-context

Answer

kubectl config set-context

Answer

kubectl config current-context

Question 13

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The 'OOMKilled' status indicates the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days, the issue is likely a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to handle the higher memory usage without being killed.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Question 14

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The OOMKilled status indicates the container was terminated by the Linux Out-of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 15

Which TWO of the following are valid ways to isolate a set of pods from all ingress traffic except from monitoring pods?

Accepted Answer

Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp }, ingress: [ { from: [ { podSelector: { matchLabels: { role: monitoring } } } ] } ]. It uses a NetworkPolicy with a `podSelector` targeting the protected pods and an `ingress` rule that explicitly allows traffic only from pods with the label `role: monitoring`. This isolates the target pods from all other ingress traffic, as Kubernetes NetworkPolicy defaults to denying ingress when any ingress rule is defined, and only the specified source pods are permitted.

Answer

Apply a NetworkPolicy with ingress rule allowing from a specific pod only

Answer

Apply a NetworkPolicy with empty podSelector and ingress rule allowing all

Answer

Apply a NetworkPolicy with podSelector: matchLabels: { app: myapp } and ingress rule with namespaceSelector: { matchLabels: { name: monitoring } }

Certified Kubernetes Administrator CKA practice test

Three ways to study

Study CKA by domain

Study CKA by topic

Cluster Architecture, Installation and Configuration practice questions

Services and Networking practice questions

Workloads and Scheduling practice questions

Storage practice questions

Troubleshooting practice questions

Cluster Architecture, Installation & Configuration practice questions

Workloads & Scheduling practice questions

Services & Networking practice questions

CKA fundamentals practice questions

CKA scenario practice questions

CKA troubleshooting practice questions

Top CKA questions

Certified Kubernetes Administrator CKA practice questions

How to use these CKA questions

Quick answer