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

Question 1

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 2

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 3

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

Accepted Answer

kubectl logs mypod --previous. The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

Answer

kubectl exec -it mypod -- sh

Answer

kubectl delete pod mypod && kubectl create -f mypod.yaml

Answer

kubectl describe pod mypod

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

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 8

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 9

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

You need to back up etcd on a single control plane node. Which command correctly creates a 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 required `ETCDCTL_API=3` environment variable and specifies the necessary TLS client certificates (`--cacert`, `--cert`, `--key`) to authenticate to the etcd server, which by default listens on `https://127.0.0.1:2379` with mutual TLS enabled. The `snapshot save` command creates a point-in-time backup of the etcd data store, essential for disaster recovery in a Kubernetes control plane.

Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 snapshot save /backup/etcd-snapshot.db

Answer

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

Answer

etcdctl snapshot save /backup/etcd-snapshot.db

Question 11

A ClusterRole named 'pod-reader' exists that grants get, list, and watch permissions on pods. You want to bind this ClusterRole to a user 'john' in the 'development' namespace only. Which resource should you create?

Accepted Answer

RoleBinding 'john-pod-reader' in namespace 'development' referencing ClusterRole 'pod-reader' and user 'john'. A RoleBinding in a specific namespace can reference a ClusterRole to grant its permissions only within that namespace. Since the requirement is to bind the existing 'pod-reader' ClusterRole to user 'john' exclusively in the 'development' namespace, a RoleBinding named 'john-pod-reader' in the 'development' namespace is the correct resource. This allows the ClusterRole's pod read permissions to be scoped down to a single namespace.

Answer

Add user 'john' to the 'pod-reader' ClusterRole definition

Answer

Role 'pod-reader' in namespace 'development'

Answer

ClusterRoleBinding 'john-pod-reader' binding 'pod-reader' to user 'john'

Question 12

Which command initializes a Kubernetes control plane node using kubeadm?

Accepted Answer

kubeadm init. `kubeadm init` is the specific command used to bootstrap and initialize a Kubernetes control plane node. It performs pre-flight checks, generates certificates, creates the static Pod manifests for core control plane components (API server, controller manager, scheduler, etcd), and configures the admin kubeconfig file. This is the standard kubeadm workflow for setting up a new cluster.

Answer

kubeadm create

Answer

kubeadm setup

Answer

kubeadm start

Question 13

Which component is responsible for maintaining network rules on worker nodes?

Accepted Answer

kube-proxy. kube-proxy is the component responsible for maintaining network rules on worker nodes. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates iptables, IPVS, or userspace rules on the node to route traffic to the correct Pods. This ensures that network traffic directed at a Service's ClusterIP or NodePort is properly forwarded to the backend Pods.

Answer

kube-scheduler

Answer

kubelet

Answer

kube-controller-manager

Question 14

A node named 'worker-1' is unhealthy. You want to mark it as unschedulable and move workloads to other nodes. Which command sequence is correct?

Accepted Answer

kubectl cordon worker-1; kubectl drain worker-1. `kubectl cordon worker-1` marks the node as unschedulable, preventing new pods from being scheduled onto it, and `kubectl drain worker-1` safely evicts all existing pods from the node, respecting PodDisruptionBudgets and terminating pods gracefully. This sequence ensures workloads are moved to other nodes without disrupting running services.

Answer

kubectl uncordon worker-1; kubectl drain worker-1

Answer

kubectl delete node worker-1; kubectl cordon worker-1

Answer

kubectl drain worker-1; kubectl cordon worker-1

Question 15

You run `kubectl get pods` and get an error: 'error: You must be logged in to the server (Unauthorized)'. What is the most likely cause?

Accepted Answer

The kubeconfig file is missing or invalid.. The error 'You must be logged in to the server (Unauthorized)' indicates that the kubectl client successfully reached the API server, but the request was rejected because the client's credentials (typically from the kubeconfig file) are missing, expired, or invalid. The kubeconfig file contains the cluster, user, and context information required for authentication; if it is misconfigured or not present, kubectl cannot authenticate and returns this specific HTTP 401 Unauthorized error.

Answer

The API server is not running.

Answer

The pod does not exist.

Answer

The namespace does not exist.