Cluster Architecture, Installation and Configuration — CKA Practice Quiz

Question 1

You created a ClusterRole named 'pod-reader' that grants get, list, and watch on pods. A developer's ServiceAccount 'ci-bot' in the 'dev' namespace needs to read pods only within the 'dev' namespace. Which binding correctly grants exactly this access using the existing ClusterRole?

Accepted Answer

Create a RoleBinding in the 'dev' namespace that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot'.

Answer

Create a ClusterRoleBinding that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot' in namespace 'dev'.

Answer

Create a RoleBinding in the 'default' namespace that references the ClusterRole 'pod-reader' and the ServiceAccount 'ci-bot'.

Answer

Convert the ClusterRole to a Role in the 'dev' namespace, then create a ClusterRoleBinding referencing it.

Question 2

After bootstrapping a new single-control-plane cluster with kubeadm, you notice all nodes report NotReady and every Pod (including CoreDNS) remains stuck in ContainerCreating. Running 'kubectl describe pod' on a CoreDNS Pod shows the event: 'Failed to create pod sandbox: ... failed to find plugin "..." in path [/opt/cni/bin] ... network plugin is not ready: cni config uninitialized'. What is the correct action to bring the cluster to a healthy state?

Accepted Answer

Deploy a CNI plugin (e.g., apply the Calico or Flannel manifest) so the Pod network add-on initializes the node network.

Answer

Restart the kubelet on all nodes with 'systemctl restart kubelet' to force sandbox recreation.

Answer

Re-run 'kubeadm init' with the '--pod-network-cidr' flag to reconfigure the cluster networking.

Answer

Increase the CoreDNS Deployment replica count and add tolerations for the node.kubernetes.io/not-ready taint.

Question 3

A worker node's kubelet is running, but you suspect containers are failing at the runtime level. The node uses containerd as its CRI. You need to list all running containers and inspect a specific container's status directly at the runtime layer, bypassing the Kubernetes API. Which tool and configuration is the correct approach?

Accepted Answer

Use crictl with the runtime endpoint set to unix:///run/containerd/containerd.sock (e.g., via /etc/crictl.yaml or --runtime-endpoint) to run 'crictl ps' and 'crictl inspect'.

Answer

Use 'docker ps' and 'docker inspect' since Kubernetes always manages containers through the Docker daemon socket.

Answer

Run 'kubectl get pods -o wide' on the node, since kubectl communicates directly with the container runtime when run locally.

Answer

Use 'ctr --namespace k8s.io containers list' after setting the CRI endpoint to unix:///var/run/crio/crio.sock.

Question 4

Your production cluster uses an external etcd topology (etcd runs on dedicated nodes outside the control-plane machines). You need to take an etcd snapshot for backup from one of the etcd nodes using etcdctl v3. The etcd cluster is secured with client certificate authentication. Which command correctly produces the snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl snapshot save /backup/snap.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/server.crt --key=/etc/etcd/server.key

Answer

ETCDCTL_API=3 etcdctl snapshot save /backup/snap.db --endpoints=http://127.0.0.1:2379

Answer

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

Answer

ETCDCTL_API=2 etcdctl backup --data-dir=/var/lib/etcd --backup-dir=/backup

Question 5

You are responsible for etcd backups on a kubeadm-provisioned cluster where etcd runs as a stacked static pod on the control-plane node. Before a risky upgrade, you must take a manual snapshot of the etcd data from the control-plane host. The etcd server certificates are located in /etc/kubernetes/pki/etcd/. Which command correctly captures a consistent snapshot?

Accepted Answer

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db --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

Answer

ETCDCTL_API=3 etcdctl snapshot save /opt/etcd-backup.db --endpoints=https://127.0.0.1:2379 --insecure-skip-tls-verify

Answer

kubectl get etcd -n kube-system -o yaml > /opt/etcd-backup.db

Answer

cp -r /var/lib/etcd /opt/etcd-backup.db while the etcd static pod is running

Question 6

You are administering a three-node stacked etcd control plane provisioned with kubeadm. After a network partition, users report intermittent API server errors. You want to inspect the etcd cluster membership and confirm each member's health directly from one control-plane node. Which command correctly queries etcd using the certificates that kubeadm places on the node?

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 endpoint health --cluster

Answer

ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/ca.crt --cert=/etc/kubernetes/pki/apiserver.crt --key=/etc/kubernetes/pki/apiserver.key endpoint health --cluster

Answer

kubectl get --raw /healthz/etcd --server=https://127.0.0.1:2379

Answer

ETCDCTL_API=2 etcdctl cluster-health --endpoints=https://127.0.0.1:2379 --ca-file=/etc/kubernetes/pki/etcd/ca.crt

Question 7

You are deploying an application named 'billing' with Helm. The chart's values.yaml sets 'replicaCount: 2'. Your team maintains an environment file prod-values.yaml that sets 'replicaCount: 4'. During a hotfix rollout you run: helm install billing ./billing-chart -f prod-values.yaml --set replicaCount=6. After the release completes, how many replicas will the Deployment be configured with, and why?

Accepted Answer

6 replicas, because --set has the highest precedence and overrides both values.yaml and the -f file

Answer

4 replicas, because the -f file is applied last and overrides both the chart default and --set

Answer

2 replicas, because the chart's built-in values.yaml always takes priority over runtime overrides

Answer

The install fails because you cannot combine -f and --set in a single helm command

Question 8

A platform engineer reports that a Helm release named 'billing-api' was installed several days ago, but running `helm list` in their current shell shows no releases. Other teammates confirm the workload pods are running in the 'finance' namespace. Which command will correctly reveal the 'billing-api' release and its status?

Accepted Answer

helm list --all-namespaces

Answer

helm status billing-api --revision 0

Answer

helm repo list | grep billing-api

Answer

kubectl get releases -A

Question 9

You maintain a kubeadm-provisioned cluster that has been running for just over a year. This morning, kubectl commands from the admin workstation begin failing with 'x509: certificate has expired or is not yet valid', and the API server static pod is repeatedly restarting. Investigation shows the cluster's PKI certificates were never rotated. Which single command should you run on the control-plane node to renew all kubeadm-managed certificates at once, after which you must restart the control-plane components?

Accepted Answer

kubeadm certs renew all

Answer

kubeadm init phase certs all --force

Answer

kubeadm alpha kubeconfig user --client-name admin

Answer

kubectl certificate approve $(kubectl get csr -o name)

Question 10

You are bootstrapping a highly-available control plane with kubeadm. The first control-plane node was initialized several hours ago using 'kubeadm init' with a stacked etcd topology behind a load balancer. Now you want to join a second control-plane node using 'kubeadm join --control-plane'. The join command fails because it cannot download the required control-plane certificates from the cluster. What is the correct way to make those certificates available for the join?

Accepted Answer

Run 'kubeadm init phase upload-certs --upload-certs' on the first control-plane node to re-upload the certificates to a new kubeadm-certs Secret, then obtain the new certificate key and pass it to the join command with --certificate-key

Answer

Manually copy the /etc/kubernetes/pki directory from the first node to the second node and re-run the same join command, since kubeadm never distributes certificates over the network

Answer

Regenerate the bootstrap token with 'kubeadm token create' and pass it with --token; the certificate download uses the same token and no separate key is needed

Answer

Run 'kubeadm certs renew all' on the first node to refresh the certificates, which automatically re-populates the certificate cache used by joining control-plane nodes

Question 11

You are provisioning a new control-plane node with kubeadm. The node has both containerd (socket at unix:///run/containerd/containerd.sock) and CRI-O (socket at unix:///run/crio/crio.sock) installed. When you run 'kubeadm init', the command fails with an error indicating that multiple container runtime endpoints were detected and it cannot proceed. You want the cluster to use containerd. Which action correctly resolves this and initializes the cluster?

Accepted Answer

Run 'kubeadm init --cri-socket unix:///run/containerd/containerd.sock' to explicitly select the containerd runtime endpoint.

Answer

Set the KUBELET_EXTRA_ARGS environment variable to point to containerd and re-run 'kubeadm init' without additional flags.

Answer

Uninstall the kubelet, reinstall it, and run 'kubeadm init', which auto-detects the first runtime alphabetically.

Answer

Run 'kubeadm init --container-runtime=containerd' since kubeadm reads the runtime name directly.

Question 12

You are bootstrapping a new control-plane node with kubeadm on a server inside an air-gapped datacenter that has no internet access. Before running 'kubeadm init', you want to verify exactly which container images this specific kubeadm version requires so you can pre-load them into your local registry mirror. Which command lets you list those required images without contacting any external endpoint or initializing the cluster?

Accepted Answer

kubeadm config images list

Answer

kubeadm init --dry-run

Answer

kubeadm config images pull

Answer

crictl images list

Question 13

You are bootstrapping a highly-available cluster with kubeadm using the stacked etcd topology. After running 'kubeadm init --upload-certs' on the first control-plane node and successfully joining a second control-plane node, you attempt to join a third control-plane node two hours later using the same '--certificate-key' value printed during init. The join fails with an error indicating the certificate key cannot be used to decrypt the certificates. What is the cause and correct remediation?

Accepted Answer

The certificate key expired because uploaded certs in the kubeadm-certs Secret are deleted after two hours; run 'kubeadm init phase upload-certs --upload-certs' on an existing control-plane node to regenerate a new key, then join with that key.

Answer

The bootstrap token expired; regenerate a token with 'kubeadm token create' and reuse the original certificate key to join the node.

Answer

The CA certificate rotated automatically; renew all certificates with 'kubeadm certs renew all' on the first node before joining the third node.

Answer

Control-plane joins are limited to two nodes with stacked etcd; you must switch to an external etcd topology to add a third control-plane node.

Question 14

You are adding a new worker node to an existing kubeadm cluster. On the worker, you run 'kubeadm join 10.0.0.5:6443 --token abc123.def4567890ghijkl' without any other flags. The join fails immediately with an error stating that the cluster CA could not be validated because no --discovery-token-ca-cert-hash was provided and --discovery-token-unsafe-skip-ca-verification was not set. You want to join securely without disabling verification. Which action correctly obtains the value needed to complete the join?

Accepted Answer

On a control plane node, compute the CA cert hash with: openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der | openssl dgst -sha256 -hex, then pass it as --discovery-token-ca-cert-hash sha256:<hash>

Answer

Regenerate the bootstrap token with 'kubeadm token create' and rerun join; the new token embeds the CA hash automatically

Answer

Copy /etc/kubernetes/admin.conf to the worker and pass it via --kubeconfig so the join trusts the CA implicitly

Answer

Add --discovery-token-unsafe-skip-ca-verification to bypass the CA check, which is the standard secure way to join production nodes

Question 15

You are adding a new worker node to an existing kubeadm cluster. The control plane was set up two days ago. When you run the 'kubeadm join' command that was printed during 'kubeadm init', the node fails with an error indicating the bootstrap token is invalid or has expired. You need to generate a fresh join command from the control plane node. Which command produces a complete, ready-to-use join command including a new token and the discovery CA cert hash?

Accepted Answer

kubeadm token create --print-join-command

Answer

kubeadm token list

Answer

kubeadm init phase upload-certs --upload-certs

Answer

kubeadm token generate

Question 16

You administer a kubeadm-managed cluster where the control-plane node currently runs Kubernetes v1.29.4. You have already run 'apt-get install -y kubeadm=1.30.1-*' on the control-plane node and confirmed the kubeadm binary reports v1.30.1. Your goal is to upgrade the control-plane components (API server, controller manager, scheduler, etcd static pods) to v1.30.1. Which command should you run next to perform this upgrade on the first control-plane node?

Accepted Answer

kubeadm upgrade apply v1.30.1

Answer

kubeadm upgrade node

Answer

kubectl set image -n kube-system pod/kube-apiserver kube-apiserver=registry.k8s.io/kube-apiserver:v1.30.1

Answer

apt-get install -y kubelet=1.30.1-* && systemctl restart kubelet

Question 17

You are upgrading a kubeadm-managed cluster. The control plane has already been upgraded to v1.29.2. You now need to upgrade a worker node named 'worker-3'. You have run 'apt-get install kubeadm=1.29.2-*' and 'kubeadm upgrade node' on worker-3. What is the correct sequence of remaining steps to safely complete the worker upgrade, minimizing disruption to running workloads?

Accepted Answer

From a control-plane node run 'kubectl drain worker-3 --ignore-daemonsets', then on worker-3 upgrade kubelet and kubectl packages, run 'systemctl daemon-reload && systemctl restart kubelet', then run 'kubectl uncordon worker-3'.

Answer

On worker-3 upgrade kubelet and kubectl packages first, restart kubelet, then run 'kubectl drain worker-3' and finally 'kubectl uncordon worker-3'.

Answer

Run 'kubectl cordon worker-3', upgrade kubelet, restart kubelet, then re-run 'kubeadm upgrade apply v1.29.2' on worker-3 to finalize the node.

Answer

From a control-plane node run 'kubectl drain worker-3 --force --delete-emptydir-data', upgrade kubelet, restart kubelet — no uncordon is needed because drain automatically re-enables scheduling after upgrade.

Question 18

You manage a highly-available cluster that was bootstrapped with kubeadm using an external etcd topology (etcd runs on dedicated hosts, not as static pods managed by kubeadm). You are upgrading the first control-plane node from v1.29 to v1.30 and run 'kubeadm upgrade apply v1.30.0'. The command reports it will manage component upgrades. What is the correct expectation about etcd during this kubeadm upgrade?

Accepted Answer

kubeadm will not upgrade or manage etcd; you must upgrade the external etcd cluster manually and separately from the kubeadm workflow.

Answer

kubeadm automatically upgrades the external etcd members by connecting to each etcd host over SSH during 'upgrade apply'.

Answer

kubeadm regenerates the etcd static pod manifests on the control-plane node, which restarts the external etcd members.

Answer

kubeadm refuses to run 'upgrade apply' entirely until etcd is converted to a stacked topology.

Question 19

You are upgrading a worker node named worker-3 as part of a rolling kubeadm upgrade. Before running the kubelet package upgrade, you attempt to drain the node with `kubectl drain worker-3`, but the command fails with an error stating that the node contains DaemonSet-managed Pods and Pods with local storage (emptyDir volumes). You must safely evict the workloads and proceed with the upgrade without losing critical control-plane agents that run on every node. Which command correctly drains the node in this situation?

Accepted Answer

kubectl drain worker-3 --ignore-daemonsets --delete-emptydir-data

Answer

kubectl drain worker-3 --force --grace-period=0

Answer

kubectl cordon worker-3 --ignore-daemonsets

Answer

kubectl drain worker-3 --delete-daemonsets --keep-emptydir-data

Question 20

You upgraded the control plane of a kubeadm cluster to v1.30 successfully. When you run `kubectl get nodes`, the control-plane node shows v1.30 but three worker nodes still show v1.28 and remain Ready. New pods scheduled to the workers run fine, but you are preparing to upgrade the workers. Before draining and upgrading a worker, which command should you run ON that worker node to update the local kubeadm-managed component configuration and pull the correct kubelet config?

Accepted Answer

kubeadm upgrade node

Answer

kubeadm upgrade apply v1.30

Answer

kubeadm init phase kubelet-start

Answer

kubectl drain <node> --ignore-daemonsets && systemctl restart kubelet

More CKA practice