CKA Cluster Architecture Installation and Configuration Practice Questions

Free CKA Cluster Architecture Installation and Configuration practice test questions

8 questions from this domain with answers and explanations - different from the samples on the main CKA page. Sign up free to practice the full set.

1. Question 1Cluster Architecture Installation and Configuration

   You need to take a snapshot of the etcd database for backup purposes. Which command should you use?

   • Aetcdctl backup --data-dir /tmp/etcd-backup.db
   • Bkubectl backup etcd /tmp/etcd-backup.db
   • Ckubeadm etcd snapshot /tmp/etcd-backup.db
   • DETCDCTL_API=3 etcdctl snapshot save /tmp/etcd-backup.dbCorrect
   ✓ Correct answer: D

   The etcdctl v3 API command for creating an etcd snapshot is 'etcdctl snapshot save <path>' (or 'etcdctl snapshot create <path>' in some tooling contexts). When etcd is secured with TLS - as it is in kubeadm clusters - you must supply --cacert, --cert, and --key pointing to the etcd CA and peer certificates, and set ETCDCTL_API=3. The resulting snapshot file can later be restored with 'etcdctl snapshot restore'.

   Why the other options are wrong

   • Aetcdctl backup --data-dir /tmp/etcd-backup.db uses the legacy etcd v2 backup subcommand, which is not available in etcd v3 clusters managed by kubeadm and does not produce a portable snapshot file.
   • Bkubectl backup etcd /tmp/etcd-backup.db is not a valid kubectl subcommand - kubectl has no built-in capability to create etcd backups.
   • Ckubeadm etcd snapshot /tmp/etcd-backup.db is not a valid kubeadm subcommand - kubeadm does not provide snapshot functionality for etcd.
2. Question 2Cluster Architecture Installation and Configuration

   Which statement accurately describes how the kubelet runs on each node?

   • AIt runs as a static pod on every node
   • BIt runs as a DaemonSet across all nodes
   • CIt runs as a host process, not as a podCorrect
   • DIt runs inside the kube-proxy container
   ✓ Correct answer: C

   Unlike the control plane components, the kubelet is not containerized; it runs directly on each node, typically as a systemd service. It is the agent that talks to the API server and starts every other pod, including static pods, so it must exist before any container runs. This is why kubelet issues are diagnosed with systemctl and journalctl rather than kubectl.

   Why the other options are wrong

   • AStatic pods are run by the kubelet, so the kubelet cannot itself be a static pod.
   • BThe kubelet starts pods but is not itself managed as a DaemonSet workload.
   • Dkube-proxy is a separate component; the kubelet is not embedded in it.
3. Question 3Cluster Architecture Installation and Configuration

   When initializing a new Kubernetes cluster, which kubeadm flag defines the IP address range from which scheduled workloads receive their addresses?

   • A--pod-network-cidrCorrect
   • B--service-cidr
   • C--node-cidr
   • D--cluster-cidr
   ✓ Correct answer: A

   The '--pod-network-cidr' flag passed to 'kubeadm init' sets the CIDR range allocated to the pod network and is written into the cluster configuration. The value must match what the chosen CNI plugin expects - for example, Flannel defaults to 10.244.0.0/16 and Calico defaults to 192.168.0.0/16. kubeadm also uses this value to configure the kube-controller-manager's --cluster-cidr flag so node subnet allocations are drawn from the correct range.

   Why the other options are wrong

   • B--service-cidr is a different kubeadm init flag that specifies the IP range used for Kubernetes Service virtual IPs, not the range used for pod IP address allocation.
   • C--node-cidr is not a valid kubeadm init flag - node subnet CIDRs are derived automatically from the pod network CIDR by the controller manager and are not specified independently during initialization.
   • D--cluster-cidr is the kube-controller-manager flag that stores the pod network CIDR internally, but it is not a flag used directly with 'kubeadm init' - the correct kubeadm init flag is --pod-network-cidr.
4. Question 4Cluster Architecture Installation and Configuration

   Which command verifies the status and integrity of an etcd snapshot file?

   • Aetcdctl snapshot info /opt/backup/etcd-snapshot.db
   • Betcdctl snapshot verify /opt/backup/etcd-snapshot.db
   • Cetcdctl snapshot status /opt/backup/etcd-snapshot.dbCorrect
   • Detcdctl snapshot check /opt/backup/etcd-snapshot.db
   ✓ Correct answer: C

   etcdctl snapshot status reads the snapshot file and reports its hash, revision number, total key count, and total size in bytes. This metadata allows operators to verify that the snapshot file is intact and to confirm which revision of the data it contains.

   Why the other options are wrong

   • Aetcdctl snapshot info is not a valid etcdctl subcommand; the correct command for examining snapshot metadata is snapshot status.
   • Betcdctl snapshot verify is not a recognized etcdctl subcommand; no such verify subcommand exists under snapshot in etcdctl v3.
   • Detcdctl snapshot check is not a valid etcdctl subcommand; the correct command to inspect a snapshot file is snapshot status.
5. Question 5Cluster Architecture Installation and Configuration

   Which process on a worker node is responsible for pulling container images, starting containers, and monitoring pod health?

   • Akube-scheduler
   • BkubeletCorrect
   • Ccontainerd
   • Dkube-proxy
   ✓ Correct answer: B

   The kubelet is the primary node agent present on every Kubernetes node. It registers the node with the API server, watches for PodSpec assignments targeting its node, instructs the container runtime (via CRI) to pull images and start containers, mounts volumes, configures networking via CNI, and continuously probes container liveness and readiness to report pod health back to the control plane.

   Why the other options are wrong

   • AThe kube-scheduler runs only on the control plane and is responsible for deciding which node a pod should run on; it does not pull images or manage container lifecycle on any node.
   • Ccontainerd is the low-level container runtime that executes containers at the OS level, but it does not watch the Kubernetes API, manage pod health checks, or handle pod scheduling; it receives instructions from the kubelet via the CRI.
   • Dkube-proxy maintains Service networking rules on the node; it does not pull container images, start containers, or monitor pod health - those responsibilities belong to the kubelet.
6. Question 6Cluster Architecture Installation and Configuration

   After upgrading the kubelet on a worker node and restarting the kubelet service, what is the final step?

   • AUncordon the node to make it schedulable againCorrect
   • BRe-register the node with the API server
   • CRun kubeadm upgrade apply on the worker
   • DReboot the worker node
   ✓ Correct answer: A

   The drain step in a node upgrade workflow cordons the node (marks it unschedulable) in addition to evicting pods. After the kubelet package is upgraded and the kubelet service is restarted, the node remains cordoned. Running kubectl uncordon <node> removes the unschedulable taint, allowing the Kubernetes scheduler to once again assign new pods to the node and restoring its full participation in the cluster.

   Why the other options are wrong

   • BRe-register the node with the API server is not necessary; the kubelet maintains its registration with the API server automatically on restart and does not require manual re-registration after an upgrade.
   • CRun kubeadm upgrade apply on the worker is incorrect; kubeadm upgrade apply is only run on the first control plane node, not on worker nodes. Worker nodes use kubeadm upgrade node if they run control plane components, or skip it entirely if they are pure workers.
   • DReboot the worker node is not required as part of the standard Kubernetes upgrade workflow; restarting the kubelet service (systemctl restart kubelet) is sufficient, and an unnecessary reboot would extend the maintenance window.
7. Question 7Cluster Architecture Installation and Configuration

   You need to add a new etcd member to an existing etcd cluster. Which command should you run?

   • Aetcdctl join <name> --peer-urls=https://<ip>:2380
   • Betcdctl cluster add <name> --endpoint=https://<ip>:2380
   • Cetcdctl member add <name> --peer-urls=https://<ip>:2380Correct
   • Detcdctl add member <name> --peer-url=https://<ip>:2380
   ✓ Correct answer: C

   etcdctl member add registers a new etcd member with the existing cluster by specifying the member name and its peer URL. After running this command, the cluster enters a transitional state expecting the new member to start up and connect. The new member must then be started with the ETCD_INITIAL_CLUSTER_STATE=existing environment variable to join rather than bootstrap a new cluster.

   Why the other options are wrong

   • Aetcdctl join is not a valid etcdctl command - no join subcommand exists in etcdctl v3; the correct command is member add.
   • Betcdctl cluster add is not a valid etcdctl command - no cluster add subcommand exists in etcdctl v3.
   • Detcdctl add member reverses the verb and object order and is not valid etcdctl syntax - the correct form is etcdctl member add.
8. Question 8Cluster Architecture Installation and Configuration

   After a cluster upgrade, custom resources are missing. What might have happened?

   • ACustom resources are stored in a separate database that lives outside of the etcd datastore
   • BCustom resources are always deleted automatically whenever the cluster is upgraded to a new version
   • CThe namespace holding all of the custom resources was deleted during the upgrade process
   • DThe CustomResourceDefinition (CRD) may have been deleted or the API version changed; check if the CRD still existsCorrect
   ✓ Correct answer: D

   CustomResourceDefinitions register new API types in the cluster. During a Kubernetes upgrade, if a CRD was defined for an alpha or beta API group that was removed in the new version, the CRD itself may become invalid or be deleted. Additionally, operators or Helm charts may remove CRDs as part of their upgrade lifecycle. When custom resources are missing after an upgrade, the first diagnostic step is to run kubectl get crd to confirm the CRD still exists and that its served API versions match the version used by the resources.

   Why the other options are wrong

   • ACustom resources are stored in etcd like built-in objects, not in a separate external database.
   • BUpgrades do not delete custom resources; they disappear only if the backing CRD is removed or changed.
   • CA namespace deletion would affect all resources there, but the likely cause is a missing or altered CRD.

How Cluster Architecture Installation and Configuration is tested

This domain holds 197 of the 903 questions in the CKA bank, about 22%. The mix is 185 single-answer multiple choice and 12 multiple-response, so it is worth practising the formats as well as the content.

Once you have a few attempts recorded, CertGrid scores every domain separately and points you at the weakest one, so you can drill Cluster Architecture Installation and Configuration on its own rather than re-running full-length mocks.

Other CKA exam domains

• Workloads and Scheduling187 questions
• Services and Networking168 questions
• Storage168 questions
• Troubleshooting183 questions
• All CKA practice questions903 total
• Cluster Architecture Installation and Configuration study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Cluster Architecture Installation and Configuration FAQ