CKA Cluster Architecture, Installation and Configuration Practice Test 8 — 15 Questions

Question 1

You run 'kubectl get nodes' and see that one node is marked as 'NotReady'. Which component is likely failing on that node?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and reporting its status via periodic heartbeats (NodeStatus updates). When a node is marked as 'NotReady', it means the kubelet has failed to send these heartbeats to the control plane (specifically, the node controller) within the --node-monitor-grace-period (default 40s), indicating the kubelet process is likely down, unresponsive, or misconfigured.

Answer

kube-proxy

Answer

kube-scheduler

Answer

container runtime (e.g., containerd)

Question 2

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

Accepted Answer

kubectl describe pod test-pod. `kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Answer

kubectl logs test-pod

Answer

kubectl exec -it test-pod -- /bin/bash

Answer

kubectl get events

Question 3

Which of the following YAML snippets correctly defines a Kubernetes Deployment with 3 replicas and a rolling update strategy?

Accepted Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1. It uses the stable `apps/v1` API version, specifies 3 replicas, and defines a `RollingUpdate` strategy with both `maxUnavailable` and `maxSurge` set to 1. This ensures that during an update, at most one Pod is unavailable and at most one extra Pod is created, maintaining application availability.

Answer

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate

Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
  maxUnavailable: 1
  maxSurge: 1

Answer

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deploy
spec:
  replicas: 3
  strategy:
    type: OnDelete

Question 4

Which kubectl command is used to mark a node as unschedulable so that no new pods are scheduled onto it?

Accepted Answer

kubectl cordon . The `kubectl cordon ` command marks a node as unschedulable by setting the `node.Spec.Unschedulable` field to `true`. This prevents the Kubernetes scheduler from placing any new pods onto that node, while existing pods continue to run unaffected. This is the correct command for the described task.

Answer

kubectl taint <node>

Answer

kubectl uncordon <node>

Answer

kubectl drain <node>

Question 5

You have a kubeconfig file with multiple contexts. How do you switch to the context named 'prod-cluster'?

Accepted Answer

kubectl config use-context prod-cluster. `kubectl config use-context` is the command specifically designed to switch the current context in a kubeconfig file. It updates the `current-context` field in the kubeconfig to point to the specified context, which then determines which cluster, user, and namespace are used by default for subsequent `kubectl` commands.

Answer

kubectl config set-cluster prod-cluster

Answer

kubectl config set-context prod-cluster

Answer

kubectl config view prod-cluster

Question 6

A user reports that they cannot access a Service of type ClusterIP from within the cluster. The Service selects pods that are running and responding. Which of the following is the MOST likely cause?

Accepted Answer

The Service's targetPort does not match the container's containerPort. The Service's `targetPort` must match the `containerPort` defined in the pod's container spec. Even if the pods are running and responding, if the `targetPort` points to a different port than the one the container is listening on, traffic will be forwarded to the wrong port and the connection will fail. The `port` field on the Service is the port the Service itself listens on, while `targetPort` is the port on the pod where traffic is actually sent.

Answer

The Service's port does not match the container's containerPort

Answer

The Service type is NodePort instead of ClusterIP

Answer

The Service selector does not match any pod labels

Question 7

Which TWO of the following are valid methods to authenticate to the Kubernetes API server?

Accepted Answer

Client certificate. Option A (Client certificate) is correct because the Kubernetes API server natively supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O fields become group memberships. Option B (ServiceAccount token) is correct because pods authenticate to the API server using automatically mounted ServiceAccount tokens (JWTs) presented as Bearer tokens, validated by the API server against the service account signing key. Option C (Secrets) is not an authentication method itself — Secrets are objects that may store credentials such as tokens, but they do not authenticate a client to the API server. Option D (RBAC) is an authorization mechanism that determines what an authenticated identity may do, not how it proves its identity. Option E (Node authorization) is an authorization mode (Node authorizer) that governs what kubelets may access, not an authentication method.

Answer

Secrets

Answer

RBAC

Answer

Node authorization

Question 8

A CKA candidate runs 'kubectl get nodes' and sees that a worker node is in the 'NotReady' state. Which command should be used to diagnose the node's kubelet health?

Accepted Answer

journalctl -u kubelet. The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the most direct way to diagnose kubelet health is to inspect its systemd unit logs using 'journalctl -u kubelet', which shows startup errors, certificate issues, or resource exhaustion that prevent the kubelet from functioning correctly.

Answer

systemctl status docker

Answer

kubectl get events --all-namespaces

Answer

kubectl logs -n kube-system kubelet-<node>

Question 9

An administrator needs to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. Which of the following steps is performed FIRST?

Accepted Answer

Run 'kubeadm upgrade plan' on the first control plane node. Before any upgrade operations, kubeadm requires an assessment of the cluster's upgrade path and potential issues. 'kubeadm upgrade plan' on the first control plane node checks the current and target versions, validates the upgrade feasibility, and displays the upgrade steps and any manual interventions needed. This must be done first to ensure the upgrade is safe and to identify any version skew or configuration problems before proceeding.

Answer

Drain all worker nodes

Answer

Run 'kubectl cordon' on all nodes

Answer

Upgrade kubelet on the first control plane node

Question 10

An administrator backs up etcd data using 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. Which command correctly restores this snapshot on a new etcd instance?

Accepted Answer

etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir=/var/lib/etcd-restored. `etcdctl snapshot restore` is the proper command to restore an etcd snapshot to a new data directory. The `--data-dir` flag specifies where the restored data should be placed, allowing the new etcd instance to use that directory. This command recreates the etcd member's data from the snapshot file, which is essential for disaster recovery.

Answer

kubectl apply -f /backup/etcd-snapshot.db

Answer

etcdctl snapshot load /backup/etcd-snapshot.db

Answer

ETCDCTL_API=3 etcdctl restore /backup/etcd-snapshot.db

Question 11

A developer is creating a Pod with a single container that should restart only if the process exits with non-zero. Which restartPolicy should be used?

Accepted Answer

OnFailure. In Kubernetes, the `restartPolicy` for a Pod controls container restart behavior. The requirement is to restart only when the process exits with a non-zero code, which is exactly what `OnFailure` does. `Always` restarts on any exit (zero or non-zero), `Never` does not restart at all, and `UnlessStopped` is not a valid Kubernetes restart policy (it is a Docker restart policy). Note that while Pods and Jobs support `OnFailure`, workloads like Deployments, StatefulSets, and DaemonSets only support `Always`.

Answer

Never

Answer

Always

Answer

UnlessStopped

Question 12

A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?

Accepted Answer

Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa. A Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

Answer

Create a ClusterRole with 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa

Answer

Add the ServiceAccount to the cluster-admin group

Answer

Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa

Question 13

Which component is responsible for running containers on a Kubernetes node?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on each Kubernetes node. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., Docker, containerd, CRI-O) via the Container Runtime Interface (CRI). It receives Pod specifications from the API server and manages the lifecycle of the containers accordingly.

Answer

kube-proxy

Answer

kube-scheduler

Answer

kube-controller-manager

Question 14

You need to drain a node 'node1' and ensure that pods are evicted gracefully. Which command should you use?

Accepted Answer

kubectl drain node1. `kubectl drain node1` safely evicts all pods from the node while respecting PodDisruptionBudgets (PDBs) and graceful termination periods. It cordons the node first (marking it unschedulable) and then evicts pods, ensuring that workloads are rescheduled on other nodes without disruption.

Answer

kubectl delete node node1

Answer

kubectl cordon node1

Answer

kubectl taint node node1 key=value:NoSchedule

Question 15

An administrator runs 'kubectl get pods' and sees a pod stuck in 'Pending' state. Which of the following is NOT a typical cause?

Accepted Answer

A required ConfigMap does not exist. A missing ConfigMap does not prevent a pod from being scheduled; it only causes the pod to fail at runtime when it tries to mount or use the ConfigMap. The 'Pending' state specifically indicates that the pod has not been scheduled to a node, which is a scheduling issue, not a runtime configuration issue. Therefore, a missing ConfigMap is not a typical cause of a pod stuck in 'Pending'.

Answer

Insufficient CPU or memory resources on any node

Answer

PersistentVolumeClaim is pending and not bound

Answer

Node selector labels do not match any node