Courseiva

CCNA Cluster Architecture, Installation and Configuration Questions

75 of 158 questions · Page 1/3 · Cluster Architecture, Installation and Configuration · Answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

What is the purpose of the kube-proxy component?

A.It proxies API requests to the kube-apiserver
B.It manages network rules for Services and endpoints
C.It stores cluster state
D.It schedules pods to nodes
AnswerB

kube-proxy implements the Service abstraction by writing network rules — typically iptables or IPVS — that distribute traffic destined for a Service's clusterIP among its backing Pod endpoints. It watches the API for Services and EndpointSlices, then updates these rules so that connections are load-balanced and reachable from within the cluster. This is the core purpose of the component.

Why this answer

B is correct because kube-proxy is the component responsible for implementing the network rules that enable Kubernetes Services to function. It runs on each node and maintains iptables or IPVS rules to route traffic to the correct backend Pods based on the Service's endpoints, handling load balancing and service discovery at the network layer.

Exam trap

The trap here is that candidates confuse kube-proxy with an API proxy or ingress controller, but kube-proxy specifically handles Service-level network rules at the node level, not application-layer routing or API request proxying.

How to eliminate wrong answers

Option A is wrong because proxying API requests to the kube-apiserver is the role of the kube-apiserver itself or an API proxy like kube-aggregator, not kube-proxy. Option C is wrong because storing cluster state is the function of etcd, a distributed key-value store, not kube-proxy. Option D is wrong because scheduling pods to nodes is the responsibility of the kube-scheduler, which uses resource requests and constraints to assign Pods, while kube-proxy only handles network traffic routing.

Practice this question →
2
MCQmedium

A node named 'worker-1' is unhealthy. You want to mark it as unschedulable and move workloads to other nodes. Which command sequence is correct?

A.kubectl uncordon worker-1; kubectl drain worker-1
B.kubectl cordon worker-1; kubectl drain worker-1
C.kubectl delete node worker-1; kubectl cordon worker-1
D.kubectl drain worker-1; kubectl cordon worker-1
AnswerB

This is the correct sequence because `kubectl cordon` immediately taints the node as unschedulable, ensuring no new workloads are assigned to it. Following this with `kubectl drain` safely evicts existing pods, forcing controllers to recreate them on healthy nodes. This orderly transition prevents race conditions where evicted pods are immediately rescheduled back onto the same failing node.

Why this answer

`kubectl cordon worker-1` marks the node as unschedulable, preventing new pods from being scheduled onto it, and `kubectl drain worker-1` safely evicts all existing pods from the node, respecting PodDisruptionBudgets and terminating pods gracefully. This sequence ensures workloads are moved to other nodes without disrupting running services.

Exam trap

The trap here is that candidates often confuse the order of `cordon` and `drain`, mistakenly thinking draining first is safe, but the CKA exam tests the understanding that cordoning must precede draining to prevent new pods from being scheduled onto the node during the eviction process.

How to eliminate wrong answers

Option A is wrong because `kubectl uncordon` makes a node schedulable, which is the opposite of what is needed for an unhealthy node. Option C is wrong because `kubectl delete node` removes the node from the cluster entirely, which is too aggressive and not required for simply moving workloads; also, cordoning after deletion is meaningless. Option D is wrong because draining a node before cordoning it can cause new pods to be scheduled onto the node during the drain process, defeating the purpose of moving workloads away.

Practice this question →
3
MCQmedium

During a cluster upgrade, what is the correct order of operations for upgrading a node?

A.Upgrade kubelet, drain the node, then uncordon
B.Drain the node, uncordon, then upgrade kubelet
C.Drain the node, upgrade kubelet and kube-proxy, then uncordon
D.Uncordon the node, drain, then upgrade
AnswerC

This sequence represents the official Kubernetes standard operating procedure for node upgrades to ensure zero-downtime. Draining safely evicts running pods to other nodes, upgrading the kubelet and kube-proxy updates the node's control plane components while idle, and uncordoning finally marks the upgraded node as schedulable again. This minimizes service disruption and maintains cluster stability.

Why this answer

During a node upgrade, the node must first be drained to safely evict all pods and ensure workloads are rescheduled. Then, the kubelet and kube-proxy (which run as system services) are upgraded to match the control plane version. Finally, the node is uncordoned to make it schedulable again, allowing new pods to be placed on it.

Exam trap

The trap here is that candidates may think uncordoning can be done before upgrading (options B and D) or that upgrading can precede draining (option A), but the CKA requires strict adherence to the drain-upgrade-uncordon sequence to maintain workload availability and version compatibility.

How to eliminate wrong answers

Option A is wrong because upgrading kubelet before draining the node can cause running pods to be disrupted or lost, as the kubelet restart may terminate them without proper eviction. Option B is wrong because uncordoning the node before upgrading kubelet would immediately schedule new pods onto a node with an outdated kubelet, violating version skew policies and risking incompatibility. Option D is wrong because uncordoning before draining defeats the purpose of draining, and upgrading before draining is unsafe; the correct sequence is drain, upgrade, then uncordon.

Practice this question →
4
MCQmedium

A new Kubernetes administrator runs 'kubeadm join --token <token> <control-plane-ip>:6443 --discovery-token-ca-cert-hash sha256:<hash>' on a worker node. The join fails with 'error execution phase preflight: couldn't validate the identity of the API Server'. What is the most likely cause?

A.The --discovery-token-ca-cert-hash value is incorrect
B.The token has expired
C.The kubelet is not running on the worker node
D.The API server is not reachable on port 6443
AnswerA

The --discovery-token-ca-cert-hash parameter provides a critical security measure by ensuring the joining node can securely verify the identity of the control plane's Certificate Authority. If this hash value is incorrect, the joining node cannot trust the CA certificate presented by the API server during the TLS handshake. This leads to the 'couldn't validate the identity' error, as the cryptographic proof of authenticity fails, preventing the secure establishment of communication.

Why this answer

The error 'couldn't validate the identity of the API Server' indicates that the CA certificate hash provided with --discovery-token-ca-cert-hash does not match the actual hash of the API server's CA certificate. This hash is used to verify the API server's identity during the TLS bootstrap process. An incorrect hash value will cause the preflight check to fail, as the worker node cannot confirm it is connecting to the legitimate control plane.

Exam trap

CNCF often tests the distinction between token expiration and CA hash mismatch, where candidates confuse a token-related error with a TLS validation error, but the specific phrase 'couldn't validate the identity of the API Server' directly points to the CA certificate hash being incorrect.

How to eliminate wrong answers

Option B is wrong because an expired token would cause a different error, such as 'token is invalid' or 'failed to request bootstrap token', not a failure to validate the API server's identity. Option C is wrong because if the kubelet were not running, the join command would fail with an error about the kubelet not being active or a connection refused, not a CA hash validation error. Option D is wrong because if the API server were unreachable on port 6443, the error would be a network timeout or connection refused, not a TLS identity validation failure.

Practice this question →
5
MCQeasy

Which command correctly backs up etcd data using etcdctl with API version 3?

A.ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db
B.etcdctl backup /backup/snapshot.db
C.etcdctl snapshot-backup /backup/snapshot.db
D.ETCDCTL_API=3 etcdctl --snapshot /backup/snapshot.db
AnswerA

This command correctly sets the environment variable `ETCDCTL_API=3` to enforce the use of the v3 API, which is mandatory for modern Kubernetes clusters. It then invokes the proper `snapshot save` subcommand to write a consistent point-in-time backup of the etcd database to the specified file path.

Why this answer

Etcdctl requires the environment variable `ETCDCTL_API=3` to use the v3 API, which supports the `snapshot save` command for creating a consistent point-in-time backup of etcd data. The command `ETCDCTL_API=3 etcdctl snapshot save /backup/snapshot.db` correctly specifies the API version and the subcommand to save a snapshot to the given file path.

Exam trap

The trap here is that candidates may confuse the deprecated v2 API `etcdctl backup` command with the v3 API `snapshot save` command, or incorrectly assume a flag like `--snapshot` can replace the required subcommand structure.

How to eliminate wrong answers

Option B is wrong because `etcdctl backup` is not a valid command in etcdctl v3; the `backup` subcommand existed in the deprecated v2 API but is not used for v3 snapshots. Option C is wrong because `etcdctl snapshot-backup` is not a recognized subcommand; the correct subcommand is `snapshot save`. Option D is wrong because `--snapshot` is not a valid flag for etcdctl; the correct syntax uses the `snapshot save` subcommand, not a flag.

Practice this question →
6
MCQeasy

Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?

A.kubelet
B.kube-scheduler
C.container runtime
D.kube-proxy
AnswerA

The kubelet is the Kubernetes node agent that runs on every node, including control-plane nodes. It registers the node with the API server, watches for Pod objects bound to that node, and continually drives the actual state of containers toward the desired PodSpec. It performs liveness, readiness, and startup probes and reports pod/node status back to the API server. Because it is the component that owns the pod lifecycle on a node, it is the only component in this list that is a required Kubernetes component on every node.

Why this answer

The kubelet is the primary node agent that runs on every node in a Kubernetes cluster. It is responsible for ensuring that containers described in PodSpecs are running and healthy by communicating with the container runtime via the CRI (Container Runtime Interface). Without the kubelet, no pod or container lifecycle management can occur on that node.

Exam trap

The trap here is that candidates confuse the container runtime (which actually runs containers) with the kubelet (which orchestrates them), leading them to pick 'container runtime' because they think it directly ensures containers are running, but the kubelet is the agent that manages the pod lifecycle and delegates to the runtime.

How to eliminate wrong answers

Option B (kube-scheduler) is wrong because it runs only on the control plane node and is responsible for assigning pods to nodes based on resource availability and constraints, not for running containers on each node. Option C (container runtime) is wrong because while it is present on every node and actually runs the containers, it does not manage pods or ensure containers are running; that orchestration is the kubelet's job, and the runtime only executes container commands. Option D (kube-proxy) is wrong because it runs on every node but handles network proxying and service load balancing, not container lifecycle management.

Practice this question →
7
MCQhard

You are setting up a new Kubernetes cluster using kubeadm. You run 'kubeadm init --pod-network-cidr=10.244.0.0/16' on the control plane node. The command fails with: '[preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running: output: time="..." level=fatal msg="validate service connection: CRI v1 runtime API is not implemented for endpoint 'unix:///var/run/containerd/containerd.sock': rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService'"'. What is the most likely cause?

A.The --pod-network-cidr flag is incorrect
B.The kubelet version is incompatible with containerd
C.The containerd runtime does not support the CRI v1 API; it may be an older version that only supports v1alpha2
D.The containerd service is not running
AnswerC

Modern Kubernetes releases require the Container Runtime Interface (CRI) v1 API to communicate with the container runtime. Older versions of containerd (prior to v1.6.0) only implement the deprecated v1alpha2 CRI API, causing the kubelet's initialization handshake to fail when it attempts to connect. Upgrading containerd to v1.6.0 or later, or correctly configuring its CRI plugin, is required to enable v1 API support.

Why this answer

The error message indicates that the containerd socket is reachable but the CRI v1 API (runtime.v1.RuntimeService) is not implemented. This typically occurs when containerd is an older version that only supports the CRI v1alpha2 API. Kubernetes 1.24+ defaults to the CRI v1 API, so an older containerd without v1 support will fail during kubeadm init.

Exam trap

The trap here is that candidates often assume the error means the container runtime is not running at all (Option D), but the detailed error message clearly indicates the socket is reachable and the issue is an API version mismatch, not a service outage.

How to eliminate wrong answers

Option A is wrong because the --pod-network-cidr flag is used for pod networking (e.g., Flannel) and does not affect CRI API version negotiation; a mismatch would cause a different error later, not a CRI preflight failure. Option B is wrong because the error is about the CRI API version, not kubelet version incompatibility; kubelet communicates with containerd via CRI, and version mismatches typically manifest as runtime communication errors, not an 'unimplemented' API error. Option D is wrong because the error explicitly shows the socket is reachable ('unix:///var/run/containerd/containerd.sock') and the service is responding, but the requested API version is not supported; if containerd were not running, the error would be 'connection refused' or 'no such file or directory'.

Practice this question →
8
MCQmedium

Which of the following YAML snippets correctly defines a Kubernetes Deployment with 3 replicas and a rolling update strategy?

A.apiVersion: extensions/v1beta1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate
B.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
C.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1
D.apiVersion: apps/v1 kind: Deployment metadata: name: my-deploy spec: replicas: 3 strategy: type: OnDelete
AnswerB

This YAML snippet correctly defines a Kubernetes Deployment. It utilizes the stable `apps/v1` API version, which is the standard for Deployments in current Kubernetes releases. Furthermore, it explicitly configures the `RollingUpdate` strategy with `maxUnavailable` and `maxSurge` parameters, ensuring a controlled and highly available update process by specifying how many pods can be unavailable or created beyond the desired replica count during an update.

Why this answer

It uses the stable `apps/v1` API version, specifies 3 replicas, and defines a `RollingUpdate` strategy with both `maxUnavailable` and `maxSurge` set to 1. This ensures that during an update, at most one Pod is unavailable and at most one extra Pod is created, maintaining application availability.

Exam trap

The trap here is that candidates often forget that `rollingUpdate` subfields must be properly nested under `strategy` and that `extensions/v1beta1` is deprecated, leading them to choose Option A or misindented Option C, while Option D tests confusion between Deployment and DaemonSet update strategies.

How to eliminate wrong answers

Option A is wrong because it uses the deprecated `extensions/v1beta1` API version, which is no longer supported in recent Kubernetes clusters and lacks the `rollingUpdate` subfields required for a complete rolling update configuration. Option C is wrong because the `rollingUpdate` field is empty and the `maxUnavailable` and `maxSurge` fields are incorrectly placed at the same indentation level as `strategy`, making them invalid YAML for the Deployment spec. Option D is wrong because it uses `type: OnDelete`, which is not a valid update strategy for Deployments; `OnDelete` is only used with DaemonSets, and Deployments require either `RollingUpdate` or `Recreate`.

Practice this question →
9
MCQmedium

A ClusterRole named 'pod-reader' exists that grants get, list, and watch permissions on pods. You want to bind this ClusterRole to a user 'john' in the 'development' namespace only. Which resource should you create?

A.RoleBinding 'john-pod-reader' in namespace 'development' referencing ClusterRole 'pod-reader' and user 'john'
B.Add user 'john' to the 'pod-reader' ClusterRole definition
C.Role 'pod-reader' in namespace 'development'
D.ClusterRoleBinding 'john-pod-reader' binding 'pod-reader' to user 'john'
AnswerA

This option correctly identifies the mechanism for granting namespace-specific permissions derived from a cluster-wide role. A RoleBinding created within the 'development' namespace, referencing the 'pod-reader' ClusterRole and the user 'john', effectively scopes the ClusterRole's permissions to only that specific namespace. This ensures 'john' can read pods exclusively within 'development', adhering to the principle of least privilege.

Why this answer

A RoleBinding in a specific namespace can reference a ClusterRole to grant its permissions only within that namespace. Since the requirement is to bind the existing 'pod-reader' ClusterRole to user 'john' exclusively in the 'development' namespace, a RoleBinding named 'john-pod-reader' in the 'development' namespace is the correct resource. This allows the ClusterRole's pod read permissions to be scoped down to a single namespace.

Exam trap

The trap here is that candidates often confuse ClusterRoleBinding with RoleBinding when binding a ClusterRole, forgetting that a ClusterRoleBinding grants cluster-wide access, while a RoleBinding scopes the ClusterRole's permissions to a single namespace.

How to eliminate wrong answers

Option B is wrong because ClusterRole definitions are non-namespaced and cannot include user bindings; users are bound via RoleBinding or ClusterRoleBinding objects, not by editing the ClusterRole itself. Option C is wrong because creating a new Role named 'pod-reader' in the 'development' namespace would duplicate the existing ClusterRole's rules and does not leverage the already defined ClusterRole, which is the intended resource. Option D is wrong because a ClusterRoleBinding grants permissions cluster-wide across all namespaces, which violates the requirement to restrict access to only the 'development' namespace.

Practice this question →
10
MCQmedium

A ClusterRoleBinding grants cluster-admin access to a user. Which field in the ClusterRoleBinding specifies the user?

A.users
B.subjects
C.roleRef
D.bindings
AnswerB

`subjects` is the field in a ClusterRoleBinding that defines who the binding applies to. Each entry in the `subjects` list is an object with a `kind` of `User`, `Group`, or `ServiceAccount`. For a cluster admin grant, you would include a subject like `{"kind": "User", "name": "alice", "apiGroup": "rbac.authorization.k8s.io"}`. This field is the only place where the user identity is attached to the binding, so it is the correct answer.

Why this answer

In Kubernetes RBAC, the `subjects` field in a ClusterRoleBinding (or RoleBinding) specifies the users, groups, or service accounts that the binding applies to. The `subjects` array contains objects with `kind`, `name`, and optionally `apiGroup` or `namespace`, allowing you to reference a specific user by name. Option B is correct because `subjects` is the only field that defines the identity of the principal receiving the permissions.

Exam trap

CNCF often tests the distinction between `subjects` (who gets the permissions) and `roleRef` (what permissions they get), and candidates mistakenly choose `users` because it sounds intuitive, but Kubernetes uses the generic `subjects` field to accommodate multiple identity types.

How to eliminate wrong answers

Option A is wrong because `users` is not a valid field in a ClusterRoleBinding; the correct field is `subjects`, which can include users, groups, or service accounts. Option C is wrong because `roleRef` specifies the ClusterRole (or Role) being bound, not the user; it references the role's name and API group. Option D is wrong because `bindings` is not a field in a ClusterRoleBinding; it is a general term for the RBAC resource itself, not a property within it.

Practice this question →
11
MCQeasy

Which of the following is NOT a control plane component in Kubernetes?

A.kube-scheduler
B.etcd
C.kube-proxy
D.kube-apiserver
AnswerC

kube-proxy is the correct answer because it is a node-level component that runs on every worker node, not on the control plane. Its job is to maintain network rules and handle traffic routing for Services, typically using iptables or IPVS, so it forwards requests to backend pods. Since it does not participate in cluster-wide control decisions, it is not a control plane component.

Why this answer

kube-proxy is not a control plane component; it is a node-level (worker) component responsible for implementing network rules and handling service-to-pod traffic via iptables or IPVS. The control plane consists of kube-apiserver, etcd, kube-scheduler, and kube-controller-manager.

Exam trap

The trap here is that candidates often confuse kube-proxy as a control plane component because it interacts with the API server and is essential for networking, but it operates at the node level and is not part of the control plane's core management functions.

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a core control plane component that assigns pods to nodes based on resource availability and constraints. Option B is wrong because etcd is the distributed key-value store that holds all cluster state and configuration data, making it a critical control plane component. Option D is wrong because kube-apiserver is the front-end of the control plane, exposing the Kubernetes API and handling all RESTful requests for cluster operations.

Practice this question →
12
MCQmedium

You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?

A.kubeadm upgrade plan
B.kubeadm upgrade apply v1.29.0
C.kubeadm upgrade node
D.kubeadm upgrade diff
AnswerA

Running `kubeadm upgrade plan` is the recommended first step when upgrading a Kubernetes control plane. This command analyzes your cluster to check if it can be upgraded, detects the current component versions, and displays the available target versions along with the exact configuration changes that will be applied. It ensures there are no version compatibility blockers before you commit to the actual upgrade process.

Why this answer

After upgrading kubeadm on the control plane node, the first command to run is `kubeadm upgrade plan`. This command checks the current cluster version, validates that the upgrade path is supported (e.g., from v1.28.0 to v1.29.0), and displays the available versions to upgrade to, along with any manual steps required. It is a prerequisite to ensure the upgrade is safe before proceeding with `kubeadm upgrade apply`.

Exam trap

The trap here is that candidates often confuse the sequence and jump directly to `kubeadm upgrade apply`, thinking it is the first step, but the CKA exam tests the prerequisite validation step (`kubeadm upgrade plan`) to ensure a safe upgrade process.

How to eliminate wrong answers

Option B is wrong because `kubeadm upgrade apply v1.29.0` should only be run after `kubeadm upgrade plan` has confirmed the upgrade path and there are no blockers; running it first could lead to an unsupported or failed upgrade. Option C is wrong because `kubeadm upgrade node` is used on worker nodes (or secondary control plane nodes) to upgrade the local kubelet and kube-proxy, not on the primary control plane node during the initial upgrade. Option D is wrong because `kubeadm upgrade diff` is not a valid kubeadm command; it does not exist in the kubeadm toolset and would result in an error.

Practice this question →
13
Multi-Selecthard

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

Select 2 answers
A.kubeadm certs renew all
B.kubeadm certs check-expiration
C.kubectl config view
D.kubeadm upgrade plan
E.kubectl cluster-info
AnswersA, B

This command performs a unified renewal of every Kubernetes certificate that kubeadm manages, including the API server, controller-manager, scheduler, and etcd certificates, plus the client certificates in kubeconfig files. It is the go-to action when certificates were created with default validity and need refreshing. After running it, the control plane components must be restarted to start using the new certificates.

Why this answer

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.

Exam trap

The trap here is that candidates confuse `kubeadm certs` subcommands with `kubectl` commands, mistakenly thinking `kubectl config view` or `kubectl cluster-info` can reveal certificate expiration, when in fact only `kubeadm` has direct access to the PKI files on the control plane node.

Practice this question →
14
MCQmedium

To make a node unschedulable without evicting existing pods, which command should be used?

A.kubectl cordon node01
B.kubectl taint node01 key=value:NoSchedule
C.kubectl drain node01
D.kubectl uncordon node01
AnswerA

kubectl cordon node01 sets the node's `spec.unschedulable` field to `true`, which tells the Kubernetes scheduler to skip this node for all future pod placements. Existing pods on the node are completely unaffected and continue to run normally, because cordon only flips a scheduling flag and does not interact with the kubelet or the pod lifecycle. This is the exact, and only, standard command for making a node unschedulable without evicting anything.

Why this answer

`kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the precise command for the task described, as it modifies the node's `spec.unschedulable` field to `true` without affecting running workloads.

Exam trap

The trap here is that candidates confuse taints (which control pod placement based on tolerations) with cordoning (which globally blocks all scheduling), or they mistakenly choose `drain` which evicts pods, missing the explicit 'without evicting existing pods' constraint.

How to eliminate wrong answers

Option B is wrong because `kubectl taint node01 key=value:NoSchedule` adds a taint that prevents new pods from being scheduled unless they tolerate the taint, but it does not make the node unschedulable globally; pods without tolerations are blocked, but the node remains schedulable for tolerating pods, and existing pods are unaffected. Option C is wrong because `kubectl drain node01` evicts all existing pods from the node (with graceful termination) and then cordons it, which violates the requirement to not evict pods. Option D is wrong because `kubectl uncordon node01` makes a node schedulable again, which is the opposite of the desired action.

Practice this question →
15
MCQmedium

An admin runs 'kubectl get pods' and sees a pod in the 'Pending' state. Which is the most likely cause?

A.The pod has been deleted
B.The pod is waiting for a container to start
C.The pod cannot be scheduled due to insufficient resources
D.The container image is invalid
AnswerC

The Pending phase most commonly indicates that the scheduler cannot find a suitable node to place the pod. The scheduler evaluates resource requests (CPU, memory, ephemeral storage) against the allocatable capacity and remaining availability of each node; if every node has insufficient available resources, the pod remains unscheduled and stuck in Pending. This is typically confirmed by describing the pod and observing events such as FailedScheduling.

Why this answer

A pod in 'Pending' state indicates that the pod has been accepted by the Kubernetes API server but is not yet running. The most common cause is that the scheduler cannot find a node that satisfies the pod's resource requests (CPU, memory) or other scheduling constraints (taints, node selector, affinity rules). This results in the pod remaining unscheduled, hence 'Pending'.

Exam trap

CNCF often tests the distinction between pod states: candidates confuse 'Pending' with image-related issues, but 'Pending' specifically means the pod has not been scheduled yet, whereas image errors occur after scheduling.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because waiting for a container to start is part of the normal pod lifecycle after scheduling, and the pod would be in 'ContainerCreating' or 'Running' state, not 'Pending'. Option D is wrong because an invalid container image would cause the pod to transition to 'ImagePullBackOff' or 'ErrImagePull' after scheduling, not remain in 'Pending'.

Practice this question →
16
MCQhard

You have a cluster with multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0 using kubeadm. What is the correct sequence of steps?

A.Upgrade kubeadm on the control plane node, upgrade control plane components, then drain and upgrade each worker node by upgrading kubelet and kubectl.
B.Upgrade kubeadm on the control plane node, then upgrade kubelet and kubectl on worker nodes, then upgrade kubelet and kubectl on control plane node.
C.Drain all nodes, upgrade kubelet and kubectl on all nodes, then upgrade kubeadm on the control plane node.
D.Upgrade kubelet and kubectl on all nodes first, then upgrade kubeadm on the control plane node.
AnswerA

This sequence precisely follows the official `kubeadm` upgrade procedure, ensuring cluster stability and minimal downtime. First, `kubeadm` itself is upgraded on the control plane to manage the new version. Then, the control plane components (API server, controller-manager, scheduler) are upgraded to establish the new cluster version. Finally, each worker node is individually drained to gracefully evict pods, upgraded by updating `kubelet` and `kubectl`, and then uncordoned, preventing a full cluster outage.

Why this answer

The official kubeadm upgrade workflow requires upgrading kubeadm first on the control plane node, then using `kubeadm upgrade apply` to upgrade control plane components, and finally draining and upgrading each worker node by updating kubelet and kubectl. This sequence ensures the cluster's management plane is updated before worker nodes, maintaining control plane stability and API compatibility during the rolling upgrade.

Exam trap

The trap here is that candidates often think upgrading kubelet and kubectl first is safe, but the CKA tests the understanding that kubeadm and control plane components must be upgraded before worker node binaries to maintain version compatibility and cluster stability.

How to eliminate wrong answers

Option B is wrong because upgrading kubelet and kubectl on worker nodes before upgrading control plane components can cause version mismatches, as the kubelet must be at most one minor version behind the kube-apiserver. Option C is wrong because draining all nodes before upgrading kubeadm on the control plane is unnecessary and disrupts workloads prematurely; kubeadm must be upgraded first to enable the upgrade command. Option D is wrong because upgrading kubelet and kubectl on all nodes before kubeadm prevents the control plane from orchestrating the upgrade, and the kubelet version must not exceed the kube-apiserver version.

Practice this question →
17
Multi-Selectmedium

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

Select 2 answers
A.kubectl create role pod-reader --verb=get,list --resource=pods -n default
B.kubectl create role pod-reader --verb=discover --resource=pods -n default
C.kubectl create role pod-reader --verb=delete --resource=pods -n default
D.Apply a YAML with apiVersion: rbac.authorization.k8s.io/v1, kind: Role, rules: [apiGroups: [""], resources: ["pods"], verbs: ["get", "list"]]
E.kubectl create clusterrole pod-reader --verb=get,list --resource=pods
AnswersA, D

This command imperatively creates a Role named pod-reader in the default namespace, explicitly selected with -n default. The verbs get and list are valid RBAC verbs that map to reading an individual Pod and enumerating all Pods, respectively. Because it targets the pods resource in the core API group and uses the create role subcommand, the resulting object is namespaced and applies only within that namespace.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse Role with ClusterRole, or assume that any verb like 'discover' is valid, or overlook that the question requires both 'get' and 'list' verbs specifically.

Practice this question →
18
MCQmedium

An administrator needs to allow a service account 'monitor-sa' in namespace 'monitoring' to read pods across all namespaces. Which RBAC resources should be created?

A.Create a ClusterRole with pod read permissions and a ClusterRoleBinding to monitor-sa
B.Create a ClusterRole with pod read permissions and a RoleBinding in each namespace
C.Create a Role in the monitoring namespace and a RoleBinding to monitor-sa
D.Create a Role with pod read permissions and a ClusterRoleBinding to monitor-sa
AnswerA

To grant cluster-wide read access to pods for a ServiceAccount, you must define a ClusterRole containing the get, list, and watch verbs for the pods resource. Binding this ClusterRole to the monitor-sa ServiceAccount using a ClusterRoleBinding applies these permissions globally across all namespaces in the cluster.

Why this answer

A ClusterRole is required because the service account needs to read pods across all namespaces, which is a cluster-scoped permission. A ClusterRoleBinding binds that ClusterRole to the service account 'monitor-sa', granting the permissions cluster-wide. This is the correct approach for cross-namespace access.

Exam trap

The trap here is that candidates often confuse Role vs ClusterRole scope, thinking a Role can be used with a ClusterRoleBinding or that multiple RoleBindings are the only way to achieve cross-namespace access.

How to eliminate wrong answers

Option B is wrong because creating a RoleBinding in each namespace would require manual creation and maintenance in every namespace, which is inefficient and error-prone; a ClusterRoleBinding achieves the same goal with a single resource. Option C is wrong because a Role is namespace-scoped and cannot grant permissions across multiple namespaces, so it would only allow reading pods in the 'monitoring' namespace. Option D is wrong because a Role is namespace-scoped and cannot be used with a ClusterRoleBinding; the binding expects a ClusterRole, not a Role, and the combination is invalid.

Practice this question →
19
MCQmedium

You are the administrator of a cluster that uses an external etcd cluster. The kube-apiserver manifest on the control-plane node contains the flag `--etcd-servers=https://10.0.0.5:2379`. You need to add a second etcd endpoint at `https://10.0.0.6:2379` to increase availability. Where should you make this change?

A.Modify the kube-apiserver's kubeconfig file at /etc/kubernetes/kube-apiserver.conf and add the endpoint under clusters.
B.Run `kubectl edit pod kube-apiserver-<node>` to modify the container arguments directly.
C.Update the etcd cluster configuration by running `etcdctl member update` on each etcd node.
D.Edit the kube-apiserver static Pod manifest in /etc/kubernetes/manifests/ and add the new endpoint to the --etcd-servers flag as a comma-separated value.
AnswerD

Static Pod manifests in /etc/kubernetes/manifests/ are the source of truth for control-plane components. Editing the kube-apiserver manifest and adding the second endpoint as a comma-separated value in --etcd-servers is the correct declarative approach; the kubelet will restart the Pod automatically.

Why this answer

Adding an etcd endpoint for the kube-apiserver requires editing the static Pod manifest and updating the --etcd-servers flag with a comma-separated list of endpoints. The kubelet watches the manifest directory and will restart the kube-apiserver Pod with the new configuration.

Exam trap

The trap here is assuming that static Pods can be modified through the Kubernetes API, when in fact they must be edited on the node's filesystem.

Practice this question →
20
MCQmedium

You are preparing to upgrade a Kubernetes cluster from v1.27 to v1.28 using kubeadm. What is the correct order of operations for upgrading the control plane nodes?

A.Upgrade all worker nodes first, then upgrade the control plane nodes.
B.Upgrade the first control plane node, then upgrade the remaining control plane nodes, then upgrade worker nodes.
C.Upgrade all nodes simultaneously by running kubeadm upgrade apply on all nodes at once.
D.Upgrade worker nodes, then upgrade the control plane nodes, then drain the worker nodes.
AnswerB

This sequence aligns with the official Kubernetes upgrade workflow using kubeadm. You must first run kubeadm upgrade apply on a primary control plane node to update cluster-wide configurations and the local control plane. Afterward, you execute kubeadm upgrade node on the remaining control plane instances before safely upgrading the worker nodes.

Why this answer

The recommended upgrade order for a kubeadm-managed cluster is to upgrade the first control plane node (using `kubeadm upgrade apply`), then the remaining control plane nodes (using `kubeadm upgrade node`), and finally the worker nodes. This ensures the cluster's control plane components (etcd, kube-apiserver, kube-controller-manager, kube-scheduler) are updated first, maintaining cluster stability and API server availability during the process.

Exam trap

The trap here is that candidates may think upgrading all nodes simultaneously is faster or that worker nodes should be upgraded first to avoid downtime, but the CKA expects strict adherence to the kubeadm upgrade workflow where control plane nodes must be upgraded before worker nodes.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before control plane nodes can cause incompatibility between the newer kubelet versions and the older kube-apiserver, leading to node registration or API communication failures. Option C is wrong because `kubeadm upgrade apply` is designed to be run on only one control plane node at a time; running it simultaneously on all nodes would cause race conditions and corrupt the cluster state. Option D is wrong because draining worker nodes before upgrading the control plane is unnecessary and inefficient; the correct sequence is to upgrade control plane nodes first, then drain and upgrade worker nodes.

Practice this question →
21
MCQeasy

What is the default port for the Kubernetes API server?

A.10250
B.8080
C.2379
D.6443
AnswerD

Kubernetes API server listens on TCP port 6443 by default for secure HTTPS traffic, which is the endpoint encoded in kubeconfig files and used by kubectl, controllers, and external clients. This port is enabled by default, uses TLS for encrypted communication, and can be overridden with the --secure-port flag on kube-apiserver. All core API requests, including authentication and RBAC enforcement, pass through this secure listener.

Why this answer

The Kubernetes API server defaults to port 6443 for secure HTTPS traffic. This is the standard port used by kubectl and other clients to communicate with the control plane over TLS-encrypted connections, as defined in the Kubernetes documentation and default kube-apiserver configuration.

Exam trap

The trap here is that candidates often confuse the deprecated insecure port 8080 with the default secure port 6443, especially if they have experience with older Kubernetes versions or minikube setups that might expose port 8080 locally.

How to eliminate wrong answers

Option A is wrong because port 10250 is the default port for the kubelet's HTTPS API, used for node-level operations and metrics, not the API server. Option B is wrong because port 8080 was the default insecure port for the API server in older versions (pre-1.0) and is now deprecated and disabled by default; modern clusters require TLS on 6443. Option C is wrong because port 2379 is the default client port for etcd, the key-value store used by Kubernetes, not the API server itself.

Practice this question →
22
MCQeasy

Which command initializes a Kubernetes control plane node using kubeadm?

A.kubeadm create
B.kubeadm setup
C.kubeadm start
D.kubeadm init
AnswerD

kubeadm init is the only correct command for initializing a Kubernetes control-plane node. It runs a battery of preflight checks, generates the certificate authority and component certificates, writes administrative kubeconfig files, and places static Pod manifests for the kube-apiserver, kube-controller-manager, and kube-scheduler. It also initializes a local etcd server by default, though you can configure it to use an external etcd cluster with a --config file. After successful initialization, 'kubeadm join' provides the token and CA hash needed to add worker nodes.

Why this answer

`kubeadm init` is the specific command used to bootstrap and initialize a Kubernetes control plane node. It performs pre-flight checks, generates certificates, creates the static Pod manifests for core control plane components (API server, controller manager, scheduler, etcd), and configures the admin kubeconfig file. This is the standard kubeadm workflow for setting up a new cluster.

Exam trap

The trap here is that candidates may confuse the generic 'init' verb with other common system administration commands like 'start' or 'setup', or they may mistakenly think 'create' is a valid kubeadm subcommand because other tools (e.g., `kubectl create`) use that verb.

How to eliminate wrong answers

Option A is wrong because `kubeadm create` is not a valid kubeadm subcommand; kubeadm does not have a 'create' verb for initializing nodes. Option B is wrong because `kubeadm setup` is not a valid kubeadm subcommand; the correct verb for initializing the control plane is 'init', not 'setup'. Option C is wrong because `kubeadm start` is not a valid kubeadm subcommand; kubeadm does not manage the lifecycle of running processes—it generates configuration and static manifests, leaving process management to the container runtime and kubelet.

Practice this question →
23
Multi-Selecthard

Which THREE are valid methods to provide authentication to the Kubernetes API server? (Select three.)

Select 3 answers
A.Username and password
B.Client certificates
C.ServiceAccount bearer tokens
D.Static token file
E.SSH keys
AnswersB, C, D

Client certificate authentication uses X.509 certificates signed by a certificate authority that the API server trusts (configured via --client-ca-file). When a user presents a certificate, the API server validates the signature, expiration, and key usage, and then extracts the Common Name as the username and Organization as the groups. This method is cryptographically strong, supports revocation through CRLs, and is one of the primary ways administrators and advanced users authenticate to the cluster.

Why this answer

Option B (Client certificates) is correct because the Kubernetes API server supports X.509 client certificate authentication via the --client-ca-file flag, where the certificate's CN becomes the username and O becomes the group. Option C (ServiceAccount bearer tokens) is correct because pods authenticate to the API server using ServiceAccount tokens mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, which are validated by the API server's service account token authenticator. Option D (Static token file) is correct because the API server can be configured with --token-auth-file to authenticate requests bearing a bearer token listed in a CSV token file.

Option A (Username and password) is not a valid API server authentication method — basic auth was removed in Kubernetes 1.19, so it no longer applies. Option E (SSH keys) is not valid because SSH keys are used for secure shell access to nodes, not for authenticating to the Kubernetes API server.

Exam trap

The trap here is that candidates may confuse SSH keys (used for node-level access) with client certificates or tokens used for API server authentication, or mistakenly think username/password is still a supported method in current Kubernetes versions.

Practice this question →
24
Multi-Selecthard

You need to prepare a worker node for maintenance. Which TWO actions should you perform? (Choose TWO.)

Select 2 answers
A.kubectl delete node <node>
B.kubectl uncordon <node>
C.kubectl drain <node> --ignore-daemonsets
D.kubectl cordon <node>
E.kubectl taint nodes <node> key=value:NoSchedule
AnswersC, D

kubectl drain <node> --ignore-daemonsets is a crucial command for preparing a node for maintenance. It safely evicts all user-managed pods from the specified node, relocating them to other available nodes in the cluster. The `--ignore-daemonsets` flag is essential because DaemonSets are designed to run one pod per node, and attempting to evict them would be futile and prevent the drain operation from completing. This ensures the node is clear of application workloads while allowing critical cluster services managed by DaemonSets to remain, facilitating a smooth maintenance window.

Why this answer

`kubectl drain` safely evicts all pods from a node before maintenance, and the `--ignore-daemonsets` flag is necessary because DaemonSet pods cannot be evicted (they are managed by the node controller). Option D is correct because `kubectl cordon` marks the node as unschedulable, preventing new pods from being scheduled onto it, which is a prerequisite before draining to avoid race conditions.

Exam trap

The trap here is that candidates often think `kubectl cordon` alone is sufficient for maintenance, but it only prevents new scheduling—it does not evict existing pods, so you must also drain the node to safely move workloads off.

Practice this question →
25
Multi-Selecteasy

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

Select 3 answers
A.etcd
B.kube-proxy
C.kubelet
D.kube-apiserver
E.container runtime
AnswersB, C, E

kube-proxy is a lightweight network proxy that runs on every node as a DaemonSet, implementing Kubernetes Service semantics by managing traffic rules via iptables, IPVS, or other compatible backends. Its core job is to translate a Service's virtual ClusterIP to the specific Pod endpoints selected by that Service, enabling automatic load balancing and service discovery across workers. A node without kube-proxy would fail to route service traffic, breaking connectivity to applications exposed through ClusterIP, NodePort, or LoadBalancer Services.

Why this answer

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.

Exam trap

CNCF often tests the misconception that etcd or kube-apiserver are distributed across all nodes, but in a standard Kubernetes cluster, they are strictly control plane components and never run on worker nodes.

Practice this question →
26
Multi-Selectmedium

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

Select 2 answers
A.The existing ClusterRole 'deployer'
B.Create a new ClusterRole with the same rules
C.RoleBinding in namespace 'app' referencing ClusterRole 'deployer' and ServiceAccount 'ci-cd'
D.ClusterRoleBinding with subject ServiceAccount 'ci-cd' in namespace 'app'
E.A Secret for the ServiceAccount
AnswersA, C

The ClusterRole 'deployer' is the correct object to rely on because it already encapsulates the exact permissions needed to create resources. In RBAC, a ClusterRole is a cluster-scoped set of rules, but it does not grant anything until referenced by a binding. Reusing this existing ClusterRole avoids duplicating rules and keeps permission definitions centralized, which is the recommended practice.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse RoleBinding and ClusterRoleBinding, thinking a ClusterRole must always be bound with a ClusterRoleBinding, but a RoleBinding can bind a ClusterRole to grant permissions only in a specific namespace.

Practice this question →
27
MCQmedium

You have a service account named 'my-sa' in the 'default' namespace. You want to mount its token into a pod automatically. Which field in the pod spec achieves this?

A.spec.serviceAccountName
B.spec.serviceAccount
C.spec.containers[].env[].valueFrom.secretKeyRef
D.spec.automountServiceAccountToken
AnswerA

The `spec.serviceAccountName` field within a Pod's definition is the precise mechanism for explicitly associating a Pod with a specific Kubernetes ServiceAccount. When this field is set, Kubernetes ensures that the specified ServiceAccount's token is automatically mounted into the Pod at `/var/run/secrets/kubernetes.io/serviceaccount`, providing the Pod with the necessary credentials to interact with the Kubernetes API server. This direct linkage is crucial for granting Pods specific permissions defined by role bindings to that ServiceAccount.

Why this answer

Setting `spec.serviceAccountName` to 'my-sa' in the pod spec automatically mounts the service account token as a volume at `/var/run/secrets/kubernetes.io/serviceaccount/`. This is the standard way to associate a service account with a pod, and Kubernetes automatically handles token projection and mounting for that service account.

Exam trap

The trap here is that candidates confuse `spec.serviceAccountName` with the deprecated `spec.serviceAccount` field, or think that `spec.automountServiceAccountToken` alone is sufficient to mount a specific service account's token, when it only controls the mounting behavior for the default service account.

How to eliminate wrong answers

Option B is wrong because `spec.serviceAccount` is a deprecated field (removed in Kubernetes 1.24+) that previously served the same purpose as `spec.serviceAccountName`, but it is no longer recommended and may not be recognized in current API versions. Option C is wrong because `spec.containers[].env[].valueFrom.secretKeyRef` is used to inject a specific secret key as an environment variable, not to automatically mount the service account token; it requires manual creation of a token secret and does not leverage automatic token mounting. Option D is wrong because `spec.automountServiceAccountToken` is a boolean field that controls whether the default service account token is automatically mounted (defaults to true), but it does not specify which service account to use; it only enables or disables the automatic mounting behavior.

Practice this question →
28
MCQmedium

An administrator needs to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. Which of the following steps is performed FIRST?

A.Run 'kubeadm upgrade plan' on the first control plane node
B.Drain all worker nodes
C.Run 'kubectl cordon' on all nodes
D.Upgrade kubelet on the first control plane node
AnswerA

Running 'kubeadm upgrade plan' on the first control plane node is the correct initial step because it checks the current cluster version, validates that the upgrade path is supported, and lists the available kubeadm versions and the components (etcd, control plane, kubelet) that will be upgraded, along with any manual steps required. It also verifies that the node is healthy and gives you a preview of the exact upgrade commands, making it a safe, non-destructive first action before any draining or version changes.

Why this answer

Before any upgrade operations, kubeadm requires an assessment of the cluster's upgrade path and potential issues. 'kubeadm upgrade plan' on the first control plane node checks the current and target versions, validates the upgrade feasibility, and displays the upgrade steps and any manual interventions needed. This must be done first to ensure the upgrade is safe and to identify any version skew or configuration problems before proceeding.

Exam trap

The trap here is that candidates often assume draining or cordoning nodes is the first step, but the CKA exam emphasizes that the upgrade plan must be run first to validate the upgrade path and avoid irreversible errors.

How to eliminate wrong answers

Option B is wrong because draining worker nodes is a later step, performed after the control plane components have been upgraded to avoid disrupting workloads prematurely. Option C is wrong because 'kubectl cordon' marks nodes as unschedulable, but this is typically done per node during the upgrade process, not as the first step across all nodes; the initial step is to assess the upgrade plan. Option D is wrong because upgrading kubelet on the first control plane node happens after the control plane components (kube-apiserver, etc.) have been upgraded via kubeadm, and after the upgrade plan has been reviewed.

Practice this question →
29
MCQhard

An admin attempts to restore an etcd snapshot using 'etcdctl snapshot restore' but encounters an error. Which environment variable must be set for etcdctl to work with v3 API?

A.ETCD_API=3
B.ETCDCTL_API=v3
C.ETCDCTL_API=3
D.ETCDCTL_VERSION=3
AnswerC

etcdctl defaults to the v2 API unless told otherwise, so snapshot restore against a v3 data directory fails. Setting ETCDCTL_API=3 forces etcdctl to speak the v3 API, matching the cluster's etcd version and allowing the restore to proceed.

Why this answer

Etcdctl uses the etcd v2 API by default, and to interact with the v3 API (which is the standard for etcd v3.x clusters), the environment variable `ETCDCTL_API=3` must be set. Without this variable, `etcdctl snapshot restore` will fail as it relies on v3-specific commands and data model.

Exam trap

The trap here is that candidates often confuse the variable name (`ETCDCTL_API` vs `ETCD_API`) or the value format (`3` vs `v3`), leading them to pick a syntactically similar but incorrect option.

How to eliminate wrong answers

Option A is wrong because the environment variable is `ETCDCTL_API`, not `ETCD_API`; `ETCD_API` is not a recognized variable by etcdctl. Option B is wrong because the value must be `3` (integer), not `v3`; etcdctl expects a numeric string for the API version. Option D is wrong because `ETCDCTL_VERSION` is not a valid environment variable; etcdctl uses `ETCDCTL_API` to select the API version, not a version string.

Practice this question →
30
MCQmedium

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?

A.Increase the CPU request for the container
B.Delete and recreate the pod to clear the crash loop
C.Delete the namespace and redeploy all workloads
D.Increase the memory limit in the pod's container resource specification
AnswerD

An OOMKilled event directly indicates that the container attempted to consume more memory than specified by its `resources.limits.memory` configuration, leading the operating system to terminate the process. Increasing this memory limit in the pod's container specification provides the application with more available RAM, thereby preventing the Out-Of-Memory termination and allowing the pod to run stably without crashing. This directly addresses the root cause of the CrashLoopBackOff.

Why this answer

The 'OOMKilled' status indicates that the container was terminated because it exceeded its memory limit. Since the pod ran successfully for days before crashing, the most likely cause is a memory leak or increased workload demand. Increasing the memory limit in the container's resource specification allows the pod to use more memory without being killed, directly addressing the root cause.

Exam trap

The trap here is that candidates might confuse CPU and memory resource issues, or think that restarting the pod will fix the problem, when in fact the OOMKilled status requires adjusting the memory limit or fixing the application's memory usage.

How to eliminate wrong answers

Option A is wrong because increasing CPU requests does not affect memory constraints; OOMKilled is a memory issue, not a CPU issue. Option B is wrong because deleting and recreating the pod will not resolve the underlying memory limit problem; the pod will crash again once it exceeds the same limit. Option C is wrong because deleting the entire namespace is an extreme and unnecessary action that disrupts all workloads, and it does not fix the specific memory limit configuration for the pod.

Practice this question →
31
Multi-Selectmedium

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

Select 2 answers
A.container runtime
B.kube-apiserver
C.kube-scheduler
D.kubelet
E.kube-proxy
AnswersB, C

The kube-apiserver is the front end of the Kubernetes control plane, exposing the Kubernetes API and acting as the primary interface for all cluster management. It validates and processes RESTful requests, persists state to etcd, and coordinates communication between control plane and worker nodes via controllers and other components. Without it, no kubectl command or cluster operation could be executed, making it the core gateway of the control plane.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse node-level components (kubelet, kube-proxy, container runtime) with control plane components, especially because kubelet and kube-proxy are critical for cluster operation but run on every node, not just the control plane.

Practice this question →
32
MCQmedium

A Kubernetes cluster was upgraded from v1.28 to v1.29. After the upgrade, nodes report NotReady. You check kubelet logs and see: 'error: failed to run Kubelet: misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs"'. What is the most likely cause?

A.The container runtime version is incompatible with Kubernetes v1.29
B.The kubelet cannot connect to the API server
C.The kubelet was not restarted after the upgrade
D.The kubelet configuration has a different cgroup driver than the container runtime
AnswerD

Kubernetes strictly requires that the kubelet and the underlying container runtime (e.g., containerd, CRI-O) utilize the identical cgroup driver, either `systemd` or `cgroupfs`, for proper resource management and isolation. When the kubelet is configured to use one driver (e.g., `systemd`) and the container runtime is configured for another (e.g., `cgroupfs`), this fundamental mismatch prevents the kubelet from effectively managing pod resources, leading to critical operational failures.

Why this answer

The error message explicitly states that the kubelet's cgroup driver (systemd) differs from the container runtime's cgroup driver (cgroupfs). In Kubernetes, the kubelet and the container runtime must use the same cgroup driver to manage resource limits correctly. After upgrading from v1.28 to v1.29, the kubelet configuration may have been reset or changed, causing this mismatch, which prevents the kubelet from starting and the node from becoming Ready.

Exam trap

The trap here is that candidates may think the error is about API server connectivity or runtime version compatibility, but the specific error message directly points to a cgroup driver mismatch, which is a common misconfiguration after upgrades.

How to eliminate wrong answers

Option A is wrong because the error is about cgroup driver mismatch, not runtime version incompatibility; Kubernetes v1.29 supports Docker via cri-dockerd, and the runtime version is not the issue. Option B is wrong because the kubelet fails to start before it can even attempt to connect to the API server; the error occurs during kubelet initialization, not during API communication. Option C is wrong because the kubelet was restarted as part of the upgrade process (the error appears in its logs), and restarting alone would not fix a configuration mismatch; the issue is the configuration itself, not the lack of a restart.

Practice this question →
33
Multi-Selectmedium

Which TWO of the following are responsibilities of the kube-controller-manager?

Select 2 answers
A.Monitoring Pod status and ensuring the desired number of replicas are running.
B.Maintaining network rules on nodes.
C.Assigning Pods to nodes based on resource availability.
D.Managing cloud provider-specific resources like load balancers.
E.Managing endpoints for Services.
AnswersA, E

This is the core responsibility of the ReplicaSet controller within the kube-controller-manager. It continuously watches Pod state through the API server, and when actual replicas differ from the desired count—due to failures, scaling, or deletion—it creates or terminates Pods to reconcile the cluster to the declarative spec. This is a classic example of a controller using the control loop pattern, and it is exactly the kind of work the kube-controller-manager performs.

Why this answer

Option A is correct because the kube-controller-manager runs the ReplicaSet (and ReplicationController) controller, which continuously watches Pod status via the API server and creates or deletes Pods so that the actual number of replicas matches the desired count in the spec. Option E is correct because the kube-controller-manager also runs the endpoints controller (and endpointslice controller), which populates Endpoints/EndpointSlice objects for Services by tracking the readiness and IP addresses of the Pods selected by each Service's selector. Option B is wrong because maintaining network rules on nodes is the job of the kube-proxy component, not the kube-controller-manager.

Option C is wrong because assigning Pods to nodes is the responsibility of the kube-scheduler, which filters and scores nodes based on resource availability and constraints. Option D is wrong because managing cloud provider-specific resources such as load balancers is handled by the cloud-controller-manager (cloud controller manager), which was split out from the kube-controller-manager.

Exam trap

The trap here is that candidates often confuse the responsibilities of the kube-controller-manager with those of the kube-scheduler or kube-proxy, especially because all three components run on the control plane and interact with the API server.

Practice this question →
34
MCQeasy

Which command initializes a new Kubernetes control plane node using kubeadm?

A.kubeadm bootstrap
B.kubeadm create cluster
C.kubeadm init
D.kubeadm start
AnswerC

kubeadm init is the correct command because it initializes a new Kubernetes control-plane node. It performs preflight checks, creates the cluster's certificate authority and signed certificates, generates kubeconfig files for admin and system components, and writes static pod manifests for kube-apiserver, kube-controller-manager, kube-scheduler, and etcd to /etc/kubernetes/manifests. After these steps, it optionally configures a bootstrap token and prints a `kubeadm join` command for worker nodes. This is the standard, supported way to bring up the control plane when using kubeadm.

Why this answer

The correct command to initialize a new Kubernetes control plane node using kubeadm is `kubeadm init`. This command runs the bootstrap process that sets up the control plane components (API server, controller manager, scheduler, etcd) and generates the join token for worker nodes. It is the standard, documented command in the Kubernetes documentation for initializing a control plane node.

Exam trap

The trap here is that candidates may confuse `kubeadm init` with other common cluster creation commands (like `kubeadm bootstrap` or `kubeadm create cluster`) because they sound intuitive, but only `kubeadm init` is the correct, official subcommand for initializing the control plane.

How to eliminate wrong answers

Option A is wrong because `kubeadm bootstrap` is not a valid kubeadm command; the correct subcommand for initializing the control plane is `init`, and `bootstrap` is used in other contexts (e.g., TLS bootstrap for kubelet). Option B is wrong because `kubeadm create cluster` is not a valid kubeadm command; kubeadm uses `init` for control plane setup and `join` for adding nodes, not a `create cluster` subcommand. Option D is wrong because `kubeadm start` is not a valid kubeadm command; kubeadm does not have a `start` subcommand—it relies on `init` and `join` for cluster lifecycle, and systemd or kubelet handles starting components.

Practice this question →
35
MCQmedium

A developer is creating a Pod with a single container that should restart only if the process exits with non-zero. Which restartPolicy should be used?

A.Never
B.Always
C.UnlessStopped
D.OnFailure
AnswerD

OnFailure: This policy restarts the container only when the process exits with a non-zero code, which matches the requirement exactly. Since Kubernetes 1.15, Deployments allow this policy.

Why this answer

In Kubernetes, the `restartPolicy` for a Pod controls container restart behavior. The requirement is to restart only when the process exits with a non-zero code, which is exactly what `OnFailure` does. `Always` restarts on any exit (zero or non-zero), `Never` does not restart at all, and `UnlessStopped` is not a valid Kubernetes restart policy (it is a Docker restart policy). Note that while Pods and Jobs support `OnFailure`, workloads like Deployments, StatefulSets, and DaemonSets only support `Always`.

Exam trap

Candidates often confuse Docker restart policies (like `unless-stopped`) with Kubernetes restart policies. Kubernetes only supports `Always`, `OnFailure`, and `Never`. Another major trap is forgetting that Deployments only support `Always`; if you need `OnFailure` or `Never` behavior, you must use a Pod or a Job.

How to eliminate wrong answers

Option A (Never) is wrong because it prevents any restart, even on non-zero exit, which does not meet the requirement of restarting on failure. Option C (UnlessStopped) is not a valid Kubernetes restartPolicy; the valid values are Always, OnFailure, and Never. Option D (OnFailure) is wrong because it restarts only when the container exits with a non-zero code, but the question specifies the container should restart only if the process exits with non-zero, which is exactly what OnFailure does — however, the correct answer is B (Always) because the question states 'should restart only if the process exits with non-zero' and the provided correct answer is B, indicating a misinterpretation: the developer wants restart on non-zero, but the Deployment's default and required policy for replica management is Always, which also covers non-zero exits.

Practice this question →
36
MCQhard

You are troubleshooting a pod that is in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.' What is the most likely cause?

A.The pod requires more CPU than any node can provide
B.The pod is using a hostPort that conflicts with another pod
C.The pod has a node selector that doesn't match any node
D.The pod is trying to schedule on the master node which has a taint that is not tolerated
AnswerD

Control plane nodes are typically configured with a default taint, such as node-role.kubernetes.io/control-plane:NoSchedule, to prevent user workloads from consuming critical system resources. For a pod to successfully schedule onto such a node, its specification must explicitly define a matching toleration, otherwise, it remains in a Pending state with a taint-related scheduling event.

Why this answer

The pod is in 'Pending' state because none of the three nodes are schedulable for it. The 'kubectl describe pod' event explicitly states that all three nodes have the taint 'node-role.kubernetes.io/master: ' and the pod does not have a corresponding toleration. Master nodes are typically tainted to prevent general workloads from scheduling on them, so a pod without a toleration for that taint cannot be placed on any master node, leaving zero available nodes.

Exam trap

The trap here is that candidates often confuse taints/tolerations with node selectors or resource constraints, but the event message directly identifies the taint as the cause, making D the only correct answer.

How to eliminate wrong answers

Option A is wrong because the event message does not mention insufficient CPU or any resource shortage; it specifically cites taints and tolerations. Option B is wrong because a hostPort conflict would produce a different event, such as 'hostPort conflict' or 'failed to find port', not a taint-related message. Option C is wrong because a node selector mismatch would generate an event like '0/3 nodes are available: 3 node(s) didn't match node selector', not a taint-based message.

Practice this question →
37
MCQmedium

You are upgrading a cluster from v1.28 to v1.29. You have already drained and upgraded all worker nodes. The control plane nodes have not been upgraded yet. 'kubectl get nodes' shows the control plane nodes are still v1.28. What is the correct next step?

A.Drain the worker nodes and downgrade them to v1.28
B.Uncordon the worker nodes
C.Upgrade the control plane nodes to v1.29
D.Restart the kubelet on all nodes
AnswerC

Kubernetes upgrade best practices mandate that the control plane components, particularly the kube-apiserver, must be at a version equal to or higher than the kubelet running on worker nodes. Since the worker nodes have already been upgraded to v1.29, the immediate and correct next step is to upgrade the control plane nodes to v1.29. This action ensures API compatibility, allowing the kube-apiserver to properly communicate with and manage the newer kubelet versions, thereby preventing critical API mismatches and maintaining cluster health.

Why this answer

The correct next step is to upgrade the control plane nodes to v1.29. In a Kubernetes cluster upgrade, the control plane must be upgraded before or in conjunction with the worker nodes, but since the worker nodes have already been upgraded and drained, the control plane nodes are still running v1.28. Upgrading the control plane nodes ensures that the API server, scheduler, and controller manager are at the target version, which is required for cluster stability and to support the upgraded kubelets on the worker nodes.

Exam trap

The trap here is that candidates may think uncordoning worker nodes is safe after draining, but the CKA exam tests the understanding that the control plane must be upgraded before worker nodes are made schedulable again to avoid version skew issues.

How to eliminate wrong answers

Option A is wrong because draining and downgrading the worker nodes to v1.28 would undo the upgrade progress and is unnecessary; the worker nodes are already at the target version and should remain upgraded. Option B is wrong because uncordoning the worker nodes before the control plane is upgraded would allow pods to be scheduled onto nodes running a newer kubelet than the control plane, which can cause compatibility issues and is not recommended; the control plane must be upgraded first. Option D is wrong because restarting the kubelet on all nodes does not change the version of the control plane components; the kubelet version is already correct on worker nodes, and the control plane needs a deliberate upgrade process, not a restart.

Practice this question →
38
MCQmedium

You run `kubectl get pods` and get an error: 'error: You must be logged in to the server (Unauthorized)'. What is the most likely cause?

A.The kubeconfig file is missing or invalid.
B.The API server is not running.
C.The pod does not exist.
D.The namespace does not exist.
AnswerA

The error "error you must be logged in to the server (Unauthorized)" or similar, which is implied by the truncated prompt, directly indicates an authentication failure. This occurs when kubectl cannot successfully present valid credentials to the Kubernetes API server, most commonly because the kubeconfig file is either missing, corrupted, or contains incorrect cluster addresses, user certificates, or authentication tokens. Without a valid kubeconfig, the client cannot establish an authenticated session.

Why this answer

The error 'You must be logged in to the server (Unauthorized)' indicates that the kubectl client successfully reached the API server, but the request was rejected because the client's credentials (typically from the kubeconfig file) are missing, expired, or invalid. The kubeconfig file contains the cluster, user, and context information required for authentication; if it is misconfigured or not present, kubectl cannot authenticate and returns this specific HTTP 401 Unauthorized error.

Exam trap

The trap here is that candidates confuse authentication errors (401 Unauthorized) with connectivity errors (connection refused) or authorization errors (403 Forbidden), leading them to incorrectly suspect the API server is down or a resource is missing.

How to eliminate wrong answers

Option B is wrong because if the API server were not running, kubectl would return a connection refused or timeout error (e.g., 'Unable to connect to the server'), not an authentication error. Option C is wrong because the error occurs before any pod-specific operation; the client cannot even list pods due to authentication failure, so the existence of a pod is irrelevant. Option D is wrong because the error is about authentication, not authorization to a namespace; a missing namespace would cause a different error like 'namespace not found' or 'the server could not find the requested resource', not an Unauthorized response.

Practice this question →
39
MCQhard

A user reports that they cannot access a Service of type ClusterIP from within the cluster. The Service selects pods that are running and responding. Which of the following is the MOST likely cause?

A.The Service's port does not match the container's containerPort
B.The Service type is NodePort instead of ClusterIP
C.The Service's targetPort does not match the container's containerPort
D.The Service selector does not match any pod labels
AnswerC

The `Service.spec.targetPort` is the critical configuration that directs incoming traffic from the Service to a specific port on the Pod's containers. If this `targetPort` value does not precisely match the port number or named port that the application inside the container is actually listening on, the traffic will be misrouted within the Pod. Consequently, the application will not receive the incoming requests, leading to the user experiencing an inaccessible service.

Why this answer

The Service's `targetPort` must match the `containerPort` defined in the pod's container spec. Even if the pods are running and responding, if the `targetPort` points to a different port than the one the container is listening on, traffic will be forwarded to the wrong port and the connection will fail. The `port` field on the Service is the port the Service itself listens on, while `targetPort` is the port on the pod where traffic is actually sent.

Exam trap

The trap here is that candidates confuse the Service's `port` (the cluster-facing port) with the `targetPort` (the pod-facing port), and incorrectly assume the `port` must match the container's `containerPort`, leading them to choose Option A instead of C.

How to eliminate wrong answers

Option A is wrong because the Service's `port` does not need to match the container's `containerPort`; the `port` is the Service's own listening port, and traffic is forwarded to the `targetPort`. Option B is wrong because a Service of type NodePort still works for internal cluster access (it also gets a ClusterIP), so changing the type to NodePort would not cause a failure to access from within the cluster. Option D is wrong because the question explicitly states that the Service selects pods that are running and responding, meaning the selector matches the pod labels correctly.

Practice this question →
40
MCQmedium

You run 'kubectl get nodes' and see that one node is marked as 'NotReady'. Which component is likely failing on that node?

A.kube-proxy
B.kube-scheduler
C.kubelet
D.container runtime (e.g., containerd)
AnswerC

The kubelet is the primary agent that runs on each worker node and is responsible for registering the node with the API server, ensuring that containers are running in a Pod, and continuously monitoring the node's health and resources. It reports this critical information back to the Kubernetes control plane. If the kubelet itself fails, stops communicating with the API server, or cannot perform its duties (e.g., due to resource exhaustion or internal errors), the control plane will mark that specific node as NotReady because it can no longer receive reliable status updates or manage pods on it.

Why this answer

The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and reporting its status via periodic heartbeats (NodeStatus updates). When a node is marked as 'NotReady', it means the kubelet has failed to send these heartbeats to the control plane (specifically, the node controller) within the --node-monitor-grace-period (default 40s), indicating the kubelet process is likely down, unresponsive, or misconfigured.

Exam trap

The trap here is that candidates often confuse the container runtime (e.g., containerd) as the direct cause of node unreadiness, but the kubelet is the component that reports the node condition, and a runtime failure would manifest as a kubelet-level error (e.g., 'runtime network not ready') rather than a missing heartbeat.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node to manage network rules (e.g., iptables/IPVS) for Services; its failure would cause connectivity issues to pods/services but does not affect the node's readiness status reported by the kubelet. Option B is wrong because kube-scheduler is a control plane component that runs on the master node(s) and is responsible for assigning pods to nodes; it does not run on worker nodes and has no role in reporting node health. Option D is wrong because while a failing container runtime (e.g., containerd, CRI-O) can prevent pods from starting and may eventually cause the kubelet to mark the node as NotReady, the immediate and direct cause of the 'NotReady' status is the kubelet's failure to report its heartbeat; the kubelet itself is the component that detects runtime failures and updates the node condition accordingly.

Practice this question →
41
MCQhard

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate'. What does this indicate?

A.The pod has been successfully scheduled to the node
B.The node has insufficient resources and is tainted
C.The node is not reachable by the control plane
D.The node does not exist
AnswerC

The node.kubernetes.io/unreachable taint is set by the node controller when it stops receiving heartbeats from the kubelet, meaning the control plane can no longer reach or manage the node. Pods without a matching toleration are blocked from scheduling onto that node, leaving them Pending. This matches the kubectl describe output showing an unreachable taint, confirming the root cause is loss of control-plane connectivity to the node.

Why this answer

The error message indicates that the node has a taint of `node.kubernetes.io/unreachable`, which is automatically added by the node controller when the control plane cannot communicate with the node (e.g., due to network failure or kubelet being down). The pod remains in 'Pending' because no node is available that tolerates this taint, meaning the node is unreachable from the control plane. This matches option C.

Exam trap

The trap here is that candidates often confuse taints related to resource pressure (like memory or disk) with the unreachable taint, or assume 'Pending' means the pod is scheduled but waiting for resources, when in fact the specific taint name directly indicates a node reachability issue.

How to eliminate wrong answers

Option A is wrong because a pod in 'Pending' state has not been scheduled to any node; successful scheduling would show a node name in the pod status. Option B is wrong because the taint `node.kubernetes.io/unreachable` is not related to resource insufficiency; resource issues would show taints like `node.kubernetes.io/disk-pressure` or `node.kubernetes.io/memory-pressure`, and the error would mention insufficient resources, not unreachability. Option D is wrong because the error explicitly states '1 node(s) had taint', confirming the node exists but is unreachable; a non-existent node would not appear in the node list or would show a different error like 'node not found'.

Practice this question →
42
MCQhard

An administrator is setting up RBAC to allow a CI/CD pipeline to create and delete pods only in the 'ci' namespace. Which combination of resources should be created?

A.Role and RoleBinding
B.ClusterRole and RoleBinding
C.ClusterRole and ClusterRoleBinding
D.Role and ClusterRoleBinding
AnswerA

This combination is the correct and most granular approach for granting permissions within a specific namespace. A `Role` defines a set of permissions (e.g., create pods, list deployments) that are strictly confined to the namespace where the `Role` is created. Subsequently, a `RoleBinding` links this namespace-scoped `Role` to a specific subject, such as a service account used by a CI/CD pipeline, thereby granting those defined permissions exclusively within that particular namespace. This adheres to the principle of least privilege by preventing unintended access to other parts of the cluster.

Why this answer

A Role and RoleBinding are the correct combination because the CI/CD pipeline needs to create and delete pods only within the 'ci' namespace. A Role defines permissions scoped to a specific namespace, and a RoleBinding grants those permissions to a user or service account within that same namespace. This ensures the pipeline cannot affect resources in other namespaces.

Exam trap

The trap here is that candidates often assume a ClusterRole is always needed for any pipeline or service account, but for namespace-scoped resources, a Role and RoleBinding are sufficient and more secure, and the exam tests understanding of scope versus permissions.

How to eliminate wrong answers

Option B is wrong because a ClusterRole is cluster-scoped and, when used with a RoleBinding, can grant permissions across namespaces if the ClusterRole references cluster-scoped resources; however, for namespace-scoped resources like pods, a Role is more restrictive and appropriate. Option C is wrong because a ClusterRoleBinding grants permissions cluster-wide, which would allow the pipeline to create and delete pods in all namespaces, violating the requirement to restrict access to the 'ci' namespace only. Option D is wrong because a Role cannot be bound with a ClusterRoleBinding; a RoleBinding is required to bind a Role to a subject within a namespace.

Practice this question →
43
MCQmedium

A cluster has multiple kubeconfig files. You want to set the current context to 'admin@production' for all future kubectl commands. Which command should you run?

A.kubectl config set-context admin@production
B.kubectl config use-context admin@production
C.kubectl config set-cluster admin@production
D.kubectl config get-contexts admin@production
AnswerB

This command directly updates the `current-context` field in your active kubeconfig file to `admin@production`. Once executed, all subsequent `kubectl` commands will target the cluster and use the user credentials defined within this specific context, making it the correct choice for switching active environments.

Why this answer

The `kubectl config use-context` command is used to set the current context in a kubeconfig file, which determines the cluster, user, and namespace that kubectl will use by default for all subsequent commands. Option B correctly specifies `admin@production` as the context to switch to, making it the active context for future kubectl operations.

Exam trap

The trap here is that candidates confuse `set-context` (which only defines or updates a context entry) with `use-context` (which actually switches the active context), leading them to select option A.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-context` creates or modifies a context entry in the kubeconfig file but does not set it as the current context; it only defines or updates the context's properties (cluster, user, namespace). Option C is wrong because `kubectl config set-cluster` modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, not a context or the current context. Option D is wrong because `kubectl config get-contexts` lists all available contexts or shows details for a specific context, but it does not change the active context.

Practice this question →
44
MCQeasy

What is the purpose of the kube-proxy component in a Kubernetes cluster?

A.It provides network proxy and load balancing for services
B.It schedules pods to nodes
C.It manages the lifecycle of pods
D.It stores cluster configuration data
AnswerA

kube-proxy watches the Kubernetes API for Services and EndpointSlices, then programs node-level iptables or IPVS rules so that traffic to a Service's ClusterIP is DNATed to healthy backend Pod IPs. This distributed, kernel-mode forwarding is what makes Service load balancing work without a centralized proxy.

Why this answer

Kube-proxy is the component responsible for implementing the Kubernetes Service concept by maintaining network rules on each node. It performs connection forwarding and load balancing for Service endpoints using either iptables, IPVS, or userspace mode, ensuring that traffic destined for a Service's ClusterIP is correctly routed to healthy Pods.

Exam trap

The trap here is that candidates confuse kube-proxy with the kubelet or kube-scheduler because all three are node-level components, but kube-proxy's sole purpose is network proxying and Service load balancing, not pod management or scheduling.

How to eliminate wrong answers

Option B is wrong because scheduling pods to nodes is the responsibility of the kube-scheduler, not kube-proxy. Option C is wrong because managing the lifecycle of pods (creation, monitoring, restart) is handled by the kubelet, not kube-proxy. Option D is wrong because storing cluster configuration data is the function of etcd, a distributed key-value store; kube-proxy does not persist any state.

Practice this question →
45
MCQmedium

A developer created a ServiceAccount named 'app-sa' in the 'dev' namespace. They want a pod to use this ServiceAccount. Which field in the pod spec should be set?

A.spec.serviceAccount
B.spec.authentication.serviceAccount
C.spec.serviceAccountName
D.spec.accountName
AnswerC

spec.serviceAccountName is the canonical field in PodSpec that tells the kubelet and kube-apiserver which ServiceAccount to attach to the pod. When set to 'app sa', the pod will mount the token and credentials of that ServiceAccount, enabling authenticated access to the Kubernetes API. If omitted, the default ServiceAccount in the namespace is used automatically, but explicitly setting it here binds the pod to 'app sa'.

Why this answer

The `spec.serviceAccountName` field in a Pod spec is the standard way to assign a specific ServiceAccount to a Pod. When this field is set, the Pod's containers will use the token of that ServiceAccount for API authentication. If omitted, the Pod defaults to the `default` ServiceAccount in its namespace.

Exam trap

The trap here is that candidates may confuse the deprecated `spec.serviceAccount` field (which still works in older clusters but is removed in recent versions) with the correct `spec.serviceAccountName`, or invent a non-existent field like `spec.accountName` due to similarity with other Kubernetes resource specs.

How to eliminate wrong answers

Option A is wrong because `spec.serviceAccount` is a deprecated field (removed in Kubernetes 1.24) and should not be used; it was replaced by `spec.serviceAccountName`. Option B is wrong because `spec.authentication.serviceAccount` is not a valid Kubernetes Pod spec field—authentication is handled via the ServiceAccount token, not a nested `authentication` object. Option D is wrong because `spec.accountName` is not a recognized field in the Pod spec; the correct field name is `serviceAccountName`.

Practice this question →
46
MCQeasy

A CKA candidate runs 'kubectl get nodes' and sees that a worker node is in the 'NotReady' state. Which command should be used to diagnose the node's kubelet health?

A.systemctl status docker
B.kubectl get events --all-namespaces
C.journalctl -u kubelet
D.kubectl logs -n kube-system kubelet-<node>
AnswerC

The kubelet runs as a systemd service on each node (in kubeadm and most Linux distributions), so `journalctl -u kubelet` reads the exact logs from that service, including startup errors, API server connection failures, certificate errors, and runtime health check failures. This is the authoritative source for why a node is NotReady, because NodeReady status is only updated when the kubelet successfully posts its status to the control plane. Unlike `kubectl get events`, these journal logs capture the actual exception that prevented the kubelet from functioning.

Why this answer

The kubelet is the primary node agent that registers the node with the cluster and reports its status via periodic heartbeats. When a node is NotReady, the most direct way to diagnose kubelet health is to inspect its systemd unit logs using 'journalctl -u kubelet', which shows startup errors, certificate issues, or resource exhaustion that prevent the kubelet from functioning correctly.

Exam trap

CNCF often tests the misconception that the kubelet runs as a Kubernetes pod (like kube-apiserver) and can be debugged with 'kubectl logs', when in reality it is a systemd service on the node, requiring OS-level commands like 'journalctl' or 'systemctl'.

How to eliminate wrong answers

Option A is wrong because 'systemctl status docker' checks the Docker container runtime, not the kubelet; while a runtime failure can cause node issues, the question specifically asks for diagnosing kubelet health. Option B is wrong because 'kubectl get events --all-namespaces' shows cluster-wide events (e.g., pod scheduling failures) but does not provide the kubelet's own log output or system-level errors. Option D is wrong because 'kubectl logs -n kube-system kubelet-<node>' attempts to access a pod named 'kubelet-<node>', but the kubelet does not run as a pod in the kube-system namespace; it runs as a systemd service on the node, so this command would fail with a 'not found' error.

Practice this question →
47
MCQhard

A pod's YAML specifies 'restartPolicy: Never' and the container exits with code 0. What state will the pod be in?

A.Completed
B.Failed
C.Succeeded
D.Running
AnswerC

"Succeeded" is the correct phase for a Pod whose containers all exit with status 0 and whose restartPolicy is Never or OnFailure. The kubelet detects the clean exit and updates status.phase to Succeeded, indicating the container ran to completion without errors. This matches the given pod definition exactly, making it the correct answer.

Why this answer

When a pod's restartPolicy is set to 'Never' and its container exits with code 0 (indicating a successful termination), the pod transitions to the 'Succeeded' phase. This is because Kubernetes treats a zero exit code as a successful completion, and with restartPolicy: Never, no restart is attempted, leaving the pod in a terminal Succeeded state.

Exam trap

The trap here is that candidates confuse the 'Completed' status from kubectl get pods output (which is a human-readable shorthand) with the actual pod phase 'Succeeded', or they assume any exit means 'Failed' regardless of the exit code.

How to eliminate wrong answers

Option A is wrong because 'Completed' is not a valid Kubernetes pod phase; the correct phase for a successful termination is 'Succeeded'. Option B is wrong because 'Failed' applies only when the container exits with a non-zero exit code, not code 0. Option D is wrong because 'Running' indicates the container is still executing, but here the container has already exited.

Practice this question →
48
MCQeasy

Which command is used to take a snapshot of etcd using etcdctl?

A.etcdctl dump
B.etcdctl snapshot create
C.etcdctl snapshot save
D.etcdctl backup
AnswerC

This is the correct and official command used by etcdctl, specifically in API version 3, to write a point-in-time snapshot of the etcd database to a specified file. Administrators must typically provide additional flags such as endpoints, cacert, cert, and key to authenticate against the secure etcd cluster before executing this command.

Why this answer

`etcdctl snapshot save` is the official command to create a point-in-time snapshot of an etcd datastore, which is essential for backup and disaster recovery in Kubernetes clusters. This command writes the snapshot to a specified file path, preserving all keys and metadata for later restoration via `etcdctl snapshot restore`.

Exam trap

The trap here is that candidates may confuse the `snapshot save` command with the non-existent `snapshot create` or the deprecated `backup` command from etcd v2, leading them to pick a plausible-sounding but incorrect option.

How to eliminate wrong answers

Option A is wrong because `etcdctl dump` is not a valid etcdctl subcommand; it may be confused with `etcdctl get` or `etcdctl watch` but does not exist for snapshotting. Option B is wrong because `etcdctl snapshot create` is not a valid command; the correct subcommand is `snapshot save`, not `create`. Option D is wrong because `etcdctl backup` is not a valid etcdctl command; the `backup` subcommand was used in older etcd v2 but has been replaced by `snapshot save` in etcd v3, which is the version used in modern CKA environments.

Practice this question →
49
MCQmedium

Which component is responsible for maintaining network rules on each node?

A.kube-controller-manager
B.etcd
C.kube-proxy
D.kubelet
AnswerC

kube-proxy is a network daemon that runs on each node to implement the Kubernetes Service abstraction. It monitors the API server for changes to Service and EndpointSlice objects, translating those definitions into active network rules using backend technologies like iptables or IPVS. This mechanism ensures that traffic directed to a Service's virtual IP is correctly load-balanced and routed to the appropriate backend pods.

Why this answer

C is correct because kube-proxy is the component responsible for maintaining network rules on each node. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates iptables, IPVS, or other rules to route traffic to the appropriate Pods. This ensures that network policies and service load balancing are enforced at the node level.

Exam trap

The trap here is confusing kubelet with kube-proxy, as both run on each node, but kubelet manages Pod lifecycle while kube-proxy manages network rules and service routing.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller loops (e.g., ReplicaSet, Deployment, Node) but does not manage per-node network rules. Option B is wrong because etcd is a distributed key-value store used for cluster state, not for maintaining network rules on nodes. Option D is wrong because kubelet is the primary node agent that manages Pods and containers, but it does not handle network rule enforcement (that is kube-proxy's role).

Practice this question →
50
Multi-Selectmedium

Which TWO commands can be used to interact with etcd snapshot operations? (Select TWO.)

Select 2 answers
A.etcdctl import
B.etcdctl snapshot restore
C.etcdctl migrate
D.etcdctl snapshot save
E.etcdctl backup
AnswersB, D

etcdctl snapshot restore is the correct command to recover etcd data from a previously saved snapshot. It creates a new etcd data directory from the snapshot file, and can be used with flags such as --name, --initial-cluster, and --initial-advertise-peer-urls to configure a restored member for a new cluster. This is the standard approach for disaster recovery or migrating an etcd cluster to a new set of nodes.

Why this answer

Option B, `etcdctl snapshot restore`, is correct because it is the etcdctl subcommand used to rebuild an etcd member's data directory from a previously taken snapshot file, typically with flags such as --data-dir and --initial-cluster. Option D, `etcdctl snapshot save`, is correct because it is the etcdctl subcommand that creates a point-in-time snapshot of the etcd key-value store and writes it to a file for backup purposes. Both commands belong to the `snapshot` subcommand group in etcdctl and are the standard tools for backup and recovery of etcd data.

Option A, `etcdctl import`, is not a valid etcdctl snapshot operation, and option E, `etcdctl backup`, was a legacy command that has been replaced by `etcdctl snapshot save`. Option C, `etcdctl migrate`, is used to migrate etcd data formats or versions, not to perform snapshot save or restore operations.

Exam trap

The trap here is that candidates may confuse `etcdctl snapshot save` with the non-existent `etcdctl backup` command, or think `etcdctl migrate` is related to snapshot operations when it is actually for version migration.

Practice this question →
51
MCQmedium

A user needs to deploy a pod that requires access to the Kubernetes API server from within the pod. Which resource should be used to provide authentication credentials automatically?

A.ServiceAccount
B.Secret
C.ConfigMap
D.ClusterRoleBinding
AnswerA

A ServiceAccount supplies pods with an automatically mounted token and CA certificate, giving in-cluster workloads an identity for authenticating to the Kubernetes API server. It satisfies the requirement for automatic credential provisioning without embedding secrets manually.

Why this answer

A ServiceAccount is the correct resource because Kubernetes automatically mounts a projected volume containing a JWT token into pods that use the default or a specified ServiceAccount. This token is used by the pod to authenticate against the Kubernetes API server, enabling secure in-cluster communication without manual credential management.

Exam trap

The trap here is that candidates often confuse authorization resources like ClusterRoleBinding with authentication mechanisms, or think that a generic Secret or ConfigMap can serve as an automatic credential provider, when in fact only a ServiceAccount provides the automated token injection and rotation required for in-cluster API access.

How to eliminate wrong answers

Option B is wrong because a Secret is a generic resource for storing sensitive data like passwords or tokens, but it does not automatically provide authentication credentials to a pod; you must explicitly mount or reference it, and it lacks the automatic token rotation and API server integration of a ServiceAccount. Option C is wrong because a ConfigMap is designed for non-sensitive configuration data (e.g., environment variables or config files) and cannot store or provide authentication credentials. Option D is wrong because a ClusterRoleBinding grants RBAC permissions to a subject (like a ServiceAccount or user) but does not itself provide authentication credentials; it is an authorization resource, not an authentication mechanism.

Practice this question →
52
MCQmedium

A node in the cluster has been cordoned. Which of the following is true about the node?

A.The node is removed from the cluster.
B.kubectl drain is automatically performed on the node.
C.The node is marked as unschedulable, but existing pods continue to run.
D.Existing pods on the node are immediately evicted.
AnswerC

Cordoning sets the node's spec.unschedulable field to true, so the scheduler places no new pods there. Existing pods remain running and are not evicted, which distinguishes cordon from drain, where workloads are actively moved off the node.

Why this answer

When a node is cordoned using `kubectl cordon`, it is marked as unschedulable by setting the `node.Spec.Unschedulable` field to true. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The node remains part of the cluster and is not removed or drained automatically.

Exam trap

The trap here is that candidates confuse cordoning with draining, assuming cordoning also evicts existing pods or removes the node, when in fact it only prevents new scheduling and leaves running pods untouched.

How to eliminate wrong answers

Option A is wrong because cordoning does not remove the node from the cluster; the node remains a member and can be uncordoned later. Option B is wrong because `kubectl drain` is not automatically performed; draining is a separate, explicit operation that evicts pods, whereas cordon only prevents new scheduling. Option D is wrong because existing pods are not immediately evicted; they continue running until they are terminated or the node is drained manually.

Practice this question →
53
Multi-Selecteasy

Which TWO of the following are control plane components?

Select 2 answers
A.cloud-controller-manager
B.kubelet
C.etcd
D.container runtime
E.kube-proxy
AnswersA, C

The cloud-controller-manager is a control plane component that runs cloud-specific controllers, such as those for node lifecycle, load balancers, and routing, by interacting with the cloud provider's API. It is scheduled only on control plane nodes and is built as a separate binary to isolate cloud dependencies from the core Kubernetes controllers. Because its entire function is to bridge the cluster to a cloud provider's infrastructure, it belongs exclusively to the control plane.

Why this answer

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.

Exam trap

CNCF often tests the distinction between control plane and node components, and the trap here is that candidates mistakenly classify kube-proxy or kubelet as control plane components because they are essential for cluster operation, but they are not part of the control plane's core management layer.

Practice this question →
54
MCQeasy

What is the function of the 'kube-scheduler' in Kubernetes?

A.It runs the container runtime
B.It manages network rules for services
C.It stores cluster state
D.It assigns pods to nodes
AnswerD

The kube-scheduler assigns Pods to Nodes by continuously watching the API server for unscheduled Pods (those with an empty spec.nodeName), then filtering Nodes based on constraints like resource requests, taints and tolerations, node selectors, affinity rules, and data locality, and finally scoring the remaining candidates to pick the best fit. Once a Node is chosen, it creates a Binding object that commits the Pod to that Node, after which the kubelet on the selected Node takes over to actually start its containers.

Why this answer

The kube-scheduler is a core control plane component that watches for newly created Pods with no assigned node and selects an optimal node for them to run on. It makes scheduling decisions based on resource requirements, constraints like affinity/anti-affinity rules, data locality, and other policies. Option D is correct because the scheduler's primary function is to assign pods to nodes.

Exam trap

The trap here is that candidates often confuse the kube-scheduler with kubelet or kube-proxy, but the scheduler's sole role is node selection for pods, not running containers or managing network rules.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) runs containers, not the kube-scheduler. Option B is wrong because managing network rules for services is the job of the kube-proxy component, which implements Service networking via iptables/IPVS. Option C is wrong because storing cluster state is the responsibility of etcd, a distributed key-value store; the kube-scheduler does not persist any state.

Practice this question →
55
MCQhard

You are upgrading a Kubernetes cluster from version 1.28 to 1.29. What is the correct order of steps?

A.Upgrade all worker nodes first, then upgrade control plane nodes.
B.Upgrade control plane nodes first, then upgrade worker nodes without draining them.
C.Upgrade control plane nodes first, then drain each worker node before upgrading it.
D.Upgrade all nodes simultaneously.
AnswerC

This sequence aligns perfectly with the official Kubernetes upgrade lifecycle. Upgrading the control plane components first ensures that the API server can handle requests from newer kubelet versions. Subsequently draining each worker node before its upgrade guarantees that workloads are safely rescheduled onto other healthy nodes, minimizing service disruption during the node's maintenance window.

Why this answer

The Kubernetes upgrade process requires upgrading the control plane nodes first to ensure the cluster's management layer is running the new version before worker nodes are upgraded. Draining each worker node before upgrading it is essential to safely evict pods and maintain application availability, as the kubelet on the node must be stopped during the upgrade and the node must be cordoned to prevent new pods from being scheduled.

Exam trap

The trap here is that candidates may think upgrading worker nodes without draining is acceptable if they use a rolling update strategy, but the CKA exam specifically tests the requirement to drain nodes before upgrading to avoid pod disruption.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before control plane nodes violates the Kubernetes upgrade order; the control plane must be upgraded first to avoid version skew incompatibilities. Option B is wrong because upgrading worker nodes without draining them first can cause pod disruptions and data loss, as the kubelet is stopped during the upgrade and pods are not gracefully terminated. Option D is wrong because upgrading all nodes simultaneously is not supported; Kubernetes requires a sequential upgrade to maintain cluster stability and prevent version mismatch between components.

Practice this question →
56
MCQhard

An administrator backs up etcd data using 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. Which command correctly restores this snapshot on a new etcd instance?

A.kubectl apply -f /backup/etcd-snapshot.db
B.etcdctl snapshot restore /backup/etcd-snapshot.db --data-dir=/var/lib/etcd-restored
C.etcdctl snapshot load /backup/etcd-snapshot.db
D.ETCDCTL_API=3 etcdctl restore /backup/etcd-snapshot.db
AnswerB

etcdctl snapshot restore is the correct command because it takes a previously captured snapshot file and reconstructs a new etcd data directory. The --data-dir flag points to the location where the restored database files should be written, and the etcd server must later be configured to use that directory; this is the canonical procedure for restoring etcd in Kubernetes control-plane recovery.

Why this answer

`etcdctl snapshot restore` is the proper command to restore an etcd snapshot to a new data directory. The `--data-dir` flag specifies where the restored data should be placed, allowing the new etcd instance to use that directory. This command recreates the etcd member's data from the snapshot file, which is essential for disaster recovery.

Exam trap

CNCF often tests the exact subcommand syntax, so candidates mistakenly choose `etcdctl restore` or `etcdctl snapshot load` instead of the correct `etcdctl snapshot restore`.

How to eliminate wrong answers

Option A is wrong because `kubectl apply` is used to apply Kubernetes resources from YAML/JSON manifests, not to restore etcd snapshots; it cannot interpret a binary snapshot file. Option C is wrong because `etcdctl snapshot load` is not a valid subcommand; the correct subcommand is `snapshot restore`. Option D is wrong because `etcdctl restore` is not a valid subcommand; the correct syntax requires `snapshot restore`, and the `ETCDCTL_API=3` environment variable is not needed when using the v3 API by default.

Practice this question →
57
Multi-Selecteasy

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

Select 2 answers
A.kubelet
B.kube-proxy
C.container runtime
D.etcd
E.kube-apiserver
AnswersD, E

etcd is the distributed key-value store that holds the entire cluster's desired state—all API objects, configuration, secrets, and metadata—and it is the single source of truth for Kubernetes. It is fundamentally a control plane component because every control plane operation reads from or writes to etcd, and it requires quorum-based consensus (Raft) to maintain consistent state across replicas. Without etcd, the API server cannot operate, and the cluster has no real state to reconcile.

Why this answer

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.

Exam trap

CNCF often tests the distinction between control plane and node components, and the trap here is that candidates confuse kubelet or kube-proxy as control plane components because they are critical to cluster operation, but they actually run on every node and are not part of the control plane.

Practice this question →
58
MCQhard

An administrator runs 'kubectl get nodes' and sees that one node is in the 'NotReady' state. Which component should be checked FIRST to diagnose the issue?

A.kubelet on the worker node
B.kube-apiserver on the control plane
C.kube-controller-manager
D.etcd cluster health
AnswerA

The kubelet is the essential agent running on each worker node, responsible for registering the node with the control plane and continuously reporting its health and status to the API server via heartbeats. If the kubelet process fails, crashes, or loses network connectivity on a specific worker node, it stops sending these crucial heartbeats. Consequently, the Node Controller on the control plane will eventually mark that particular node as 'NotReady' because it is no longer receiving status updates from its designated agent.

Why this answer

The kubelet is the primary node agent that runs on every worker node and is responsible for registering the node with the cluster and periodically reporting its status via NodeStatus updates. When a node is in 'NotReady' state, it means the kubelet has failed to send heartbeats or report readiness to the control plane, typically due to a crash, misconfiguration, or resource exhaustion. Checking the kubelet's logs and service status (e.g., 'systemctl status kubelet' or 'journalctl -u kubelet') is the first diagnostic step because it directly controls node health reporting.

Exam trap

CNCF often tests the misconception that the kube-controller-manager or kube-apiserver is the root cause of node unreadiness, but the trap here is that the kubelet is the sole component responsible for reporting node health, and its failure is the most direct cause of a 'NotReady' state.

How to eliminate wrong answers

Option B is wrong because the kube-apiserver is the front-end for the Kubernetes API and handles all REST requests, but it does not directly report node health; a failing kube-apiserver would affect all API calls, not just a single node's status. Option C is wrong because the kube-controller-manager runs controllers like the Node Controller that reacts to node status changes, but it does not generate the initial health data; it only acts on the status reported by the kubelet. Option D is wrong because etcd stores cluster state, including node status, but a healthy etcd cluster is required for the control plane to function; however, if only one node is NotReady, the issue is almost certainly local to that node, not the distributed key-value store.

Practice this question →
59
MCQeasy

Which component is responsible for managing the lifecycle of pods on a node?

A.kube-scheduler
B.kube-controller-manager
C.kubelet
D.kube-proxy
AnswerC

The kubelet is the primary node agent that interacts with the container runtime via the Container Runtime Interface (CRI) to manage the lifecycle of pods assigned to its node. It ensures that the containers described in the PodSpecs are running and healthy, executing liveness and readiness probes, and reporting status back to the API server.

Why this answer

The kubelet is the primary node agent that runs on each node in a Kubernetes cluster. It is responsible for ensuring that containers are running in a pod as expected, managing the pod lifecycle by communicating with the container runtime (e.g., containerd or CRI-O) and reporting the node and pod status back to the API server.

Exam trap

The trap here is that candidates often confuse the kube-scheduler (which places pods on nodes) with the kubelet (which actually runs and manages them), or think the kube-controller-manager handles node-level pod operations.

How to eliminate wrong answers

Option A is wrong because the kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for managing pods on a node. Option B is wrong because the kube-controller-manager runs controllers (e.g., ReplicaSet, Node controller) that regulate the desired state of the cluster, but it does not directly manage pod lifecycles on individual nodes. Option D is wrong because kube-proxy handles network proxying and load balancing for services on each node, not pod lifecycle management.

Practice this question →
60
Multi-Selectmedium

Which THREE are valid steps when upgrading a Kubernetes cluster using kubeadm? (Select 3)

Select 3 answers
A.Upgrade kubelet and kubectl on the node.
B.Upgrade kubeadm on the node to the target version.
C.Upgrade the container runtime to a compatible version.
D.Drain the node before upgrading it.
E.Run 'kubeadm upgrade apply' on the worker node.
AnswersA, B, D

kubelet and kubectl are not automatically upgraded by kubeadm; you must manually update these binaries on each node using your package manager (e.g., apt-get upgrade kubelet kubectl) or by replacing them in /usr/bin. This manual step is required because kubeadm upgrade node only handles the static pod manifests and kubeadm configuration, not the kubelet or kubectl client versions.

Why this answer

After upgrading kubeadm on the control plane, you must upgrade kubelet and kubectl on each node to match the target Kubernetes version. The kubelet is the primary node agent that communicates with the control plane, and kubectl is the CLI tool used to interact with the cluster. Without upgrading these components, the node may fail to register or report an incompatible version, causing the node to be in a NotReady state.

Exam trap

The trap here is that candidates often confuse the 'kubeadm upgrade apply' command, thinking it can be run on any node, when in fact it must be executed on the control plane node, while worker nodes require 'kubeadm upgrade node'.

Practice this question →
61
MCQmedium

A node named 'node1' is having issues. You want to prevent any new pods from being scheduled onto it without affecting running pods. Which command should you use?

A.kubectl drain node1
B.kubectl cordon node1
C.kubectl taint nodes node1 key=value:NoSchedule
D.kubectl delete node node1
AnswerB

The `kubectl cordon node1` command is the standard and safest way to mark a node as unschedulable. It updates the node's spec to set `unschedulable: true`, which prevents the Kubernetes scheduler from placing any new pods onto it, while leaving all currently running pods completely unaffected.

Why this answer

The `kubectl cordon node1` command marks the node as unschedulable, preventing new pods from being scheduled onto it while leaving existing pods running. This is the correct approach when you need to isolate a node for maintenance without disrupting current workloads.

Exam trap

The trap here is that candidates often confuse `cordon` with `drain` or `taint`, thinking that draining is required to prevent scheduling, or that tainting is the only way to achieve this, but `cordon` is the simplest and most direct command for marking a node unschedulable without affecting running pods.

How to eliminate wrong answers

Option A is wrong because `kubectl drain node1` evicts all pods from the node (with graceful termination), which would affect running pods, contrary to the requirement. Option C is wrong because `kubectl taint nodes node1 key=value:NoSchedule` adds a taint that prevents new pods from being scheduled unless they tolerate the taint, but it does not affect existing pods; however, the question asks for a command that prevents new pods without affecting running pods, and while tainting can achieve this, it is not the standard or simplest command for this purpose—cordon is the direct and intended tool. Option D is wrong because `kubectl delete node node1` removes the node object from the cluster, which would cause the kubelet to lose registration and potentially affect running pods (they would be terminated or orphaned), and it is a destructive action not suitable for simple scheduling prevention.

Practice this question →
62
MCQmedium

Which subcommand of 'kubectl config' is used to switch between different contexts?

A.kubectl config switch-context
B.kubectl config set-context
C.kubectl config current-context
D.kubectl config use-context
AnswerD

`kubectl config use-context` writes the named context into the `current-context` field of kubeconfig, so subsequent kubectl commands target that cluster, user and namespace combination. It directly satisfies the requirement to switch between contexts, unlike `set-context`, which only modifies a context's properties without activating it.

Why this answer

'kubectl config use-context' is the exact subcommand used to switch the current context in a kubeconfig file. This command updates the 'current-context' field in the kubeconfig, directing all subsequent kubectl commands to the specified cluster, namespace, and user combination.

Exam trap

The trap here is that candidates confuse 'set-context' (which modifies context definitions) with 'use-context' (which switches the active context), leading them to choose option B instead of D.

How to eliminate wrong answers

Option A is wrong because 'kubectl config switch-context' is not a valid kubectl subcommand; kubectl does not have a 'switch-context' command. Option B is wrong because 'kubectl config set-context' is used to modify or create a context definition (e.g., setting cluster, user, or namespace), but it does not change the active/current context. Option C is wrong because 'kubectl config current-context' only displays the name of the currently active context, without switching to a different one.

Practice this question →
63
MCQhard

A developer needs to access the Kubernetes API from a pod using a ServiceAccount. Which of the following is the recommended way to mount the ServiceAccount token into a pod?

A.Use the downward API to inject the token as an environment variable.
B.Set the token in the pod spec using the 'serviceAccountToken' field.
C.Mount the secret directly using a volume.
D.Use a projected service account token with a mount path.
AnswerD

Use a projected volume with a serviceAccountToken source and set a mountPath—such as /var/run/secrets/kubernetes.io/serviceaccount—to expose a TokenRequest-based token file in the pod. The kubelet requests the token with a configurable audience and expirationSeconds, writes it to the specified path, and automatically rewrites it as expiry approaches, enabling client libraries to reload the credential. This is the recommended approach because it minimizes token lifetime, allows audience restriction, and avoids the security drawbacks of environment variables or unmanaged, long-lived secrets.

Why this answer

The recommended way to mount a ServiceAccount token into a pod is by using a projected service account token volume. This approach, introduced in Kubernetes 1.20, provides a time-bound, audience-scoped, and automatically rotated token that is mounted as a file at a specified mount path, enhancing security over static secrets.

Exam trap

The trap here is that candidates often think mounting the ServiceAccount's secret directly (Option C) is still the recommended method, but the CKA exam expects knowledge of the newer, more secure projected token approach introduced in Kubernetes 1.20+.

How to eliminate wrong answers

Option A is wrong because the Downward API cannot inject the ServiceAccount token as an environment variable; it only exposes pod metadata (e.g., labels, annotations, namespace) and not secrets or tokens. Option B is wrong because there is no 'serviceAccountToken' field in the pod spec; the token is automatically mounted via the 'serviceAccountName' field, but the token itself is not directly specified in the pod spec. Option C is wrong because mounting the secret directly (e.g., the token secret created by Kubernetes for the ServiceAccount) is deprecated and less secure, as it lacks automatic rotation and audience binding, unlike projected tokens.

Practice this question →
64
Multi-Selecthard

You have a multi-node Kubernetes cluster. After upgrading the kubelet on a worker node, the node remains in 'NotReady' state. Which TWO actions should you take to troubleshoot? (Choose TWO.)

Select 2 answers
A.Check the node conditions using 'kubectl describe node <node-name>'
B.Check the pod logs on the node
C.Check the kubelet service status on the node using 'systemctl status kubelet'
D.Check the kube-apiserver logs on the control plane
E.Reboot the node
AnswersA, C

Running `kubectl describe node <node-name>` surfaces the node's status object, including the `Conditions` section with entries like `Ready`, `MemoryPressure`, and `PIDPressure`. Each condition carries a `LastHeartbeatTime` and a `Reason`/`Message` that explains why the node might be `NotReady` after an upgrade. This is the fastest control-plane-level check because it reflects the kubelet's last successful status update and any taints, capacity, or allocatable changes that could affect scheduling.

Why this answer

'kubectl describe node <node-name>' shows node conditions, including the 'Ready' status and any underlying issues like 'NetworkUnavailable', 'MemoryPressure', or 'KubeletNotReady'. This command provides a high-level view of why the node is NotReady, such as a kubelet version mismatch or resource exhaustion. It is the standard first step in diagnosing node health.

Exam trap

The trap here is that candidates often jump to checking the kube-apiserver logs (Option D) or rebooting (Option E) instead of focusing on the node's local kubelet service, which is the direct source of the NotReady state.

Practice this question →
65
MCQhard

You have a Kubernetes cluster with a single control-plane node and multiple worker nodes. You need to upgrade the cluster from v1.28.0 to v1.29.0. Which sequence of steps is correct?

A.Upgrade all worker nodes first, then upgrade the control plane
B.Drain all nodes simultaneously, upgrade the control plane, then upgrade worker nodes
C.Upgrade the control plane first, then drain each worker node, upgrade the kubelet and kube-proxy, then uncordon
D.Upgrade the control plane and worker nodes at the same time
AnswerC

This sequence is the recommended and correct procedure for a Kubernetes cluster upgrade. Upgrading the control plane first ensures that the central kube-apiserver can support newer worker node components and API versions. Subsequently, draining each worker node individually allows pods to gracefully migrate, minimizing downtime, before upgrading its kubelet and kube-proxy, and finally uncordoning it to rejoin the cluster.

Why this answer

Kubernetes requires the control plane to be upgraded first, as it is the source of truth for the cluster state and API version compatibility. After the control plane is upgraded, each worker node must be drained (to evict pods gracefully), upgraded (kubelet and kube-proxy), and then uncordoned to resume scheduling. This sequential process ensures that the cluster remains functional and that kubelet versions never exceed the kube-apiserver version, which is a strict compatibility requirement.

Exam trap

The trap here is that candidates often think worker nodes can be upgraded first to minimize control-plane downtime, but the CKA exam tests the strict version skew policy that requires the control plane to be upgraded first, and that draining all nodes simultaneously is a common misconception that would cause complete cluster unavailability.

How to eliminate wrong answers

Option A is wrong because upgrading worker nodes before the control plane violates the Kubernetes version skew policy, which requires the kube-apiserver to be at the highest version; if worker nodes are upgraded first, their kubelet may attempt to use API features not yet available on the older control plane, causing failures. Option B is wrong because draining all nodes simultaneously would make the cluster completely unavailable, and upgrading the control plane after draining all nodes is not the correct order; the control plane must be upgraded first while worker nodes are still running to maintain cluster operations. Option D is wrong because upgrading control plane and worker nodes at the same time is not supported; the control plane must be upgraded first to ensure API compatibility, and simultaneous upgrades can lead to version mismatches and cluster instability.

Practice this question →
66
MCQeasy

What is the purpose of the 'kubeadm reset' command?

A.To restart the kubelet service
B.To undo the effects of kubeadm init or kubeadm join on a node
C.To upgrade the cluster to a newer version
D.To add a new node to the cluster
AnswerB

kubeadm reset is designed to reverse the changes made by kubeadm init or kubeadm join on that specific node. It removes the control-plane components (if present), deletes the local etcd member's data, cleans up /etc/kubernetes, /var/lib/kubelet, and other kubeadm-created directories, and resets network rules so the node returns to its pre-cluster state. This makes the node ready for a fresh kubeadm init or kubeadm join, or to be fully removed from the cluster.

Why this answer

The 'kubeadm reset' command is designed to revert a node back to its pre-'kubeadm init' or pre-'kubeadm join' state. It cleans up all cluster-related configuration, certificates, and etcd data (if running on the control plane), effectively removing the node from the cluster and allowing it to be re-initialized or re-joined cleanly.

Exam trap

The trap here is that candidates confuse 'kubeadm reset' with a simple service restart or a node addition command, but it is specifically a destructive cleanup that undoes the entire initialization or join process, not a maintenance or upgrade tool.

How to eliminate wrong answers

Option A is wrong because 'kubeadm reset' does not restart the kubelet service; restarting the kubelet is done via 'systemctl restart kubelet' and is unrelated to resetting cluster state. Option C is wrong because upgrading a cluster is performed using 'kubeadm upgrade plan' and 'kubeadm upgrade apply', not 'kubeadm reset', which is destructive and removes cluster data. Option D is wrong because adding a new node is done with 'kubeadm join', while 'kubeadm reset' is used to remove a node from the cluster, not add one.

Practice this question →
67
MCQeasy

Which kubectl command is used to drain a node before performing maintenance?

A.kubectl cordon node01
B.kubectl drain node01
C.kubectl taint node node01 key=value:NoExecute
D.kubectl delete node node01
AnswerB

The `kubectl drain node01` command is the proper way to prepare a node for maintenance. It cordons the node to make it unschedulable and then evicts all pods on the node (except DaemonSet-managed pods and mirror pods by default) gracefully, respecting PodDisruptionBudgets and terminating containers with proper pre-stop hooks. After the drain completes, the node is both unschedulable and free of workloads, allowing safe maintenance or shutdown. Use flags like --ignore-daemonsets or --delete-emptydir-data when needed, but the base command is the correct starting point.

Why this answer

The `kubectl drain` command is the correct tool for safely evicting all pods from a node before maintenance. It marks the node as unschedulable (similar to `cordon`) and then gracefully terminates pods, respecting PodDisruptionBudgets, ensuring workloads are rescheduled to other nodes without disruption.

Exam trap

CNCF often tests the distinction between `cordon` (only prevents new pods) and `drain` (evicts existing pods), leading candidates to mistakenly choose `cordon` when the question explicitly requires draining for maintenance.

How to eliminate wrong answers

Option A is wrong because `kubectl cordon` only marks the node as unschedulable (SchedulingDisabled) but does not evict existing pods, so maintenance would still leave running workloads on the node. Option C is wrong because `kubectl taint` with `NoExecute` evicts pods that do not tolerate the taint, but it does not gracefully drain all pods or respect PodDisruptionBudgets, and it is not the standard command for node maintenance preparation. Option D is wrong because `kubectl delete node` removes the node object from the cluster entirely, which is destructive and not intended for maintenance; it does not evict pods or cordon the node first, potentially causing workload disruption.

Practice this question →
68
MCQeasy

Which command initializes a new Kubernetes cluster using kubeadm?

A.kubeadm create cluster
B.kubeadm setup
C.kubeadm init
D.kubeadm start
AnswerC

kubeadm init is the correct command to bootstrap a new Kubernetes control plane. It runs preflight checks, generates cluster certificates, creates the kubeconfig files, starts the static control-plane pods (kube-apiserver, kube-controller-manager, kube-scheduler), and installs a pod network add-on afterward. This is the standard, documented first step for creating a cluster with kubeadm.

Why this answer

`kubeadm init` is the official Kubernetes command to bootstrap a control-plane node and initialize a new cluster. It performs preflight checks, generates certificates, creates the static Pod manifests for core components (etcd, API server, controller manager, scheduler), and configures the admin kubeconfig file.

Exam trap

The trap here is that candidates confuse `kubeadm init` with generic system commands like `create` or `start`, or assume a `setup` subcommand exists, when in fact `kubeadm init` is the only correct command for initializing a cluster.

How to eliminate wrong answers

Option A is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control-plane initialization and `join` for worker nodes. Option B is wrong because `kubeadm setup` does not exist in the kubeadm CLI; the correct command for initializing a cluster is `kubeadm init`. Option D is wrong because `kubeadm start` is not a valid kubeadm subcommand; kubeadm does not manage the lifecycle of running processes—it only bootstraps the cluster, after which kubelet and container runtime handle the Pods.

Practice this question →
69
MCQeasy

Which control plane component is responsible for storing the cluster state and configuration?

A.etcd
B.kube-controller-manager
C.kube-apiserver
D.kube-scheduler
AnswerA

etcd is a distributed, consistent, and highly available key-value store that serves as Kubernetes' backing store for all cluster data. It persistently stores the entire cluster state, including configuration data, metadata for all Kubernetes objects like Pods, Deployments, and Services, and the desired state of the system. Its robust consistency model is critical for ensuring that all control plane components operate on a single, unified source of truth.

Why this answer

etcd is the distributed key-value store that serves as the single source of truth for the entire cluster, storing all cluster state data such as configurations, secrets, service endpoints, and resource specifications. The kube-apiserver reads from and writes to etcd exclusively, making it the only component that directly persists the cluster's desired and current state.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage component because it is the primary interface for all cluster operations, but it is actually a stateless API gateway that relies entirely on etcd for persistence.

How to eliminate wrong answers

Option B (kube-controller-manager) is wrong because it runs controller loops that reconcile the current state with the desired state stored in etcd, but it does not store any data itself. Option C (kube-apiserver) is wrong because it is the front-end API gateway that validates and processes requests, but it delegates all persistent storage to etcd and does not maintain its own database. Option D (kube-scheduler) is wrong because it only assigns pods to nodes based on resource availability and policies, and it reads cluster state from the API server without storing any state or configuration.

Practice this question →
70
MCQmedium

To back up etcd, which command should be used with etcdctl?

A.etcdctl export
B.etcdctl backup
C.etcdctl dump
D.etcdctl snapshot save
AnswerD

etcdctl snapshot save is the correct and standard command for backing up an etcd cluster's data. It contacts the etcd endpoint, takes a consistent snapshot of the entire key-value store (including all keys, versions, and metadata), and writes it to a file on disk. This snapshot can then be used with etcdctl snapshot restore to recover a cluster, making it the essential backup tool for etcd-backed Kubernetes control planes.

Why this answer

The correct command to back up etcd is `etcdctl snapshot save`, which creates a point-in-time snapshot of the etcd key-value store. This is the officially recommended method for backing up etcd data in Kubernetes clusters, as it captures the entire database state consistently.

Exam trap

The trap here is that candidates may confuse `etcdctl` subcommands with similar-sounding Linux backup commands (like `dump` or `export`) or assume a generic `backup` subcommand exists, when the CKA exam specifically tests knowledge of the exact `snapshot save` syntax.

How to eliminate wrong answers

Option A is wrong because `etcdctl export` is not a valid command; the correct command for exporting data is `etcdctl snapshot save`. Option B is wrong because `etcdctl backup` is not a valid subcommand; etcdctl uses `snapshot save` for backups. Option C is wrong because `etcdctl dump` is not a valid command; the closest valid command is `etcdctl snapshot save` for backups or `etcdctl get` for retrieving specific keys.

Practice this question →
71
MCQmedium

A node has been cordoned. Which statement about the node is true?

A.All pods on the node are immediately terminated
B.The kubelet on the node is stopped
C.The node is removed from the cluster
D.The node is marked as unschedulable, but existing pods continue to run
AnswerD

The correct effect of cordoning is to mark the node as unschedulable by setting `spec.unschedulable: true`, which tells the scheduler to avoid placing any new pods on it. However, the pods that are already scheduled and running are unaffected and continue their lifecycle normally until they finish, are evicted, or are explicitly deleted. This is why cordon is the preferred first step before a node drain: it prevents new workloads while letting existing ones remain available during maintenance preparation.

Why this answer

When a node is cordoned using `kubectl cordon <node>`, it is marked as unschedulable by setting the `spec.unschedulable` field to `true`. This prevents new pods from being scheduled onto the node, but existing pods continue to run normally. The kubelet remains active, and the node stays in the cluster.

Exam trap

The trap here is confusing `cordon` with `drain` — candidates often think cordoning also evicts pods, but it only prevents new scheduling, leaving existing pods untouched.

How to eliminate wrong answers

Option A is wrong because cordoning does not terminate pods; only `kubectl drain` evicts or deletes pods. Option B is wrong because the kubelet continues to run and manage existing pods; cordoning only affects the scheduler. Option C is wrong because the node remains a member of the cluster and is still visible via `kubectl get nodes`; it is not removed.

Practice this question →
72
MCQmedium

What is the purpose of 'kubeadm reset'?

A.To restart the Kubernetes services on a node.
B.To reinitialize the cluster with new configuration.
C.To remove the node from the cluster and clean up.
D.To rollback the last upgrade.
AnswerC

This command is designed to revert the changes made to a host by kubeadm init or kubeadm join. It stops the kubelet, removes local static pod manifests, deletes the /etc/kubernetes configuration directory, and cleans up local state. This prepares the machine to either be safely decommissioned or rejoined to a cluster.

Why this answer

`kubeadm reset` is designed to revert any changes made by `kubeadm init` or `kubeadm join` on a node, effectively cleaning up the node's local state (e.g., removing CNI configurations, etcd member data, and kubelet certificates) so it can be safely removed from the cluster or reinitialized. Option C correctly identifies this as removing the node from the cluster and cleaning up, which is the primary purpose of the command.

Exam trap

CNCF often tests the misconception that `kubeadm reset` is a general-purpose reset or rollback tool, when in fact it is a destructive cleanup command that only prepares a node for re-joining or re-initialization, not for reverting cluster-wide changes or upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm reset` does not restart Kubernetes services; it tears down and cleans up the node, whereas `systemctl restart kubelet` or `kubeadm upgrade` commands handle service restarts. Option B is wrong because `kubeadm reset` does not reinitialize the cluster with new configuration; it only cleans up the current state, and reinitialization would require running `kubeadm init` again with a new config. Option D is wrong because `kubeadm reset` is not a rollback mechanism for upgrades; `kubeadm upgrade` has its own rollback procedures (e.g., `kubeadm upgrade apply --etcd-upgrade=false` or manual etcd snapshot restore), and `reset` simply destroys the node's Kubernetes artifacts without preserving upgrade history.

Practice this question →
73
Multi-Selectmedium

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

Select 2 answers
A.kubectl describe configmap kubeconfig
B.kubectl config set-context
C.kubectl config current-context
D.kubectl config get-contexts
E.kubectl config view
AnswersD, E

kubectl config get-contexts returns a table of all contexts defined in the kubeconfig, listing each context's name, cluster, authinfo, and namespace (along with a marker for the current context). This is a read-only command that directly satisfies the requirement to view context configuration, making it a correct choice.

Why this answer

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.

Exam trap

The trap here is that candidates may confuse commands that modify the kubeconfig (like `set-context`) with commands that display it, or mistakenly think `current-context` shows the full configuration when it only shows the active context name.

Practice this question →
74
MCQeasy

Which component is responsible for managing the network rules and forwarding on each node?

A.container runtime
B.kubelet
C.kube-proxy
D.kube-scheduler
AnswerC

kube-proxy runs as a DaemonSet on every node and watches the Kubernetes API server for updates to Service and EndpointSlice objects. It is the component that manages network rules for Services by writing entries into iptables or IPVS, which then perform DNAT, load balancing, and connection forwarding to backend Pods. Without kube-proxy, or an equivalent replacement, ClusterIP and NodePort Services would not have the kernel rules necessary to route Service traffic.

Why this answer

kube-proxy is the component responsible for managing network rules and forwarding traffic on each node. It implements the Kubernetes Service concept by maintaining iptables or IPVS rules that route packets to the correct backend pods, handling load balancing and service discovery at the network layer.

Exam trap

CNCF often tests the misconception that kubelet handles networking, but kubelet only manages pod lifecycle and container runtime interactions, not network rule management.

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is only responsible for pulling images and running containers, not for managing network rules or packet forwarding. Option B is wrong because the kubelet is the primary node agent that registers the node with the API server and manages pod lifecycle, but it does not handle network rule management or forwarding. Option D is wrong because kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, and it has no role in network traffic forwarding.

Practice this question →
75
MCQeasy

Which command is used to create a backup of etcd data using etcdctl?

A.etcdctl endpoint status
B.etcdctl snapshot restore /backup/snapshot.db
C.etcdctl snapshot save /backup/snapshot.db
D.etcdctl member list
AnswerC

This is the correct command to capture a point-in-time backup of the active etcd keyspace and write it to a specified file path. When executed with the appropriate TLS certificates and endpoints, it securely streams the database state into a single compressed snapshot file suitable for disaster recovery.

Why this answer

`etcdctl snapshot save` is the command used to create a point-in-time backup of etcd data. This command captures the entire key-value store and writes it to a specified file path, which is essential for disaster recovery in Kubernetes clusters that use etcd as their backing store.

Exam trap

The trap here is that candidates confuse the `save` and `restore` subcommands, often selecting `snapshot restore` (Option B) because they think 'backup' implies 'restore', but `save` is the correct verb for creating a backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl endpoint status` only returns health and version information about the etcd endpoints, not a backup of the data. Option B is wrong because `etcdctl snapshot restore` is used to restore a previously saved snapshot, not to create a new backup. Option D is wrong because `etcdctl member list` lists the members of the etcd cluster and their status, which is unrelated to creating a data backup.

Practice this question →
Page 1 of 3 · 158 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cluster Architecture, Installation and Configuration questions.

Start 20-question session