Courseiva

CCNA Cluster Architecture, Installation and Configuration Questions

75 of 80 questions · Page 1/2 · 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

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 →
4
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 →
5
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 →
6
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 →
7
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 →
8
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 →
9
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 →
10
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 →
11
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 →
12
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 →
13
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 →
14
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

This variable enables the v3 API.

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 →
15
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 →
16
MCQhard

You need to grant a ServiceAccount named 'jenkins' in the 'ci' namespace the ability to list pods in the 'production' namespace. Which RBAC resources should you create?

A.Create a ClusterRole in the 'production' namespace and a RoleBinding in the 'ci' namespace.
B.Create a Role in the 'production' namespace and a RoleBinding in the 'ci' namespace referencing the Role.
C.Create a Role in the 'ci' namespace and a RoleBinding binding the ServiceAccount to the Role.
D.Create a ClusterRole and a ClusterRoleBinding binding the ServiceAccount to the ClusterRole.
AnswerD

A ClusterRole can define permissions for pods in any namespace, and a ClusterRoleBinding grants those permissions cluster-wide, including to the ServiceAccount.

Why this answer

A ServiceAccount in one namespace ('ci') needs to list pods in another namespace ('production'). A ClusterRole grants permissions cluster-wide (or across namespaces), and a ClusterRoleBinding binds it to the ServiceAccount, allowing cross-namespace access. Roles and RoleBindings are namespace-scoped and cannot grant permissions across namespaces.

Exam trap

The trap here is that candidates often think a RoleBinding can bind a Role from another namespace, but RoleBindings are namespace-scoped and can only reference Roles in the same namespace, making a ClusterRole and ClusterRoleBinding necessary for cross-namespace access.

How to eliminate wrong answers

Option A is wrong because a ClusterRole cannot be created inside a namespace; ClusterRoles are cluster-scoped resources. Option B is wrong because a Role in the 'production' namespace is namespace-scoped, and a RoleBinding in the 'ci' namespace cannot reference a Role from a different namespace; RoleBindings must reference a Role in the same namespace. Option C is wrong because a Role in the 'ci' namespace only grants permissions within that namespace, not in the 'production' namespace.

Practice this question →
17
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 →
18
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.Delete and recreate the pod to clear the crash loop
B.Increase the memory limit in the pod's container resource specification
C.Increase the CPU request for the container
D.Delete the namespace and redeploy all workloads
AnswerB

An OOMKilled event signifies that the container attempted to consume more memory than its configured limits.memory in the pod's resource specification. By increasing this memory limit, you provide the container with additional RAM, allowing it to operate without exceeding its allocated resources. This directly resolves the memory exhaustion issue, preventing the Linux kernel from terminating the process and clearing the CrashLoopBackOff.

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, allowing the container to allocate more memory without being killed by the Out-Of-Memory (OOM) killer.

Exam trap

The trap here is that candidates may confuse OOMKilled with a CPU throttling issue or think that simply restarting the pod will fix the problem, when in fact the memory limit must be adjusted to prevent the OOM killer from terminating the container.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the pod will not resolve the underlying memory limit issue; the new pod will still have the same memory limit and will be OOMKilled again. Option C is wrong because increasing the CPU request does not affect memory allocation; OOMKilled is a memory-related termination, not CPU-related. Option D is wrong because deleting the namespace and redeploying all workloads is an extreme and unnecessary action that does not address the specific memory limit problem and would cause unnecessary disruption.

Practice this question →
19
Multi-Selectmedium

Which TWO of the following are valid methods to provide a token to a Pod for authenticating to the Kubernetes API server?

Select 2 answers
A.Using a ConfigMap to store the token and mounting it
B.Using a projected volume with a ServiceAccountToken projection
C.Storing a token in a Secret and mounting it as a volume
D.Mounting a ServiceAccount token into the pod automatically
E.Setting the token as an environment variable using the downward API
AnswersB, D

You can use a projected volume to inject a token with a specific audience and expiration.

Why this answer

A projected volume with a ServiceAccountToken projection allows you to explicitly control the token's audience, expiration, and path, and it requests a time-bound, audience-scoped token from the TokenRequest API. This is the recommended method for pods that need to authenticate to the Kubernetes API server with custom token properties.

Exam trap

The trap here is that candidates often think storing a token in a Secret and mounting it (Option C) is a valid authentication method, but the CKA tests whether you know that the correct approach is to use the TokenRequest API via a projected volume or rely on the automatic ServiceAccount token mount, not to manually create and mount Secret-based tokens.

Practice this question →
20
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 →
21
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 →
22
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 →
23
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 →
24
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 →
25
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

ServiceAccounts are automatically mounted as volumes in pods, providing a token for API authentication.

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 →
26
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 status to unschedulable, so no new pods are placed, but existing pods remain.

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 →
27
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 →
28
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 →
29
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 →
30
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 →
31
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

This command sets the current context for kubectl.

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 →
32
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 →
33
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 →
34
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 →
35
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 →
36
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 →
37
MCQmedium

An admin wants to view the current context in their kubeconfig. Which command should they use?

A.kubectl config get-contexts
B.kubectl cluster-info
C.kubectl config current-context
D.kubectl config view
AnswerC

kubectl config current-context is the dedicated subcommand that reads the kubeconfig file and prints the name of the currently active context to standard output. It returns exactly one line—the context name—with no additional formatting, making it ideal for scripting and automation. This directly satisfies the admin's need to view the current context, so it is the correct command.

Why this answer

`kubectl config current-context` is the exact command to display the currently active context from the kubeconfig file. The context includes the cluster, namespace, and user that `kubectl` will use by default. This is a direct query of the `current-context` field in the kubeconfig YAML/JSON structure.

Exam trap

The trap here is that candidates often confuse `get-contexts` (which lists all contexts) with `current-context` (which shows only the active one), or they mistakenly think `cluster-info` or `config view` will directly reveal the current context without additional parsing.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts from the kubeconfig file, not just the current one; it requires the user to visually identify the active context (marked with an asterisk). Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., master and services), not the current context from the kubeconfig. Option D is wrong because `kubectl config view` outputs the entire kubeconfig file contents, which includes all contexts, clusters, and users, but does not specifically highlight or return only the current context.

Practice this question →
38
MCQhard

After running 'kubeadm certs check-expiration', an admin sees that the 'apiserver' certificate expires in 30 days. Which command should be used to renew it?

A.kubeadm upgrade node
B.openssl req -new -x509 -days 365 -key /etc/kubernetes/pki/apiserver.key -out /etc/kubernetes/pki/apiserver.crt
C.kubeadm certs renew apiserver
D.kubectl certificate renew apiserver
AnswerC

This renews the apiserver certificate.

Why this answer

`kubeadm certs renew apiserver` is the dedicated kubeadm command to renew the API server certificate without restarting the control plane. It updates the certificate in place using the existing CA, and the new certificate is automatically picked up after a static pod restart or kubelet reload.

Exam trap

The trap here is that candidates may confuse `kubeadm certs renew` with `kubectl certificate` (which handles CSR approval, not renewal) or attempt a manual openssl command that breaks the trust chain, while the correct approach is the kubeadm-managed renewal that preserves CA-signed trust.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade node` is used to upgrade the kubelet configuration on worker nodes, not to renew certificates on the control plane. Option B is wrong because `openssl req -new -x509` creates a self-signed certificate, which would break the PKI trust chain; Kubernetes requires certificates signed by the cluster CA, not self-signed ones. Option D is wrong because `kubectl certificate renew` is not a valid kubectl command; certificate renewal in kubeadm is handled by the `kubeadm certs` subcommand, not kubectl.

Practice this question →
39
MCQmedium

You are using kubeadm to initialize a cluster. After running 'kubeadm init', you follow the instructions to set up the kubeconfig for the regular user. Which of the following commands should you run to allow kubectl to communicate with the cluster?

A.sudo cp /etc/kubernetes/controller-manager.conf $HOME/.kube/config
B.sudo cp /etc/kubernetes/scheduler.conf $HOME/.kube/config
C.sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
D.sudo cp /etc/kubernetes/kubelet.conf $HOME/.kube/config
AnswerC

This copies the admin kubeconfig to the user's home directory, which kubectl uses by default.

Why this answer

After running 'kubeadm init', the admin.conf file is generated in /etc/kubernetes/ and contains the cluster CA certificate, client certificate, and API server endpoint. This is the only kubeconfig file that grants full administrative access to the cluster, making it the correct file to copy to the user's $HOME/.kube/config for kubectl to communicate with the cluster.

Exam trap

The trap here is that candidates confuse the various kubeconfig files generated by kubeadm (each tied to a specific control plane component) and mistakenly copy a component-specific config (like controller-manager.conf or kubelet.conf) instead of the admin.conf, which is the only one designed for administrative kubectl access.

How to eliminate wrong answers

Option A is wrong because /etc/kubernetes/controller-manager.conf is the kubeconfig used by the kube-controller-manager component, not for regular user kubectl access. Option B is wrong because /etc/kubernetes/scheduler.conf is the kubeconfig used by the kube-scheduler component, not for regular user kubectl access. Option D is wrong because /etc/kubernetes/kubelet.conf is the kubeconfig used by the kubelet on the node, not for regular user kubectl access.

Practice this question →
40
Multi-Selecthard

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

Select 3 answers
A.Service account bearer tokens
B.Anonymous requests
C.Static token file
D.Password file with usernames and passwords
E.X.509 client certificates
AnswersA, C, E

Used by pods to authenticate.

Why this answer

Service account bearer tokens are a valid authentication method to the Kubernetes API server. When a pod is associated with a service account, Kubernetes automatically mounts a token into the pod at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the API server validates against the TokenReview API, allowing the pod to authenticate as that service account.

Exam trap

CNCF often tests the misconception that static token files and password files are equivalent, but static token files (option C) are valid while password files (option D) were deprecated and removed, so candidates must remember the deprecation timeline.

Practice this question →
41
MCQeasy

Which command allows you to view the current context in a kubeconfig file?

A.kubectl config get-contexts
B.kubectl cluster-info
C.kubectl config view
D.kubectl config current-context
AnswerD

kubectl config current-context is the dedicated kubectl subcommand that prints exactly the name of the context currently selected for use, reading the current-context field from your kubeconfig. It is the most direct, script-friendly way to determine which cluster and user your kubectl commands will target, and it returns a nonzero exit status if no current context is set.

Why this answer

`kubectl config current-context` is the dedicated kubectl command that displays the currently active context from the kubeconfig file. It reads the `current-context` field from the kubeconfig (typically `~/.kube/config`) and outputs its name, making it the most direct way to view the current context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which lists all contexts) with `kubectl config current-context` (which shows only the active one), leading them to choose A because they see the current context listed with an asterisk, but the question specifically asks for the command that 'allows you to view the current context' — not all contexts.

How to eliminate wrong answers

Option A is wrong because `kubectl config get-contexts` lists all available contexts in the kubeconfig file, but it does not specifically isolate or highlight the current context; it requires visual inspection to identify the one marked with an asterisk. Option B is wrong because `kubectl cluster-info` displays information about the cluster endpoints (e.g., Kubernetes master and services), not the current context from the kubeconfig. Option C is wrong because `kubectl config view` outputs the entire kubeconfig file contents (including contexts, clusters, users, and current-context), which is more verbose and not a targeted way to view just the current context.

Practice this question →
42
MCQeasy

Which command is used to backup etcd data using etcdctl?

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

etcdctl snapshot save <filename> is the canonical etcd backup operation: it connects to the etcd endpoint (default https://127.0.0.1:2379), takes a consistent point-in-time snapshot of the keyspace, and writes it to the specified file. The resulting snapshot is the input used by etcdctl snapshot restore to rebuild a cluster, and it should be created with endpoint, CA, cert, and key flags when TLS is enabled.

Why this answer

`etcdctl snapshot save` is the official command in etcdctl v3 to create a point-in-time backup of the etcd data store. This command captures the entire key-value store and metadata into a snapshot file, which can later be restored using `etcdctl snapshot restore` to recover the cluster state.

Exam trap

The trap here is that candidates confuse the deprecated v2 `etcdctl backup` command with the correct v3 `etcdctl snapshot save` command, or they assume any 'export' or 'dump' verb is sufficient for a full backup.

How to eliminate wrong answers

Option A is wrong because `etcdctl backup` is not a valid command in etcdctl v3; it was used in the deprecated v2 API but is no longer supported. Option B is wrong because `etcdctl export` dumps key-value pairs in JSON format but does not create a consistent, restorable snapshot of the entire etcd data store. Option D is wrong because `etcdctl dump` is not a valid etcdctl command; it may be confused with `etcdctl snapshot save` or other dump utilities but does not exist in the etcdctl CLI.

Practice this question →
43
MCQeasy

Which component on a worker node is responsible for maintaining network rules and forwarding traffic to the correct pod?

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

The kube-proxy is the essential component on each worker node responsible for implementing the Kubernetes Service abstraction. It continuously watches the Kubernetes API server for Service and EndpointSlice objects and translates them into network rules, typically using iptables or IPVS, within the node's kernel. This ensures that requests directed to a Service IP are correctly routed and load-balanced to the healthy Pods backing that Service, effectively maintaining the data plane for cluster networking.

Why this answer

kube-proxy is the correct component because it runs on each worker node and is responsible for implementing Kubernetes Service concepts by maintaining network rules (iptables or IPVS) that allow network communication to Pods from inside or outside the cluster. It forwards traffic to the correct Pod by load-balancing across the endpoints of a Service, using the cluster IP and port.

Exam trap

The trap here is that candidates often confuse kube-proxy with kubelet, thinking the node agent manages networking, but kubelet only ensures Pods are running while kube-proxy specifically handles Service-to-Pod traffic rules.

How to eliminate wrong answers

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

Practice this question →
44
Multi-Selectmedium

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

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

etcd is a distributed, strongly consistent key-value store that holds the authoritative state of the entire Kubernetes cluster, including all objects, configs, and secrets. It is a foundational control plane component because every API read/write is persisted there, and control plane controllers rely on its data. Without a healthy etcd quorum, the cluster cannot function correctly.

Why this answer

etcd is a distributed key-value store that serves as the primary datastore for the Kubernetes cluster, storing all cluster state and configuration data. The kube-controller-manager runs controller processes that regulate the state of the cluster, such as the node controller, replication controller, and endpoints controller. Both are core control plane components that run on the master node(s).

Exam trap

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

Practice this question →
45
MCQeasy

Which command can you use to check the expiration date of certificates managed by kubeadm?

A.kubeadm certs check-expiration
B.kubectl get certificates
C.kubeadm certs list
D.kubeadm certs renew --check
AnswerA

The `kubeadm certs check-expiration` command is the official kubeadm subcommand for inspecting the validity of all certificates managed by kubeadm. It reads the certificate files from the default PKI directory (usually /etc/kubernetes/pki) and from the kubeconfig files in /etc/kubernetes, then prints a table showing the remaining validity period for each certificate. This is the canonical way to audit certificate expiration on a cluster bootstrapped with kubeadm, and it also displays the CA certificates separately from the leaf certificates.

Why this answer

The correct command is `kubeadm certs check-expiration`, which is a dedicated kubeadm subcommand that inspects all certificates managed by kubeadm and displays their expiration dates, remaining validity, and renewal status. This command reads the certificate files from `/etc/kubernetes/pki/` and parses their X.509 metadata, providing a concise summary without requiring external tools like OpenSSL.

Exam trap

The trap here is that candidates confuse the `kubeadm certs` subcommands, often misremembering `list` or inventing flags like `--check`, when the actual command uses the precise verb `check-expiration` to separate inspection from renewal.

How to eliminate wrong answers

Option B is wrong because `kubectl get certificates` is not a valid kubectl command; kubectl interacts with Kubernetes API resources, not filesystem certificates, and there is no built-in 'certificates' resource type. Option C is wrong because `kubeadm certs list` does not exist; the correct subcommand for listing certificate details is `check-expiration`, not `list`. Option D is wrong because `kubeadm certs renew --check` is not a valid flag; the `renew` subcommand performs actual renewal, and there is no `--check` flag — the check functionality is separated into the `check-expiration` subcommand.

Practice this question →
46
MCQeasy

Which command is used to initialize a Kubernetes cluster using kubeadm?

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

kubeadm init is the correct command because it initializes a Kubernetes control-plane node, performing preflight checks, generating PKI certificates, kubeconfig files, and etcd cluster configuration. It is the standard bootstrap mechanism for building a new cluster and is the only valid 'initialization' subcommand in kubeadm's CLI.

Why this answer

The correct command to initialize a Kubernetes cluster using kubeadm is `kubeadm init`. This command performs the bootstrap process by setting up the control plane components (e.g., API server, etcd, controller manager, scheduler) on the node, generating certificates, and creating the necessary configuration files in `/etc/kubernetes/`. It is the standard first step after installing kubeadm, kubelet, and a container runtime.

Exam trap

The trap here is that candidates confuse `kubeadm init` with non-existent commands like `kubeadm create cluster` or `kubeadm bootstrap`, assuming a more intuitive or verbose command exists, when in fact kubeadm's subcommands are deliberately minimal and specific.

How to eliminate wrong answers

Option B is wrong because `kubeadm create cluster` is not a valid kubeadm subcommand; kubeadm uses `init` for control plane initialization and `join` for worker nodes, not a generic 'create cluster'. Option C is wrong because `kubeadm start` does not exist; starting the cluster is handled by the kubelet service and systemd, not by kubeadm directly. Option D is wrong because `kubeadm bootstrap` is not a valid command; the bootstrap process is triggered by `kubeadm init` (or `kubeadm join` for nodes), and there is no separate 'bootstrap' subcommand.

Practice this question →
47
MCQmedium

An admin runs 'kubectl get pods' and sees a pod in 'Pending' state for a long time. 'kubectl describe pod' shows '0/1 nodes are available: 1 node has memory pressure'. Which is the most likely cause?

A.The node's disk is full.
B.The pod's image pull secret is missing.
C.The node is under memory pressure and cannot admit the pod.
D.The pod requires more CPU than any node can provide.
AnswerC

Memory pressure prevents the scheduler from placing the pod on that node.

Why this answer

The '0/1 nodes are available: 1 node has memory pressure' message in `kubectl describe pod` indicates that the kubelet on the node has set a memory pressure condition, which triggers eviction thresholds. When a node is under memory pressure, the kubelet refuses to admit new pods (except those with QoS class Guaranteed) to prevent further resource exhaustion, leaving the pod stuck in Pending state. This matches option C exactly.

Exam trap

CNCF often tests the distinction between different node pressure conditions (memory vs. disk vs. PID) and their corresponding error messages, so candidates must recognize that 'memory pressure' is a specific kubelet condition, not a generic resource shortage.

How to eliminate wrong answers

Option A is wrong because a full disk would cause 'disk pressure', not 'memory pressure', and would be reported as '0/1 nodes are available: 1 node has disk pressure'. Option B is wrong because a missing image pull secret would cause an ImagePullBackOff or ErrImagePull error, not a Pending state with node availability issues. Option D is wrong because insufficient CPU would be reported as 'Insufficient cpu' in the node conditions, not 'memory pressure', and the pod would still be schedulable if memory were available.

Practice this question →
48
MCQhard

A cluster was upgraded from v1.28 to v1.29 using kubeadm. After upgrading the control plane, nodes remain at v1.28. What is the correct next step to upgrade a worker node?

A.Drain the node, then run 'kubeadm upgrade node' on the worker node.
B.SSH into the worker node and run 'kubeadm upgrade node', then upgrade kubelet and kubectl, then restart kubelet.
C.Upgrade kubelet on the worker node using the package manager and restart kubelet.
D.Run 'kubeadm upgrade apply' on the worker node.
AnswerB

This is the standard procedure for upgrading a worker node with kubeadm.

Why this answer

After upgrading the control plane with kubeadm, worker nodes must be upgraded individually. The correct sequence is to SSH into the worker node, run 'kubeadm upgrade node' to upgrade the kubelet configuration and static pod manifests, then upgrade the kubelet and kubectl binaries (typically via the package manager), and finally restart the kubelet to pick up the new version. This ensures the node runs the same Kubernetes version as the control plane.

Exam trap

The trap here is that candidates often assume simply upgrading the kubelet binary via the package manager is sufficient, but the CKA exam tests the understanding that 'kubeadm upgrade node' must be run first to update the node's configuration and static pod manifests, ensuring a complete and consistent upgrade.

How to eliminate wrong answers

Option A is wrong because 'kubeadm upgrade node' is the correct command, but draining the node before running it is not strictly required as the first step; the standard procedure is to upgrade the node first, then drain and uncordon as needed for workload migration. Option C is wrong because upgrading only the kubelet binary without running 'kubeadm upgrade node' will not update the node's kubelet configuration or static pod manifests, leading to version mismatches and potential cluster instability. Option D is wrong because 'kubeadm upgrade apply' is used only on the control plane node to upgrade the cluster state; running it on a worker node is invalid and will fail.

Practice this question →
49
MCQhard

You are performing a backup of etcd using the command: 'ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db'. You get an error: 'Error: context deadline exceeded'. What is the most likely cause?

A.The endpoint flag is missing or incorrect, causing the client to timeout trying to connect
B.The etcdctl version is incompatible with etcd
C.The etcd cluster is not running
D.The snapshot file already exists and is locked
AnswerA

When etcdctl attempts to connect to the etcd cluster without a specified --endpoints flag, it defaults to localhost:2379. In many Kubernetes environments, etcd runs on a dedicated control plane node, often with a different IP address, or behind a firewall, or even on a non-standard port. If the client cannot establish a connection to the default or specified endpoint within the configured timeframe, the operation will result in a "context deadline exceeded" or similar timeout error, indicating that the server did not respond to the connection attempt. This is distinct from an active refusal.

Why this answer

The error 'context deadline exceeded' indicates that the etcdctl client attempted to connect to the etcd endpoint but the request timed out before a connection could be established. This is most commonly caused by the --endpoints flag being omitted or pointing to an incorrect address (e.g., localhost:2379 instead of the actual etcd listener), so the client cannot reach the etcd server within the default timeout period.

Exam trap

The trap here is that candidates may assume the error is due to the cluster being down or a file lock, but the 'deadline exceeded' message specifically points to a network connectivity or endpoint misconfiguration issue, not a server-side unavailability or filesystem problem.

How to eliminate wrong answers

Option B is wrong because an incompatible etcdctl version typically produces a different error, such as 'etcdserver: api version mismatch' or 'rpc error: code = Unimplemented', not a context deadline exceeded. Option C is wrong because if the etcd cluster is not running, the client would receive a 'connection refused' error immediately, not a timeout after a deadline. Option D is wrong because a locked or existing snapshot file would cause a file write error (e.g., 'file exists' or 'permission denied'), not a network-level timeout error.

Practice this question →
50
MCQmedium

An administrator runs 'kubectl cordon node1' and then 'kubectl drain node1 --ignore-daemonsets'. What is the effect on node1?

A.Node1 is marked as unschedulable and all pods except DaemonSets are evicted
B.Node1 is marked as unschedulable but no pods are evicted
C.New pods are scheduled onto node1 and existing pods are evicted
D.Node1 is marked as schedulable and all pods are evicted
AnswerA

The `kubectl cordon node1` command initially marks `node1` as unschedulable, preventing the Kubernetes scheduler from placing any new pods on it. Subsequently, `kubectl drain node1` proceeds to gracefully evict all existing pods from the node. By default, or with the `--ignore-daemonsets` flag, pods managed by DaemonSets are typically not evicted during a drain operation, as they are designed to run one instance per node. This combined action prepares the node for maintenance without disrupting critical system services.

Why this answer

The `kubectl cordon node1` command marks node1 as unschedulable, preventing new pods from being scheduled onto it. The subsequent `kubectl drain node1 --ignore-daemonsets` command evicts all pods from node1 except DaemonSets (which are ignored because they are managed by the DaemonSet controller and typically need to run on every node). This combination makes node1 unschedulable and removes all non-DaemonSet pods, preparing the node for maintenance.

Exam trap

The trap here is that candidates often confuse `cordon` (which only marks the node unschedulable) with `drain` (which evicts pods), or mistakenly think `--ignore-daemonsets` means no pods are evicted at all, when in fact it only excludes DaemonSet pods from eviction.

How to eliminate wrong answers

Option B is wrong because the drain command with `--ignore-daemonsets` does evict pods (except DaemonSets), not just mark the node unschedulable. Option C is wrong because the cordon command marks the node as unschedulable, so new pods are not scheduled onto node1; additionally, the drain command evicts existing pods, not schedules new ones. Option D is wrong because cordon marks the node as unschedulable, not schedulable, and the drain command evicts all pods except DaemonSets, not all pods.

Practice this question →
51
MCQeasy

Which command displays the expiration date of all certificates managed by kubeadm?

A.kubeadm certs check-expiration
B.kubeadm alpha certs check-expiration
C.kubeadm certs list
D.kubectl get certificates
AnswerA

kubeadm certs check-expiration is the official command that reads the X.509 certificates under /etc/kubernetes/pki and prints a table containing each certificate's common name, expiry date, and residual time. It also highlights certificates that are already expired or about to expire, allowing administrators to plan a kubeadm certificate renew or upgrade. This is the only command that directly answers the question of certificate expiration for kubeadm-managed clusters.

Why this answer

`kubeadm certs check-expiration` is the dedicated command in kubeadm v1.15+ that inspects the expiration dates of all certificates managed by kubeadm, including those for the API server, kubelet, and etcd. It reads certificate files from `/etc/kubernetes/pki/` and displays their remaining validity period in a human-readable table.

Exam trap

The trap here is that candidates confuse `kubeadm` certificate management commands with `kubectl` CSR resources, or assume an outdated `alpha` subcommand is still valid, leading them to pick B or D instead of the correct A.

How to eliminate wrong answers

Option B is wrong because `kubeadm alpha certs check-expiration` was deprecated in kubeadm v1.15 and removed in v1.20; the `alpha` subcommand no longer exists in current versions, making this command invalid. Option C is wrong because `kubeadm certs list` is not a valid kubeadm subcommand; the correct verb is `check-expiration`, not `list`. Option D is wrong because `kubectl get certificates` targets Kubernetes CertificateSigningRequest (CSR) resources, not the static certificate files managed by kubeadm; it shows CSR status, not expiration dates of the actual X.509 certificates on disk.

Practice this question →
52
MCQhard

You need to back up etcd on a single control plane node. Which command correctly creates a snapshot?

A.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 snapshot save /backup/etcd-snapshot.db
B.ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db
C.etcdctl snapshot save /backup/etcd-snapshot.db
D.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db
AnswerD

This is the correct backup command: it forces the v3 API, explicitly connects to the local etcd endpoint via HTTPS, and supplies the CA certificate and client certificate/key from the standard kubeadm PKI paths. Those credentials satisfy etcd's mutual TLS requirement and allow a verified snapshot to be written to /backup/etcd-snapshot.db.

Why this answer

It uses the required `ETCDCTL_API=3` environment variable and specifies the necessary TLS client certificates (`--cacert`, `--cert`, `--key`) to authenticate to the etcd server, which by default listens on `https://127.0.0.1:2379` with mutual TLS enabled. The `snapshot save` command creates a point-in-time backup of the etcd data store, essential for disaster recovery in a Kubernetes control plane.

Exam trap

The trap here is that candidates often forget the TLS certificates or the `ETCDCTL_API=3` variable, assuming a simple `etcdctl snapshot save` will work, but the CKA exam environment enforces secure connections requiring full authentication flags.

How to eliminate wrong answers

Option A is wrong because it omits the required TLS certificate flags (`--cacert`, `--cert`, `--key`), so the command will fail with a certificate verification error when connecting to the etcd server over HTTPS. Option B is wrong because `snapshot restore` is used to restore a snapshot to a new data directory, not to create a backup; it does not produce a snapshot file. Option C is wrong because it lacks both the `ETCDCTL_API=3` environment variable (which enables the v3 API) and the required TLS flags, and it does not specify the endpoint, so it defaults to the v2 API and will fail to connect.

Practice this question →
53
MCQmedium

A developer needs to create a Role that allows listing pods in the 'dev' namespace. Which YAML snippet correctly defines this Role?

A.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-lister rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]
B.apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-lister-binding namespace: dev subjects: - kind: User name: dev-user roleRef: kind: Role name: pod-lister apiGroup: rbac.authorization.k8s.io
C.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-lister namespace: dev rules: - apiGroups: [""] resources: ["pods"] verbs: ["list"]
D.apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-lister rules: - apiGroups: [""] resources: ["pods"] verbs: ["get"]
AnswerC

This defines a Role in the dev namespace with list pods permission.

Why this answer

It defines a Role (not ClusterRole) scoped to the 'dev' namespace with the 'list' verb on 'pods', which matches the requirement exactly. In Kubernetes RBAC, a Role grants permissions within a specific namespace, and the empty apiGroups string [""] refers to the core API group where pods reside.

Exam trap

The trap here is that candidates often confuse 'get' with 'list' or choose a ClusterRole thinking it can be used for namespace-scoped access, but the CKA exam tests precise understanding that a Role must be namespace-scoped and use the correct verb for the intended operation.

How to eliminate wrong answers

Option A is wrong because it defines a ClusterRole, which is cluster-scoped and not namespace-scoped; while a ClusterRole can be used to grant permissions across namespaces, the requirement specifically asks for a Role in the 'dev' namespace. Option B is wrong because it defines a RoleBinding, which binds a Role to a user but does not define the Role itself; the question asks for the Role definition, not the binding. Option D is wrong because it defines a Role with the verb 'get' instead of 'list'; 'get' allows retrieving a specific pod by name, but the requirement is to list pods, which requires the 'list' verb.

Practice this question →
54
MCQmedium

An administrator runs 'kubectl run test-pod --image=nginx' and the pod is created but stays in 'Pending' state. Which command would BEST help diagnose why the pod is not running?

A.kubectl logs test-pod
B.kubectl describe pod test-pod
C.kubectl exec -it test-pod -- /bin/bash
D.kubectl get events
AnswerB

The `kubectl describe pod` command provides a comprehensive, human-readable summary of a specific pod's current state, including its status, conditions, and a chronological list of *events* directly associated with it. For a pending pod, this command is invaluable as it surfaces critical information such as scheduler decisions, volume attachment issues, image pull failures, or resource constraints directly within the 'Events' section, clearly indicating the root cause of the pending state.

Why this answer

`kubectl describe pod test-pod` provides a detailed summary of the pod's current state, including events, conditions, and status messages that reveal why the pod is stuck in 'Pending'. The 'Pending' state typically indicates that the pod has not been scheduled to a node, often due to resource constraints (CPU/memory), persistent volume claims not being bound, or node selector mismatches. The 'Conditions' and 'Events' sections in the output directly expose these issues, making it the most effective diagnostic command.

Exam trap

The trap here is that candidates often assume `kubectl logs` or `kubectl exec` can diagnose startup issues, but these commands only work on running containers, so they fail silently or with errors when the pod is still pending, wasting time and misdirecting troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl logs test-pod` retrieves container logs, but the pod is in 'Pending' state and has not started any containers, so there are no logs to fetch; this command would fail with an error like 'container is waiting to start'. Option C is wrong because `kubectl exec -it test-pod -- /bin/bash` attempts to execute a command inside a running container, but since the pod is not running (Pending), there is no container to attach to, and the command will fail. Option D is wrong because `kubectl get events` shows cluster-wide events, which may include relevant information but is less targeted than `kubectl describe pod`; it requires filtering through many events and may not show pod-specific details like scheduler failure reasons or volume binding errors as clearly.

Practice this question →
55
MCQmedium

A cluster was installed using kubeadm. You need to upgrade the cluster from v1.28 to v1.29. Which of the following is the correct order of operations?

A.Drain each node, upgrade control plane, then upgrade worker nodes
B.Drain control plane node, upgrade kubeadm and kubelet on control plane, uncordon, then repeat for worker nodes
C.Upgrade worker nodes first, then control plane nodes
D.Upgrade all nodes simultaneously
AnswerB

This is the exact procedure recommended by the official kubeadm upgrade documentation: for the control plane node, run `kubectl drain` (with `--ignore-daemonsets`), upgrade the `kubeadm` binary, run `kubeadm upgrade apply`, upgrade `kubelet`, restart it, then `uncordon` the node. Repeating the same drain-upgrade-uncordon cycle for worker nodes ensures they remain within the supported version skew and maintains cluster availability throughout the rolling upgrade.

Why this answer

The kubeadm upgrade process requires the control plane node to be upgraded first, as it hosts the core cluster components (API server, scheduler, controller-manager). Draining the node ensures workloads are evicted, then kubeadm and kubelet are upgraded on the control plane, followed by uncordoning. Worker nodes are upgraded afterward to maintain cluster stability and compatibility.

Exam trap

The trap here is that candidates often assume all nodes can be upgraded in any order or simultaneously, but the CKA requires strict sequential upgrade of control plane first, then workers, with drain/uncordon steps.

How to eliminate wrong answers

Option A is wrong because it suggests draining all nodes before upgrading, but the control plane must be upgraded first, not simultaneously with workers. Option C is wrong because upgrading worker nodes before the control plane would break cluster coordination, as the API server version must be higher or equal to kubelet versions. Option D is wrong because upgrading all nodes simultaneously is not supported with kubeadm; it would cause version mismatches and potential cluster downtime.

Practice this question →
56
MCQeasy

Which component is responsible for maintaining network rules on worker nodes?

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

kube-proxy is the component that directly maintains network rules on each node. It watches the Kubernetes API for Service and EndpointSlice objects, then programs iptables rules (or IPVS entries) to translate a Service's ClusterIP to the IP addresses of its backing Pods. This provides load-balanced, virtual-IP connectivity to Pods without a traditional proxy process in the data path.

Why this answer

kube-proxy is the component responsible for maintaining network rules on worker nodes. It watches the Kubernetes API server for changes to Services and EndpointSlices, then updates iptables, IPVS, or userspace rules on the node to route traffic to the correct Pods. This ensures that network traffic directed at a Service's ClusterIP or NodePort is properly forwarded to the backend Pods.

Exam trap

The trap here is that candidates often confuse kubelet with kube-proxy because both run on worker nodes, but kubelet manages containers while kube-proxy manages network rules.

How to eliminate wrong answers

Option B (kube-scheduler) is wrong because it is responsible for assigning Pods to nodes based on resource availability and scheduling policies, not for maintaining network rules. Option C (kubelet) is wrong because it is the primary node agent that manages Pod lifecycle, container health, and mounts volumes, but it does not handle network rule enforcement. Option D (kube-controller-manager) is wrong because it runs controller processes such as the Node Controller, Replication Controller, and Endpoint Controller, but it does not implement per-node network rules.

Practice this question →
57
MCQeasy

You are setting up a new Kubernetes cluster using kubeadm. After running 'kubeadm init', you want to start using the cluster with kubectl. Which of the following commands should you run to configure kubectl for the admin user?

A.mkdir -p $HOME/.kube && sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config
B.sudo kubeadm reset --force
C.sudo cp /etc/kubernetes/admin.conf /root/.kube/config
D.sudo cp /etc/kubernetes/pki/admin.conf $HOME/.kube/config
AnswerA

This is the correct sequence: `mkdir -p $HOME/.kube` ensures the default kubeconfig directory exists, `sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config` copies the cluster-admin kubeconfig generated by kubeadm into the current user's home, and `sudo chown $(id -u):$(id -g) $HOME/.kube/config` makes the file readable/writable by the current user. Because the admin.conf file is owned by root (readable only by root), sudo is required for the copy; without the chown, kubectl would fail to read the kubeconfig. The resulting `~/.kube/config` is discovered automatically by kubectl, granting full cluster-admin privileges to the local user.

Why this answer

After running 'kubeadm init', the admin kubeconfig file is generated at /etc/kubernetes/admin.conf. To use kubectl as a regular (non-root) user, you must copy this file to the user's $HOME/.kube/config directory and then change its ownership to the current user. This ensures kubectl can authenticate to the cluster using the admin certificate and key embedded in the config file.

Exam trap

The trap here is that candidates might mistakenly copy the admin.conf to /root/.kube/config (option C) thinking it works for any user, or confuse the admin.conf location with the pki directory (option D), while the correct approach requires copying to the current user's home directory and fixing ownership.

How to eliminate wrong answers

Option B is wrong because 'kubeadm reset --force' is used to tear down a cluster or reinitialize it, not to configure kubectl; running it would destroy the cluster state. Option C is wrong because it copies the admin.conf to /root/.kube/config, which only configures kubectl for the root user, not for the current admin user; the CKA environment typically expects non-root usage. Option D is wrong because it references /etc/kubernetes/pki/admin.conf, which does not exist — the admin kubeconfig is located at /etc/kubernetes/admin.conf, not in the pki directory.

Practice this question →
58
MCQeasy

Which component is responsible for assigning pods to nodes?

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

kube-scheduler is the control plane component that selects the optimal node for each newly created pod. It subscribes to the API server's watch stream for pending pods, filters nodes according to resource requirements, taints/tolerations, node selectors, and affinity rules, then scores the feasible candidates to choose the best match. The decision is written back as a binding object, which sets the pod's nodeName field, so this component alone is responsible for assigning pods to nodes.

Why this answer

The kube-scheduler is responsible for assigning pods to nodes based on resource requirements, constraints, and policies. It watches for newly created pods that have no node assignment and selects an optimal node for each pod to run on.

Exam trap

The trap here is that candidates often confuse the kubelet's role of running pods with the scheduler's role of assigning pods to nodes, or think the API server handles scheduling because it processes pod creation requests.

How to eliminate wrong answers

Option B is wrong because kubelet is the agent that runs on each node and ensures containers are running in a pod, but it does not decide which node a pod should be scheduled on. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane and handles API requests, but it does not perform scheduling decisions. Option D is wrong because kube-controller-manager runs controller processes like replication controller and node controller, but pod-to-node assignment is the scheduler's responsibility.

Practice this question →
59
MCQmedium

A developer wants to run a one-time batch job that processes data and then exits. Which Kubernetes resource should be used?

A.DaemonSet
B.CronJob
C.Deployment
D.Job
AnswerD

A Kubernetes Job creates one or more pods and ensures that a specified number of them successfully terminate, tracking the overall completion. It is the ideal controller for a one-time batch task because the pod runs to completion and the Job status becomes Complete, without any automatic restart of the finished pod. If the pod fails, the Job can restart it according to the backoffLimit, ensuring the task eventually succeeds.

Why this answer

A Job is the correct Kubernetes resource for a one-time batch task that runs to completion and then exits. It ensures a specified number of Pods terminate successfully, making it ideal for processing data and exiting without requiring continuous availability.

Exam trap

The trap here is that candidates often confuse a CronJob with a Job, assuming any batch-like task requires scheduling, but the question explicitly says 'one-time,' which eliminates the need for a schedule.

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, providing continuous background services like logging or monitoring, not a one-time batch job. Option B is wrong because a CronJob is used for scheduling recurring tasks at specified times (e.g., every hour), not for a single execution. Option C is wrong because a Deployment manages a set of replica Pods intended to run indefinitely, maintaining a desired state with rolling updates, not a finite task that exits.

Practice this question →
60
MCQmedium

A pod is failing with 'CrashLoopBackOff'. You run 'kubectl logs mypod' and see no output. What is the first troubleshooting step?

A.kubectl logs mypod --previous
B.kubectl exec -it mypod -- sh
C.kubectl delete pod mypod && kubectl create -f mypod.yaml
D.kubectl describe pod mypod
AnswerA

The `kubectl logs mypod --previous` command is the correct approach because a `CrashLoopBackOff` state indicates that the container has started, crashed, and Kubernetes is attempting to restart it. The `--previous` flag is crucial as it retrieves the logs from the *last terminated instance* of the container, which contains the actual error messages or stack traces that caused the crash, rather than the potentially empty logs of the currently restarting container.

Why this answer

The correct first step is to use `kubectl logs mypod --previous` because the pod is in `CrashLoopBackOff`, meaning the current container has crashed and restarted. Since `kubectl logs mypod` shows no output, the current container may have exited before writing logs, or logs were written to stderr. The `--previous` flag retrieves logs from the last terminated container instance, which often contains the crash error message.

Exam trap

The trap here is that candidates assume `kubectl logs` shows all available logs, forgetting that a crashed container's output is only accessible via the `--previous` flag, leading them to choose `kubectl describe pod` or exec instead.

How to eliminate wrong answers

Option B is wrong because `kubectl exec -it mypod -- sh` attempts to start an interactive shell in a running container, but the pod is in `CrashLoopBackOff` and the container is not running, so exec will fail with an error like 'cannot exec into a container in a crashed state'. Option C is wrong because deleting and recreating the pod will lose the previous container's logs and crash history, making debugging harder; it is a reactive restart, not a diagnostic step. Option D is wrong because `kubectl describe pod mypod` shows pod events and status but does not provide the application-level error output from the crashed container; it is useful for infrastructure issues but not for application crash logs.

Practice this question →
61
MCQhard

You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?

A.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io
B.kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io
C.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: ClusterRole name: deployer apiGroup: rbac.authorization.k8s.io
D.apiVersion: v1 kind: ServiceAccount metadata: name: deployer namespace: app --- kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: default rules: - apiGroups: ["apps"] resources: ["deployments"] verbs: ["create"] --- kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: deployer namespace: app subjects: - kind: ServiceAccount name: deployer namespace: app roleRef: kind: Role name: deployer apiGroup: rbac.authorization.k8s.io
AnswerA

This is the correct solution as it precisely meets the requirements. It creates a `ServiceAccount` named `deployer` in the `app` namespace. A `Role` is then defined in the `app` namespace, granting the specific permission to create `deployments`. Finally, a `RoleBinding` in the `app` namespace associates this namespaced `Role` with the `deployer` `ServiceAccount`, ensuring permissions are confined strictly to the 'app' namespace.

Why this answer

It creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Exam trap

A common pitfall is the misconception that a RoleBinding can only bind a Role, but in fact a RoleBinding can bind a ClusterRole, granting the ClusterRole's permissions only within the RoleBinding's namespace. Therefore, option C is technically valid and would also satisfy the requirement. However, the exam's expected answer is option A because it uses a namespaced Role, adhering to the principle of least privilege.

Option B is incorrect because it uses a ClusterRoleBinding, which grants permissions cluster-wide. Option D is incorrect because the Role is created in the 'default' namespace instead of 'app'.

How to eliminate wrong answers

Option B is wrong because it uses a ClusterRole and ClusterRoleBinding, which grant permissions cluster-wide (across all namespaces), not just in the 'app' namespace as required. Option C is wrong because it uses a ClusterRole with a RoleBinding; while a RoleBinding can reference a ClusterRole, the binding itself is namespaced, but the ClusterRole's scope is still cluster-wide, which is unnecessarily broad and not the minimal required RBAC for a single namespace. Option D is wrong because the Role is defined in the 'default' namespace, not in the 'app' namespace, so the RoleBinding in 'app' cannot reference a Role from a different namespace; Role and RoleBinding must be in the same namespace.

Practice this question →
62
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 memory limit in the pod's container resource specification
B.Delete the namespace and redeploy all workloads
C.Delete and recreate the pod to clear the crash loop
D.Increase the CPU request for the container
AnswerA

Increasing the memory limit in the pod's container resource specification directly addresses a CrashLoopBackOff state caused by OOMKilled (Out Of Memory Killed). When a container exceeds its allocated memory limit, the host kernel's OOM killer terminates the process, causing the container to crash. By providing more memory, the application has sufficient resources to operate without being prematurely terminated, allowing the pod to transition to a Running state.

Why this answer

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

Exam trap

CNCF often tests the misconception that restarting or recreating the pod will resolve a CrashLoopBackOff caused by resource limits, but the trap here is that the OOMKilled error is a resource constraint issue, not a transient failure, so only adjusting the memory limit or removing the limit will stop the crash loop.

How to eliminate wrong answers

Option B is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime for all workloads in the namespace. Option C is wrong because deleting and recreating the pod will only restart the container with the same memory limit, resulting in the same OOMKilled crash and continued CrashLoopBackOff. Option D is wrong because increasing the CPU request does not affect memory constraints; the OOMKilled error is caused by exceeding the memory limit, not CPU resources.

Practice this question →
63
Multi-Selectmedium

You are applying the following RBAC manifest: --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: development name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"] Which TWO statements are true about this Role? (Choose TWO.)

Select 2 answers
A.It also grants access to secrets in the 'development' namespace
B.It allows reading pod details in the 'development' namespace
C.It grants permissions across all namespaces
D.It grants permissions only within the 'development' namespace
E.It allows creating pods in the 'development' namespace
AnswersB, D

This Role grants the verbs "get," "watch," and "list" for the "pods" resource, which are all read-only operations in Kubernetes RBAC. "get" retrieves a single pod's details, "list" enumerates pods, and "watch" streams pod changes. Because the rule is scoped to the development namespace via a Role and the verbs are read-only, this correctly describes the permission to read pod details in that namespace.

Why this answer

The Role explicitly defines rules for the 'pods' resource with verbs 'get', 'watch', and 'list' in the 'development' namespace. These verbs allow reading pod details such as their specifications, status, and metadata. The Role is scoped to the 'development' namespace, so it only grants these read permissions within that namespace.

Exam trap

The trap here is that candidates often confuse a Role with a ClusterRole, mistakenly thinking a Role can grant permissions across all namespaces, or they assume that granting access to 'pods' implicitly grants access to related resources like secrets or logs.

Practice this question →
64
MCQhard

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

A.The pod is missing resource requests.
B.The pod does not tolerate the node's taint.
C.The node is cordoned.
D.The kubelet is not running on the node.
AnswerB

The taint is preventing scheduling unless the pod has a toleration.

Why this answer

The pod is stuck in 'Pending' because the scheduler cannot find a node that satisfies its scheduling constraints. The 'kubectl describe pod' output explicitly states that 1 node has a taint (node-role.kubernetes.io/master) that the pod does not tolerate. By default, pods do not tolerate the master taint, so they are not scheduled onto master nodes unless a toleration is added.

This is the direct cause of the pending state.

Exam trap

The trap here is that candidates may confuse taints with node cordoning or resource constraints, but the specific error message about 'taint that the pod didn't tolerate' directly points to a toleration mismatch, not a resource or node readiness issue.

How to eliminate wrong answers

Option A is wrong because missing resource requests would cause the scheduler to fail with a different error message, such as 'Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option C is wrong because a cordoned node would show 'node(s) were cordoned' or 'node(s) had taint node.kubernetes.io/unschedulable' in the describe output, not a taint about node-role.kubernetes.io/master. Option D is wrong because if the kubelet were not running, the node would show as 'NotReady' and the scheduler would report '0/1 nodes are available: 1 node(s) were not ready', not a taint-related message.

Practice this question →
65
MCQmedium

Which kubeconfig context is currently active?

A.kubectl config view
B.kubectl cluster-info
C.kubectl config get-contexts
D.kubectl config current-context
AnswerD

Directly shows current context.

Why this answer

`kubectl config current-context` is the dedicated kubectl command that displays the name of the currently active context from the kubeconfig file. The active context determines which cluster, user, and namespace are used by default for kubectl commands, making this the precise way to identify the active context.

Exam trap

The trap here is that candidates often confuse `kubectl config get-contexts` (which shows all contexts with an asterisk on the active one) with a command that directly outputs only the active context, leading them to choose option C instead of the more precise D.

How to eliminate wrong answers

Option A is wrong because `kubectl config view` displays the entire kubeconfig file contents (clusters, users, contexts) but does not explicitly indicate which context is currently active; it requires manual inspection to find the `current-context` field. Option B is wrong because `kubectl cluster-info` shows information about the cluster the current context points to (e.g., control plane endpoints), not the name of the active context itself. Option C is wrong because `kubectl config get-contexts` lists all available contexts and marks the active one with an asterisk (*) in the output, but it does not directly output just the active context name; it requires parsing the list.

Practice this question →
66
MCQhard

A user reports that they can't authenticate to the cluster using a kubeconfig file. Running 'kubectl config view' shows the current context points to a user with client certificate and key. Which command checks the expiration date of the client certificate?

A.kubeadm upgrade plan --certificate-expiration
B.kubectl config view --raw | grep client-certificate
C.openssl x509 -in /etc/kubernetes/admin.conf -text -noout
D.kubeadm certs check-expiration
AnswerD

This subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.

Why this answer

`kubeadm certs check-expiration` is the dedicated kubeadm command to display expiration dates for all PKI certificates in the cluster, including the client certificate used by the user's kubeconfig. This command parses the certificates directly from the `/etc/kubernetes/pki` directory and shows remaining validity, making it the precise tool for this scenario.

Exam trap

The trap here is that candidates confuse the kubeconfig file (a YAML configuration) with a certificate file, leading them to incorrectly use `openssl` directly on the kubeconfig or grep for the certificate data without parsing its expiration.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade plan --certificate-expiration` is not a valid flag; `kubeadm upgrade plan` shows upgrade options, not certificate expiration. Option B is wrong because `kubectl config view --raw | grep client-certificate` only outputs the path or base64-encoded certificate data, not the expiration date; it does not decode or parse the certificate. Option C is wrong because `openssl x509 -in /etc/kubernetes/admin.conf -text -noout` attempts to read a kubeconfig file as a certificate, but `admin.conf` is a YAML file, not a PEM-encoded certificate; the command would fail or produce garbage.

Practice this question →
67
Multi-Selectmedium

Your cluster has three control plane nodes. You suspect the etcd cluster has a leader election issue. Which TWO commands can help diagnose the etcd cluster health and membership? (Choose TWO.)

Select 2 answers
A.etcdctl cluster-status
B.etcdctl version
C.etcdctl endpoint health --cluster
D.etcdctl snapshot save snapshot.db
E.etcdctl member list
AnswersC, E

`etcdctl endpoint health --cluster` queries every endpoint listed in the cluster's member information and reports each endpoint's health and latency. The `--cluster` flag tells the client to read the member list from an existing endpoint and check all members, not just a single address. A healthy response from all endpoints indicates the cluster is operational and has quorum, making this an effective first diagnostic.

Why this answer

`etcdctl endpoint health --cluster` queries the health status of all etcd endpoints in the cluster, which directly reveals if any node is unreachable or unhealthy—a common symptom of leader election issues. Option E is correct because `etcdctl member list` displays the current cluster membership, including each member's ID, name, peer URLs, and client URLs, allowing you to verify that all expected control plane nodes are properly joined and that no split-brain or quorum loss has occurred.

Exam trap

The trap here is that candidates may confuse `etcdctl cluster-status` (which does not exist) with the valid `etcdctl endpoint status` command, or they may think snapshot commands are diagnostic tools rather than backup utilities.

Practice this question →
68
MCQhard

You are asked to backup the etcd database on a control plane node. The etcd is running as a static pod. Which command sequence will create a consistent snapshot?

A.kubectl exec -n kube-system etcd-controlplane -- etcdctl snapshot save /backup/etcd-snapshot.db
B.ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snapshot.db
C.ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /backup/etcd-snapshot.db
D.etcdctl --endpoints=http://localhost:2379 snapshot save /backup/etcd-snapshot.db
AnswerC

This command is the correct approach for backing up an etcd database on a Kubernetes control plane. It explicitly sets `ETCDCTL_API=3` for compatibility with modern etcd versions, specifies the secure HTTPS endpoint `https://127.0.0.1:2379`, and provides all required TLS certificates (`--cacert`, `--cert`, `--key`) for mutual authentication with the etcd server. This ensures a secure and successful connection, allowing `etcdctl` to perform the snapshot operation reliably.

Why this answer

It uses the etcdctl v3 API with the required authentication flags (--cacert, --cert, --key) and the correct endpoint (https://127.0.0.1:2379) to connect to the etcd server running as a static pod. This ensures a consistent snapshot is taken over the secure gRPC connection, which is mandatory when etcd is configured with TLS.

Exam trap

The trap here is that candidates assume 'kubectl exec' into the etcd pod (Option A) is sufficient, but they forget that etcdctl inside the pod still needs explicit TLS flags and endpoint specification, or they mistakenly use an insecure HTTP endpoint (Option D) without realizing that production etcd requires HTTPS.

How to eliminate wrong answers

Option A is wrong because 'kubectl exec' into the etcd container runs etcdctl inside the pod, but it does not automatically provide the necessary TLS certificates or endpoint, and the command lacks the required --cacert, --cert, --key flags, so it will fail to authenticate. Option B is wrong because it runs etcdctl on the host without specifying an endpoint or TLS credentials, so it defaults to the local unix socket or insecure connection, which will not reach the etcd server running as a static pod with TLS enabled. Option D is wrong because it uses an HTTP endpoint (http://localhost:2379) instead of HTTPS, and etcd in a production cluster (including static pods) requires TLS encryption; the connection will be refused or fail authentication.

Practice this question →
69
MCQmedium

You have a kubeconfig file with multiple contexts. How do you switch to the context named 'prod-cluster'?

A.kubectl config set-cluster prod-cluster
B.kubectl config set-context prod-cluster
C.kubectl config view prod-cluster
D.kubectl config use-context prod-cluster
AnswerD

kubectl config use-context prod-cluster is the correct command because it explicitly writes the name prod-cluster to the current-context field in the kubeconfig file. After this runs, kubectl commands resolve the current context to prod-cluster and load its associated cluster and user credentials. It is the direct counterpart to the question's intent of switching the active context.

Why this answer

`kubectl config use-context` is the command specifically designed to switch the current context in a kubeconfig file. It updates the `current-context` field in the kubeconfig to point to the specified context, which then determines which cluster, user, and namespace are used by default for subsequent `kubectl` commands.

Exam trap

The trap here is that candidates confuse `set-context` (which defines a context) with `use-context` (which activates it), leading them to pick option B instead of D.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-cluster` only modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, it does not change the active context. Option B is wrong because `kubectl config set-context` creates or modifies a context entry (associating a cluster, user, and namespace) but does not switch to it; it only defines the context. Option C is wrong because `kubectl config view` displays the contents of the kubeconfig file (or a merged view) and does not alter the current context.

Practice this question →
70
MCQhard

A ServiceAccount 'monitor-sa' needs to be able to list Pods in namespace 'monitoring'. Which RBAC configuration is appropriate?

A.Create a ClusterRole with 'get' and 'list' verbs on pods, then a ClusterRoleBinding to monitor-sa
B.Add the ServiceAccount to the cluster-admin group
C.Create a Role in default namespace with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa
D.Create a Role in namespace 'monitoring' with 'get' and 'list' verbs on pods, then a RoleBinding in 'monitoring' to monitor-sa
AnswerD

Why this answer

A Role in the 'monitoring' namespace with 'get' and 'list' verbs on pods, combined with a RoleBinding in the same namespace to the 'monitor-sa' ServiceAccount, grants the exact permissions required within the scope of that namespace. This follows the principle of least privilege by scoping permissions to the specific namespace where the pods reside.

Exam trap

The trap here is that candidates often confuse the scope of Roles versus ClusterRoles, mistakenly using a ClusterRole when a namespace-scoped Role is sufficient, or creating a Role in the wrong namespace and assuming a RoleBinding can bridge namespaces.

How to eliminate wrong answers

Option A is wrong because a ClusterRole with 'get' and 'list' verbs on pods, bound via a ClusterRoleBinding, would grant these permissions cluster-wide (across all namespaces), which is excessive for a requirement limited to the 'monitoring' namespace. Option B is wrong because adding the ServiceAccount to the 'cluster-admin' group grants full cluster-wide administrative privileges, violating the principle of least privilege and far exceeding the need to only list pods. Option C is wrong because a Role created in the 'default' namespace cannot grant permissions in the 'monitoring' namespace; RoleBindings only apply within the namespace of the Role, so the binding in 'monitoring' would have no effect.

Practice this question →
71
MCQmedium

A developer created a ClusterRole named 'pod-reader' with rules to get and list pods. They created a ClusterRoleBinding 'read-pods-global' binding this ClusterRole to a service account 'sa-pod-reader' in the 'default' namespace. Which of the following is true about the permissions of this service account?

A.The service account can only read pods in the 'default' namespace
B.The service account can read pods in all namespaces
C.The service account can only list pods, not get them
D.The service account cannot read pods in any namespace
AnswerB

This is correct because a ClusterRoleBinding grants the permissions defined in the ClusterRole to the specified subject (the service account) cluster-wide. The pod-reader ClusterRole includes the 'get' and 'list' verbs on 'pods', and those permissions apply to pods in all namespaces. Therefore, the service account can read pod objects from any namespace, including metadata, specs, and statuses.

Why this answer

ClusterRoleBindings are cluster-scoped, meaning they grant permissions across all namespaces. Since the ClusterRoleBinding 'read-pods-global' binds the 'pod-reader' ClusterRole to the service account 'sa-pod-reader', the service account can get and list pods in every namespace, not just the 'default' namespace.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, mistakenly thinking the service account's permissions are limited to the namespace where the binding or the service account is defined.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding grants permissions cluster-wide, not limited to the namespace of the service account or the binding. Option C is wrong because the ClusterRole 'pod-reader' includes both 'get' and 'list' verbs, so the service account can perform both operations. Option D is wrong because the binding successfully grants the permissions defined in the ClusterRole, so the service account can read pods in all namespaces.

Practice this question →
72
MCQhard

You run 'kubeadm certs check-expiration' and see that the 'apiserver' certificate expires in 30 days. What is the correct way to renew just that certificate using kubeadm?

A.kubeadm alpha certs renew apiserver
B.kubeadm certs renew apiserver
C.kubeadm init phase certs apiserver --renew
D.kubectl create certificate apiserver
AnswerB

Renews the specific certificate.

Why this answer

`kubeadm certs renew apiserver` is the standard command in modern kubeadm (v1.15+) to renew a specific certificate without affecting others. It regenerates the apiserver certificate using the existing CA key, updating the expiration date while keeping the same Subject and SANs.

Exam trap

The trap here is that candidates confuse the deprecated `kubeadm alpha` subcommand with the current `kubeadm certs` subcommand, or mistakenly think `kubectl` can manage kubeadm certificates, leading them to pick options that are either outdated or nonexistent.

How to eliminate wrong answers

Option A is wrong because `kubeadm alpha certs renew` was deprecated in v1.15 and removed in v1.20; the `alpha` subcommand no longer exists in current kubeadm versions. Option C is wrong because `kubeadm init phase certs apiserver --renew` is not a valid command; `kubeadm init phase` is used for generating certificates during initial cluster setup, not for renewal, and there is no `--renew` flag. Option D is wrong because `kubectl create certificate apiserver` does not exist; `kubectl` manages Kubernetes resources, not certificate renewal, and the apiserver certificate is a file-based X.509 certificate managed by kubeadm, not a Kubernetes API object.

Practice this question →
73
MCQmedium

You need to allow a specific user to create and manage deployments in the 'development' namespace only. Which RBAC resources should you create?

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

A Role defines permissions within a namespace, and a RoleBinding grants those permissions to a user in that namespace.

Why this answer

A Role grants permissions within a specific namespace, and a RoleBinding binds that Role to a user or service account within the same namespace. To restrict a user to creating and managing deployments only in the 'development' namespace, you need a Role (scoped to that namespace) and a RoleBinding (also scoped to that namespace). ClusterRole and ClusterRoleBinding are cluster-scoped and would grant permissions across all namespaces, which is not desired here.

Exam trap

CNCF often tests the distinction between namespace-scoped and cluster-scoped resources, and the trap here is that candidates mistakenly think a ClusterRole is required for any 'management' task, or they confuse the scope of RoleBinding vs ClusterRoleBinding, leading them to pick options that grant permissions beyond the intended namespace.

How to eliminate wrong answers

Option A is wrong because a ClusterRole is cluster-scoped and, when combined with a ClusterRoleBinding, grants permissions across all namespaces, not just the 'development' namespace. Option B is wrong because a Role is namespace-scoped, but a ClusterRoleBinding is cluster-scoped; this combination would either fail (if the Role is referenced by a ClusterRoleBinding, which is not allowed) or require a ClusterRole, making the Role irrelevant. Option D is wrong because a ClusterRole is cluster-scoped, and while a RoleBinding can bind it to a namespace, the ClusterRole itself still has cluster-wide scope; using a ClusterRole here is unnecessary and could grant unintended permissions if not carefully scoped, whereas a simple Role is the correct namespace-scoped resource.

Practice this question →
74
MCQeasy

Which kubeconfig context field defines the set of users, clusters, and namespaces for kubectl operations?

A.contexts
B.namespaces
C.clusters
D.users
AnswerA

In a kubeconfig file, the `contexts` field is a list of named context objects, each holding three keys: `cluster`, `user`, and optionally `namespace`. The context is the only construct that binds a specific user to a specific cluster, and it can also set a default namespace for kubectl commands. Therefore, the `contexts` field is what defines the full set of user-to-cluster associations.

Why this answer

The `contexts` field in a kubeconfig file defines a named context that bundles together a specific cluster, user, and default namespace. When you run `kubectl` commands, the current context determines which cluster to authenticate against, which user credentials to use, and which namespace to operate in by default. This is why option A is correct.

Exam trap

The trap here is that candidates confuse the `contexts` field with the `current-context` field or think that `namespaces`, `clusters`, or `users` individually define the full operational scope, when in fact only the context object combines all three.

How to eliminate wrong answers

Option B (namespaces) is wrong because a namespace is a Kubernetes resource that provides scope for objects within a cluster, not a kubeconfig field that defines the set of users, clusters, and namespaces. Option C (clusters) is wrong because the `clusters` field in kubeconfig only defines cluster endpoints and certificate authority data, not the user or namespace binding. Option D (users) is wrong because the `users` field only stores client credentials (e.g., client certificates, tokens), not the cluster or namespace association.

Practice this question →
75
MCQmedium

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

A.Create a Role with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring
B.Create a ClusterRole with rules for pods and services (verbs: create) and a ClusterRoleBinding binding it to sa-monitor
C.Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a ClusterRoleBinding binding it to sa-monitor
D.Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a RoleBinding binding it to sa-monitor in namespace monitoring
AnswerC

ClusterRole + ClusterRoleBinding grants cluster-wide permissions.

Why this answer

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

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, thinking a ClusterRole bound via a RoleBinding still grants cluster-wide access, but in reality, the RoleBinding scopes the permissions to its namespace.

How to eliminate wrong answers

Option A is wrong because a Role and RoleBinding are namespace-scoped and cannot grant permissions cluster-wide; they would only apply within the 'monitoring' namespace. Option B is wrong because it uses the verb 'create' instead of 'get, watch, list', which grants write access (create) rather than read access; also, the requirement is to read, not create resources. Option D is wrong because a ClusterRole bound with a RoleBinding only grants permissions within the namespace of the RoleBinding, not cluster-wide, defeating the purpose of the ClusterRole.

Practice this question →
Page 1 of 2 · 80 questions totalNext →

Ready to test yourself?

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

Start 20-question session