CKA Practice Test 45 — 15 Questions

Question 1

Which TWO of the following are valid methods to authenticate to the Kubernetes API server?

Accepted Answer

Client certificate. Option A (Client certificate) is correct because the Kubernetes API server natively supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O fields become group memberships. Option B (ServiceAccount token) is correct because pods authenticate to the API server using automatically mounted ServiceAccount tokens (JWTs) presented as Bearer tokens, validated by the API server against the service account signing key. Option C (Secrets) is not an authentication method itself — Secrets are objects that may store credentials such as tokens, but they do not authenticate a client to the API server. Option D (RBAC) is an authorization mechanism that determines what an authenticated identity may do, not how it proves its identity. Option E (Node authorization) is an authorization mode (Node authorizer) that governs what kubelets may access, not an authentication method.

Answer

Secrets

Answer

RBAC

Answer

Node authorization

Question 2

Which TWO are true about taints and tolerations? (Select 2)

Accepted Answer

A node can have multiple taints. Option B is correct because a Kubernetes node can carry multiple taints simultaneously, each expressed as key=value:effect, and a pod must tolerate every NoSchedule/NoExecute taint on that node to be scheduled there. Option E is correct because tolerations are declared in a pod's spec (spec.tolerations) and let the scheduler place that pod on a node whose taints it matches, effectively overriding the taint's scheduling restriction. Option A is wrong because taints only repel pods that lack matching tolerations, not all pods; pods with appropriate tolerations can still schedule. Option C is wrong because taints are applied to nodes (via kubectl taint nodes), not to pods. Option D is wrong because tolerations are set on pods, not on nodes.

Answer

Taints prevent all pods from scheduling on a node

Answer

Taints are applied to pods

Answer

Tolerations are set on nodes

Question 3

Which TWO of the following are control plane components? (Select 2)

Accepted Answer

etcd. etcd (D) is a control plane component because it is the consistent, highly-available key-value store that persists all cluster state and configuration data for Kubernetes. kube-apiserver (E) is also a control plane component: it exposes the Kubernetes API, validates and processes REST requests, and is the central communication hub through which all other components interact. By contrast, kubelet (A) runs on each worker node to manage pods and containers, kube-proxy (B) runs on nodes to implement Service networking rules via iptables/IPVS, and the container runtime (C) runs on nodes to actually pull images and run containers, so none of these three are control plane components.

Answer

kubelet

Answer

kube-proxy

Answer

container runtime

Question 4

Which TWO of the following are control plane components?

Accepted Answer

cloud-controller-manager. The cloud-controller-manager (A) is a control plane component because it runs cloud-specific controller loops (node, route, and service controllers) that interact with the underlying cloud provider's API, and it runs on the control plane alongside the API server and scheduler. etcd (C) is the control plane's consistent, highly-available key-value store that persists all cluster state and objects, making it a core control plane component. By contrast, kubelet (B) is a node agent that runs on each worker node and manages pod lifecycles via the CRI, so it is a node component, not control plane. The container runtime (D) is node-level software (e.g., containerd or CRI-O) that actually runs containers, and kube-proxy (E) is a node-level network proxy implementing Service rules via iptables/IPVS, so neither belongs to the control plane.

Answer

kubelet

Answer

container runtime

Answer

kube-proxy

Question 5

Which TWO commands can be used to view the configuration of a kubeconfig file?

Accepted Answer

kubectl config get-contexts. Option E, `kubectl config view`, is correct because it prints the merged kubeconfig settings (clusters, contexts, users, and current-context) from the kubeconfig file, optionally with `--minify` or `--raw`. Option D, `kubectl config get-contexts`, is correct because it lists the contexts defined in the kubeconfig, showing NAME, CLUSTER, AUTHINFO, and NAMESPACE, which is a way to view part of the configuration. Option A is wrong because a kubeconfig is a client-side file, not a ConfigMap object, so `kubectl describe configmap kubeconfig` would only work if such a ConfigMap existed in the cluster. Option B is wrong because `kubectl config set-context` modifies a context rather than displaying configuration. Option C is wrong because `kubectl config current-context` only displays the name of the active context, not the configuration itself.

Answer

kubectl describe configmap kubeconfig

Answer

kubectl config set-context

Answer

kubectl config current-context

Question 6

Which TWO of the following are valid methods to configure kubectl to use a specific context?

Accepted Answer

kubectl config use-context my-context. Option C, `kubectl config use-context my-context`, is correct because it directly switches the current context in the kubeconfig file, making all subsequent kubectl commands target that context's cluster, user, and namespace. Option D, `export KUBECONFIG=/path/to/config`, is correct because setting the KUBECONFIG environment variable tells kubectl which kubeconfig file(s) to load, thereby selecting the context defined in that file (or the file's current-context). Option A is not a valid way to select a context because `kubectl config set-context my-context` creates or modifies a context entry but does not activate it. Option B, `kubectl config current-context`, only displays the currently active context and does not configure or change it. Option E, `kubectl --config /path/to/config get pods`, is invalid because kubectl has no `--config` flag; the correct flag is `--kubeconfig`.

Answer

kubectl config set-context my-context

Answer

kubectl config current-context

Answer

kubectl --config /path/to/config get pods

Question 7

Which TWO components are part of the Kubernetes control plane? (Choose TWO.)

Accepted Answer

kube-apiserver. The Kubernetes control plane is the set of components that make global cluster decisions and expose the cluster API, and it includes the kube-apiserver (B) and kube-scheduler (C). The kube-apiserver (B) is the front end of the control plane: it validates and processes REST requests, persists cluster state in etcd, and is the only component that talks directly to etcd. The kube-scheduler (C) is also a control-plane component: it watches for newly created Pods with no assigned node and selects a suitable node based on resource requirements, affinity/anti-affinity, taints and tolerations, and other scheduling policies. The other options are node-level components, not control-plane components: the container runtime (A) executes containers on a node, the kubelet (D) is the node agent that ensures containers described in PodSpecs are running and healthy, and kube-proxy (E) maintains network rules on nodes to implement Service networking.

Answer

container runtime

Answer

kubelet

Answer

kube-proxy

Question 8

Which TWO commands can be used to check the expiration of certificates managed by kubeadm?

Accepted Answer

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity. Option E, `kubeadm certs check-expiration`, is correct because it is the dedicated kubeadm subcommand that lists all kubeadm-managed certificates (in /etc/kubernetes/pki and /etc/kubernetes/pki/etcd) along with their expiration dates, residual time, and CA certificate validity. Option C, `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity`, is correct because it directly parses the X.509 certificate file and prints its Validity period (Not Before / Not After), which is a valid way to inspect the expiration of any individual kubeadm-managed certificate. Option A, `kubeadm upgrade plan`, is not correct because it reports available Kubernetes version upgrades and only incidentally warns about certificate expiry, not as its purpose. Option B, `kubectl get certificates`, is not correct because there is no built-in `certificates` resource in Kubernetes (that would require cert-manager CRDs, which are unrelated to kubeadm PKI). Option D, `kubeadm certs renew --all`, is not correct because it renews certificates rather than checking their expiration.

Answer

kubeadm upgrade plan

Answer

kubectl get certificates

Answer

kubeadm certs renew --all

Question 9

Your kubeadm cluster was initialized with default certificates. You need to check the expiration of the API server certificate and renew it if necessary. Which TWO commands are appropriate? (Choose TWO.)

Accepted Answer

kubeadm certs renew all. Option B, `kubeadm certs check-expiration`, is correct because it is the dedicated kubeadm subcommand that reads the certificates stored in /etc/kubernetes/pki (and the kubeconfig files in /etc/kubernetes) and prints each certificate's expiration date, residual time, and whether it is CA or not, which directly satisfies the requirement to check expiration. Option A, `kubeadm certs renew all`, is correct because it renews every certificate managed by kubeadm, including the API server certificate (apiserver.crt), and is the standard way to renew them when they are expired or near expiry. Option C, `kubectl config view`, only displays the kubeconfig context, cluster, and user settings and reveals nothing about certificate expiration dates. Option D, `kubeadm upgrade plan`, checks available Kubernetes version upgrades and component compatibility, not certificate expiry. Option E, `kubectl cluster-info`, merely shows the addresses of the control plane and core services, so it cannot check or renew certificates.

Answer

kubectl config view

Answer

kubeadm upgrade plan

Answer

kubectl cluster-info

Question 10

Which TWO of the following are valid ways to create a Role in the 'default' namespace that grants get and list on pods?

Accepted Answer

kubectl create role pod-reader --verb=get,list --resource=pods -n default. Option A is correct because `kubectl create role` is the imperative command for creating a namespaced Role, and `--verb=get,list --resource=pods -n default` precisely specifies the get and list verbs on pods in the default namespace. Option D is correct because a declarative YAML manifest with `apiVersion: rbac.authorization.k8s.io/v1`, `kind: Role`, and a rule using the core API group (`apiGroups: [""]`), `resources: ["pods"]`, and `verbs: ["get", "list"]` defines exactly the required namespaced Role. Option B is wrong because `discover` is not a valid RBAC verb for granting pod access. Option C is wrong because `delete` grants deletion, not get/list. Option E is wrong because `kubectl create clusterrole` creates a ClusterRole (cluster-scoped), not a Role in the default namespace.

Answer

kubectl create role pod-reader --verb=discover --resource=pods -n default

Answer

kubectl create role pod-reader --verb=delete --resource=pods -n default

Answer

kubectl create clusterrole pod-reader --verb=get,list --resource=pods

Question 11

You have a ClusterRole named 'deployer' that allows creating Deployments and Services. You want to grant a ServiceAccount 'ci-cd' in namespace 'app' the permissions defined in this ClusterRole. Which TWO resources are needed? (Choose TWO.)

Accepted Answer

The existing ClusterRole 'deployer'. Option A is correct because the existing ClusterRole 'deployer' already contains the desired rules (create Deployments and Services), so it can be referenced directly without duplicating it. Option C is correct because a RoleBinding in namespace 'app' can reference a ClusterRole and bind it to the ServiceAccount 'ci-cd', thereby granting those ClusterRole permissions only within the 'app' namespace. Option B is unnecessary since the ClusterRole already exists and re-creating the same rules would be redundant. Option D is wrong because a ClusterRoleBinding would grant the permissions cluster-wide, not scoped to namespace 'app' as intended. Option E is incorrect because ServiceAccount tokens are handled automatically by Kubernetes and no manual Secret is required for this binding.

Answer

Create a new ClusterRole with the same rules

Answer

ClusterRoleBinding with subject ServiceAccount 'ci-cd' in namespace 'app'

Answer

A Secret for the ServiceAccount

Question 12

Which THREE of the following are components of the Kubernetes control plane? (Choose THREE.)

Accepted Answer

kube-apiserver. The Kubernetes control plane consists of the components that make global cluster decisions and store cluster state. kube-apiserver (A) is correct because it exposes the Kubernetes API and serves as the front end of the control plane, handling all REST requests and validating/updating objects in etcd. kube-scheduler (B) is correct because it watches for newly created Pods with no assigned node and selects a suitable node for them to run on. etcd (C) is correct because it is the consistent, highly-available key-value store that persists all cluster data and is the backing store for the API server. kubelet (D) is not a control plane component; it is a node agent that runs on each worker node and manages Pods and containers on that node. kube-proxy (E) is also not a control plane component; it is a node-level network proxy that implements Service networking rules on each node.

Answer

kubelet

Answer

kube-proxy

Question 13

You have taken an etcd snapshot using 'ETCDCTL_API=3 etcdctl snapshot save snapshot.db'. Which TWO commands are needed to restore this snapshot to a new etcd member? (Choose TWO.)

Accepted Answer

Update the etcd configuration (e.g., --data-dir) and restart the etcd service. Option D is correct because 'etcdctl snapshot restore snapshot.db --data-dir=/var/lib/etcd-restore' is the actual command that rebuilds the etcd data directory from the saved snapshot, writing a fresh member's data into the specified --data-dir. Option C is correct because after restoring the snapshot to a new data directory, the etcd member's configuration (for example the --data-dir flag in the etcd unit file or manifest) must be pointed at that restored directory and the etcd service restarted so the new member starts from the restored state. Option A ('etcdctl endpoint health') only checks cluster endpoint health and does not perform any restore action. Option B ('etcdctl snapshot save backup.db') creates a new snapshot rather than restoring one. Option E ('etcdctl snapshot status snapshot.db') only reports metadata such as hash, revision, and total keys in the snapshot file and does not restore it.

Answer

etcdctl endpoint health

Answer

etcdctl snapshot save backup.db

Answer

etcdctl snapshot status snapshot.db

Question 14

Which TWO components run on worker nodes? (Select 2)

Accepted Answer

kubelet. kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles via the container runtime. kube-proxy (E) is also correct because it runs on each worker node to maintain network rules (iptables/IPVS) that implement Kubernetes Service load balancing and pod networking. etcd (A) is incorrect because it is the cluster's distributed key-value datastore, typically running on control plane nodes. kube-apiserver (C) is incorrect because it is the control plane's front-end REST API server, not a worker node component. kube-scheduler (D) is incorrect because it is a control plane component that assigns pods to nodes rather than running on the worker nodes themselves.

Answer

etcd

Answer

kube-apiserver

Answer

kube-scheduler

Question 15

Which THREE components run on every worker node in a Kubernetes cluster? (Choose THREE.)

Accepted Answer

kube-proxy. kube-proxy (B) is correct because it runs on every worker node and maintains the node's network rules (via iptables/IPVS) to implement Kubernetes Service load balancing and ClusterIP routing. kubelet (C) is correct because it is the node agent that runs on every worker node, registers the node with the API server, and manages Pod lifecycle by instructing the container runtime via the CRI. The container runtime (E) is correct because every worker node must have a CRI-compliant runtime (e.g., containerd or CRI-O) to actually pull images and run containers for Pods. In contrast, etcd (A) is the cluster's distributed key-value datastore and runs on control plane nodes, not worker nodes, and kube-apiserver (D) is the control plane's API front end, also not part of the worker node's required components.

Answer

etcd

Answer

kube-apiserver