Free CKA sample questions

Correct answer: --peer-client-cert-auth

`--peer-client-cert-auth=true` makes an etcd member check that every incoming peer request (port 2380) presents a valid client certificate signed by the peer CA (`--peer-trusted-ca-file`). The flag defaults to `false`, and the etcd docs recommend enabling it to block unauthenticated, forged peers. kubeadm sets it to `true` in the etcd static Pod, together with `--peer-cert-file` and `--peer-key-file`. `--listen-client-urls` and `--advertise-client-urls` concern client traffic on port 2379, and `--initial-cluster-state` (`new` or `existing`) only matters when a member bootstraps.

Correct answer: A policy in `dev-ns` that denies all egress traffic by default but does not explicitly allow DNS traffic.

When a NetworkPolicy selects Pods for egress, as a default deny-all egress policy in `dev-ns` does, those Pods may open only the connections that some egress rule allows. The docs caution that 'a default deny-all egress policy also blocks DNS traffic'. Queries from `dev-ns` Pods to the cluster DNS Service (CoreDNS in `kube-system`, UDP/TCP port 53) are therefore dropped, and even the FQDN `db-service.prod-ns.svc.cluster.local` cannot be resolved. The fix is an egress rule that allows port 53 to the CoreDNS Pods, for example `namespaceSelector` `kubernetes.io/metadata.name: kube-system` plus `podSelector` `k8s-app: kube-dns`. The other policies do not touch the lookup: ingress rules in `prod-ns` or on `dev-ns` Pods do not filter the outgoing DNS query, and an egress policy in `prod-ns` only affects Pods in `prod-ns`.

Correct answer: 1. `kubectl drain worker-01 --ignore-daemonsets` 2. `apt-get install -y kubeadm=1.33.1-1.1` 3. `kubeadm upgrade node` 4. `apt-get install -y kubelet=1.33.1-1.1 kubectl=1.33.1-1.1` 5. `systemctl restart kubelet` 6. `kubectl uncordon worker-01`

Worker nodes are upgraded one at a time after the control plane. Drain the node (from a machine with an admin kubeconfig) and upgrade the kubeadm package. Then run `kubeadm upgrade node`; on a worker it fetches the kubeadm ClusterConfiguration and upgrades the node's kubelet configuration. Upgrade the kubelet and kubectl packages, restart the kubelet and uncordon the node. pkgs.k8s.io package versions look like `1.33.1-1.1`, and the docs pin them as `'1.33.x-*'`. The v1.35 'Upgrading Linux nodes' page drains after `kubeadm upgrade node` and runs `systemctl daemon-reload` before restarting the kubelet; draining first is equally safe. The other sequences are wrong. Skipping the drain disrupts running workloads. Upgrading only the kubelet skips `kubeadm upgrade node`, so the node's kubelet configuration is not upgraded. `kubeadm upgrade node` runs on the node being upgraded; it cannot target a worker from a control plane node.

Correct answer: `kubectl debug -it --image=busybox:1.28 --share-processes --copy-to=debug-pod`

`kubectl debug` is built for this. `kubectl exec` needs a running container that already contains the tools, and here the container keeps crashing and lacks them. `kubectl attach` only connects to the existing process's streams, and `port-forward` tunnels traffic from your workstation. `kubectl debug -it --image=busybox:1.28 --share-processes --copy-to=debug-pod` creates a copy of the Pod named `debug-pod` with an extra busybox container (which provides `ping`, `wget`, `nc` and `nslookup`) and attaches to it. All containers in the copy share its network namespace, so you can test connectivity to the database from the application's network environment, and `--share-processes` lets you see the application's processes. The copy is a new Pod with its own IP and, unless you add `--keep-labels`, without the original labels. To debug inside the original Pod instead, add an ephemeral container with `kubectl debug -it --image=busybox:1.28 --target= `. Delete `debug-pod` when you are finished.

Correct answer: `kubectl create secret generic db-credentials -n backend --from-literal=username=admin --from-literal=password='S3cur3P@ssw0rd!'`

`kubectl create secret generic` with one `--from-literal=key=value` per key is the documented way to create a Secret from raw data. The password is wrapped in single quotes so that the shell does not interpret special characters such as `!` or `$`. The second command stores the wrong password value (the echoed text `password: S3cur3P@ssw0rd!` plus a newline), `kubectl create secret` has no `--username`/`--password` flags and needs a subcommand such as `generic`, and `--from-env-file` needs a credentials file written beforehand. Values passed on the command line can end up in your shell history, so clear or avoid the history entry when handling real credentials.

Correct answers: A nodeAffinity rule with a `requiredDuringSchedulingIgnoredDuringExecution` `nodeSelectorTerm` that matches only nodes without the control-plane role label (operator `DoesNotExist`) explicitly excludes the control plane nodes.; No toleration is needed: DaemonSet pods do not tolerate the `node-role.kubernetes.io/control-plane:NoSchedule` taint by default, so the taint alone already keeps them off the control plane nodes.

The DaemonSet controller adds only a fixed set of tolerations to its Pods: `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` (NoExecute), and `disk-pressure`, `memory-pressure`, `pid-pressure`, `unschedulable` and, for hostNetwork Pods, `network-unavailable` (NoSchedule). The control-plane taint is not among them, so the existing `node-role.kubernetes.io/control-plane:NoSchedule` taint already keeps DaemonSet Pods off the control plane nodes; the documentation's example adds an explicit control-plane toleration only to make a DaemonSet run there. To make the exclusion explicit (for example, in case a broad toleration is added later), add required node affinity with `key: node-role.kubernetes.io/control-plane` and `operator: DoesNotExist`; the DaemonSet controller creates Pods only on nodes that match the Pod template's node affinity. Adding the toleration would do the opposite, DaemonSets have no `replicas` field, and taints are not ignored for DaemonSet Pods, so no anti-affinity rule against kube-apiserver Pods is needed.

The DaemonSet controller adds only a fixed set of tolerations to its Pods: `node.kubernetes.io/not-ready` and `node.kubernetes.io/unreachable` (NoExecute), and `disk-pressure`, `memory-pressure`, `pid-pressure`, `unschedulable` and, for hostNetwork Pods, `network-unavailable` (NoSchedule). The control-plane taint is not among them, so the existing `node-role.kubernetes.io/control-plane:NoSchedule` taint already keeps DaemonSet Pods off the control plane nodes; the documentation's example adds an explicit control-plane toleration only to make a DaemonSet run there. To make the exclusion explicit (for example, in case a broad toleration is added later), add required node affinity with `key: node-role.kubernetes.io/control-plane` and `operator: DoesNotExist`; the DaemonSet controller creates Pods only on nodes that match the Pod template's node affinity. Adding the toleration would do the opposite, DaemonSets have no `replicas` field, and taints are not ignored for DaemonSet Pods, so no anti-affinity rule against kube-apiserver Pods is needed.

Correct answer: `kubectl auth can-i get pods -n production --as=system:serviceaccount:staging:app-reader`

The `kubectl auth can-i` subcommand is specifically designed for this purpose. It allows you to impersonate a user, group, or service account (using the `--as` flag) and check if they have permission to perform a specific action on a resource. It returns a simple 'yes' or 'no', making it the most direct and efficient way to answer the question.

Correct answer: kube-proxy

kube-proxy runs on every node and watches Services and EndpointSlices. For a NodePort Service it programs packet-forwarding rules on every node, so every node accepts traffic on the node port. On Linux these are iptables rules by default, or nftables; IPVS mode is deprecated in v1.35. The kernel then DNATs the packet to one of the ready backend Pod IPs, which may be on another node, and the Pod network set up by the CNI plugin delivers it there. kube-proxy does not relay the packets itself. CoreDNS only resolves names. The CNI plugin provides Pod-to-Pod connectivity but not the Service-to-Pod mapping. An Ingress controller handles HTTP routing for Ingress resources, not NodePort traffic.

Correct answer: `kubectl top pods -A --sort-by=cpu`

The `kubectl top pods` command displays CPU and memory usage for pods. The `-A` flag (or `--all-namespaces`) ensures you see pods from all namespaces, and `--sort-by=cpu` orders the output to show the highest CPU consumers first, making it easy to identify the culprit. This command requires the Metrics Server to be installed in the cluster.

Correct answer: True

True. The v1.35 install guide says that 'the default behavior of a kubelet is to fail to start if swap memory is detected on a node', so swap must be either disabled or explicitly tolerated. With the default configuration (`failSwapOn: true`), disable it on every node with `sudo swapoff -a`. Then remove the swap entries from `/etc/fstab` (or disable the systemd swap units) so it stays off after a reboot. Tolerating swap is an explicit opt-in: set `failSwapOn: false` and, if workloads should use swap, a `swapBehavior` other than the default `NoSwap` (swap support is GA since v1.34). kubeadm's own preflight check only warns about swap; it is the kubelet that refuses to start.