CKA Practice Questions

kubectl cordon node-04 sets spec.unschedulable: true on the Node. The scheduler then places no new Pods there, while the existing Pods keep running; kubectl get nodes shows the node as Ready,SchedulingDisabled, and kubectl uncordon reverses it. kubectl drain also cordons the node but then evicts its Pods, which is not wanted yet. A custom NoSchedule taint only repels Pods that do not tolerate it and does not mark the node unschedulable. kubectl stop node is not a kubectl command.

A CronJob creates Jobs on a repeating schedule written in cron format (minute, hour, day of month, month, day of week), so "0 1 * * *" means 01:00 every day. Without .spec.timeZone, kube-controller-manager interprets the schedule in its own local time zone; set .spec.timeZone: "Etc/UTC" to make sure the job runs at 01:00 UTC. A Deployment or StatefulSet runs long-lived Pods, and a Job runs only once.

True. For CPU and memory utilization the HPA controller queries the resource metrics API (metrics.k8s.io), an aggregated API that is usually served by Metrics Server, an add-on that has to be deployed separately. Without an implementation of that API the HPA cannot read Pod usage and takes no scaling action. Custom and external metrics come from separate APIs (custom.metrics.k8s.io and external.metrics.k8s.io).

A Pod in which no container has CPU or memory requests or limits is in the BestEffort QoS class. When the node runs out of memory before the kubelet can reclaim it, the kernel OOM killer picks victims by oom_score. The kubelet gives BestEffort containers oom_score_adj 1000, the highest value (Guaranteed containers get -997), so they are killed first and report OOMKilled. For node-pressure eviction, the kubelet first ranks Pods whose usage exceeds their requests, then by Priority. A BestEffort Pod has no requests, so any usage exceeds them, and 'the kubelet prefers to evict BestEffort Pods'. An OOM kill is not an eviction: the container is terminated and can be restarted according to restartPolicy, whereas an evicted Pod ends in phase Failed with reason Evicted. Setting requests (and limits) moves these Pods to Burstable or Guaranteed.

This is the correct syntax for a Kustomize overlay. The resources field points to the base configuration. The replicas field is a special transformer that finds a resource by name and sets its replica count. commonAnnotations is another transformer that adds the specified annotation to all resources managed by this kustomization.

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