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

Question 1

A Kubernetes cluster was upgraded from v1.28 to v1.29. After the upgrade, nodes report NotReady. You check kubelet logs and see: 'error: failed to run Kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"'. What is the most likely cause?

Accepted Answer

The kubelet configuration has a different cgroup driver than the container runtime. Option D is correct because the error message explicitly states that the kubelet's cgroup driver (systemd) differs from the container runtime's cgroup driver (cgroupfs). In Kubernetes, the kubelet and the container runtime must use the same cgroup driver to manage resource limits correctly. After upgrading from v1.28 to v1.29, the kubelet configuration may have been reset or changed, causing this mismatch, which prevents the kubelet from starting and the node from becoming Ready.

Answer

The container runtime version is incompatible with Kubernetes v1.29

Answer

The kubelet cannot connect to the API server

Answer

The kubelet was not restarted after the upgrade

Question 2

You are setting up a new Kubernetes cluster using kubeadm. You run 'kubeadm init --pod-network-cidr=10.244.0.0/16' on the control plane node. The command fails with: '[preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running: output: time="..." level=fatal msg="validate service connection: CRI v1 runtime API is not implemented for endpoint 'unix:///var/run/containerd/containerd.sock': rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService'"'. What is the most likely cause?

Accepted Answer

The containerd runtime does not support the CRI v1 API; it may be an older version that only supports v1alpha2. The error message indicates that the containerd socket is reachable but the CRI v1 API (runtime.v1.RuntimeService) is not implemented. This typically occurs when containerd is an older version that only supports the CRI v1alpha2 API. Kubernetes 1.24+ defaults to the CRI v1 API, so an older containerd without v1 support will fail during kubeadm init.

Answer

The --pod-network-cidr flag is incorrect

Answer

The kubelet version is incompatible with containerd

Answer

The containerd service is not running

Question 3

Which kubectl command is used to view the current context in the kubeconfig file?

Accepted Answer

kubectl config current-context. Option C is correct because `kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. This command directly queries the `current-context` field in the kubeconfig and outputs its value, allowing you to verify which cluster, user, and namespace combination is active without modifying any configuration.

Answer

kubectl config view

Answer

kubectl config use-context

Answer

kubectl config get-contexts

Question 4

An administrator needs to allow a service account 'monitor-sa' in namespace 'monitoring' to read pods across all namespaces. Which RBAC resources should be created?

Accepted Answer

Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa. A ClusterRole is required because the service account needs to read pods across all namespaces, which is a cluster-scoped permission. A ClusterRoleBinding binds that ClusterRole to the service account 'monitor-sa', granting the permissions cluster-wide. This is the correct approach for cross-namespace access.

Answer

Create a ClusterRole with pod read permissions and a RoleBinding in each namespace

Answer

Create a Role in the monitoring namespace and a RoleBinding to monitor-sa

Answer

Create a Role with pod read permissions and a ClusterRoleBinding to monitor-sa

Question 5

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db. Option C is correct because it uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Answer

kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db

Answer

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

Answer

etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db

Question 6

Which component on a worker node is responsible for maintaining network rules and forwarding traffic to the correct pod?

Accepted Answer

kube-proxy. kube-proxy is the correct component because it runs on each worker node and is responsible for implementing Kubernetes Service concepts by maintaining network rules (iptables or IPVS) that allow network communication to Pods from inside or outside the cluster. It forwards traffic to the correct Pod by load-balancing across the endpoints of a Service, using the cluster IP and port.

Answer

Container runtime

Answer

kubelet

Answer

kube-scheduler

Question 7

A node has been cordoned. Which statement about the node is true?

Accepted Answer

The node is marked as unschedulable, but existing pods continue to run. When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

Answer

All pods on the node are immediately terminated

Answer

The kubelet on the node is stopped

Answer

The node is removed from the cluster

Question 8

You are upgrading a cluster from v1.28 to v1.29. You have already drained and upgraded all worker nodes. The control plane nodes have not been upgraded yet. 'kubectl get nodes' shows the control plane nodes are still v1.28. What is the correct next step?

Accepted Answer

Upgrade the control plane nodes to v1.29. The correct next step is to upgrade the control plane nodes to v1.29. In a Kubernetes cluster upgrade, the control plane must be upgraded before or in conjunction with the worker nodes, but since the worker nodes have already been upgraded and drained, the control plane nodes are still running v1.28. Upgrading the control plane nodes ensures that the API server, scheduler, and controller manager are at the target version, which is required for cluster stability and to support the upgraded kubelets on the worker nodes.

Answer

Drain the worker nodes and downgrade them to v1.28

Answer

Uncordon the worker nodes

Answer

Restart the kubelet on all nodes

Question 9

Which of the following is NOT a control plane component?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on each worker node, not on the control plane. It is responsible for ensuring that containers are running in a Pod as expected by interacting with the container runtime (e.g., containerd or CRI-O). Control plane components are those that manage the cluster's state and scheduling decisions, which run on the control plane nodes.

Answer

kube-apiserver

Answer

kube-controller-manager

Answer

kube-scheduler

Question 10

You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?

Accepted Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io. Option A is correct because it creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Answer

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: ClusterRole
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: ClusterRole
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: default
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Question 11

You need to check the expiration date of certificates used by the kube-apiserver. Which command should you use?

Accepted Answer

kubeadm certs check-expiration. Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command to display the expiration dates of all certificates managed by kubeadm in the cluster, including the kube-apiserver certificate. This command reads the certificate files from `/etc/kubernetes/pki/` and outputs the remaining validity period for each, making it the most direct and accurate method for checking certificate expiration in a kubeadm-deployed cluster.

Answer

kubeadm certs renew

Answer

kubectl get secrets -n kube-system

Answer

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout

Question 12

What is the purpose of the 'kubeadm reset' command?

Accepted Answer

To undo the effects of kubeadm init or kubeadm join on a node. The 'kubeadm reset' command is designed to revert a node back to its pre-'kubeadm init' or pre-'kubeadm join' state. It cleans up all cluster-related configuration, certificates, and etcd data (if running on the control plane), effectively removing the node from the cluster and allowing it to be re-initialized or re-joined cleanly.

Answer

To restart the kubelet service

Answer

To upgrade the cluster to a newer version

Answer

To add a new node to the cluster

Question 13

Which TWO of the following are valid methods to provide a token to a Pod for authenticating to the Kubernetes API server?

Accepted Answer

Using a projected volume with a ServiceAccountToken projection. Option B is correct because a projected volume with a ServiceAccountToken projection allows you to explicitly control the token's audience, expiration, and path, and it requests a time-bound, audience-scoped token from the TokenRequest API. This is the recommended method for pods that need to authenticate to the Kubernetes API server with custom token properties.

Answer

Using a ConfigMap to store the token and mounting it

Answer

Storing a token in a Secret and mounting it as a volume

Answer

Setting the token as an environment variable using the downward API

Question 14

Which THREE of the following are valid steps in a Kubernetes cluster upgrade procedure using kubeadm?

Accepted Answer

Drain the control plane node before upgrading it. Option A is correct because draining the control plane node before upgrading it ensures that all workloads are evicted and rescheduled to other nodes, preventing service disruption. This is a standard Kubernetes procedure where 'kubectl drain' marks the node as unschedulable and evicts pods, respecting PodDisruptionBudgets.

Answer

Downgrade the kubelet on worker nodes to match the control plane version

Answer

Uncordon the node before draining it

Question 15

Which TWO commands can be used to view the configuration of a kubeconfig file?

Accepted Answer

kubectl config get-contexts. Option D is correct because `kubectl config get-contexts` lists all contexts defined in the kubeconfig file, showing their names, clusters, and users. Option E is correct because `kubectl config view` displays the entire merged kubeconfig file content, including clusters, users, and contexts, in YAML or JSON format.

Answer

kubectl describe configmap kubeconfig

Answer

kubectl config set-context

Answer

kubectl config current-context