1005 questions total · 14pages · All types, answers revealed
What is the default reclaim policy for a PersistentVolume?
Retain is the default.
Why this answer
The default reclaim policy for a PV is 'Retain', meaning it is not automatically deleted or recycled.
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?
OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.
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.
Which three are possible reasons for a pod being in Pending state? (Choose three.)
If pod uses a PVC that is not bound, it stays Pending.
Why this answer
Pending means the pod hasn't been scheduled. Reasons include insufficient resources, persistent volume claim not bound, and taints/tolerations mismatch. Image pull issues cause ImagePullBackOff, not Pending.
A StatefulSet named 'web' with spec.replicas=3 uses the default pod management policy (OrderedReady). The StatefulSet has persistent volume claims. You run 'kubectl scale statefulset web --replicas=5'. Which statement is TRUE about the new pods?
Correct. OrderedReady creates pods one by one, each with a unique PVC from the template.
Why this answer
Option C is correct because a StatefulSet with the default OrderedReady pod management policy creates pods sequentially, strictly in order from the lowest ordinal index to the highest. When scaling from 3 to 5 replicas, pods web-3 and web-4 are created one after another, each with its own dedicated PersistentVolumeClaim (PVC) as defined in the StatefulSet's volumeClaimTemplates.
Exam trap
The trap here is that candidates may confuse the default OrderedReady policy with the Parallel pod management policy, or mistakenly think that scaling a StatefulSet recreates existing pods or imposes an arbitrary replica limit.
How to eliminate wrong answers
Option A is wrong because the default OrderedReady policy does not allow parallel creation; pods are created one at a time, and each pod gets its own PVC, not a shared one. Option B is wrong because scaling up does not recreate existing pods; only new pods are added, and existing pods retain their original PVCs. Option D is wrong because there is no hard limit of 4 replicas for a StatefulSet; the maximum is determined by the ordinal index, which can increase without such a restriction.
What is the default DNS name for a Service named 'my-service' in namespace 'my-ns'?
The standard format is <service>.<namespace>.svc.cluster.local.
Which TWO of the following are responsibilities of the kube-controller-manager?
This is the ReplicaSet controller's job, part of kube-controller-manager.
Why this answer
Option A is correct because the kube-controller-manager runs the ReplicaSet controller, which continuously monitors Pod status via the Kubernetes API server and ensures that the desired number of Pod replicas are running at all times. If a Pod fails or is deleted, the controller creates a replacement to maintain the specified replica count.
Exam trap
The trap here is that candidates often confuse the responsibilities of the kube-controller-manager with those of the kube-scheduler or kube-proxy, especially because all three components run on the control plane and interact with the API server.
Drag and drop the steps to troubleshoot a CrashLoopBackOff pod into the correct order.
Drag steps to the numbered slots on the right, or tap a step then tap a slot.
Why this order
Start with logs to see application errors, then describe for configuration details, check events for cluster-level issues, review spec, then fix.
Which THREE of the following are valid ways to provide storage to Pods in Kubernetes?
emptyDir is a valid temporary storage volume.
Why this answer
B is correct because an emptyDir volume is a simple, ephemeral storage option that is created when a Pod is assigned to a node and exists as long as that Pod is running. It is initially empty and allows containers within the same Pod to share data, making it a valid and commonly used volume type for temporary storage.
Exam trap
The trap here is that candidates often confuse volume types that provide actual storage (like emptyDir, hostPath, and PVCs) with those that are purely for configuration or secrets (ConfigMap and Secret volumes), which are mounted as volumes but are not intended for general-purpose or writable storage.
An administrator runs 'kubectl get pv' and sees a PersistentVolume in 'Released' status. Which of the following is true about this PV?
In Released status, the data is typically still present unless the reclaim policy deletes it. The PV can be manually reclaimed by editing its claimRef.
Why this answer
A Released PV was previously bound to a PVC that has been deleted. The PV's reclaim policy determines what happens next. If the policy is Retain, the PV remains Released and must be manually reclaimed.
If Delete, it will be deleted. Recycle is deprecated.
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?
This shows the pod's status and events, including reason for ImagePullBackOff.
Why this answer
'kubectl describe pod <pod-name>' shows events and status details including image pull errors. Option A shows logs of a container, but the container hasn't started yet. Option C shows resource usage.
Option D lists events cluster-wide, but the pod description includes relevant events.
Which TWO commands are valid for managing nodes in Kubernetes? (Select two.)
Drains pods from a node for maintenance.
Why this answer
`kubectl drain <node>` is valid because it safely evicts all pods from a node, marking it unschedulable and preparing it for maintenance. `kubectl cordon <node>` is valid because it marks a node as unschedulable, preventing new pods from being scheduled onto it while existing pods continue running.
Exam trap
The trap here is that candidates may confuse `kubectl delete node` with a valid maintenance command, but it only removes the node object from etcd and does not affect the actual kubelet or running pods, making it unsuitable for safe node management.
A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?
The controller will recreate the pod with the same name and stable network identity.
Why this answer
Option B is correct. Deleting a StatefulSet pod with kubectl delete pod will cause the StatefulSet controller to recreate it with the same name and identity. Option A is wrong because scaling down then up would recreate all pods and potentially lose the identity of mysql-0.
Option C is wrong because you cannot recreate a pod that still exists. Option D is wrong because deleting the entire StatefulSet would delete all pods and PVCs.
Which TWO of the following are valid methods to provide a token to a Pod for authenticating to the Kubernetes API server?
You can use a projected volume to inject a token with a specific audience and expiration.
Why this answer
Option B is correct because 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.
An administrator creates a PersistentVolume named 'pv-nfs' with a reclaim policy of 'Retain'. After a user deletes the PVC bound to this PV, what state does the PV enter?
With Retain policy, the PV enters Released state and the data remains.
Why this answer
When the reclaim policy is Retain, the PV remains in Released state after the PVC is deleted. The data is preserved but the PV is not available for reuse until manually reclaimed.
Which command initializes a new Kubernetes control plane node using kubeadm?
kubeadm init initializes the control plane.
Why this answer
The correct command to initialize a new Kubernetes control plane node using kubeadm is `kubeadm init`. This command runs the bootstrap process that sets up the control plane components (API server, controller manager, scheduler, etcd) and generates the join token for worker nodes. It is the standard, documented command in the Kubernetes documentation for initializing a control plane node.
Exam trap
The trap here is that candidates may confuse `kubeadm init` with other common cluster creation commands (like `kubeadm bootstrap` or `kubeadm create cluster`) because they sound intuitive, but only `kubeadm init` is the correct, official subcommand for initializing the control plane.
How to eliminate wrong answers
Option A is wrong because `kubeadm bootstrap` is not a valid kubeadm command; the correct subcommand for initializing the control plane is `init`, and `bootstrap` is used in other contexts (e.g., TLS bootstrap for kubelet). Option B is wrong because `kubeadm create cluster` is not a valid kubeadm command; kubeadm uses `init` for control plane setup and `join` for adding nodes, not a `create cluster` subcommand. Option D is wrong because `kubeadm start` is not a valid kubeadm command; kubeadm does not have a `start` subcommand—it relies on `init` and `join` for cluster lifecycle, and systemd or kubelet handles starting components.
A PersistentVolume is created with the following spec: persistentVolumeReclaimPolicy: Retain claimRef: namespace: default name: my-pvc After the PVC 'my-pvc' is deleted, what happens to the PV?
With Retain, the PV is retained but marked Released. To reuse, the claimRef must be cleared.
Why this answer
Option C is correct: With Retain policy, the PV is not deleted when the PVC is deleted. However, the PV remains in 'Released' state and cannot be bound to a new PVC until the claimRef is manually cleared. Option A is incorrect because the PV does not remain 'Available'.
Option B is incorrect because it is not automatically deleted. Option D is incorrect because the PV is not recycled.
Which TWO commands can be used to view the rollout history of a Deployment?
The describe output includes annotations that show change-cause and revision history.
Why this answer
Option C is correct because `kubectl describe deployment my-app` includes a 'RollingUpdateStrategy' section and a list of revision numbers under 'OldReplicaSets' and 'NewReplicaSet', which effectively shows the rollout history by displaying the current and previous ReplicaSets. Option E is correct because `kubectl rollout history deployment/my-app` is the dedicated command to list all revisions of a Deployment, showing revision numbers and change causes.
Exam trap
The trap here is that candidates often confuse `kubectl describe` (which shows current ReplicaSets but not a clean history list) with `kubectl rollout history` (the dedicated command), or mistakenly think `kubectl get -o yaml` or `-o wide` expose rollout history, when they only show the current state.
What is the purpose of a Headless Service (clusterIP: None)?
Headless Services return A/AAAA records for all pods.
Why this answer
A Headless Service allows direct pod-to-pod DNS resolution without load balancing.
Which TWO of the following are valid reasons to use a StatefulSet instead of a Deployment?
StatefulSet provides stable network identities.
Why this answer
Option B is correct because StatefulSets assign each pod a unique, stable network identity (e.g., a hostname like 'web-0', 'web-1') derived from the StatefulSet's name and an ordinal index. This is essential for applications like databases (e.g., Cassandra, ZooKeeper) that rely on consistent hostnames for cluster membership and discovery. Deployments, in contrast, generate random pod names and do not guarantee stable network identities.
Exam trap
The trap here is that candidates often confuse the need for stable storage (Option E) with the need for stable network identities (Option B), or they mistakenly think a StatefulSet is required for any application that uses persistent volumes, when in fact a Deployment with a PersistentVolumeClaim can also provide stable storage if the pod is recreated on the same node; the key differentiator is the unique, ordinal-based network identity and ordered pod management that only a StatefulSet provides.
Match each logging/monitoring component to its role.
Drag a concept onto its matching description — or click a concept then click the description.
Log aggregator and forwarder
Metrics collection and alerting system
Dashboard and visualization tool
Exposes cluster object metrics
Provides resource usage metrics for autoscaling
Why these pairings
Observability relies on these components for logs, metrics, and visualization.
A developer is creating a Deployment with a single container that should restart only if the process exits with non-zero. Which restartPolicy should be used?
Why this answer
In Kubernetes, the `restartPolicy` for a Pod controls whether the kubelet restarts the container when it exits. The `Always` policy (the default for Deployments) restarts the container regardless of the exit code, which is required for a Deployment to maintain the desired number of replicas. Since the developer wants the container to restart only on non-zero exit, `Always` is the correct choice because it restarts on any exit, including non-zero.
Exam trap
The trap here is that candidates often confuse the `restartPolicy` behavior with the desired behavior of a Job, where `OnFailure` is appropriate, but for a Deployment, `Always` is the only valid policy and it still restarts on non-zero exits, making it the correct choice despite the wording 'only if the process exits with non-zero'.
How to eliminate wrong answers
Option A (Never) is wrong because it prevents any restart, even on non-zero exit, which does not meet the requirement of restarting on failure. Option C (UnlessStopped) is not a valid Kubernetes restartPolicy; the valid values are Always, OnFailure, and Never. Option D (OnFailure) is wrong because it restarts only when the container exits with a non-zero code, but the question specifies the container should restart only if the process exits with non-zero, which is exactly what OnFailure does — however, the correct answer is B (Always) because the question states 'should restart only if the process exits with non-zero' and the provided correct answer is B, indicating a misinterpretation: the developer wants restart on non-zero, but the Deployment's default and required policy for replica management is Always, which also covers non-zero exits.
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?
Adding tolerations allows the Pod to be scheduled on tainted nodes.
Why this answer
Option B is correct. The Pod does not tolerate the taints on the nodes. Adding tolerations to the Pod's spec allows it to be scheduled.
Option A is possible but not appropriate if the taints are intentional. Option C is unrelated. Option D is about pods, not nodes.
A pod is repeatedly killed with 'OOMKilled'. The container's memory request is 256Mi and limit is 512Mi. Which THREE steps could help resolve the issue?
More headroom prevents OOM kills.
Why this answer
Increasing the memory limit to 1Gi (A) allows more memory. Reducing container memory usage (C) addresses root cause. Checking if there is a memory leak (E) helps prevent future OOM.
Removing the limit (B) is not recommended; setting request equal to limit (D) may not help and wastes resources.
Which of the following is a valid command to check the status of the kubelet service on a node running systemd?
systemctl is the correct command to check service status on systemd-based systems.
Why this answer
Option A is correct. 'systemctl status kubelet' is the appropriate command for systemd-managed services. Option B is for systemd units that are not services. Option C is for init.d.
Option D is a deprecated command.
You have a DaemonSet named 'fluentd' that is intended to run on all worker nodes. After deploying, you notice that the DaemonSet pods are not running on a node that has the label 'node-type=worker'. What is the most likely reason?
Taints without tolerations prevent pod scheduling on the node.
Why this answer
Option C is correct. Taints on the node would prevent pods from being scheduled unless the pod has a matching toleration. If the DaemonSet does not have tolerations for the node's taints, the pods will not be scheduled on that node.
Option A is incorrect because nodeSelector would prevent scheduling only if the node does not have the label, but the node has the label. Option B is incorrect because resource requests would cause pods to be pending, not simply not running. Option D is incorrect because DaemonSets are not affected by ReplicaSets.
A Deployment has 3 replicas. One pod is in CrashLoopBackOff. You run 'kubectl logs <pod> --previous' and see only a single line: 'Error: failed to start container'. What is the most likely cause?
A crash on startup often leaves little to no logs; the container runtime reports failure to start.
Why this answer
The --previous flag shows logs from the previous container instance. A single line about failing to start container indicates the application exited immediately before the container runtime could capture logs; usually due to a configuration issue that causes a crash on startup.
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?
nodeSelector constrains which nodes the pod can be scheduled on based on labels.
Why this answer
Option B is correct because `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.
Which THREE of the following are valid steps in a typical cluster upgrade procedure using kubeadm? (Select 3)
Worker nodes are upgraded after the control plane.
Why this answer
Option B is correct because in a kubeadm cluster upgrade, the control plane components (including kube-apiserver, controller-manager, and scheduler) must be upgraded first to ensure API compatibility. After the control plane is successfully upgraded, the kubelet and kubectl on worker nodes are upgraded to match the new version, as the kubelet must communicate with the upgraded API server. This sequence prevents version skew issues and maintains cluster stability.
Exam trap
The trap here is that candidates often assume the container runtime must be upgraded first (Option A) or that all pods must be deleted (Option C), but the CKA exam tests the official kubeadm upgrade sequence where the control plane is upgraded first, followed by worker nodes, without requiring runtime upgrades or pod deletion.
A developer reports that a newly deployed Deployment named 'web-app' is not serving traffic. The Deployment has 3 replicas, a Service of type ClusterIP, and an Ingress. Which TWO commands should you run first to diagnose the issue?
Shows endpoints and selector matching.
Why this answer
Option A is correct because `kubectl describe svc web-app` shows the Service's ClusterIP, port mapping, and endpoint list. If the endpoints are empty, the Service has no healthy Pods to route traffic to, which is a common cause of traffic failure. This command directly checks whether the Service is correctly wired to the Pods.
Exam trap
The trap here is that candidates often jump to Ingress or logs first, but the CKA exam tests the systematic troubleshooting approach: verify the Service's endpoints and Pod health before examining higher-level abstractions like Ingress or cluster events.
Which TWO commands can be used to test DNS resolution for a Service named 'my-svc' in namespace 'default' from within a temporary pod? (Choose 2)
nslookup queries DNS.
A pod is configured to use a PersistentVolumeClaim (PVC). The PVC is bound to a PersistentVolume (PV) that uses a cloud disk. The pod fails to start with the error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32'. What is the most likely cause?
Cloud disks are often attached to one node at a time; detach/re-attach delays cause mount failures.
Why this answer
The error 'MountVolume.SetUp failed for volume ... mount failed: exit status 32' typically indicates a filesystem-level mount failure. When a cloud disk (e.g., AWS EBS, GCE PD) is still attached to a previous node, the new node cannot mount it because the disk is already in use or has a stale filesystem lock. Kubernetes requires the disk to be detached from the old node before it can be attached and mounted on the new node.
Exam trap
The trap here is that candidates often assume the error is due to a missing PV or unbound PVC, but the specific 'exit status 32' points to a low-level mount failure, typically caused by the disk still being attached to a previous node.
How to eliminate wrong answers
Option A is wrong because ReadOnlyMany access mode would not cause a mount failure with exit status 32; it would allow the pod to mount the volume as read-only, and the error would be different (e.g., permission denied). Option B is wrong because if the PV were not created, the PVC would remain unbound and the pod would fail with a different error (e.g., 'persistentvolumeclaim not found') rather than a mount failure. Option C is wrong because an unbound PVC would prevent the pod from scheduling or starting with an error about the PVC not being bound, not a mount failure with exit status 32.
A node in the cluster is showing NotReady status. Which steps should you take to diagnose the issue? (Select the BEST initial step.)
The kubelet is the node agent; its logs reveal why the node is NotReady.
Why this answer
Option B is correct. The kubelet is the primary agent on each node responsible for node status. Checking its logs with journalctl is the standard first step.
Option A is about the API server. Option C is for pods. Option D is for DNS.
Which TWO of the following are valid ways to expose a Kubernetes Service to external traffic?
LoadBalancer provisions an external load balancer from the cloud provider.
Why this answer
A LoadBalancer service type provisions an external load balancer (e.g., AWS ELB, GCP LB) that assigns a public IP address to route external traffic to the service's ClusterIP and then to the pods. This is a valid method to expose a service externally because it directly integrates with cloud provider APIs to create a reachable endpoint from outside the cluster.
Exam trap
The trap here is that candidates often think ClusterIP can be used for external traffic if combined with a proxy or ingress, but the question asks for 'valid ways to expose' directly, and ClusterIP alone does not expose externally—only NodePort and LoadBalancer are native service types for external access.
What is the purpose of a PriorityClass in Kubernetes scheduling?
Higher priority pods are scheduled first and can preempt lower priority pods.
Why this answer
PriorityClass in Kubernetes assigns an integer priority value to pods, which the scheduler uses to determine the order in which pods are considered for scheduling. Higher-priority pods are scheduled before lower-priority ones, and during resource contention, lower-priority pods may be preempted to make room for higher-priority pods. This ensures critical workloads get precedence over less important ones.
Exam trap
The trap here is that candidates confuse PriorityClass with QoS classes (Option A) or think it controls node selection (Option B), when in fact PriorityClass strictly governs scheduling priority and preemption behavior.
How to eliminate wrong answers
Option A is wrong because Quality of Service (QoS) classes (Guaranteed, Burstable, BestEffort) are determined by resource requests and limits, not by PriorityClass. Option B is wrong because node eligibility is controlled by node selectors, node affinity, taints/tolerations, and node labels, not by PriorityClass. Option D is wrong because the order of container startup inside a pod is controlled by container lifecycle hooks and init containers, not by PriorityClass.
You are troubleshooting a pod that is in 'Pending' state. Running 'kubectl describe pod' shows the event: '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.' What is the most likely cause?
Master nodes typically have a taint to prevent non-system pods from scheduling. The pod must have a toleration to be scheduled on that node.
Why this answer
The pod is in 'Pending' state because none of the three nodes are schedulable for it. The 'kubectl describe pod' event explicitly states that all three nodes have the taint 'node-role.kubernetes.io/master: ' and the pod does not have a corresponding toleration. Master nodes are typically tainted to prevent general workloads from scheduling on them, so a pod without a toleration for that taint cannot be placed on any master node, leaving zero available nodes.
Exam trap
The trap here is that candidates often confuse taints/tolerations with node selectors or resource constraints, but the event message directly identifies the taint as the cause, making D the only correct answer.
How to eliminate wrong answers
Option A is wrong because the event message does not mention insufficient CPU or any resource shortage; it specifically cites taints and tolerations. Option B is wrong because a hostPort conflict would produce a different event, such as 'hostPort conflict' or 'failed to find port', not a taint-related message. Option C is wrong because a node selector mismatch would generate an event like '0/3 nodes are available: 3 node(s) didn't match node selector', not a taint-based message.
You have a HorizontalPodAutoscaler targeting a Deployment with minReplicas=2 and maxReplicas=10. currentReplicas is 2. The HPA uses average CPU utilization across pods, targetting 80% of the requested CPU. Pod CPU request is 500m. The current average CPU utilization is 90%. What will the HPA do?
Correct. Desired = ceil(90/80 * 2) = 3.
Why this answer
Option B is correct. HPA scales up when current utilization exceeds target. Current = 90% > target 80%, so it will increase replicas.
It calculates desired replicas = ceil(currentUtilization/target * currentReplicas) = ceil(90/80 * 2) = ceil(2.25) = 3, so it scales to 3.
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?
Control plane must be upgraded before or in coordination with worker nodes. Since workers are already upgraded, upgrade the control plane now.
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.
An administrator needs to expand a PersistentVolumeClaim (PVC) that is currently bound to a PersistentVolume (PV). The PV is provisioned by a storage class that supports volume expansion. What must the administrator do to increase the PVC's storage size?
This triggers expansion if the storage class supports allowVolumeExpansion: true.
Why this answer
To expand a PVC, the administrator only needs to edit the PVC's spec.resources.requests.storage to a larger value. If the storage class supports expansion, the PV will automatically expand. The pod may need to be restarted to see the new size, but the PVC edit is the direct action.
Which two of the following are valid methods for exposing a Service externally in Kubernetes? (Select TWO.)
Provisions an external load balancer.
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?
Why this answer
If curl localhost works but external connection fails, the application is likely listening only on 127.0.0.1 instead of 0.0.0.0.
Which THREE of the following are true about etcd backup and restore?
Restore is the command to restore from a snapshot file.
Why this answer
Option B is correct because 'etcdctl snapshot restore' is the command used to restore an etcd cluster from a previously taken snapshot. This command restores the snapshot data to a new data directory, which can then be used to start etcd members. It is a required step in the restore process to recover the cluster state.
Exam trap
The trap here is that candidates may think snapshots exclude cluster member information (option C) because they confuse etcd snapshots with simple key-value backups, but etcd snapshots actually include all cluster metadata required for full recovery.
Which of the following Service types exposes a Service on a static port on each node's IP?
NodePort exposes the Service on each Node's IP at a static port (the NodePort).
Why this answer
NodePort exposes the Service on each Node's IP at a static port (the NodePort). ClusterIP only exposes internally, LoadBalancer provisions an external load balancer, and ExternalName maps to an external DNS name.
You run `kubectl get pods` and get an error: 'error: You must be logged in to the server (Unauthorized)'. What is the most likely cause?
Unauthorized error indicates authentication failure, typically due to a missing or misconfigured kubeconfig.
Why this answer
The error 'You must be logged in to the server (Unauthorized)' indicates that the kubectl client successfully reached the API server, but the request was rejected because the client's credentials (typically from the kubeconfig file) are missing, expired, or invalid. The kubeconfig file contains the cluster, user, and context information required for authentication; if it is misconfigured or not present, kubectl cannot authenticate and returns this specific HTTP 401 Unauthorized error.
Exam trap
The trap here is that candidates confuse authentication errors (401 Unauthorized) with connectivity errors (connection refused) or authorization errors (403 Forbidden), leading them to incorrectly suspect the API server is down or a resource is missing.
How to eliminate wrong answers
Option B is wrong because if the API server were not running, kubectl would return a connection refused or timeout error (e.g., 'Unable to connect to the server'), not an authentication error. Option C is wrong because the error occurs before any pod-specific operation; the client cannot even list pods due to authentication failure, so the existence of a pod is irrelevant. Option D is wrong because the error is about authentication, not authorization to a namespace; a missing namespace would cause a different error like 'namespace not found' or 'the server could not find the requested resource', not an Unauthorized response.
An application requires a persistent volume that can be shared across multiple Pods running on different nodes, with read-write access from all Pods simultaneously. Which access mode should be specified in the PersistentVolumeClaim?
ReadWriteMany allows multiple Pods across nodes to read and write simultaneously.
Why this answer
The correct access mode is ReadWriteMany (RWX), which allows the volume to be mounted as read-write by multiple Pods across different nodes simultaneously. This matches the requirement for shared concurrent read-write access from all Pods.
Exam trap
The trap here is that candidates often confuse ReadWriteMany with ReadWriteOnce, assuming that 'once' means 'one Pod' rather than 'one node', or they forget that ReadOnlyMany does not grant write access despite allowing multi-Pod mounting.
How to eliminate wrong answers
Option A is wrong because ReadWriteOncePod restricts the volume to a single Pod on a single node, preventing sharing. Option B is wrong because ReadOnlyMany allows multiple Pods to mount the volume but only in read-only mode, not read-write. Option C is wrong because ReadWriteOnce allows only a single node to mount the volume as read-write, blocking multi-node sharing.
You want to expose a Deployment named 'web' on port 80 internally within the cluster. Which command creates a ClusterIP Service?
Explicitly or implicitly, this creates a ClusterIP Service.
Why this answer
kubectl expose deployment web --port=80 creates a ClusterIP Service by default.
Which command shows all events in the cluster, sorted by timestamp?
This command retrieves events sorted by creation timestamp.
Why this answer
Option A is correct. kubectl get events with --sort-by flag displays events sorted by timestamp. Option B is invalid. Options C and D are incorrect.
Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod? (Select TWO.)
envFrom loads all keys from a ConfigMap as environment variables.
Why this answer
Option C is correct because `envFrom` with `configMapRef` allows you to inject all key-value pairs from a ConfigMap as environment variables into a pod, which is a concise way to expose ConfigMap data without specifying each key individually. This is a native Kubernetes feature that automatically creates environment variables for each entry in the ConfigMap.
Exam trap
The trap here is that candidates confuse `envFrom` with `configMapRef` (which injects all keys) with the `env` field using `valueFrom` and `configMapKeyRef` (which injects a single key), and they may also mistakenly think mounting a ConfigMap as a volume sets environment variables, when it actually creates files.
Which THREE of the following are valid steps to troubleshoot a Node in NotReady state? (Choose three)
Why this answer
Troubleshooting a Node involves checking kubelet status, logs, and container runtime. Restarting apiserver or deleting the node are not appropriate first steps.
You create a Job named 'pi-job' that runs a single pod to compute pi to 2000 decimal places. After creation, the pod runs and completes successfully. Which command would you use to view the pod's logs after completion?
You can view logs of a completed pod using 'kubectl logs' with the job name.
Why this answer
Option D is correct because `kubectl logs` is the standard command to retrieve logs from a pod, and it can reference a Job directly by using the syntax `kubectl logs job/<job-name>`. This retrieves the logs from the pod that was created by the Job after it has completed, without needing to know the pod's name.
Exam trap
The trap here is that candidates confuse `kubectl logs` with `kubectl exec` or `kubectl describe`, or they miss the correct syntax `kubectl logs job/<name>` versus the invalid `kubectl log`.
How to eliminate wrong answers
Option A is wrong because `kubectl describe job/pi-job` shows metadata, status, and events of the Job, but does not display pod logs. Option B is wrong because `kubectl exec` requires a running pod to execute commands; after the pod completes, it is in a terminated state and cannot be exec'd into. Option C is wrong because the command `kubectl log` is not a valid kubectl command; the correct verb is `logs`.
A user creates a PersistentVolumeClaim with a storage class 'ssd' that does not exist in the cluster. What will happen when the PVC is created?
Without a valid storage class, dynamic provisioning cannot occur, and manual PV binding requires a matching class.
Why this answer
If a PVC specifies a storage class that does not exist, it will remain in Pending state because there is no provisioner to dynamically provision a volume. It will not bind to any existing PV unless the PV has the same storage class annotation, but the non-existent class means no dynamic provisioning.
A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?
The policy selects all pods and has no ingress rules, so ingress is denied. Egress is not restricted.
Why this answer
A NetworkPolicy with podSelector: {} selects all pods in the namespace. With no ingress rules, it denies all ingress traffic. Since there is no egress section, egress traffic is not affected (default allow).
You are troubleshooting a network connectivity issue between two pods in different namespaces. The pods have the following labels: pod-a in namespace 'foo' with labels {app: web}, pod-b in namespace 'bar' with labels {app: db}. You verify that both pods have IP addresses and can ping the Kubernetes service IP. However, pod-a cannot connect to pod-b on port 5432. What should you check first?
A NetworkPolicy may be blocking traffic from pod-a to pod-b, especially across namespaces.
Why this answer
Option A is correct. NetworkPolicies can restrict ingress traffic across namespaces. Since pod-a can reach the Kubernetes service, the issue is likely a NetworkPolicy blocking the specific traffic.
Options B, C, and D are less likely.
A user reports that they cannot access a Service of type ClusterIP from within the cluster. The Service selects pods that are running and responding. Which of the following is the MOST likely cause?
If targetPort is not set correctly, traffic will not reach the container.
Why this answer
Option C is correct because the Service's `targetPort` must match the `containerPort` defined in the pod's container spec. Even if the pods are running and responding, if the `targetPort` points to a different port than the one the container is listening on, traffic will be forwarded to the wrong port and the connection will fail. The `port` field on the Service is the port the Service itself listens on, while `targetPort` is the port on the pod where traffic is actually sent.
Exam trap
The trap here is that candidates confuse the Service's `port` (the cluster-facing port) with the `targetPort` (the pod-facing port), and incorrectly assume the `port` must match the container's `containerPort`, leading them to choose Option A instead of C.
How to eliminate wrong answers
Option A is wrong because the Service's `port` does not need to match the container's `containerPort`; the `port` is the Service's own listening port, and traffic is forwarded to the `targetPort`. Option B is wrong because a Service of type NodePort still works for internal cluster access (it also gets a ClusterIP), so changing the type to NodePort would not cause a failure to access from within the cluster. Option D is wrong because the question explicitly states that the Service selects pods that are running and responding, meaning the selector matches the pod labels correctly.
You are tasked with ensuring that a critical application runs on a specific node that has dedicated hardware. The node is labeled with 'hw=special'. You want to guarantee that only pods from this application are scheduled on that node, and no other pods can use it. Which scheduling feature should you use?
Node affinity with a required rule forces the pod to nodes matching the label, and combined with taints/tolerations can achieve exclusivity. It is the primary feature for hard scheduling constraints.
Why this answer
Option C is correct because node affinity with a `requiredDuringSchedulingIgnoredDuringExecution` rule ensures that a pod is scheduled only on nodes matching the specified label (e.g., `hw=special`). This is the appropriate feature to guarantee that only pods from this application are scheduled on that specific node, as it restricts scheduling to that node while also preventing other pods from using it if combined with taints and tolerations. However, to fully prevent other pods from using the node, you must also taint the node; node affinity alone only ensures the pod goes to that node, but does not block other pods.
Exam trap
The trap here is that candidates often confuse node affinity with taints and tolerations, thinking that node affinity alone can prevent other pods from using the node, when in fact it only ensures the pod is placed on the node but does not repel other pods; taints and tolerations are needed for that exclusivity.
How to eliminate wrong answers
Option A is wrong because taints and tolerations are used to repel pods from nodes unless they tolerate the taint, but they do not guarantee that a pod will be scheduled on a specific node; they only prevent pods without the toleration from being scheduled there. Option B is wrong because pod affinity is used to co-locate pods relative to each other (e.g., schedule a pod near another pod), not to constrain pods to a specific node based on node labels. Option D is wrong because `nodeSelector` with `matchExpressions` is a simpler form of node affinity that can select nodes based on labels, but it does not provide the full `requiredDuringSchedulingIgnoredDuringExecution` semantics and is less flexible; more importantly, `nodeSelector` alone does not prevent other pods from using the node, just as node affinity alone does not.
Which kubectl command creates a PersistentVolumeClaim named 'pvc-data' with 1Gi storage access mode ReadWriteOnce?
Correct syntax.
Why this answer
The correct command uses 'kubectl create pvc' or 'kubectl apply -f' with a YAML file. Option B uses the imperative command with the correct syntax.
You want to ensure that a pod only runs on nodes that have a GPU. Nodes with GPUs are labeled with 'gpu=true'. Which scheduling constraint should you use?
nodeSelector directly requires the node to have the label gpu=true.
Why this answer
Option B is correct. nodeSelector is the simplest way to require a node label. Option A (nodeName) is for specific node names. Option C (nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution) can also be used, but nodeSelector is more straightforward for a simple equality.
Option D (podAffinity) is for scheduling pods relative to other pods, not nodes.
Which THREE of the following are possible causes for a pod to remain in 'Pending' state?
If a PVC is not bound, the pod cannot start and remains pending.
Why this answer
Correct answers are A, B, and D. Resource constraints, taint/toleration issues, and PVC not bound are common causes. C would cause CrashLoopBackOff, not Pending.
E would cause the pod to run.
You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)
Describe shows events and state information.
Why this answer
To debug a crash loop, check logs, describe events, and inspect the container exit code via describe.
You run 'kubectl get nodes' and see that one node is marked as 'NotReady'. Which component is likely failing on that node?
The kubelet reports node status; if it's not functioning, the node becomes NotReady.
Why this answer
The kubelet is the primary node agent that runs on every node and is responsible for registering the node with the cluster and reporting its status via periodic heartbeats (NodeStatus updates). When a node is marked as 'NotReady', it means the kubelet has failed to send these heartbeats to the control plane (specifically, the node controller) within the --node-monitor-grace-period (default 40s), indicating the kubelet process is likely down, unresponsive, or misconfigured.
Exam trap
The trap here is that candidates often confuse the container runtime (e.g., containerd) as the direct cause of node unreadiness, but the kubelet is the component that reports the node condition, and a runtime failure would manifest as a kubelet-level error (e.g., 'runtime network not ready') rather than a missing heartbeat.
How to eliminate wrong answers
Option A is wrong because kube-proxy is a network proxy that runs on each node to manage network rules (e.g., iptables/IPVS) for Services; its failure would cause connectivity issues to pods/services but does not affect the node's readiness status reported by the kubelet. Option B is wrong because kube-scheduler is a control plane component that runs on the master node(s) and is responsible for assigning pods to nodes; it does not run on worker nodes and has no role in reporting node health. Option D is wrong because while a failing container runtime (e.g., containerd, CRI-O) can prevent pods from starting and may eventually cause the kubelet to mark the node as NotReady, the immediate and direct cause of the 'NotReady' status is the kubelet's failure to report its heartbeat; the kubelet itself is the component that detects runtime failures and updates the node condition accordingly.
A pod is scheduled to a node that has a local SSD mounted at /mnt/ssd. The administrator wants the pod to use this SSD for ephemeral storage that is accessible only while the pod runs on this specific node. Which volume type should be used?
hostPath mounts a specific path from the host into the pod, allowing direct access to the SSD.
Why this answer
A hostPath volume mounts a file or directory from the host node's filesystem into the pod. This is suitable for using node-local storage like an SSD, but note it is not portable and ties the pod to the node. emptyDir is ephemeral but uses the pod's default storage (usually disk or tmpfs), not a specific host path. configMap and secret are for configuration data.
You need to check the logs of a container that previously ran but has crashed. Which command would you use?
kubectl logs pod --previous shows the logs of the last terminated container.
Why this answer
The --previous flag retrieves logs from the previous instance of a container in a pod.
You are a platform engineer managing a Kubernetes cluster with 5 worker nodes (node1-node5). The cluster runs a mix of stateless web services and stateful databases. Users report that a critical database Pod (part of a StatefulSet) is frequently evicted during node maintenance. The StatefulSet has a single replica. You need to improve the availability of this database Pod. The current configuration: the Pod has resource requests (2 CPU, 4Gi memory) and limits (4 CPU, 8Gi memory). The cluster uses the default scheduler with no custom policies. Nodes have varying capacities: node1 and node2 have 8 CPU/32Gi memory, node3-node5 have 4 CPU/16Gi memory. During rolling node reboots, the database Pod gets evicted and takes a long time to reschedule because no node has enough resources. What should you do to minimize downtime and ensure the Pod is rescheduled promptly after eviction?
High priority ensures the scheduler preempts lower-priority Pods to make room for the database Pod, reducing scheduling delay.
Why this answer
Assigning a high priority class (Option C) ensures that when the database Pod is evicted during node maintenance, the scheduler treats it as a higher-priority workload than other Pods. This allows it to preempt lower-priority Pods on nodes with sufficient capacity (e.g., node1 or node2), even if those nodes appear fully allocated, thereby minimizing downtime and ensuring prompt rescheduling.
Exam trap
CNCF often tests the distinction between disruption budgets (which prevent eviction) and priority/preemption (which ensure rescheduling after eviction), leading candidates to mistakenly choose PDB when the real issue is resource contention after eviction.
How to eliminate wrong answers
Option A is wrong because nodeAffinity with a 'prefer' rule is a soft scheduling preference, not a guarantee; during eviction, the scheduler may still place the Pod on a smaller node if node1/node2 are full, leading to scheduling failures. Option B is wrong because a PodDisruptionBudget (PDB) with minAvailable: 1 only protects against voluntary disruptions (e.g., node drains) by preventing eviction if it would violate the budget, but it does not help with resource availability after eviction; the Pod still cannot be scheduled if no node has enough free resources. Option D is wrong because increasing resource requests to match limits (4 CPU, 8Gi memory) would make the Pod even harder to schedule, as it would require more resources than the smaller nodes (node3-node5) can provide, worsening the problem.
A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate'. What does this indicate?
The 'unreachable' taint indicates the node controller has lost contact with the node.
Why this answer
The error message indicates that the node has a taint of `node.kubernetes.io/unreachable`, which is automatically added by the node controller when the control plane cannot communicate with the node (e.g., due to network failure or kubelet being down). The pod remains in 'Pending' because no node is available that tolerates this taint, meaning the node is unreachable from the control plane. This matches option C.
Exam trap
The trap here is that candidates often confuse taints related to resource pressure (like memory or disk) with the unreachable taint, or assume 'Pending' means the pod is scheduled but waiting for resources, when in fact the specific taint name directly indicates a node reachability issue.
How to eliminate wrong answers
Option A is wrong because a pod in 'Pending' state has not been scheduled to any node; successful scheduling would show a node name in the pod status. Option B is wrong because the taint `node.kubernetes.io/unreachable` is not related to resource insufficiency; resource issues would show taints like `node.kubernetes.io/disk-pressure` or `node.kubernetes.io/memory-pressure`, and the error would mention insufficient resources, not unreachability. Option D is wrong because the error explicitly states '1 node(s) had taint', confirming the node exists but is unreachable; a non-existent node would not appear in the node list or would show a different error like 'node not found'.
Headless Service returns individual pod IPs via DNS, suitable for stateful apps.
Why this answer
A Headless Service (ClusterIP: None) is correct because it allows clients to discover individual pod IPs via DNS lookups, returning A/AAAA records for each pod rather than a single ClusterIP. This provides stable network identities for stateful pods, as each pod gets a unique DNS name (e.g., pod-name.service-name.namespace.svc.cluster.local) that resolves directly to its IP, enabling external access through a DNS-based discovery mechanism.
Exam trap
The trap here is that candidates often confuse a Headless Service with a regular ClusterIP Service, assuming that 'no ClusterIP' means no service at all, but in reality it enables direct pod DNS resolution which is essential for stateful workloads.
How to eliminate wrong answers
Option A is wrong because an ExternalName Service maps a Service to an external DNS name (via CNAME) and does not expose pods or provide stable network identities within the cluster. Option B is wrong because a NodePort Service exposes pods on a static port on each node's IP, but it does not provide per-pod DNS names or stable network identities; it load-balances traffic across pods via a single ClusterIP. Option C is wrong because a regular ClusterIP Service provides a single virtual IP that load-balances traffic across pods, not individual pod IPs or stable DNS names for each pod, which is required for stateful applications needing stable network identities.
A CSI driver is installed in the cluster. Which Kubernetes resource is used to register the CSI driver with the kubelet on each node?
CSIDriver is the object that provides metadata about the CSI driver to the rest of the cluster.
Why this answer
Option C is correct: CSIDriver is a cluster-level resource that advertises a CSI driver's capabilities and is used by kubelet to discover and interact with the driver. Option A (StorageClass) references a CSI driver but does not register it. Option B (CSINode) is created automatically by the CSI driver's node plugin.
Option D (VolumeAttachment) tracks volume attachments to nodes.
An administrator creates a PersistentVolume with the following YAML: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: pv-example spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain hostPath: path: /mnt/data ``` Which of the following is true about this PersistentVolume?
ReadWriteOnce allows only one node to mount the volume as read-write.
Why this answer
The PV uses 'hostPath', which is typically used for single-node testing and does not support multi-node access. The access mode is ReadWriteOnce (RWO), meaning the volume can be mounted as read-write by a single node. Option A is correct.
Which of the following service types exposes a service on a static port on each node's IP address?
NodePort exposes the service on a static port on each node's IP address.
Why this answer
NodePort exposes the service on a static port on each node's IP address, making the service accessible from outside the cluster.
A pod is stuck in Pending state. You describe the pod and see: '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate.' What is the most likely reason?
Why this answer
The error message '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/not-ready: }, that the pod didn't tolerate' indicates that every node in the cluster is tainted with node.kubernetes.io/not-ready, which is automatically applied by the node controller when a node becomes unreachable or fails its health checks. Since no node is Ready, the pod cannot be scheduled, and the only way to schedule it would be to add a toleration for this taint, but that would not fix the underlying node issue. Therefore, the most likely reason is that all nodes are in the NotReady state.
Exam trap
The trap here is that candidates often confuse 'tolerating a taint' with 'fixing the node condition', and assume that adding a toleration is the correct solution, when the error message explicitly states that all nodes have the taint, meaning the nodes themselves are NotReady.
Why the other options are wrong
Tolerating this taint would schedule pods on unhealthy nodes.
Would show insufficient resources, not taint.
Would show 0 nodes available due to other reasons.
An administrator is setting up RBAC to allow a CI/CD pipeline to create and delete pods only in the 'ci' namespace. Which combination of resources should be created?
Role is namespace-scoped, and RoleBinding binds it to the user within that namespace.
Why this answer
A Role and RoleBinding are the correct combination because the CI/CD pipeline needs to create and delete pods only within the 'ci' namespace. A Role defines permissions scoped to a specific namespace, and a RoleBinding grants those permissions to a user or service account within that same namespace. This ensures the pipeline cannot affect resources in other namespaces.
Exam trap
The trap here is that candidates often assume a ClusterRole is always needed for any pipeline or service account, but for namespace-scoped resources, a Role and RoleBinding are sufficient and more secure, and the exam tests understanding of scope versus permissions.
How to eliminate wrong answers
Option B is wrong because a ClusterRole is cluster-scoped and, when used with a RoleBinding, can grant permissions across namespaces if the ClusterRole references cluster-scoped resources; however, for namespace-scoped resources like pods, a Role is more restrictive and appropriate. Option C is wrong because a ClusterRoleBinding grants permissions cluster-wide, which would allow the pipeline to create and delete pods in all namespaces, violating the requirement to restrict access to the 'ci' namespace only. Option D is wrong because a Role cannot be bound with a ClusterRoleBinding; a RoleBinding is required to bind a Role to a subject within a namespace.
Which TWO of the following are valid ways to expose a ConfigMap to a pod? (Select TWO)
ConfigMaps can be mounted as volumes.
Why this answer
Options A and D are correct. ConfigMaps can be exposed as environment variables using 'valueFrom' with 'configMapKeyRef', or as volumes mounted into the container's filesystem. Option B is incorrect because ConfigMaps are not automatically injected as environment variables; they must be explicitly referenced.
Option C is incorrect because ConfigMaps cannot be used directly as the container image. Option E is incorrect because the host's /etc/config directory is not automatically populated from ConfigMaps.
A StorageClass named 'fast-ssd' uses the provisioner 'kubernetes.io/gce-pd' and has volumeBindingMode: WaitForFirstConsumer. A PVC 'my-pvc' requests 100Gi storage from this StorageClass. A pod using the PVC is scheduled to a node in zone 'us-central1-a'. When is the PV provisioned?
WaitForFirstConsumer delays binding and provisioning until a pod using the PVC is scheduled.
Why this answer
With WaitForFirstConsumer, volume binding and provisioning are delayed until a pod using the PVC is scheduled. The PV is provisioned after the pod is scheduled to a node.
A cluster has multiple kubeconfig files. You want to set the current context to 'admin@production' for all future kubectl commands. Which command should you run?
This sets the current context in kubeconfig.
Why this answer
The `kubectl config use-context` command is used to set the current context in a kubeconfig file, which determines the cluster, user, and namespace that kubectl will use by default for all subsequent commands. Option B correctly specifies `admin@production` as the context to switch to, making it the active context for future kubectl operations.
Exam trap
The trap here is that candidates confuse `set-context` (which only defines or updates a context entry) with `use-context` (which actually switches the active context), leading them to select option A.
How to eliminate wrong answers
Option A is wrong because `kubectl config set-context` creates or modifies a context entry in the kubeconfig file but does not set it as the current context; it only defines or updates the context's properties (cluster, user, namespace). Option C is wrong because `kubectl config set-cluster` modifies or adds a cluster definition (e.g., server URL, certificate authority) in the kubeconfig, not a context or the current context. Option D is wrong because `kubectl config get-contexts` lists all available contexts or shows details for a specific context, but it does not change the active context.
Which THREE of the following are common causes for a Pod to remain in Pending state? (Select THREE.)
If no node has enough resources, the Pod cannot be scheduled.
Why this answer
Options A, B, and E are correct. Insufficient cluster resources (A), taint/toleration mismatch (B), and PVC not bound (E) are common reasons for Pending. Option C (image pull error) causes ImagePullBackOff.
Option D (OOMKilled) causes CrashLoopBackOff.
A pod needs to share data between two containers during their lifecycle, but the data does not need to persist after the pod is deleted. Which volume type is most appropriate?
emptyDir provides a temporary directory that is shared between containers and deleted with the pod.
Why this answer
Option A is correct: emptyDir volumes are created when a Pod is assigned to a node and exist as long as the Pod is running. They are ideal for sharing data between containers within the same pod and are deleted when the pod is removed. Option B (hostPath) persists on the node.
Option C (configMap) is for configuration data. Option D (PVC) is for persistent storage.
You run 'kubectl get nodes' and one node shows 'NotReady'. You SSH into the node and run 'systemctl status kubelet'. Kubelet is active but 'journalctl -u kubelet -n 50' shows 'network plugin is not ready: cni config uninitialized'. What is the most likely cause?
The error indicates CNI config is uninitialized.
Why this answer
The CNI plugin configuration is missing, causing the network plugin to be unready.
Practice CKA by domain
Target a specific domain to shore up weak areas.