Certified Kubernetes Administrator Free Sample Questions

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

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.

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.

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.

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.

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

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.

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.

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.