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

Question 1

You have multiple kubeconfig files. Which command merges them into a single config file?

Accepted Answer

KUBECONFIG=config1:config2 kubectl config view --flatten > merged-config. The `KUBECONFIG` environment variable can accept a colon-separated list of kubeconfig files, and `kubectl config view --flatten` merges them into a single configuration, outputting the combined result to stdout, which can be redirected to a new file. This is the standard method for merging multiple kubeconfig files in Kubernetes.

Answer

kubectl config merge config1 config2 > merged-config

Answer

cat config1 config2 > merged-config && kubectl config use-context merged-config

Answer

kubectl merge-config config1 config2

Question 2

Which TWO of the following are valid methods to configure kubectl to use a specific context?

Accepted Answer

kubectl config use-context my-context. Option C, `kubectl config use-context my-context`, is correct because it directly switches the current context in the kubeconfig file, making all subsequent kubectl commands target that context's cluster, user, and namespace. Option D, `export KUBECONFIG=/path/to/config`, is correct because setting the KUBECONFIG environment variable tells kubectl which kubeconfig file(s) to load, thereby selecting the context defined in that file (or the file's current-context). Option A is not a valid way to select a context because `kubectl config set-context my-context` creates or modifies a context entry but does not activate it. Option B, `kubectl config current-context`, only displays the currently active context and does not configure or change it. Option E, `kubectl --config /path/to/config get pods`, is invalid because kubectl has no `--config` flag; the correct flag is `--kubeconfig`.

Answer

kubectl config set-context my-context

Answer

kubectl config current-context

Answer

kubectl --config /path/to/config get pods

Question 3

Which THREE components must be present in a high-availability control plane setup?

Accepted Answer

kube-controller-manager. In a highly available Kubernetes control plane, the three essential components are the kube-controller-manager (C), etcd (D), and kube-apiserver (E). The kube-apiserver (E) is the central management endpoint that all clients and internal components communicate with, and it must be replicated behind a load balancer for HA. etcd (D) is the distributed key-value store that holds all cluster state; running it as an odd-numbered quorum across multiple nodes provides fault tolerance. The kube-controller-manager (C) runs the control loops that reconcile cluster state, and in HA it is typically deployed on multiple control-plane nodes with leader election so one active instance drives reconciliation. kubelet (A) and kube-proxy (B) are node-level components that run on every worker node, not control-plane HA components, so they are not required for a high-availability control plane setup.

Answer

kubelet

Answer

kube-proxy

Question 4

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. 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 5

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 6

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

Accepted Answer

kubectl config current-context. `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 7

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 8

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. 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 9

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 10

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 11

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 12

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 13

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. 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 14

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. `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 15

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