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. A free account includes a fixed set of 20 questions for this exam; paid access unlocks the full bank.

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

   Meridian Healthcare is deploying a highly available Kubernetes cluster. The infrastructure team needs to determine the minimum number of etcd members required to maintain quorum and tolerate one node failure. How many etcd members should they deploy?

   • A2
   • B3Correct
   • C1
   • D5
   ✓ Correct answer: B

   The Raft consensus algorithm used by etcd requires a quorum of (n/2)+1 members to make progress. With 3 members the quorum is 2, so the cluster can tolerate exactly 1 member failure and continue operating. This is the minimum cluster size that provides any fault tolerance - a 2-member cluster has a quorum of 2, meaning it cannot tolerate any failure. While 5 members would tolerate 2 simultaneous failures, 3 is the smallest number that meets the requirement of tolerating one node failure with minimum resource usage.

   Why the other options are wrong

   • A2 etcd members provides no fault tolerance - both members must be available to form a quorum of 2, so any single failure causes the cluster to lose quorum and become read-only.
   • C1 etcd member is a single point of failure with no fault tolerance at all - while acceptable for development clusters, it cannot tolerate any node failure.
   • D5 etcd members would tolerate 2 simultaneous failures, which exceeds the minimum requirement of tolerating 1 failure - it is valid but uses more resources than necessary to meet the stated requirement.
3. Question 3Cluster Architecture Installation and Configuration

   You need to back up the etcd data store. Which command creates a snapshot of etcd?

   • Akubectl backup etcd
   • Betcdctl snapshot save /path/to/backup.dbCorrect
   • Cetcdctl export --output=/path/to/backup.db
   • Dkubeadm backup etcd
   ✓ Correct answer: B

   etcdctl is the dedicated CLI tool for etcd administration, and 'snapshot save' creates a consistent binary snapshot of the etcd data store written to the specified file path. In a TLS-secured cluster, the command must include --endpoints, --cacert, --cert, and --key flags pointing to the etcd server address and certificate files. The snapshot captures all key-value data and can be restored to a new etcd data directory using 'etcdctl snapshot restore'.

   Why the other options are wrong

   • Akubectl backup etcd is not a valid kubectl command - kubectl communicates with the Kubernetes API server and provides no functionality for directly backing up the etcd data store.
   • Cetcdctl export --output=/path/to/backup.db is not valid etcdctl syntax - etcdctl does not have an 'export' subcommand; the correct subcommand for creating a backup is 'snapshot save'.
   • Dkubeadm backup etcd is not a valid kubeadm subcommand - kubeadm manages cluster lifecycle operations such as init, join, upgrade, and reset, but does not include any built-in etcd backup functionality.
4. Question 4Cluster Architecture Installation and Configuration

   You need to check if a ServiceAccount named "deploy-sa" in namespace "ci" can list pods. Which command should you use?

   • Akubectl auth can-i list pods --as=system:serviceaccount:ci:deploy-sa -n ciCorrect
   • Bkubectl auth check list pods --sa=deploy-sa -n ci
   • Ckubectl rbac test list pods --serviceaccount=ci:deploy-sa
   • Dkubectl auth can-i list pods --as=deploy-sa --namespace=ci
   ✓ Correct answer: A

   To impersonate a ServiceAccount when checking permissions with kubectl auth can-i, the --as flag must use the fully qualified identity string system:serviceaccount:<namespace>:<name>. This causes the API server to evaluate the SubjectAccessReview as if the specified ServiceAccount were making the request.

   Why the other options are wrong

   • Bkubectl auth check list pods is not valid syntax; the correct subcommand is can-i, and there is no --sa flag - ServiceAccount impersonation uses --as with the full system:serviceaccount format.
   • Ckubectl rbac test is not a valid kubectl command; permission checking is done via kubectl auth can-i, not kubectl rbac.
   • Dkubectl auth can-i list pods --as=deploy-sa uses an incomplete identity string; specifying only the ServiceAccount name without the system:serviceaccount:<namespace>: prefix causes the API server to interpret it as a regular user named deploy-sa, not as the ServiceAccount.
5. Question 5Cluster Architecture Installation and Configuration

   In the kube-apiserver static pod manifest, which flag enables the admission controller for resource limits?

   • A--enable-admission=LimitRanger
   • B--enable-admission-plugins=LimitRangerCorrect
   • C--admission-plugins=LimitRanger
   • D--admission-control=LimitRanger
   ✓ Correct answer: B

   The kube-apiserver flag --enable-admission-plugins takes a comma-separated list of admission plugins to enable in addition to the default set. LimitRanger, which applies the defaults and limits in a namespace's LimitRange objects, is already in that default set, and naming it in --enable-admission-plugins keeps it enabled explicitly.

   Why the other options are wrong

   • A--enable-admission=LimitRanger is not a recognized kube-apiserver flag, so it cannot enable the LimitRanger admission controller.
   • CWithout the required enable prefix, --admission-plugins=LimitRanger is not a flag the kube-apiserver recognizes.
   • D--admission-control is deprecated: the current kube-apiserver reference still lists it but says to use --enable-admission-plugins or --disable-admission-plugins instead, and it will be removed in a future version.
6. Question 6Cluster Architecture Installation and Configuration

   You need to set user credentials in kubeconfig for a user named "dev-user" with a client certificate and key. Which command is correct?

   • Akubectl config set-credentials dev-user --client-certificate=dev-user.crt --client-key=dev-user.keyCorrect
   • Bkubectl config create-user dev-user --client-cert=dev-user.crt --client-key=dev-user.key
   • Ckubectl config set-user dev-user --certificate=dev-user.crt --key=dev-user.key
   • Dkubectl config add-user dev-user --cert=dev-user.crt --key=dev-user.key
   ✓ Correct answer: A

   The kubectl config set-credentials command writes a user entry into the kubeconfig file. The --client-certificate flag specifies the path to the PEM-encoded client certificate file, and --client-key specifies the corresponding private key. This is the standard way to configure certificate-based authentication for a named user in kubeconfig.

   Why the other options are wrong

   • Bkubectl config create-user is not a valid kubectl subcommand - kubectl config does not have a create-user verb, and --client-cert is not a recognized flag.
   • Ckubectl config set-user is not a valid kubectl subcommand - the correct verb is set-credentials, and --certificate is not the correct flag name for this operation.
   • Dkubectl config add-user is not a valid kubectl subcommand - no add-user verb exists in kubectl config, and --cert is not a recognized flag for this purpose.
7. Question 7Cluster Architecture Installation and Configuration

   You need to create a kubeconfig file for a user "developer" with access to the "dev" namespace only. Which approach is correct?

   • ARun kubectl auth create-user developer --namespace=dev to provision the account and its access
   • BCreate a certificate and a Role/RoleBinding in dev, then use kubectl config set-credentials and set-contextCorrect
   • CRun kubectl config add-user developer --role=dev-admin to grant scoped namespace access
   • DRun kubectl create user developer --namespace=dev to generate the scoped kubeconfig file
   ✓ Correct answer: B

   Kubernetes has no User object: a normal user is anyone who presents a credential the cluster trusts, such as a client certificate signed by the cluster CA. The usual process is to generate a private key and certificate signing request, submit it as a CertificateSigningRequest and approve it with kubectl certificate approve, create a Role in dev with the needed permissions, create a RoleBinding in dev that grants that Role to the user named in the certificate's CN, and then add the credentials and context to a kubeconfig with kubectl config set-credentials and kubectl config set-context.

   Why the other options are wrong

   • AThere is no kubectl auth create-user command; users are backed by certificates and RBAC bindings.
   • Ckubectl config add-user does not exist and cannot bind roles; RBAC needs a Role and RoleBinding.
   • DKubernetes has no User object to create; access is granted via a certificate plus RBAC in the namespace.
8. Question 8Cluster Architecture Installation and Configuration

   A cluster sat unused for 14 months. kubectl now fails with a certificate expiry error and the kubelets cannot reach the API server either. What recovers it?

   • ARenew the control plane certs with kubeadm, then regenerate the admin kubeconfigCorrect
   • BWait for the kubelet's automatic rotation to refresh the control plane certs
   • CRestart the API server, which reissues its serving certificate on boot
   • DReissue only the etcd peer certificates, since those gate API server start-up
   ✓ Correct answer: A

   kubeadm issues control plane certificates with a one-year lifetime and renews them automatically on each kubeadm upgrade, which a cluster left alone never gets. kubeadm certs renew all reissues them, after which the control plane static pods must restart to pick them up. The admin kubeconfig is the part people miss: it embeds a client certificate rather than referencing one on disk, so renewing the cluster's certificates does not update /etc/kubernetes/admin.conf and it has to be regenerated. Kubelet client certificates do rotate themselves, but only while they can still authenticate - once expired the kubelet cannot request a new one and needs the control plane fixed first.

   Why the other options are wrong

   • BKubelet rotation covers the kubelet's own client certificate and cannot renew the control plane's, and an expired kubelet cert cannot authenticate the rotation request anyway.
   • CRestarting the API server makes it read the certificate files it already has; it does not reissue its serving certificate.
   • Detcd peer certificates are only one part of the expired set, so reissuing them alone leaves the API server and kubeconfig certificates expired.

How Cluster Architecture Installation and Configuration is tested

This domain holds 167 of the 793 questions in the CKA bank, about 21%. The mix is 203 single-answer multiple choice and 14 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 Scheduling173 questions
• Services and Networking152 questions
• Storage145 questions
• Troubleshooting156 questions
• All CKA practice questions793 total
• Cluster Architecture Installation and Configuration study notesKey concepts
• Cloud Native practice examsAll Cloud Native

CKA Cluster Architecture Installation and Configuration FAQ