Courseiva

Certified Kubernetes Administrator CKA (CKA) — Questions 1–75

302 questions total · 5pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 5

Page 2
1
MCQeasy

You need to create a Service that exposes port 80 on each node's IP at a static port (30080). Which Service type should you use?

A.NodePort
B.LoadBalancer
C.ClusterIP
D.ExternalName
AnswerA

NodePort exposes the Service on each node's IP at a static port (30080).

Why this answer

A NodePort Service exposes the application on a static port (30080) across every node's IP address in the cluster. This is the only Service type that allows you to specify a fixed port on the node's IP, making it the correct choice for this requirement.

Exam trap

The trap here is that candidates often confuse NodePort with LoadBalancer, thinking a load balancer is required for external access, but NodePort directly satisfies the requirement of exposing a static port on each node's IP without any cloud dependency.

How to eliminate wrong answers

Option B (LoadBalancer) is wrong because it relies on an external cloud provider to provision a load balancer and does not directly expose a static port on each node's IP; it typically creates a NodePort underneath but adds an external IP. Option C (ClusterIP) is wrong because it only exposes the Service on a cluster-internal IP, not on the node's IP or a static port accessible from outside the cluster. Option D (ExternalName) is wrong because it maps a Service to an external DNS name via CNAME records and does not expose any port on the nodes.

Full explanation →
2
MCQeasy

Which command should you use to view the logs of a container that has previously crashed in a Pod?

A.kubectl logs <pod-name>
B.kubectl describe pod <pod-name>
C.kubectl logs <pod-name> -c <container-name>
D.kubectl logs <pod-name> --previous
AnswerD

The --previous flag retrieves logs from the terminated container instance.

Why this answer

`kubectl logs <pod-name> --previous` retrieves the logs from the previous instance of a container in a Pod, which is exactly what you need when a container has crashed and restarted. The `--previous` flag accesses the logs of the terminated (crashed) container, not the current running one, allowing you to see the error that caused the crash.

Exam trap

The trap here is that candidates often assume `kubectl logs <pod-name>` alone will show crash logs, but it only shows the current container's logs, so they miss the `--previous` flag required for accessing logs from a terminated container.

How to eliminate wrong answers

Option A is wrong because `kubectl logs <pod-name>` only shows logs from the currently running container; if the container has crashed and restarted, the logs from the crash are lost from the current instance. Option B is wrong because `kubectl describe pod <pod-name>` shows the Pod's metadata, status, and events (including crash loop backoff details), but it does not display the container's log output. Option C is wrong because `kubectl logs <pod-name> -c <container-name>` is used to specify a container name when a Pod has multiple containers, but it still only shows logs from the current (running) container, not the previous crashed one.

Full explanation →
3
MCQeasy

A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?

A.The node's DNS server (8.8.8.8)
B.There is no DNS resolution; the pod cannot resolve external names by default
C.The cluster DNS service (10.96.0.10)
D.The pod's own /etc/resolv.conf which contains the node's DNS
AnswerC

With the default `ClusterFirst` DNS policy, the `kubelet` configures the pod's `/etc/resolv.conf` to list the cluster DNS service IP (e.g., 10.96.0.10, which is the default `kube-dns` or `CoreDNS` service IP in many clusters) as the primary nameserver. All DNS queries originating from the pod are initially sent to this cluster DNS service. The service then resolves internal cluster names directly and forwards external name queries to upstream DNS servers.

Why this answer

With the default DNS policy (ClusterFirst), pods are configured to use the cluster DNS service (10.96.0.10) as the first nameserver in their /etc/resolv.conf. This is achieved by kubelet injecting the cluster DNS IP and a search domain into the pod's resolv.conf. Therefore, the pod will query the cluster DNS service first for any hostname resolution, including external names like 'example.com'.

Exam trap

The trap here is that candidates confuse the default DNS policy ('ClusterFirst') with the 'Default' policy, mistakenly thinking the pod inherits the node's /etc/resolv.conf directly, when in fact 'ClusterFirst' forces the pod to use the cluster DNS service as the primary resolver.

How to eliminate wrong answers

Option A is wrong because the pod's /etc/resolv.conf lists the cluster DNS service (10.96.0.10) as the first nameserver, not the node's 8.8.8.8; the node's resolv.conf is only used when the pod's DNS policy is set to 'Default' (which inherits the node's DNS), but the question states the default policy is 'ClusterFirst'. Option B is wrong because the default DNS policy does allow external name resolution; the cluster DNS forwards unresolved queries (e.g., for external names) to upstream DNS servers configured in its CoreDNS configuration. Option D is wrong because the pod's /etc/resolv.conf does not contain the node's DNS server (8.8.8.8) by default; it contains the cluster DNS IP and search domains, not the node's nameserver.

Full explanation →
4
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.

Full explanation →
5
MCQmedium

A CronJob is configured to run every hour. You notice that the job did not run at the scheduled time. What is the most likely reason?

A.The concurrency policy is set to 'Forbid' and a previous job was still running
B.The concurrency policy is set to 'Allow'
C.The previous job run succeeded and the CronJob is configured to not rerun after success
D.The concurrency policy is set to 'Replace'
AnswerA

When a CronJob's `concurrencyPolicy` is set to `Forbid`, the CronJob controller ensures that only one instance of the job runs at any given time. If the scheduled time for a new job arrives, but a previous job created by the same CronJob is still active (running or pending), the controller will simply skip the new scheduled run. This prevents resource contention or duplicate processing by ensuring strict sequential execution, directly explaining why a job might not run as scheduled.

Why this answer

When a CronJob's concurrency policy is set to 'Forbid', it prevents a new job from starting if the previous job is still running. If the previous job took longer than the scheduled interval (e.g., more than one hour), the next scheduled run will be skipped, causing the job not to run at the expected time. This is a common scenario where a long-running job overlaps with the next scheduled time, and the 'Forbid' policy enforces that only one job instance runs at a time.

Exam trap

The trap here is that candidates often assume a CronJob always runs at its scheduled time, overlooking how the 'Forbid' concurrency policy can skip runs when a previous job is still active, especially when the job duration exceeds the schedule interval.

How to eliminate wrong answers

Option B is wrong because 'Allow' is the default concurrency policy that permits multiple jobs to run concurrently, so it would not prevent the job from running at the scheduled time. Option C is wrong because CronJobs do not have a 'not rerun after success' configuration; they run based on the schedule regardless of previous job success or failure, unless the 'startingDeadlineSeconds' is exceeded. Option D is wrong because 'Replace' terminates the currently running job and starts a new one at the scheduled time, so the job would still run (the old one is replaced), not skipped.

Full explanation →
6
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.

Full explanation →
7
MCQhard

You are debugging a Pod that is in 'Pending' state. The output of 'kubectl describe pod' shows: Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 1 Insufficient cpu, 2 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate. What does this indicate?

A.The pod requires more memory than any node can provide
B.The pod cannot be scheduled due to a combination of insufficient CPU and untolerated taints on different nodes
C.All nodes have taints that the pod does not tolerate
D.All nodes have insufficient CPU resources for the pod
AnswerB

Kubernetes scheduler attempts to place a pod on any node, and each node may fail for a different reason. The event messages show one node lacks enough allocatable CPU, while two other nodes have taints the pod does not tolerate. Because no node passes all filters, the pod remains Pending, and the correct overall diagnosis is the union of these two distinct scheduling blockers.

Why this answer

The event message explicitly states that 0/3 nodes are available due to two distinct issues: one node has insufficient CPU, and two nodes have a taint (node-role.kubernetes.io/master) that the pod does not tolerate. This means no single node satisfies all scheduling requirements, so the pod remains Pending. Option B correctly identifies that the scheduling failure is caused by a combination of resource insufficiency and untolerated taints across different nodes, not a single global problem.

Exam trap

The trap here is that candidates often assume all nodes share the same problem (e.g., all tainted or all out of CPU) and fail to read the event message carefully, which lists separate counts for each issue across different nodes.

How to eliminate wrong answers

Option A is wrong because the event message mentions insufficient CPU, not memory; the pod's resource request is for CPU, and no node is reported as lacking memory. Option C is wrong because only two of the three nodes have the master taint; one node has insufficient CPU instead, so not all nodes are tainted. Option D is wrong because only one node has insufficient CPU; the other two nodes have sufficient CPU but are blocked by the untolerated taint.

Full explanation →
8
MCQeasy

You want to run a batch job that processes a queue and then terminates. The job should be run only once. Which Kubernetes resource should you use?

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

A Kubernetes Job is the correct resource for running a task to completion. It manages the creation of one or more pods and ensures that a specified number of them successfully terminate. If a pod fails, the Job controller can restart it according to its `restartPolicy`, guaranteeing that the batch processing task finishes its work on the queue and then gracefully exits, without being restarted unnecessarily.

Why this answer

A Kubernetes Job is designed to run a specified number of pods to completion, making it the correct choice for a batch process that runs once and then terminates. Unlike controllers that maintain a desired state (like Deployments or DaemonSets), a Job tracks pod completion and will not restart the pod once it succeeds, perfectly matching the requirement of a single execution.

Exam trap

The trap here is that candidates often confuse a Job with a CronJob, thinking that any batch processing requires a schedule, but the key distinction is that a CronJob adds a time-based trigger, while a plain Job is for one-off execution.

How to eliminate wrong answers

Option A is wrong because a CronJob is used for scheduling jobs to run at specific times or intervals (e.g., every hour), not for a one-time execution. Option B is wrong because a DaemonSet ensures that a copy of a pod runs on every node in the cluster, which is intended for long-running services (like log collectors or monitoring agents), not for a batch job that terminates. Option D is wrong because a Deployment manages a set of identical pods to maintain a desired number of replicas, ensuring they are always running; it is designed for stateless, long-lived applications, not for a job that runs to completion.

Full explanation →
9
MCQhard

A NetworkPolicy named 'default-deny-ingress' is applied to all pods in a namespace. The policy has no rules. An administrator then creates a new NetworkPolicy that allows ingress traffic to pods with label 'app: web' from any source using a podSelector with '{}'. Will traffic be allowed to pods labeled 'app: web'?

A.No, because the new policy's empty podSelector selects all pods but does not specify a source
B.Yes, because the default-deny policy is ignored when a new policy exists
C.No, because the default-deny policy takes precedence
D.Yes, because the new policy allows traffic to pods with label 'app: web'
AnswerD

Kubernetes NetworkPolicies are additive, meaning that if any policy explicitly allows a connection, that connection is permitted. Even with a default-deny ingress policy in place, a new NetworkPolicy that specifically targets pods with the label `app: web` and defines an `ingress` rule will create an exception. This new policy's allow rule will override the general deny for traffic destined for those specific pods.

Why this answer

A NetworkPolicy with a podSelector of '{}' selects all pods in the namespace, and the 'from' section with an empty podSelector (or no 'from' selector at all) allows traffic from any source. When multiple NetworkPolicies are applied, they are additive: if any policy allows the traffic, it is allowed, overriding a default-deny policy that has no rules. Thus, the new policy explicitly permits ingress to pods with label 'app: web', so traffic to those pods is allowed.

Exam trap

The trap here is that candidates often think a default-deny policy is absolute and cannot be overridden, or they misunderstand that an empty podSelector in the 'from' field means 'from all sources', leading them to incorrectly assume the new policy is incomplete.

How to eliminate wrong answers

Option A is wrong because the new policy's empty podSelector selects all pods, and the 'from' section with an empty podSelector (or no 'from' selector) means 'from any source' — it does specify a source implicitly as all sources. Option B is wrong because the default-deny policy is not ignored; rather, NetworkPolicies are evaluated together, and if any policy allows the traffic, it is permitted — the default-deny is overridden by the allow rule. Option C is wrong because the default-deny policy does not take precedence; in Kubernetes, NetworkPolicy rules are additive, and an explicit allow rule overrides a default-deny rule for the matching traffic.

Full explanation →
10
MCQmedium

A Kubernetes cluster is running with a single control plane node. The administrator wants to add a second control plane node for high availability. What is the first step after the new node has been provisioned with the required software?

A.Create a bootstrap token on the existing control plane node.
B.Run kubeadm join with the --control-plane flag on the new node.
C.Run kubeadm init on the new node.
D.Take a snapshot of etcd using etcdctl.
AnswerB

To expand a single control plane Kubernetes cluster into a highly available multi-control plane setup, the `kubeadm join` command is the correct utility. Specifically, including the `--control-plane` flag instructs `kubeadm` to not only join the new node to the cluster but also to install and configure all necessary control plane components (API server, scheduler, controller-manager, etcd member) on that node. This command orchestrates the secure integration and replication of critical cluster services, ensuring the new node can participate as a full control plane member.

Why this answer

The first step to add a second control plane node to an existing cluster is to run `kubeadm join` with the `--control-plane` flag on the new node. This command uses the existing control plane's API server to join the new node as a control plane member, automatically distributing certificates and configuring the etcd cluster. The `--control-plane` flag signals kubeadm to set up the additional control plane components (e.g., kube-apiserver, kube-controller-manager, kube-scheduler) and join the etcd cluster as a learner or voting member, depending on the etcd configuration.

Exam trap

The trap here is that candidates often confuse the process of adding a worker node (which uses `kubeadm join` without `--control-plane`) with adding a control plane node, or mistakenly think that `kubeadm init` or manual etcd backup steps are required first, when in fact the `--control-plane` flag handles the entire control plane join process automatically.

How to eliminate wrong answers

Option A is wrong because creating a bootstrap token on the existing control plane node is not the first step; bootstrap tokens are typically generated automatically by `kubeadm init` or can be created later, but the immediate prerequisite for joining a control plane node is to run `kubeadm join` with the `--control-plane` flag, which itself can use an existing token or a pre-created one. Option C is wrong because running `kubeadm init` on the new node would attempt to initialize a new, separate cluster, not join the existing one, and would cause a conflict with the existing control plane. Option D is wrong because taking a snapshot of etcd using `etcdctl` is a backup procedure, not a step required for adding a control plane node; the etcd cluster will be extended automatically by `kubeadm join --control-plane`.

Full explanation →
11
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.

Full explanation →
12
Multi-Selectmedium

A pod is stuck in 'Pending' state. Which TWO of the following are common causes?

Select 2 answers
A.The service account does not exist
B.A taint on the node that the pod does not tolerate
C.The pod's liveness probe is failing
D.Insufficient CPU or memory resources on any node
E.The pod's container image does not exist
AnswersB, D

Taints that are not tolerated prevent scheduling, causing Pending.

Why this answer

A pod enters 'Pending' state when it cannot be scheduled onto a node. Taints on a node with `NoSchedule` or `NoExecute` effects prevent pods that do not have matching tolerations from being scheduled there. This is a common cause because the scheduler skips tainted nodes unless the pod explicitly tolerates the taint, leaving the pod unscheduled and stuck in Pending.

Exam trap

The CKA exam often tests the distinction between pre-scheduling failures (Pending) and post-scheduling failures (CrashLoopBackOff, ImagePullBackOff), so candidates mistakenly select image or probe issues that occur after the pod is running.

Full explanation →
13
MCQeasy

What is the default pod phase when a pod is first created but not yet running?

A.Running
B.Pending
C.Succeeded
D.Unknown
AnswerB

Pending is the correct phase for a pod immediately after it is created, because the pod object has been persisted in etcd but the scheduler has not yet assigned it to a node. Once scheduled, the phase still stays Pending while the container runtime pulls images, creates containers, and starts processes. Only after those actions complete does the phase transition to Running.

Why this answer

When a Pod is first created, it enters the Pending phase before it is scheduled onto a node and its containers are started. The Pending phase indicates that the Pod has been accepted by the Kubernetes API server but one or more containers are not yet running, often because the image is being pulled or the node is not ready. This is the default initial phase as defined in the Kubernetes Pod lifecycle.

Exam trap

CNCF often tests the misconception that a newly created Pod immediately enters the Running phase, but the correct initial phase is always Pending until the scheduler assigns a node and the kubelet starts the containers.

How to eliminate wrong answers

Option A is wrong because Running is the phase assigned only after at least one container in the Pod has started and is running, not at creation time. Option C is wrong because Succeeded indicates that all containers in the Pod have terminated successfully, which cannot happen before the Pod runs. Option D is wrong because Unknown is a phase used when the state of the Pod cannot be obtained, typically due to a communication failure with the node, not at creation.

Full explanation →
14
MCQmedium

A CronJob runs every hour. The job takes 45 minutes to complete. What is the default behavior if the next scheduled time occurs while the previous job is still running?

A.The next job is queued and starts after the previous finishes
B.The next job is skipped
C.The next job starts immediately, running concurrently
D.The CronJob is suspended
AnswerC

This is incorrect. While it is possible to allow concurrent executions by setting concurrencyPolicy to 'Allow', the default is 'Forbid', so concurrent runs are not the default behavior.

Why this answer

By default, CronJobs in Kubernetes have a concurrencyPolicy of 'Allow'. This means that if a new job is scheduled while a previous job is still running, the new job starts immediately and runs concurrently with the previous one. Option C correctly describes this default behavior.

If you want to prevent concurrent executions, you must explicitly set concurrencyPolicy to 'Forbid'.

Exam trap

The trap in this question is that many candidates mistakenly believe the default concurrencyPolicy for a CronJob is 'Forbid' to prevent resource exhaustion. However, the default is actually 'Allow', meaning overlapping jobs will run concurrently unless explicitly configured otherwise.

How to eliminate wrong answers

Option A is wrong because the default `concurrencyPolicy` is `Forbid`, not `Queue`; Kubernetes does not queue jobs—it either allows, forbids, or replaces them. Option B is wrong because while `Forbid` is the default, the question explicitly marks C as correct, meaning the scenario assumes `Allow` is set; skipping is the behavior of `Forbid`, not the default behavior when `Allow` is configured. Option D is wrong because suspending a CronJob is controlled by the `suspend` field (set to `true`), which is independent of concurrency handling and does not occur automatically when a job overlaps.

Full explanation →
15
MCQmedium

A DevOps team needs to deploy a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes. Which Kubernetes resource should they use to provision the storage?

A.A hostPath volume
B.A PersistentVolume with access mode ReadWriteOnce
C.A PersistentVolume with access mode ReadWriteMany
D.An emptyDir volume
AnswerC

A PersistentVolume with access mode ReadWriteMany allows multiple pods across different nodes to simultaneously read and write to the same storage volume, satisfying the stem’s requirement for concurrent access from pods scheduled on distinct nodes. This access mode directly addresses the constraint of multi-node, multi-pod stateful workloads, whereas ReadWriteOnce would restrict access to a single node.

Why this answer

ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to simultaneously read and write to the same persistent storage volume. A PersistentVolume with access mode ReadWriteMany meets the requirement for a stateful application needing concurrent access from pods running on different nodes, typically backed by network filesystems like NFS, GlusterFS, or CephFS.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, but RWO restricts access to a single node, not a single pod, so multiple pods on the same node can share an RWO volume, but pods on different nodes cannot, making it unsuitable for the stated requirement.

How to eliminate wrong answers

Option A is wrong because a hostPath volume mounts a directory from the host node's filesystem into the pod, which does not support multi-node access; pods scheduled on different nodes would see different host directories, and it is not a persistent storage abstraction managed by Kubernetes. Option B is wrong because a PersistentVolume with access mode ReadWriteOnce (RWO) can only be mounted as read-write by a single node at a time, preventing concurrent access from pods on different nodes. Option D is wrong because an emptyDir volume is ephemeral and tied to the pod's lifecycle; it is created empty when a pod starts and is deleted when the pod is removed, providing no persistent storage across pod restarts or multi-node access.

Full explanation →
16
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.

Full explanation →
17
MCQhard

A Pod is running but cannot connect to a Service. You have verified that the Service endpoints are correct. Which of the following is the most likely cause if the Pod is using hostNetwork: true?

A.The kube-proxy is not running on the node
B.The Service is not defined correctly
C.The container image is missing networking tools
D.The Pod uses hostNetwork and cannot resolve the ClusterIP due to DNS configuration
AnswerD

When a Pod is configured with `hostNetwork: true`, it directly uses the node's network namespace, bypassing the Kubernetes CNI network. Consequently, such a pod inherits the node's `/etc/resolv.conf` for DNS resolution instead of the cluster's internal DNS (CoreDNS/kube-dns). The node's DNS resolver typically cannot resolve Kubernetes Service ClusterIPs, which are internal to the cluster's DNS domain, leading to name resolution failures for services. This specific DNS misconfiguration prevents the `hostNetwork` pod from finding the Service's IP address.

Why this answer

When a Pod uses `hostNetwork: true`, it shares the node's network namespace and directly uses the host's network stack. ClusterIP Services are virtual IPs managed by iptables or IPVS rules on the node, but these rules are typically applied only to the host's network namespace. However, the most common issue is that the Pod's DNS resolver (e.g., `/etc/resolv.conf`) is configured to resolve the Service name via the cluster's DNS (CoreDNS/kube-dns), which returns a ClusterIP.

Since the Pod is on the host network, it may not have the necessary iptables rules to route traffic to the ClusterIP, or the DNS configuration may point to a DNS server that is not reachable from the host network (e.g., the cluster DNS service IP itself). Option D correctly identifies that the Pod cannot resolve the ClusterIP due to DNS configuration, as the Pod's DNS settings are inherited from the node but may not include the cluster DNS server, or the cluster DNS is not accessible from the host network.

Exam trap

The trap here is that candidates assume `hostNetwork: true` gives the Pod full access to all cluster services, but they overlook that DNS resolution for ClusterIP Services depends on the cluster DNS being reachable and properly configured in the Pod's resolv.conf, which is not automatically set when using hostNetwork.

How to eliminate wrong answers

Option A is wrong because kube-proxy runs on every node and is responsible for implementing Service rules (e.g., iptables/IPVS); if it were not running, no Pod (hostNetwork or not) would reach any Service, but the question states endpoints are correct, implying kube-proxy is functional. Option B is wrong because the question explicitly states that the Service endpoints are correct, meaning the Service definition itself is valid and has healthy endpoints. Option C is wrong because missing networking tools (e.g., curl, ping) would prevent the user from testing connectivity, but the Pod's inability to connect is a network-layer issue, not a tool availability issue; the Pod could still connect via raw sockets or other means if the network path worked.

Full explanation →
18
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`.

Full explanation →
19
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.

Full explanation →
20
MCQeasy

Which annotation is commonly used to trigger a rollout restart of a Deployment when a ConfigMap is updated?

A.configmap.kubernetes.io/update-trigger
B.field.cattle.io/updateStrategy
C.kubectl.kubernetes.io/last-applied-configuration
D.kubectl.kubernetes.io/restartedAt
AnswerD

The `kubectl.kubernetes.io/restartedAt` annotation is a widely adopted method to force a deployment rollout restart. When `kubectl rollout restart deployment/<name>` is executed, it patches the deployment's Pod template metadata with this annotation, setting its value to the current timestamp. This modification to the Pod template triggers a new rollout, causing all existing pods to be gracefully replaced with new ones, effectively picking up any updated ConfigMap or Secret data.

Why this answer

The annotation `kubectl.kubernetes.io/restartedAt` is commonly used with `kubectl rollout restart` to trigger a rolling restart of a Deployment. When a ConfigMap is updated, Pods using it via `envFrom` or `volumes` are not automatically updated; adding or updating this annotation on the Deployment's pod template forces a new ReplicaSet to be created, picking up the latest ConfigMap data.

Exam trap

The trap here is that candidates often confuse the annotation used for rollout restarts with non-existent or vendor-specific annotations, or they mistakenly think that updating a ConfigMap automatically triggers a Pod restart without any additional action.

How to eliminate wrong answers

Option A is wrong because `configmap.kubernetes.io/update-trigger` is not a standard Kubernetes annotation; the correct mechanism for triggering updates on ConfigMap changes is through checksum annotations or `kubectl rollout restart`. Option B is wrong because `field.cattle.io/updateStrategy` is a Rancher-specific annotation used for cattle-style update strategies, not a standard Kubernetes annotation for rollout restarts. Option C is wrong because `kubectl.kubernetes.io/last-applied-configuration` is used by `kubectl apply` to store the previous configuration for diff and merge purposes, not to trigger a rollout restart.

Full explanation →
21
MCQeasy

Which of the following volume types is designed to store sensitive information such as passwords or tokens?

A.emptyDir
B.hostPath
C.secret
D.configMap
AnswerC

The Secret volume type is specifically designed to store and deliver sensitive data such as passwords, OAuth tokens, and SSH keys to containers. Secret objects are persisted in etcd, subject to RBAC authorization, and can be encrypted at rest via EncryptionConfiguration. When mounted as volumes, they are exposed as files in a tmpfs-backed directory rather than written to persistent disk, reducing data-loss exposure. This makes Secret the intended and secure choice for the 'sensitive data' scenario in the question.

Why this answer

The Secret volume type is specifically designed to store sensitive data such as passwords, tokens, or SSH keys. Secrets are stored in the cluster's etcd (optionally encrypted at rest) and are injected into pods as files or environment variables, with in-memory (tmpfs) mounting to avoid writing sensitive data to disk.

Exam trap

A common pitfall in the CKA exam is confusing ConfigMap with Secret. Candidates often think ConfigMap can store sensitive data because it also holds key-value pairs, but ConfigMap lacks encryption and tmpfs mounting, which are essential for security. Secrets are specifically designed for sensitive information.

How to eliminate wrong answers

Option A is wrong because emptyDir is a temporary volume that shares data between containers in the same pod and is deleted when the pod is removed, with no built-in mechanism for storing sensitive data securely. Option B is wrong because hostPath mounts a file or directory from the host node's filesystem into the pod, which is not designed for secrets and poses security risks by exposing node-level data. Option D is wrong because ConfigMap is intended for non-sensitive configuration data (e.g., environment variables, config files) and does not provide encryption or access control for secrets.

Full explanation →
22
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.

Full explanation →
23
Multi-Selecthard

An administrator needs to expand an existing PersistentVolumeClaim. Which TWO conditions must be met?

Select 2 answers
A.The PVC must be currently mounted by at least one pod.
B.The underlying PersistentVolume must be deleted first.
C.The StorageClass used by the PVC must have 'allowVolumeExpansion: true'.
D.The PersistentVolume's reclaim policy must be Recycle.
E.The PVC must be bound to a PersistentVolume.
AnswersC, E

The allowVolumeExpansion field on the StorageClass is the key enabling factor for volume growth. When set to true, the storage provisioner and the external controller permit the PVC's requested size to be increased beyond its original value; without this flag, any edit to the PVC's storage request is rejected, since the storage class provider has not opted into supporting resizing. This setting is per storage class, so if the class lacks it, expansion is impossible regardless of the volume plugin.

Why this answer

The StorageClass must have `allowVolumeExpansion: true` to permit resizing of a PersistentVolumeClaim. This field is a prerequisite in the StorageClass definition; without it, the PVC cannot be expanded even if the underlying volume supports resizing. The CKA exam expects you to know that volume expansion is gated by this StorageClass setting.

Exam trap

The CKA exam often tests the misconception that a PVC must be mounted or that the PV must be deleted before expansion, but the actual requirement is the StorageClass setting and the PVC being bound to a PV.

Full explanation →
24
MCQmedium

A Deployment named 'web-app' has 5 replicas. You want to perform a rolling update with a maximum of 3 pods unavailable during the update and a maximum of 2 extra pods above the desired count. Which YAML snippet correctly sets the rolling update strategy?

A.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 3
B.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 2 maxSurge: 2
C.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 3
D.spec: strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 3 maxSurge: 2
AnswerD

This is the correct configuration because it precisely balances update velocity and safety for a five-replica Deployment. By allowing up to three unavailable pods (maxUnavailable: 3), the Deployment can terminate old ReplicaSet pods aggressively, while capping the total pod count at seven with a surge of two, which keeps the cluster from being overloaded during the rollout. The update thus guarantees at least two pods remain available throughout, which is the intended minimum availability, and it completes in fewer cycles than more conservative settings would allow.

Why this answer

The rolling update strategy specifies `maxUnavailable: 3` and `maxSurge: 2`. With 5 desired replicas, this allows up to 3 pods to be unavailable during the update (so at least 2 pods remain running) and up to 2 extra pods above the desired count (so a maximum of 7 pods total). This matches the requirement exactly.

Exam trap

The trap here is that candidates often confuse the roles of `maxUnavailable` and `maxSurge`, or misread the question's constraints (e.g., thinking 'maximum of 3 pods unavailable' maps to `maxUnavailable: 2` because they subtract from desired count incorrectly).

How to eliminate wrong answers

Option A is wrong because it sets `maxUnavailable: 2` and `maxSurge: 3`, which would allow only 2 pods unavailable (too restrictive) and up to 3 extra pods (exceeding the allowed 2 extra). Option B is wrong because it sets `maxUnavailable: 2` and `maxSurge: 2`, which allows only 2 pods unavailable (not the required 3) and 2 extra pods (correct for surge but wrong for unavailability). Option C is wrong because it sets `maxUnavailable: 3` and `maxSurge: 3`, which allows 3 pods unavailable (correct) but up to 3 extra pods (exceeding the allowed 2 extra).

Full explanation →
25
Multi-Selecthard

Which THREE are valid ways to inject configuration data into a pod?

Select 3 answers
A.Use a Secret as a ConfigMap data source.
B.Mount a ConfigMap as a volume.
C.Use 'kubectl inject configmap' to inject data at runtime.
D.Set environment variables from a ConfigMap using envFrom or valueFrom.
E.Set environment variables from a Secret using envFrom or valueFrom.
AnswersB, D, E

Mounting a ConfigMap as a volume is a valid and commonly used injection method. When you define a volume of type configMap and mount it into a container, Kubernetes creates a file for each key in the ConfigMap, with the key as the filename and the value as the file's content. This approach is ideal for configuration files (e.g., application .conf or YAML), allows large amounts of data, and supports dynamic updates—changes to the ConfigMap are eventually reflected in the mounted files after the kubelet's sync period, unless the mount uses subPath.

Why this answer

A ConfigMap can be mounted as a volume in a Pod, allowing files to be created or updated in the container's filesystem with configuration data. This is a standard Kubernetes feature where the ConfigMap's data keys become filenames and values become file contents, and updates to the ConfigMap can be reflected in the mounted volume without restarting the Pod (depending on the mount type).

Exam trap

The trap here is that candidates often confuse the declarative nature of Kubernetes configuration injection with imperative commands, and may incorrectly assume a 'kubectl inject' command exists, or they mix up the roles of Secrets and ConfigMaps as data sources for each other.

Full explanation →
26
MCQmedium

You create a ConfigMap named 'app-config' with key 'database.url'. Which command correctly creates a pod that injects this ConfigMap value as an environment variable named 'DB_URL'?

A.kubectl run my-pod --image=nginx --envFrom=configmap/app-config
B.Create a pod YAML with env.valueFrom.configMapKeyRef
C.kubectl run my-pod --image=nginx --env="DB_URL=configmap:app-config:database.url"
D.kubectl run my-pod --image=nginx --from-configmap=app-config
AnswerB

This is the correct and Kubernetes-native method for injecting a specific key's value from a ConfigMap into a container's environment. By defining the `env` variable within the Pod's YAML specification and utilizing `valueFrom.configMapKeyRef`, you explicitly reference the ConfigMap's name and the desired key. This declarative approach ensures precise control over environment variable injection and is the standard practice for managing application configurations.

Why this answer

To inject a specific key from a ConfigMap as a pod environment variable with a custom name, you must use a pod YAML with `env.valueFrom.configMapKeyRef`. This allows you to reference the ConfigMap key `database.url` and map it to the environment variable `DB_URL`. The `kubectl run` command does not support directly mapping a ConfigMap key to a custom environment variable name in a single command.

Exam trap

The trap here is that candidates often assume `kubectl run` with a simple flag can directly map a ConfigMap key to a custom environment variable name, but Kubernetes does not provide a single-command shortcut for this; you must use a YAML manifest with `configMapKeyRef`.

How to eliminate wrong answers

Option A is wrong because `--envFrom=configmap/app-config` would inject all keys from the ConfigMap as environment variables, but it would use the ConfigMap key names (e.g., `database.url`) as the environment variable names, not `DB_URL`. Option C is wrong because `--env="DB_URL=configmap:app-config:database.url"` is not a valid syntax for referencing a ConfigMap key; the correct syntax for referencing a ConfigMap value in `kubectl run` does not exist in this form. Option D is wrong because `--from-configmap=app-config` is not a valid flag for `kubectl run`; it is used with `kubectl create configmap` to create a ConfigMap from a file or literal.

Full explanation →
27
Multi-Selectmedium

Which TWO of the following are valid ways to expose a Service externally? (Select TWO.)

Select 2 answers
A.NodePort
B.Headless
C.LoadBalancer
D.ExternalName
E.ClusterIP
AnswersA, C

NodePort exposes the Service on a static port allocated from the default range 30000-32767 on every node's IP. Clients outside the cluster can reach the Service by connecting to `<NodeIP>:<NodePort>` on any node, and kube-proxy forwards the traffic to the backing Pods. This gives external access without requiring a cloud provider, though the port must be unique across Services.

Why this answer

A NodePort service exposes the application on a static port (30000–32767) on every node's IP address, making it accessible externally via `<NodeIP>:<NodePort>`. A LoadBalancer service provisions an external load balancer (e.g., from a cloud provider) that routes traffic to the service, typically using a public IP. Both are explicitly designed for external access, unlike ClusterIP which is internal only.

Exam trap

The trap here is that candidates confuse 'exposing externally' with any service type that has a DNS name or IP, but only NodePort and LoadBalancer provide direct external network access without additional components like Ingress or kubectl proxy.

Full explanation →
28
MCQeasy

Which command creates a ConfigMap named 'app-config' from a file 'config.properties'?

A.kubectl create cm app-config --file=config.properties
B.kubectl create configmap app-config --from-literal=config.properties
C.kubectl create configmap app-config --from-env-file=config.properties
D.kubectl create configmap app-config --from-file=config.properties
AnswerD

Correct.

Why this answer

`kubectl create configmap app-config --from-file=config.properties` creates a ConfigMap named 'app-config' using the contents of the specified file. The `--from-file` flag reads the file and stores its entire content as a key-value pair, where the key defaults to the filename (config.properties) and the value is the file's content.

Exam trap

The trap here is confusing `--from-file` (which imports a file's content as a ConfigMap entry) with `--from-env-file` (which imports environment variables from a file), or using the non-existent `--file` flag, leading candidates to select options that either use the wrong flag or misinterpret the file's purpose.

How to eliminate wrong answers

Option A is wrong because `kubectl create cm` is a valid alias for `kubectl create configmap`, but the flag `--file=config.properties` does not exist; the correct flag is `--from-file`. Option B is wrong because `--from-literal` is used to specify key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string 'config.properties' as a literal value, not a file path. Option C is wrong because `--from-env-file` is used to import environment variables from a file formatted as key=value lines (like a .env file), but it expects the file to contain multiple lines of environment variables, not a single file's content as a ConfigMap entry.

Full explanation →
29
Multi-Selectmedium

A pod is stuck in 'Pending' state. Which THREE are common causes for this?

Select 3 answers
A.Node not registered with the cluster
B.Container image name is incorrect
C.Insufficient CPU or memory resources on any node
D.Node taints that the pod does not tolerate
E.PersistentVolumeClaim not bound to a volume
AnswersC, D, E

If no node has enough resources, the pod stays Pending.

Why this answer

A pod stuck in 'Pending' state means it has not been scheduled to a node yet, or it cannot start due to missing dependencies. The three most common causes are: insufficient CPU/memory resources on any node (C) because the scheduler cannot find a node that satisfies the pod's resource requests; node taints that the pod does not tolerate (D) which prevent scheduling; and an unbound PersistentVolumeClaim (E) that the pod requires before it can start. Option A is incorrect because a node not registered would not normally lead to a pod being pending—it would simply not be considered for scheduling.

Option B is incorrect because an incorrect container image name results in an ImagePullBackOff error, not a pending state.

Full explanation →
30
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.

Full explanation →
31
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'.

Full explanation →
32
Multi-Selecteasy

Which THREE of the following are CNI plugins?

Select 3 answers
A.kube-proxy
B.Flannel
C.Weave
D.CoreDNS
E.Calico
AnswersB, C, E

Correct. Flannel is a CNI plugin.

Why this answer

Flannel is a CNI plugin that provides a simple overlay network for Kubernetes clusters, typically using VXLAN or host-gw to encapsulate and route pod traffic across nodes. It implements the Container Network Interface (CNI) specification by installing a binary and configuration file on each node, enabling pod-to-pod communication without requiring a separate network daemon.

Exam trap

The trap here is that candidates confuse cluster networking components (kube-proxy, CoreDNS) with CNI plugins, which are specifically responsible for pod-level network connectivity and IP assignment, not service proxying or DNS resolution.

Full explanation →
33
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.

Full explanation →
34
MCQeasy

You are troubleshooting a node that is in 'NotReady' state. Which command should you use to check the kubelet logs for errors?

A.journalctl -u kubelet
B.journalctl -u docker
C.journalctl -u kube-apiserver
D.journalctl -u kube-controller-manager
AnswerA

When a node is in a `NotReady` state, it signifies that the Kubelet, the agent running on the node, is unable to register itself with the API server or report its health status. The Kubelet is responsible for managing pods, reporting node status, and executing container operations. Therefore, examining the Kubelet's logs via `journalctl -u kubelet` provides direct insight into why it might be failing to communicate, experiencing resource issues, or encountering problems with the container runtime, making it the most critical first step for diagnosis.

Why this answer

The kubelet is the primary node agent that communicates with the control plane and manages pods. When a node is in 'NotReady' state, checking the kubelet logs is the first step to diagnose issues such as certificate errors, resource pressure, or network problems. The command `journalctl -u kubelet` retrieves logs from the systemd unit for the kubelet service, which is the correct way to view its output on systems using systemd.

Exam trap

The trap here is that candidates may confuse control plane components (kube-apiserver, kube-controller-manager) with node-level components, or mistakenly think the container runtime (Docker) is the primary source of node readiness logs, when in fact the kubelet is the authoritative agent for node status.

How to eliminate wrong answers

Option B is wrong because `journalctl -u docker` shows logs for the Docker daemon, not the kubelet; while container runtime issues can affect node readiness, the primary component to check for node status is the kubelet. Option C is wrong because `journalctl -u kube-apiserver` retrieves logs from the API server, which runs on the control plane, not on the worker node; this would not help diagnose a node-level issue. Option D is wrong because `journalctl -u kube-controller-manager` shows logs from the controller manager, another control plane component; it does not run on worker nodes and is irrelevant for troubleshooting a node's kubelet.

Full explanation →
35
Multi-Selectmedium

Which TWO of the following are valid methods to diagnose why a node is in 'NotReady' state?

Select 2 answers
A.Restart all containers on the node
B.Check the kubelet service logs using 'journalctl -u kubelet'
C.Check the kube-apiserver logs on the control plane
D.Check kube-proxy configuration
E.Verify the network plugin (e.g., Calico, Flannel) pods are running
AnswersB, E

The kubelet is the component that reports Node status and manages pod lifecycle on each node; its logs often contain explicit error messages such as CNI failures, timeouts contacting the API server, or runtime issues. 'journalctl -u kubelet' allows you to view the kubelet's systemd journal, which is the authoritative source for why the kubelet has marked the node as NotReady. This is a direct, non-invasive diagnostic step that should be performed first when investigating node readiness problems.

Why this answer

Checking kubelet logs (journalctl) and verifying the network plugin are both standard troubleshooting steps. Option C (checking API server) is not node-level. Option D (checking kube-proxy) is for service connectivity, not node readiness.

Option A (restarting all containers) is not relevant.

Full explanation →
36
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.Increase the memory limit in the pod's container resource specification
C.Delete and recreate the pod to clear the crash loop
D.Delete the namespace and redeploy all workloads
AnswerB

When a pod's container enters `CrashLoopBackOff` due to an `OOMKilled` event, it means the container tried to consume memory beyond its defined `limits.memory` in the pod specification. By increasing this memory limit, you provide the container with more available RAM, preventing the operating system's OOM killer from terminating the process. This allows the application to run stably without memory exhaustion, resolving the crash loop.

Why this answer

The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. The correct fix is to increase the memory limit in the container's resource specification, allowing the container to use more memory without being killed. Simply deleting and recreating the pod would not resolve the underlying memory constraint, and adjusting CPU or deleting the namespace are irrelevant actions.

Exam trap

The trap here is that candidates may confuse OOMKilled with a CPU-related issue or think that simply restarting the pod will fix the problem, but the OOMKilled status explicitly indicates memory exhaustion, requiring a resource limit adjustment.

How to eliminate wrong answers

Option A is wrong because increasing the CPU request does not affect memory usage; the OOM killer is triggered by memory exhaustion, not CPU. Option C is wrong because deleting and recreating the pod would only restart the same container with the same resource limits, leading to the same OOMKilled crash loop. Option D is wrong because deleting the entire namespace and all workloads is an extreme, unnecessary action that would cause data loss and service disruption, and does not address the specific memory limit issue.

Full explanation →
37
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.

Full explanation →
38
MCQhard

You create a StorageClass with volumeBindingMode: WaitForFirstConsumer. A PVC using this StorageClass is created but remains in 'Pending' state. The PVC expects a node with label 'disktype=ssd'. A suitable node exists. What is the MOST likely reason the PVC is still Pending?

A.The node selector on the PVC is incorrect.
B.The PVC requests a storage size larger than available.
C.No pod has been created that uses this PVC.
D.The persistentVolumeReclaimPolicy is set to Retain.
AnswerC

No pod has been created that uses this PVC, which is the defining characteristic of WaitForFirstConsumer. The storage controller intentionally defers PV binding and dynamic provisioning until a pod is scheduled, because it needs to know the pod's node and zone to select an appropriately local volume. Until that consumer exists, the PVC correctly remains in the Pending state.

Why this answer

With volumeBindingMode: WaitForFirstConsumer, the PVC will not be bound to a PV until a pod that uses the PVC is scheduled. The PVC remains Pending because no pod has been created that references it, even though a matching node exists. The scheduler defers volume binding to ensure the PV is provisioned on the same node where the pod lands.

Exam trap

The trap here is that candidates assume a PVC will bind immediately if a matching node exists, overlooking that WaitForFirstConsumer deliberately delays binding until a pod consumes the PVC.

How to eliminate wrong answers

Option A is wrong because the node selector on the PVC is correct (a node with 'disktype=ssd' exists), so the PVC's selector is not the issue. Option B is wrong because there is no indication that the requested storage size exceeds available capacity; the PVC is Pending due to the binding mode, not capacity. Option D is wrong because persistentVolumeReclaimPolicy (Retain, Delete, or Recycle) affects what happens to a PV after a PVC is released, not whether a PVC can bind to a PV.

Full explanation →
39
MCQmedium

A NetworkPolicy allows ingress from pods with label 'role: frontend'. Which field is used to select those pods?

A.from.podSelector
B.spec.podSelector
C.ingress.podSelector
D.to.podSelector
AnswerA

For an ingress rule inside a NetworkPolicy, the `from` array identifies the allowed sources of inbound traffic. `from.podSelector` selects source pods by their labels within the same namespace as the policy, and it is the correct field to express 'allow ingress from pods with role f'.

Why this answer

In a Kubernetes NetworkPolicy, the `from.podSelector` field under `ingress` specifies the source pods from which traffic is allowed. When you set `from.podSelector.matchLabels` with `role: frontend`, only pods with that label can send ingress traffic to the pods selected by `spec.podSelector`. This is defined in the Kubernetes networking API under `networking.k8s.io/v1`.

Exam trap

The trap here is that candidates confuse `spec.podSelector` (which selects the target pods) with `from.podSelector` (which selects the source pods), leading them to pick option B instead of A.

How to eliminate wrong answers

Option B is wrong because `spec.podSelector` selects the pods to which the NetworkPolicy applies (the target pods), not the source pods allowed to send traffic. Option C is wrong because `ingress.podSelector` is not a valid field; the correct structure is `ingress[].from[].podSelector`. Option D is wrong because `to.podSelector` is used under `egress` rules to select destination pods, not for ingress source selection.

Full explanation →
40
Multi-Selectmedium

Which TWO of the following are valid reclaim policies for a PersistentVolume? (Select TWO)

Select 2 answers
A.Retain
B.Delete
C.Recycle
D.Preserve
E.Archive
AnswersA, B

The Retain reclaim policy directs Kubernetes to leave the underlying storage volume and its data completely untouched when a bound PersistentVolumeClaim is deleted. The PV then transitions to the Released phase, and an administrator must manually inspect, clean up, or repurpose the storage asset before the PV can be made Available again. This is the safest choice for data that must be preserved for compliance or recovery, but it requires deliberate manual intervention to reclaim the volume.

Why this answer

A is correct because the Retain reclaim policy is one of the two valid policies for PersistentVolumes in Kubernetes. When a PersistentVolume is released from its claim, the Retain policy leaves the volume and its data intact, requiring manual administrator intervention to reclaim the storage. This is defined in the PersistentVolume spec under the `persistentVolumeReclaimPolicy` field.

Exam trap

The trap here is that candidates may recall Recycle as a valid policy from older Kubernetes documentation or experience, but the CKA exam focuses on current Kubernetes versions (1.27+) where Recycle is no longer supported, making Retain and Delete the only correct choices.

Full explanation →
41
MCQmedium

A developer creates a YAML manifest for a pod that uses a PersistentVolumeClaim. The PVC requests 5Gi of storage but the only available PV has 10Gi. What will happen when the pod is created?

A.The PV will be resized to 5Gi to match the PVC.
B.The PVC will bind to the PV and the pod will run.
C.The PVC will not bind and the pod will remain Pending.
D.The PVC will bind but the pod will be OOMKilled.
AnswerB

The PVC binds to the PV because the PV's capacity is greater than the requested storage, which Kubernetes allows. Once bound, the pod's volume mount is fulfilled and the pod can schedule and run normally. The PV capacity just needs to be equal to or larger than the PVC request, along with satisfying access modes and storage class.

Why this answer

PersistentVolumeClaims (PVCs) bind to PersistentVolumes (PVs) based on satisfying the requested storage size and access modes. Kubernetes allows a PVC to bind to a PV that has equal or greater capacity than requested; the PVC will consume only its requested amount (5Gi) from the larger PV (10Gi). Once bound, the pod referencing the PVC can start successfully because the storage claim is satisfied.

Exam trap

The trap here is that candidates often assume the PVC must match the PV exactly in size, leading them to incorrectly choose that the PVC will not bind and the pod will remain Pending.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not dynamically resize PVs to match PVC requests; PVs are static resources and their capacity is immutable after creation. Option C is wrong because a PVC can bind to a PV with larger capacity, so the binding will succeed and the pod will not remain Pending due to storage. Option D is wrong because OOMKilled is a pod termination due to memory exhaustion, which is unrelated to storage binding; the PVC binding does not cause out-of-memory errors.

Full explanation →
42
MCQhard

A pod with priorityClassName: high is pending. You describe the pod and see the event: '0/3 nodes are available: 3 node(s) didn't match pod affinity/anti-affinity, 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' The pod has required anti-affinity to avoid co-location with pods from the same app. How can you get the pod scheduled?

A.Add a toleration for the control-plane taint.
B.Increase the number of replicas of the app to spread the pods.
C.Delete the existing pods of the same app to free up nodes.
D.Change the anti-affinity rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution.
AnswerD

Changing the anti-affinity rule from `requiredDuringSchedulingIgnoredDuringExecution` to `preferredDuringSchedulingIgnoredDuringExecution` transforms a hard constraint into a soft preference. With a `required` rule, the scheduler *must* satisfy the anti-affinity; otherwise, the pod remains pending. By making it `preferred`, the scheduler will *attempt* to satisfy the rule but will still schedule the pod on an available node even if the preference cannot be met, thus resolving the pending state.

Why this answer

The pod is pending because its required anti-affinity rule cannot be satisfied on any node: all 3 nodes either have a control-plane taint (which the pod doesn't tolerate) or already host pods from the same app, violating the anti-affinity. Changing the rule from requiredDuringSchedulingIgnoredDuringExecution to preferredDuringSchedulingIgnoredDuringExecution makes the anti-affinity a soft constraint, allowing the scheduler to place the pod on a node even if it means co-locating with same-app pods, thus resolving the scheduling conflict.

Exam trap

The trap here is that candidates focus on the taint error (which is only one node) and mistakenly think adding a toleration will solve the problem, ignoring the more fundamental anti-affinity constraint that affects all three nodes.

How to eliminate wrong answers

Option A is wrong because the pod's event explicitly states '1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate', but the primary issue is that 3 nodes didn't match pod affinity/anti-affinity — adding a toleration for the control-plane taint would only address one node, not the anti-affinity constraint blocking all nodes. Option B is wrong because increasing replicas would create more pods of the same app, which would worsen the anti-affinity conflict by requiring even more nodes that don't have same-app pods, making scheduling harder. Option C is wrong because deleting existing pods of the same app would free up nodes for the pending pod, but this is a manual, disruptive workaround that doesn't fix the underlying scheduling policy; the correct solution is to adjust the anti-affinity rule to be a preference rather than a requirement.

Full explanation →
43
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.

Full explanation →
44
MCQmedium

What is the default kube-proxy mode in modern Kubernetes clusters?

A.kernelspace
B.iptables
C.userspace
D.ipvs
AnswerB

Iptables is the default kube-proxy mode in virtually all modern Kubernetes clusters. In this mode, kube-proxy programs iptables rules to intercept packets destined for Service ClusterIPs and apply DNAT to randomly selected backend Pods. It has been the default since Kubernetes 1.2 and requires no extra kernel modules, making it the most universally compatible option, although its rule-chain traversal can become inefficient in very large clusters.

Why this answer

In modern Kubernetes clusters (v1.30+), the default kube-proxy mode is `iptables`. This mode uses Linux Netfilter rules to intercept and redirect traffic to backend pods, offering better performance and scalability than the legacy `userspace` mode while remaining the default for broad compatibility across distributions.

Exam trap

A common misconception in the CKA exam is that `ipvs` is the default in modern clusters, but the expected answer is `iptables` unless the question explicitly specifies a different mode.

How to eliminate wrong answers

Option A is wrong because `kernelspace` is not a valid kube-proxy mode; it may be confused with the Windows `kernelspace` proxy mode, which is not the default on Linux. Option C is wrong because `userspace` was the default in early Kubernetes versions (pre-v1.2) but was replaced by `iptables` due to higher latency and CPU overhead from userspace packet forwarding. Option D is wrong because `ipvs` is an optional mode that requires the `ipvs` kernel module and is not the default; it offers better performance for large clusters but is not set by default.

Full explanation →
45
Multi-Selecthard

Which THREE of the following are true about HorizontalPodAutoscaler (HPA)?

Select 3 answers
A.HPA can use custom metrics from the Kubernetes Metrics Server.
B.HPA supports in-place pod resizing.
C.HPA cannot scale based on memory utilization.
D.HPA can be configured with target average CPU utilization.
E.HPA can scale Deployments and StatefulSets.
AnswersA, D, E

HPA can use custom metrics via the custom.metrics.k8s.io API.

Why this answer

The HorizontalPodAutoscaler (HPA) can use custom metrics provided by the Kubernetes Metrics Server, such as requests per second or queue length, in addition to standard CPU and memory metrics. The HPA retrieves these metrics via the `metrics.k8s.io` API (for resource metrics) or custom metrics APIs, enabling scaling based on application-specific behavior.

Exam trap

The trap here is that candidates often assume HPA only supports CPU metrics, but it also supports memory and custom metrics, and they confuse horizontal scaling (replicas) with vertical scaling (in-place resizing), which is not supported by HPA.

Full explanation →
46
Multi-Selectmedium

Which two commands can be used to view the logs of a container that has crashed? (Choose two.)

Select 2 answers
A.journalctl -u kubelet
B.kubectl logs pod-name --previous
C.kubectl describe pod pod-name
D.systemctl status kubelet
E.kubectl logs pod-name
AnswersB, E

Shows logs of the terminated container.

Why this answer

To view the logs of a container that has crashed, you can use `kubectl logs pod-name` (Option E) to view the logs of the current container instance (even if it is currently in a terminated or waiting state), or `kubectl logs pod-name --previous` (Option B) to view the logs of the previous instance if the container has restarted.

`journalctl -u kubelet` (Option A) and `systemctl status kubelet` (Option D) show the logs and status of the kubelet system service itself, not the stdout/stderr of individual containers. `kubectl describe pod` (Option C) shows pod events and metadata but does not display the container's stdout/stderr logs.

Exam trap

Candidates often think that systemd services like the kubelet store container logs directly. In Kubernetes, container stdout/stderr logs are managed by the container runtime (like containerd) and written to `/var/log/pods`, which `kubectl logs` reads. The kubelet logs themselves only contain cluster-level lifecycle events, not container application logs.

Full explanation →
47
MCQeasy

Which kubectl command is used to view the logs of a container that has previously crashed in a pod?

A.kubectl logs pod-name -c container-name --tail=100
B.kubectl logs pod-name --all-containers
C.kubectl logs pod-name --previous
D.kubectl logs pod-name
AnswerC

Correct. The --previous flag retrieves logs from the previous instance of the container.

Why this answer

The `--previous` flag in `kubectl logs` retrieves logs from the previous instance of a container that has crashed and been restarted. This is essential for debugging crash loops, as the current container may have no logs or only startup logs, while the crashed container's logs contain the error.

Exam trap

The trap here is that candidates assume `kubectl logs` without flags or with `--tail` will show crash logs, but they only see the current container's logs, missing the critical error from the previous crashed instance.

How to eliminate wrong answers

Option A is wrong because `--tail=100` limits the log output to the last 100 lines of the current container's logs, but does not access logs from a previously crashed instance; it is useful for reducing output, not for crash debugging. Option B is wrong because `--all-containers` streams logs from all containers in the pod simultaneously, but it still only shows current container logs, not the logs of a container that has crashed and restarted. Option D is wrong because `kubectl logs pod-name` without flags shows only the current container's logs; if the container has crashed and been replaced, the current container's logs may be empty or irrelevant, missing the crash context.

Full explanation →
48
Multi-Selectmedium

A pod is in 'Pending' state. 'kubectl describe pod' shows: '0/3 nodes are available: 1 Insufficient memory, 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate.' Which THREE actions would resolve the issue? (Choose three)

Select 3 answers
A.Remove the taint from the control-plane nodes.
B.Decrease the memory request of the pod.
C.Increase the CPU request of the pod.
D.Add a toleration to the pod for the control-plane taint.
E.Add a node selector to the pod that matches the control-plane nodes.
AnswersA, B, D

Removing the taint from control-plane nodes makes those nodes schedulable for the pod, provided they have sufficient memory. This is a valid solution.

Why this answer

The pod cannot be scheduled because one node lacks memory and two nodes have a control-plane taint. Any single action that resolves either the memory issue (decreasing memory request) or the taint issue (removing taint or adding toleration) will make a node available. Since the question asks for three actions, A, B, and D are the correct choices as each independently resolves the scheduling block.

Options C and E do not address the reported problems.

Exam trap

Be careful with scheduling issues. A pod only needs one suitable node to schedule. You do not need to resolve the issues on all 3 nodes; resolving the issue on either the memory-constrained node (Option B) OR the tainted nodes (Options A or D) is sufficient to transition the pod out of the 'Pending' state.

Full explanation →
49
MCQeasy

A Pod with a restartPolicy of 'OnFailure' exits with code 0. What will happen?

A.The container will restart immediately.
B.The Pod will be terminated.
C.The Pod will remain in Running state.
D.The container will not restart, and the Pod will be in Succeeded phase.
AnswerD

With restartPolicy: OnFailure, an exit code of 0 means the container completed its workload successfully, so the kubelet deliberately avoids restarting it. Because all containers have exited with code 0 and no restart is warranted, the Pod's phase is set to Succeeded, which is the terminal state for successful Pod completion. This matches the expected behavior for batch or job-style workloads that should run to completion exactly once.

Why this answer

When a Pod has a restartPolicy of 'OnFailure' and its container exits with code 0 (indicating successful completion), the container will not be restarted. Instead, the Pod transitions to the Succeeded phase, as defined by Kubernetes Pod lifecycle semantics. This is because 'OnFailure' only triggers a restart on a non-zero exit code, which signifies a failure.

Exam trap

The trap here is that candidates often confuse 'OnFailure' with 'Always', assuming any exit triggers a restart, or they mistakenly think a Pod is 'terminated' (deleted) when it actually enters a terminal phase like Succeeded.

How to eliminate wrong answers

Option A is wrong because the container will restart only if the exit code is non-zero; exit code 0 indicates success, so no restart occurs. Option B is wrong because the Pod is not terminated; it enters the Succeeded phase, which is a terminal phase but not a termination of the Pod object itself. Option C is wrong because the Pod cannot remain in the Running state after the container exits; it must transition to a terminal phase (Succeeded or Failed) based on the exit code and restartPolicy.

Full explanation →
50
MCQeasy

Which command shows all events in the cluster sorted by timestamp?

A.kubectl describe events
B.kubectl get events
C.kubectl logs --all-namespaces
D.kubectl get events --sort-by=.metadata.creationTimestamp
AnswerD

D is incorrect because although `--sort-by=.metadata.creationTimestamp` sorts events, it sorts by a different timestamp field (creationTimestamp) than the default (lastTimestamp), and the question expects the default sorting behavior without additional flags. Moreover, the event ordering might not match the intended 'sorted by timestamp' meaning when events have multiple timestamps.

Why this answer

According to the official Kubernetes Cheat Sheet, the standard and documented command to list events sorted by timestamp is `kubectl get events --sort-by='.metadata.creationTimestamp'`. While modern versions of kubectl apply some default sorting, using the explicit `--sort-by` flag is the precise, guaranteed, and exam-expected method.

Exam trap

The CKA exam is open-book (using official documentation). If you search the official docs for sorting events, it explicitly directs you to use `kubectl get events --sort-by='.metadata.creationTimestamp'`. Relying on default behavior without the flag can lead to incorrect assumptions or missed points on the exam.

How to eliminate wrong answers

Option A is wrong because `kubectl describe events` does not exist as a valid command; `kubectl describe` is used for resources like pods or nodes, not for events, and would produce an error or unintended output. Option C is wrong because `kubectl logs --all-namespaces` retrieves container logs, not cluster events, and logs are not sorted by timestamp in the same way; this command addresses a different troubleshooting domain. Option D is wrong because while `kubectl get events --sort-by=.metadata.creationTimestamp` would work, it is unnecessarily verbose since `kubectl get events` already sorts by timestamp by default; the question asks for the command that shows events sorted by timestamp, and the extra flag is redundant and not the simplest correct answer.

Full explanation →
51
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.

Full explanation →
52
MCQhard

You apply the following NetworkPolicy to namespace 'ns1': apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-ingress spec: podSelector: {} policyTypes: - Ingress ingress: [] What effect does this policy have?

A.Denies all egress traffic as well.
B.Allows ingress traffic only from pods in the same namespace.
C.Denies all ingress traffic to all pods in namespace ns1.
D.Allows all ingress traffic because no explicit deny rules are defined.
AnswerC

This policy selects all pods in ns1 (or a specific subset, depending on podSelector) and explicitly lists Ingress in policyTypes while providing an empty ingress list. Under Kubernetes NetworkPolicy semantics, an empty rules list means no incoming connections are permitted, so every pod matched by the selector is denied all ingress traffic. This effectively implements a deny-all-ingress rule for the namespace.

Why this answer

This NetworkPolicy selects all pods in namespace 'ns1' (via empty `podSelector: {}`), specifies `policyTypes: [Ingress]`, and defines an empty `ingress: []` rule list. In Kubernetes, an empty `ingress: []` explicitly denies all ingress traffic because no allow rules are present, overriding the default allow-all behavior. Therefore, all ingress traffic to any pod in ns1 is denied.

Exam trap

The trap here is that candidates often misinterpret an empty `ingress: []` as 'no restrictions' (i.e., allow all), when in fact Kubernetes NetworkPolicy semantics define an empty rule list as denying all traffic of that type, which is a common point of confusion in the CKA exam.

How to eliminate wrong answers

Option A is wrong because this policy only specifies `policyTypes: [Ingress]` and does not include `Egress` in the policyTypes list, so egress traffic is unaffected and remains allowed by default. Option B is wrong because the policy has no ingress rules at all (empty `ingress: []`), so it denies all ingress traffic, not just traffic from outside the namespace; it does not selectively allow intra-namespace traffic. Option D is wrong because an empty `ingress: []` is an explicit deny — it is not an absence of rules; Kubernetes NetworkPolicy semantics treat an empty rule list as denying all traffic of that type, not allowing it.

Full explanation →
53
MCQhard

A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?

A.The kubelet configuration file has incorrect node IP.
B.The node's RBAC permissions are misconfigured.
C.The API server is not running.
D.The bootstrap token used for TLS bootstrapping has expired.
AnswerD

Bootstrap tokens used in TLS bootstrapping are intentionally short-lived and can expire, especially if they were created for a one-time node registration. When a token expires, the API server rejects the kubelet's authentication attempt, returning a 401 Unauthorized, and the kubelet cannot complete the bootstrap sequence or download the CA certificate. This precisely matches the observed symptom of a bootstrap CA retrieval failure, making it the correct root cause.

Why this answer

The bootstrap token used for TLS bootstrapping has expired. During the TLS bootstrap process, the kubelet uses a limited-time bootstrap token to authenticate with the API server and request a client certificate. If the token expires before the kubelet completes registration, the kubelet will fail to obtain the bootstrap CA certificate and cannot join the cluster, as indicated by the error 'Failed to get bootstrap CA certificate'.

Exam trap

CNCF often tests the distinction between authentication failures (expired token) and authorization failures (RBAC), leading candidates to incorrectly select RBAC misconfiguration when the actual issue is token expiry.

How to eliminate wrong answers

Option A is wrong because an incorrect node IP would cause connectivity or identity issues, but the specific error 'Failed to get bootstrap CA certificate' points to a TLS bootstrap authentication failure, not an IP misconfiguration. Option B is wrong because RBAC permissions are enforced after authentication; the kubelet cannot even authenticate with an expired token, so RBAC misconfiguration is not the root cause. Option C is wrong because if the API server were not running, the kubelet would likely report a connection refused or timeout error, not a bootstrap CA certificate retrieval failure.

Full explanation →
54
Multi-Selectmedium

Which TWO statements about emptyDir volumes are correct?

Select 2 answers
A.An emptyDir volume is created empty when a Pod is assigned to a node.
B.An emptyDir volume can be shared between Pods on different nodes.
C.An emptyDir volume persists across pod restarts.
D.An emptyDir volume is deleted when the Pod is removed from the node.
E.An emptyDir volume requires a PersistentVolume.
AnswersA, D

When the kubelet binds a Pod to a node, it creates the emptyDir as a genuinely empty directory in the Pod's sandbox before any container starts. No PersistentVolume, storage class, or pre-populated data is involved; the volume is simply a local directory whose entire lifecycle is the Pod's lifetime on that node. For memory-backed emptyDir, it is an empty tmpfs mount instead.

Why this answer

An emptyDir volume is created as an empty directory on the node when a Pod is first assigned to that node. It requires no pre-existing storage and is provisioned on the node's local filesystem (or memory if type is 'Memory').

Exam trap

The trap here is confusing 'container restart' with 'Pod removal' — candidates often think emptyDir is deleted on container restart, but it persists across container restarts and is only deleted when the Pod is deleted from the node.

Full explanation →
55
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.

Full explanation →
56
MCQmedium

A DevOps engineer is designing a Kubernetes cluster for a production environment. Which of the following is a best practice for etcd deployment?

A.Deploy etcd on exactly 2 nodes for simplicity.
B.Deploy etcd on all worker nodes to maximize redundancy.
C.Deploy etcd on dedicated nodes with SSD storage.
D.Deploy etcd on the same nodes as GPU-accelerated workloads.
AnswerC

Deploying etcd on dedicated nodes with SSD storage is the recommended best practice for production Kubernetes clusters. Dedicated nodes ensure etcd has exclusive access to CPU, memory, and network resources, preventing interference from other workloads. Furthermore, etcd is highly sensitive to disk I/O latency, making fast SSD storage crucial for maintaining low write latencies, high throughput, and overall cluster stability and responsiveness.

Why this answer

Etcd is the Kubernetes cluster's primary data store, and its performance directly impacts the entire cluster's stability and responsiveness. Dedicated nodes prevent resource contention from other workloads, while SSD storage provides the low-latency, high-IOPS performance required for etcd's frequent write operations (especially with the default 1 MB write-ahead log). This isolation is a recommended best practice in the official Kubernetes documentation for production clusters.

Exam trap

The trap here is that candidates often assume 'more nodes = more redundancy' (Option B) or that 'simplicity is better' (Option A), without understanding that etcd's Raft consensus requires an odd number of members and that dedicated, fast storage is non-negotiable for production reliability.

How to eliminate wrong answers

Option A is wrong because etcd requires an odd number of members (typically 3, 5, or 7) to maintain a quorum for the Raft consensus algorithm; exactly 2 nodes cannot achieve a majority (quorum requires > N/2, so 2 nodes would need both to agree, creating a single point of failure). Option B is wrong because deploying etcd on all worker nodes introduces severe performance risks due to resource contention with application pods, and it violates the principle of separating the control plane from data plane components. Option D is wrong because GPU-accelerated workloads are typically compute-intensive and can cause unpredictable I/O and CPU spikes, which would degrade etcd's latency-sensitive operations and risk cluster instability.

Full explanation →
57
MCQhard

You have a multi-node cluster. One node shows 'NotReady'. You run 'journalctl -u kubelet' on that node and see 'network plugin is not ready'. What is the most likely cause?

A.The CNI plugin pod (e.g., Calico) is not running on that node
B.The container runtime (e.g., containerd) is down
C.The kubelet service is not running
D.The node's IP address has changed
AnswerA

The kubelet agent on each node continuously monitors the health and operational status of the CNI plugin. If the CNI plugin's pod (e.g., Calico, Flannel) crashes, fails its readiness probes, or is not running on a specific node, the kubelet cannot properly configure network interfaces for pods or establish essential network routes. Consequently, the kubelet reports the node's status as `NotReady` with the specific `NetworkPluginNotReady` condition, indicating a fundamental failure in the node's networking capabilities.

Why this answer

The 'network plugin is not ready' error from kubelet indicates that the kubelet is waiting for a CNI (Container Network Interface) plugin to configure the pod network. If the CNI plugin pod (e.g., Calico, Flannel, Weave) is not running on that specific node, the kubelet cannot set up the network for pods, causing the node to remain in 'NotReady' state. This is the most direct cause because the kubelet relies on the CNI plugin to report readiness before marking the node as Ready.

Exam trap

The trap here is that candidates often confuse 'network plugin is not ready' with a general network connectivity issue or a kubelet failure, but the error specifically points to the CNI plugin not being operational on that node, not the kubelet itself or the container runtime.

How to eliminate wrong answers

Option B is wrong because if the container runtime (e.g., containerd) were down, the kubelet would report a different error, such as 'container runtime is down' or 'failed to connect to containerd', not a network plugin error. Option C is wrong because if the kubelet service were not running, you would not be able to run 'journalctl -u kubelet' successfully, and the node would not show 'NotReady' but would be unreachable entirely. Option D is wrong because a changed node IP address would cause kubelet to fail to register with the control plane, typically resulting in 'Node not found' or authentication errors, not a 'network plugin is not ready' message.

Full explanation →
58
MCQhard

A StatefulSet named 'db' has 3 replicas. You need to update the pod template to change the resource limits. After applying the change, you run 'kubectl rollout status sts db' and it hangs. What is the most likely reason?

A.The update strategy is set to OnDelete, and you need to delete pods manually.
B.The StatefulSet's pod management policy is OrderedReady, and the first pod to update (db-2) is not becoming Ready.
C.The maxSurge setting is preventing the update from starting.
D.The StatefulSet's service name is incorrect, causing DNS resolution failures.
AnswerB

StatefulSets with the default `RollingUpdate` strategy update pods in reverse ordinal order, meaning `db-2`, then `db-1`, then `db-0`. The `OrderedReady` pod management policy, which is also the default, mandates that each new pod must become `Ready` before the controller proceeds to update the next pod. If `db-2` fails its readiness probe, the entire rollout will halt indefinitely at that point, causing `kubectl rollout status` to hang.

Why this answer

StatefulSets with the default OrderedReady pod management policy update pods sequentially in reverse order (from highest ordinal to lowest). When `kubectl rollout status sts db` hangs, it indicates that the update is stuck waiting for the first pod in the update sequence (db-2) to become Ready. If db-2 fails to become Ready due to the new resource limits (e.g., insufficient cluster resources or misconfigured limits), the rollout cannot proceed to update db-1 and db-0, causing the command to hang indefinitely.

Exam trap

The trap here is that candidates confuse StatefulSet update behavior with Deployment behavior, assuming that maxSurge or maxUnavailable settings control the rollout, when in fact StatefulSets do not support those fields and rely on ordered pod management.

How to eliminate wrong answers

Option A is wrong because the OnDelete update strategy requires manual pod deletion to trigger updates, but the question states that the rollout status command hangs, implying the update was applied and is waiting for pods to become Ready—not that pods are untouched. Option C is wrong because StatefulSets do not support a maxSurge setting; maxSurge is a field for Deployments, not StatefulSets, and StatefulSets use a rolling update with partition or podManagementPolicy instead. Option D is wrong because an incorrect service name would cause DNS resolution failures for pod-to-pod communication, but it would not prevent the StatefulSet controller from updating pods or cause the rollout status to hang; the controller would still proceed with the update regardless of DNS issues.

Full explanation →
59
Multi-Selectmedium

Which TWO of the following are valid reclaim policies for a PersistentVolume?

Select 2 answers
A.Snapshot
B.Reuse
C.Retain
D.Delete
E.Archive
AnswersC, D

Retain is correct because it instructs Kubernetes to keep the PersistentVolume and its underlying data after the PVC is deleted. The PV remains in the Released phase and is not automatically available for a new PVC, which protects the data from accidental deletion. An administrator must manually clean up the volume, remove or update the claimRef, and then decide whether to reuse or destroy it.

Why this answer

The `Retain` reclaim policy is one of the three valid policies for a PersistentVolume in Kubernetes. When a PersistentVolumeClaim is deleted, a PV with `Retain` policy will not be automatically reclaimed; instead, the volume remains in a `Released` state, preserving its data for manual administrator intervention.

Exam trap

The trap here is that candidates confuse the `Retain` policy with backup or archival concepts, or mistakenly think `Snapshot` or `Archive` are valid reclaim policies, when Kubernetes only supports `Retain`, `Delete`, and the deprecated `Recycle`.

Full explanation →
60
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.

Full explanation →
61
Multi-Selectmedium

A node is in 'NotReady' state. Which TWO of the following are common causes? (Select 2)

Select 2 answers
A.A pod on the node is in ImagePullBackOff
B.The node has insufficient memory
C.The kubelet service has stopped on the node
D.The Kubernetes API server is down
E.The network plugin (e.g., Calico, Flannel) is not functioning
AnswersC, E

When the kubelet service stops on a node, it can no longer send periodic StatusUpdates (heartbeats) to the API server. After the node-monitor-grace-period expires without a heartbeat, the kube-controller-manager marks the node as NotReady, and even if the node is restarted, the status remains until a healthy kubelet reports again.

Why this answer

Options C and E are correct. A node becomes 'NotReady' when the kubelet stops reporting its status (C) or when the network plugin (e.g., Calico, Flannel) fails, preventing pod networking (E). Option A (ImagePullBackOff) is a pod-level issue and does not affect node status.

Option B (insufficient memory) leads to pod eviction but the node remains Ready if kubelet is healthy. Option D (API server down) affects the entire cluster, but nodes may still show Ready if kubelet is functioning.

Full explanation →
62
Multi-Selecthard

A Kubernetes cluster uses a NetworkPolicy to restrict traffic to a set of pods labeled 'app: db'. Which TWO statements about the following NetworkPolicy are correct? apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-policy spec: podSelector: matchLabels: app: db policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: api ports: - port: 5432

Select 2 answers
A.The database pods can accept traffic on any port from pods with label 'app: api'.
B.Pods in other namespaces with label 'app: api' cannot reach the database pods.
C.The database pods can initiate outbound connections to any destination.
D.Pods from the same namespace but without matching labels can still access the database pods.
E.Pods with label 'app: api' can connect to the database pods on TCP port 5432.
AnswersC, E

Since only Ingress is specified, egress is allowed by default.

Why this answer

NetworkPolicy only restricts inbound (Ingress) traffic when `policyTypes` includes only `Ingress`. By default, if no Egress rules are defined and `policyTypes` does not include `Egress`, outbound traffic is unrestricted. Thus, the database pods can initiate connections to any destination.

Exam trap

The trap here is that candidates often forget that a NetworkPolicy with an ingress rule implicitly denies all other ingress traffic, and that `podSelector` without `namespaceSelector` restricts the rule to the same namespace, allowing cross-namespace traffic to bypass the policy.

Full explanation →
63
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.

Full explanation →
64
MCQhard

You have a Deployment with the following resource limits for containers: memory: 256Mi. The pod is repeatedly killed with OOMKilled. You need to change the limit to 512Mi. Which field should you modify in the Deployment YAML?

A.spec.template.spec.containers[].resources.limits.memory
B.spec.template.spec.containers[].resources.requests.memory
C.spec.template.spec.containers[].resources.requests.cpu
D.spec.template.spec.containers[].resources.limits.cpu
AnswerA

The container's memory limit is implemented as a cgroup v2 (or v1) limit on the memory cgroup to which that container belongs. When the container's resident set size plus page cache exceeds this limit, the kernel's out-of-memory (OOM) killer selects a process in that cgroup — usually the container's main PID — and kills it, resulting in OOMKilled. Increasing spec.template.spec.containers[].resources.limits.memory raises this cgroup ceiling, giving the container more usable memory headroom before the kernel decides to kill its process, which is exactly why this field addresses the reported OOMKilled status.

Why this answer

The OOMKilled error occurs when a container exceeds its memory limit. To resolve this, you must increase the memory limit in the Deployment's pod template. Option A correctly identifies the field `spec.template.spec.containers[].resources.limits.memory`, which directly controls the maximum memory the container can use before being killed by the OOM killer.

Exam trap

The trap here is that candidates confuse `requests` (which only affects scheduling and QoS class) with `limits` (which enforces hard resource caps), leading them to mistakenly modify `requests.memory` instead of `limits.memory` to fix an OOMKilled issue.

How to eliminate wrong answers

Option B is wrong because `resources.requests.memory` is the minimum memory guaranteed to the container, not the limit that triggers OOMKilled; changing requests does not prevent the OOM killer from terminating the container if it exceeds the limit. Option C is wrong because `resources.requests.cpu` sets the minimum CPU allocation, which has no effect on memory-related OOM kills. Option D is wrong because `resources.limits.cpu` caps CPU usage, not memory; exceeding the CPU limit causes throttling, not OOMKilled.

Full explanation →
65
Multi-Selectmedium

Which TWO statements about PersistentVolume (PV) reclaim policies are correct?

Select 2 answers
A.Retain: The PV remains in the cluster and must be manually reclaimed.
B.Retain: The underlying storage asset is automatically deleted.
C.Recycle: The PV is automatically cleaned and made available for a new claim.
D.Delete: The PV must be manually deleted by the administrator.
E.Delete: The PV and the associated storage asset are automatically deleted.
AnswersA, E

Retain is correct because the PersistentVolume object remains in the cluster after its PVC is released, transitioning to the Released phase rather than being automatically removed. The underlying storage asset is preserved intact, and an administrator must manually reclaim it, typically by deleting the PV or clearing the claimRef so the volume can be reused under a new claim.

Why this answer

The Retain reclaim policy leaves the PersistentVolume (PV) in the cluster in a 'Released' state after the PersistentVolumeClaim (PVC) is deleted. The underlying storage asset (e.g., an EBS volume or NFS export) is not touched by Kubernetes, and the administrator must manually delete the PV object and then handle the storage asset (e.g., reuse or delete it) outside of Kubernetes.

Exam trap

The trap here is that candidates confuse Retain with automatic cleanup or think Recycle is still a valid, active policy, when in fact it has been deprecated and removed in recent Kubernetes versions.

Full explanation →
66
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.

Full explanation →
67
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.

Full explanation →
68
MCQeasy

What is the default DNS name for a Service named 'my-service' in namespace 'my-ns'?

A.my-service.my-ns.cluster.local
B.my-service.svc.my-ns.cluster.local
C.my-service.cluster.local
D.my-service.my-ns.svc.cluster.local
AnswerD

This is the standard fully qualified domain name (FQDN) for a Kubernetes Service in the 'my-ns' namespace. The format '<service>.<namespace>.svc.cluster.local' is defined by the cluster's DNS specification, typically implemented by CoreDNS, and resolves to the Service's ClusterIP or to the pod IPs for headless Services. This FQDN works from any namespace within the cluster.

Why this answer

In Kubernetes, the default DNS name for a Service follows the pattern `<service-name>.<namespace>.svc.cluster.local`. This is defined by the cluster DNS specification (CoreDNS or kube-dns). For a Service named 'my-service' in namespace 'my-ns', the fully qualified domain name (FQDN) is `my-service.my-ns.svc.cluster.local`.

The `.svc` subdomain is a fixed part of the DNS schema, distinguishing Services from other resource types like Pods.

Exam trap

The trap here is that candidates often forget the `.svc` subdomain or misplace it, leading them to choose options like A or B, but the correct order is always `<service>.<namespace>.svc.cluster.local`.

How to eliminate wrong answers

Option A is wrong because it omits the `.svc` component, which is required in the DNS name for Services; the correct pattern includes `.svc` after the namespace. Option B is wrong because it places `.svc` before the namespace, reversing the correct order; the namespace must come before `.svc`. Option C is wrong because it omits both the namespace and the `.svc` component, which would only match a Service in the default namespace if the pattern were incomplete, but the full FQDN always includes namespace and `.svc`.

Full explanation →
69
MCQmedium

You run 'kubectl get pods' and see a pod in 'ImagePullBackOff' state. Which command would help you determine the exact reason for the image pull failure?

A.kubectl describe pod <pod-name>
B.kubectl top pod <pod-name>
C.kubectl logs <pod-name>
D.kubectl get events
AnswerA

"kubectl describe pod <pod-name>" provides a comprehensive summary of a pod's current state, including its status, events, and container specifications. When a pod is in `ImagePullBackOff`, this command will display the specific events related to the image pull attempt, such as `Failed` or `ErrImagePull`, along with the exact error message from the container runtime. This detailed output is crucial for diagnosing the root cause, such as an incorrect image name, a private registry authentication failure, or network issues, making it the most direct and effective diagnostic tool.

Why this answer

A is correct because 'kubectl describe pod <pod-name>' provides detailed information about the pod, including the container status, events, and the exact error message from the image pull attempt. This output includes the reason for the ImagePullBackOff, such as a missing image, incorrect tag, authentication failure, or network issue, which is essential for troubleshooting.

Exam trap

The trap here is that candidates often choose 'kubectl logs' thinking it will show the error, but logs only exist if the container started; for ImagePullBackOff, the container never runs, so logs are empty and the describe command is the correct tool.

How to eliminate wrong answers

Option B is wrong because 'kubectl top pod' shows resource usage (CPU/memory) and does not provide any information about image pull failures. Option C is wrong because 'kubectl logs' retrieves container logs, but if the container never started due to ImagePullBackOff, there are no logs to fetch; the error is in the pod status, not in stdout/stderr. Option D is wrong because 'kubectl get events' shows cluster-wide events, but it may not include the specific image pull error for the pod, and it is less detailed than the pod description; the describe command is the standard tool for this scenario.

Full explanation →
70
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.

Full explanation →
71
MCQeasy

What is the purpose of a Headless Service (clusterIP: None)?

A.To allow DNS queries to return all pod IPs for a StatefulSet
B.To expose the Service externally via a cloud load balancer
C.To provide load balancing across pods
D.To assign a static ClusterIP
AnswerA

A headless Service (spec.clusterIP: None) allocates no ClusterIP, so kube-proxy provides no virtual IP or load balancing. Instead, the DNS entry for the Service resolves to the set of individual Pod IPs backing that Service; for a StatefulSet, this enables clients and peers to discover and connect directly to every Pod, including via stable names like pod-0.svc.namespace.svc.cluster.local. This is the standard cluster-internal pattern for stateful discovery (e.g., databases), not a stable front-end VIP.

Why this answer

A Headless Service (clusterIP: None) is used when you want to discover individual pod IPs directly, rather than having a single virtual IP load-balance traffic. When a Service has clusterIP set to None, DNS queries return the A/AAAA records for all ready pod IPs, which is essential for StatefulSets where each pod has a unique identity and needs to be addressed individually, such as in clustered databases like Cassandra or Kafka.

Exam trap

The trap here is that candidates often confuse a Headless Service with a regular ClusterIP Service, thinking it still provides load balancing or a stable virtual IP, when in fact it disables both and returns all pod IPs for direct pod-to-pod communication.

How to eliminate wrong answers

Option B is wrong because exposing a Service externally via a cloud load balancer requires setting type: LoadBalancer, not clusterIP: None. Option C is wrong because a Headless Service does not provide load balancing; it bypasses the kube-proxy and returns all pod IPs, leaving load balancing to the client or application. Option D is wrong because clusterIP: None explicitly prevents assigning a static ClusterIP; instead, it makes the Service headless with no ClusterIP at all.

Full explanation →
72
MCQhard

You have a Pod that is stuck in Pending state. Running 'kubectl describe pod' shows events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 3 node(s) had taint {key: value}, that the pod didn't tolerate.' How can you resolve this issue?

A.Increase the Pod's resource requests
B.Remove the taints from all nodes using 'kubectl taint nodes --all key:value-'
C.Delete the Pod and recreate it with a different name
D.Add appropriate tolerations to the Pod's spec
AnswerD

Adding matching tolerations to the Pod's specification directly instructs the kube-scheduler that this Pod is allowed to run on nodes with corresponding taints. This is the standard, least-privilege method to resolve scheduling issues on tainted nodes without compromising the cluster's overall node isolation strategy. Once the toleration is applied, the scheduler can successfully bind the Pod to the tainted node.

Why this answer

The Pod is stuck in Pending because none of the nodes can schedule it due to taints that the Pod does not tolerate. Option D is correct because adding the appropriate tolerations to the Pod's spec tells the scheduler that the Pod can tolerate those taints, allowing it to be scheduled on the tainted nodes. This directly addresses the mismatch between node taints and Pod tolerations.

A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

Exam trap

A common misconception in the CKA exam is that removing taints from nodes is the only fix, but the correct Kubernetes approach is to add tolerations to the Pod spec, preserving node isolation for other workloads.

How to eliminate wrong answers

Option A is wrong because increasing resource requests would only worsen scheduling constraints, not resolve taint/toleration mismatches. Option B is wrong because removing taints from all nodes is an overly broad and potentially disruptive action; the correct approach is to add tolerations to the Pod, not modify cluster-wide node settings. Option C is wrong because simply deleting and recreating the Pod with a different name does not change its toleration configuration, so it would still be stuck in Pending.

Full explanation →
73
MCQmedium

You have a DaemonSet that runs a logging agent. You want to ensure it only runs on nodes with GPU. Which field should you set in the DaemonSet's pod template spec?

A.spec.selector
B.spec.template.spec.nodeSelector
C.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution
D.spec.template.spec.nodeName
AnswerB

spec.template.spec.nodeSelector is the correct and most straightforward method to constrain a DaemonSet to run only on nodes possessing specific labels. By defining a map of key-value pairs here, the DaemonSet controller will only create pods on nodes that match all of these labels. This effectively filters the cluster's nodes, ensuring the logging agent runs exclusively on the desired subset of infrastructure.

Why this answer

`spec.template.spec.nodeSelector` is a simple, direct field in the Pod template spec that constrains which nodes the DaemonSet's pods can be scheduled on. By setting a key-value pair like `gpu: true`, you ensure the logging agent only runs on nodes that have that label, which is the standard Kubernetes mechanism for node-level selection without complex expressions.

Exam trap

The trap here is that candidates often confuse `spec.selector` (which manages pod ownership) with `nodeSelector` (which manages scheduling constraints), or they over-engineer by choosing node affinity when the simpler `nodeSelector` is sufficient for the question's requirement.

How to eliminate wrong answers

Option A is wrong because `spec.selector` is a label selector used by the DaemonSet controller to identify which pods it manages, not to constrain scheduling to specific nodes. Option C is wrong because `spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution` is a more advanced and verbose way to achieve node selection, but the question asks for the simplest field to set, and `nodeSelector` is the correct minimal answer. Option D is wrong because `spec.template.spec.nodeName` directly assigns a pod to a specific node by name, bypassing the scheduler entirely, which is inflexible and not suitable for a DaemonSet that should run on multiple nodes matching a condition.

Full explanation →
74
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.

Full explanation →
75
MCQhard

A pod runs but you cannot connect to its container port from another pod in the same namespace. 'kubectl exec' into the pod and 'curl localhost:8080' works. What is the MOST likely cause?

A.There is a NetworkPolicy blocking ingress
B.The container's port is not exposed in the pod spec
C.The Service selector does not match the pod labels
D.The pod is bound to localhost only, not 0.0.0.0
AnswerD

Binding to localhost (127.0.0.1) restricts connections to only the same network namespace, which is isolated to the container itself. Kubernetes networking relies on the pod's IP address and virtual Ethernet interfaces, so a loopback bind cannot receive traffic from outside the pod. Listening on 0.0.0.0 makes the port available on all interfaces, including the pod's external-facing one.

Why this answer

When `curl localhost:8080` works inside the pod but connections from other pods fail, the most likely cause is that the application is listening only on the loopback interface (127.0.0.1) instead of 0.0.0.0 (all interfaces). This means the container process binds to localhost, which is only reachable from within the same network namespace (the pod itself), not from external sources like other pods. Kubernetes networking relies on the container listening on 0.0.0.0 so that traffic arriving via the pod's eth0 interface (which has its own IP) can be accepted.

Exam trap

The trap here is that candidates often assume a Service issue (Option C) is the cause, but the question specifies direct pod-to-pod connectivity (not via a Service), so the real problem is the application binding to localhost, which is a classic application-layer misconfiguration rather than a Kubernetes networking misconfiguration.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy blocking ingress would prevent connections from other pods even if the application is correctly listening on 0.0.0.0, but the fact that `curl localhost:8080` works inside the pod does not rule out a NetworkPolicy; however, the symptom of localhost working while external connections fail points directly to a binding issue, not a policy. Option B is wrong because the container's port not being exposed in the pod spec (i.e., missing `containerPort`) does not affect whether the application listens on the correct interface; it only affects service discovery and documentation, not actual network connectivity. Option C is wrong because the Service selector not matching pod labels would prevent traffic from reaching the pod via the Service, but the question states the connection attempt is 'from another pod in the same namespace' — this could be direct pod-to-pod via IP, which bypasses the Service entirely, so a mismatched selector would not explain the failure.

Full explanation →

Page 1 of 5

Page 2

All pages

12345

Practice CKA by domain

Target a specific domain to shore up weak areas.

Cluster Architecture, Installation and ConfigurationServices and NetworkingWorkloads and SchedulingStorageTroubleshootingCluster Architecture, Installation & ConfigurationWorkloads & SchedulingServices & Networking
See all domains with question counts →