CKA Cluster Architecture, Installation and Configuration Practice Test 3 — 15 Questions

Question 1

Which TWO of the following are valid ways to set the namespace for a kubectl command?

Accepted Answer

kubectl config set-context $(kubectl config current-context) --namespace=myns. Option B is correct because `kubectl config set-context $(kubectl config current-context) --namespace=myns` updates the current context's default namespace, so all subsequent kubectl commands using that context will target myns without needing a flag. Option D is correct because `kubectl get pods --namespace=myns` uses the `--namespace` (or `-n`) flag to scope that single command to the myns namespace, which is a standard per-command override. Option A is invalid because `kubectl config set-context` requires a context name argument before `--namespace`; without it, the command fails. Option C is invalid because `kubectl namespace` is not a real kubectl subcommand. Option E is invalid because kubectl does not read a `KUBE_NAMESPACE` environment variable to determine the namespace.

Answer

kubectl config set-context --namespace=myns

Answer

kubectl namespace myns

Answer

export KUBE_NAMESPACE=myns

Question 2

Which THREE of the following are valid steps when restoring etcd from a snapshot using etcdctl?

Accepted Answer

Update the etcd configuration to point to the new data directory.. Option E is correct because the core of the restore procedure is running `etcdctl snapshot restore <snapshot.db>`, which rebuilds a fresh etcd data directory from the snapshot rather than overwriting the existing member's data in place. Option C is correct because `snapshot restore` requires the `--data-dir` flag to specify the destination directory where the new restored data directory will be written, since etcd cannot restore into an existing data directory. Option D is correct because the etcd process (the systemd `etcd` service or the static Pod manifest in `/etc/kubernetes/manifests`) must be stopped before restoring, so that the running member does not hold locks on or corrupt the data directory being replaced. Option A is not a valid restore step: after restoring you must point etcd at the new data directory via its configuration (e.g., `--data-dir` in the etcd manifest or unit file), but that is a post-restore reconfiguration action, not part of the `etcdctl snapshot restore` operation itself, and the question asks specifically about steps using etcdctl. Option B is incorrect because `etcdctl snapshot save` creates a backup, which is the opposite of restoring from one; it is a prerequisite performed before a failure, not a restore step.

Answer

Run etcdctl snapshot save to create a backup.

Answer

Use --data-dir flag with snapshot restore to specify the destination.

Question 3

A ClusterRoleBinding grants permissions to a user, but the user is unable to perform the action. What is a possible cause?

Accepted Answer

The subject in the ClusterRoleBinding is misspelled or missing the kind.. To make the question technically precise and ensure there is only one correct answer, we specify in the stem that the ClusterRole itself has been verified to have the correct rules. We also correct Option A to focus on the misspelled subject name (or namespace for ServiceAccounts), which is a silent failure because Kubernetes does not validate the existence of subjects when creating bindings.

Answer

The ClusterRole does not have the required rules.

Answer

The user's kubeconfig does not include the correct context.

Answer

A RoleBinding in the namespace overrides the ClusterRoleBinding.

Question 4

Which TWO of the following are valid resources for granting permissions in RBAC?

Accepted Answer

ClusterRoleBinding. In Kubernetes RBAC, permissions are granted by binding a subject (User, Group, or ServiceAccount) to a role via a binding resource, so ClusterRoleBinding (C) and RoleBinding (E) are the valid resources for granting permissions. A ClusterRoleBinding (C) grants the permissions defined in a ClusterRole to subjects cluster-wide (or to a namespaced Role via a RoleBinding), while a RoleBinding (E) grants permissions within a specific namespace. Role (A) and ClusterRole (D) only define sets of rules/permissions and do not themselves grant anything until bound, and ServiceAccount (B) is an identity/subject that receives permissions, not a resource that grants them.

Answer

Role

Answer

ServiceAccount

Answer

ClusterRole

Question 5

Which THREE of the following are valid options for the 'kubectl drain' command to safely evict pods from a node?

Accepted Answer

--force. Option C (--force) is correct because kubectl drain refuses to proceed when a node hosts pods that are not managed by a controller (bare pods); --force allows those unmanaged pods to be deleted so the drain can complete. Option D (--delete-emptydir-data) is correct because draining a node with pods using emptyDir volumes requires this flag to acknowledge and permit deletion of that local ephemeral data, otherwise the command aborts. Option E (--ignore-daemonsets) is correct because DaemonSet-managed pods cannot be evicted by drain, so this flag tells kubectl to skip them and proceed with evicting the remaining pods. Option A (--grace-period=0) is not a drain-specific option for safely evicting pods and is not among the marked correct answers, and Option B (--timeout=30s) merely sets an overall time limit rather than enabling safe eviction, so neither belongs here.

Answer

--grace-period=0

Answer

--timeout=30s

Question 6

You are using kubeadm to initialize a Kubernetes cluster. After running 'kubeadm init', the control-plane node is not ready. You run 'kubectl get nodes' and see the node status as 'NotReady'. Which component is most likely not functioning correctly?

Answer

kube-scheduler

Answer

etcd

Answer

kube-apiserver

Answer

kubelet

Question 7

Which TWO of the following are valid methods to restore an etcd cluster from a snapshot? (Choose TWO.)

Accepted Answer

Stopping all etcd members, copying the snapshot to the data directory, and starting etcd. To restore an etcd cluster from a snapshot, the `etcdctl snapshot restore` (or `etcdutl snapshot restore` in newer etcd versions) command must be used. This command extracts the snapshot database and reconstructs the necessary directory structure (including the WAL and member data) so that etcd can successfully start and recover its state.

Answer

etcdctl restore

Answer

kubectl apply -f etcd-backup.yaml

Answer

etcdctl snapshot restore

Answer

kubeadm reset

Question 8

An administrator needs to grant a service account 'sa-monitor' in namespace 'monitoring' the ability to read pods and services cluster-wide. Which RBAC configuration is correct?

Accepted Answer

Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a ClusterRoleBinding binding it to sa-monitor. The service account 'sa-monitor' needs to read pods and services across all namespaces (cluster-wide). A ClusterRole with verbs get, watch, list for pods and services, combined with a ClusterRoleBinding, grants these permissions cluster-wide, which is the only way to achieve cross-namespace read access for a service account.

Answer

Create a Role with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring

Answer

Create a ClusterRole with rules for pods and services (verbs: create) and a ClusterRoleBinding binding it to sa-monitor

Answer

Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring

Question 9

A cluster was upgraded from version 1.28 to 1.29. After the upgrade, you notice that a custom controller using the 'batch/v2alpha1' API for CronJobs no longer works. What is the most likely reason?

Accepted Answer

The batch/v2alpha1 API version is deprecated and removed in 1.29. The batch/v2alpha1 API version for CronJobs was deprecated in Kubernetes 1.21 and removed entirely in 1.29. Since the cluster was upgraded from 1.28 to 1.29, the custom controller can no longer use this API version because the API server no longer serves it. Controllers must migrate to the stable batch/v1 API version to function correctly.

Answer

The API server was not restarted after the upgrade

Answer

The CronJob resource has been renamed to ScheduledJob

Answer

The custom controller uses an incorrect kubeconfig

Question 10

You need to restore an etcd snapshot taken with 'etcdctl snapshot save'. You have a single control plane node. Which sequence of commands is correct?

Accepted Answer

Stop the API server, run 'etcdctl snapshot restore /backup/snapshot.db --data-dir /var/lib/etcd-restored', then start etcd with the restored data. Restoring an etcd snapshot requires stopping the API server first to prevent data corruption, then using 'etcdctl snapshot restore' to create a new data directory, and finally starting etcd with the restored data. The API server depends on etcd, so it must be stopped before the restore, and the restored data directory must be specified to avoid overwriting the existing etcd data.

Answer

Run 'etcdctl import /backup/snapshot.db' and restart the API server

Answer

Stop the API server, run 'etcdctl restore /backup/snapshot.db', then restart etcd

Answer

Run 'etcdctl snapshot restore /backup/snapshot.db' while etcd is running, then restart etcd

Question 11

You need to allow a specific pod running in namespace 'app' to communicate with a database pod in namespace 'db' only. Which NetworkPolicy configuration achieves this?

Accepted Answer

NetworkPolicy in namespace 'db' with podSelector: {} and ingress from namespace 'app'. To restrict ingress traffic to the 'db' namespace so that it only accepts connections from the 'app' namespace, you must apply a NetworkPolicy in the 'db' namespace. Using `podSelector: {}` in the policy spec selects all pods in the 'db' namespace, and an ingress rule with a `namespaceSelector` matching the 'app' namespace (Option B) allows traffic from all pods in that namespace. Option A is incorrect because adding an empty `podSelector: {}` inside the ingress rule is either redundant (if evaluated as an AND condition) or opens up unintended access from all pods in the local 'db' namespace (if evaluated as an OR condition in separate block elements).

Answer

NetworkPolicy in namespace 'db' with podSelector: {} and ingress from namespace 'app' and podSelector: {}

Answer

NetworkPolicy in namespace 'app' with egress to namespace 'db' and podSelector: {}

Answer

NetworkPolicy in namespace 'app' allowing ingress from namespace 'db'

Question 12

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

Accepted Answer

kube-controller-manager. The control plane is the set of components that make global cluster decisions and store cluster state, so kube-controller-manager (B), kube-scheduler (C), and etcd (E) all qualify: kube-controller-manager runs the built-in controllers (e.g., node, replication, endpoints) that reconcile desired state, kube-scheduler assigns unscheduled Pods to nodes by filtering and scoring them, and etcd is the consistent, highly-available key-value store that persists all cluster data and is the source of truth for the API server. By contrast, kube-proxy (A) is a node-level component that programs iptables/IPVS rules to implement Service load balancing, and kubelet (D) is the node agent that registers the node and manages Pod lifecycle via the CRI, so both are data-plane/worker-node components rather than control plane components.

Answer

kube-proxy

Answer

kubelet

Question 13

Which THREE of the following are valid methods to authenticate to the Kubernetes API server? (Select 3)

Accepted Answer

Service account bearer tokens. Option A (Service account bearer tokens) is correct because Kubernetes automatically mounts a service account token into pods, and the API server validates these signed JWT bearer tokens via the ServiceAccount admission controller and TokenReview to authenticate in-cluster workloads. Option C (Static token file) is correct because the kube-apiserver supports the --token-auth-file flag, which references a CSV file of tokens, usernames, and UIDs that the API server accepts as bearer token credentials. Option E (X.509 client certificates) is correct because the API server authenticates clients presenting certificates signed by the cluster CA (configured via --client-ca-file), mapping the certificate's CN and O fields to a username and group. Option B (Anonymous requests) is not a valid authentication method in the sense of verifying identity—anonymous requests are unauthenticated and only allowed if --anonymous-auth is enabled and RBAC grants the system:anonymous user access. Option D (Password file with usernames and passwords) is not a supported authentication method; Kubernetes removed basic authentication, and the API server does not accept username/password credentials.

Answer

Anonymous requests

Answer

Password file with usernames and passwords

Question 14

Which TWO of the following are correct commands to view the current context in kubeconfig? (Select 2)

Accepted Answer

kubectl config current-context. Option C, `kubectl config current-context`, is correct because it is the dedicated subcommand that prints only the name of the context currently set as active in the kubeconfig file. Option E, `kubectl config view --minify`, is correct because it outputs the kubeconfig content restricted to the current context (plus its cluster and user), effectively showing the active context's configuration. Option A, `kubectl config get-contexts -o name`, lists the names of all contexts in the kubeconfig, not just the current one, so it does not specifically show the current context. Option B, `kubectl config view --context current`, is invalid because `--context` expects an actual context name and `current` is not a recognized keyword, so it would fail or reference a nonexistent context. Option D, `kubectl config get-contexts`, lists all contexts and merely marks the current one with an asterisk, which is not a command whose purpose is to display the current context alone.

Answer

kubectl config get-contexts -o name

Answer

kubectl config view --context current

Answer

kubectl config get-contexts

Question 15

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in a CrashLoopBackOff state with an 'OOMKilled' message, which indicates that the container's memory usage exceeded its configured memory limit, causing the kernel's Out-Of-Memory (OOM) killer to terminate the process. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly addressing the root cause of the crash loop.

Answer

Delete the namespace and redeploy all workloads

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container