Certified Kubernetes Administrator CKA CKA Questions 676–726 | Page 10/10

676

MCQeasy

You have a pod that is in 'Pending' state. Which command would you use to view detailed information about the pod's status, including events that may indicate why it is not running?

A.kubectl get endpoints

B.kubectl logs pod

C.kubectl describe pod

D.kubectl get pod

AnswerC

This is the correct command because it queries the Kubernetes API server for the detailed state, conditions, and event history of the specified Pod. The "Events" section at the bottom of the output will explicitly reveal why the Pod is pending, such as insufficient CPU/memory on nodes, taints and tolerations mismatches, or unbound PersistentVolumeClaims.

Why this answer

C is correct because `kubectl describe pod` provides detailed information about the pod's current state, including status conditions, container statuses, and a chronological list of events associated with the pod. These events often contain error messages (e.g., 'FailedScheduling', 'ImagePullBackOff', 'CrashLoopBackOff') that directly explain why the pod is stuck in 'Pending' state, such as insufficient resources or persistent volume claim issues.

Exam trap

The trap here is that candidates often assume `kubectl logs` can show startup errors even when the pod has never run, or they confuse `kubectl get` with `kubectl describe`, not realizing that `get` only shows a high-level status without the event history needed for troubleshooting.

How to eliminate wrong answers

Option A is wrong because `kubectl get endpoints` displays network endpoints for services, not pod-level status or events; it is irrelevant to diagnosing a pod stuck in 'Pending'. Option B is wrong because `kubectl logs pod` retrieves container logs from a running or previously running container, but a pod in 'Pending' state has not started any containers, so there are no logs to fetch. Option D is wrong because `kubectl get pod` only shows a summary of the pod's phase (e.g., 'Pending') and basic fields like name and age, without the detailed events or conditions needed to identify the root cause.

Full explanation →

677

MCQhard

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

A.kubeadm alpha certs renew apiserver

B.kubeadm certs renew apiserver

C.kubeadm init phase certs apiserver --renew

D.kubectl create certificate apiserver

AnswerB

The kubeadm certs renew apiserver command renews only the API server serving certificate, leaving other control plane certificates untouched. It satisfies the stem's constraint of renewing just that certificate, whereas renew all would regenerate every certificate authority-signed certificate.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

678

MCQeasy

Which access mode allows multiple pods on different nodes to mount a PersistentVolume as read-write?

A.ReadWriteMany (RWX)

B.ReadWriteOncePod (RWOP)

C.ReadWriteOnce (RWO)

D.ReadOnlyMany (ROX)

AnswerA

ReadWriteMany (RWX) is the correct access mode because it explicitly allows a PersistentVolume to be mounted as read-write by multiple nodes simultaneously. This capability enables multiple pods, potentially distributed across different Kubernetes nodes, to concurrently access and modify the shared storage, directly fulfilling the question's requirement for "multiple pods on different nodes" needing read-write access. This mode is typically supported by network file systems like NFS or distributed storage solutions.

Why this answer

ReadWriteMany (RWX) is the only access mode that allows multiple pods across different nodes to mount a PersistentVolume as read-write simultaneously. This is achieved through shared filesystem protocols such as NFS, GlusterFS, or CephFS, which support concurrent access from multiple clients. The RWX mode is essential for workloads like clustered databases or shared storage applications where multiple instances need to write to the same volume.

Exam trap

The trap here is that candidates often confuse ReadWriteOnce (RWO) with multi-pod access, assuming 'Once' means one pod at a time, but it actually means one node at a time, so multiple pods on the same node can share it, but not across nodes.

How to eliminate wrong answers

Option B (ReadWriteOncePod) is wrong because it restricts the volume to a single pod on a single node, preventing any other pod from mounting it, even on the same node. Option C (ReadWriteOnce) is wrong because it allows only a single node to mount the volume as read-write, meaning multiple pods on different nodes cannot access it concurrently. Option D (ReadOnlyMany) is wrong because it permits multiple nodes to mount the volume, but only in read-only mode, not read-write.

Full explanation →

679

MCQmedium

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

A.ClusterRole and ClusterRoleBinding

B.Role and ClusterRoleBinding

C.Role and RoleBinding

D.ClusterRole and RoleBinding

AnswerC

A Role defines the permitted verbs on deployments, while a RoleBinding grants that Role to the specific user within the development namespace. Namespace-scoped RoleBinding confines the permissions to that namespace only, satisfying the requirement to manage deployments there alone.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

680

MCQhard

You are a CKA managing a production cluster with 5 worker nodes. A developer reports that a new deployment 'payment-service' is not accessible from other pods via its Service 'payment-svc' in the 'default' namespace. The Service is of type ClusterIP with selector 'app: payment'. The deployment has 3 replicas, all showing 'Running' status. From a test pod, you run 'curl http://payment-svc:8080' and get 'Connection refused'. You verify that the pods are listening on port 8080 and the container's readiness probe passes. 'kubectl get endpoints payment-svc' shows no endpoints. 'kubectl describe svc payment-svc' shows the selector 'app=payment'. What is the most likely cause?

A.A NetworkPolicy is blocking traffic from the test pod to the service IP.

B.The service type should be NodePort to allow in-cluster access.

C.The readiness probe is failing on all pods, causing them to be removed from service endpoints.

D.The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.

AnswerD

A Service's spec.selector uses exact key-value matching to choose backing pods. If the selector is app: payment and the pods are labeled app: payment-service, the values are different, so the Endpoints controller does not add any pod IP to the Service's backend. Label matching is exact, not substring-based, so the Service will have no endpoints and in-cluster clients cannot connect to it.

Why this answer

The most likely cause is that the pods' labels do not match the Service's selector. The Service 'payment-svc' uses selector 'app: payment', but the pods have label 'app: payment-service'. Since the selector does not match any pods, the Service's endpoints list is empty, causing 'Connection refused' when trying to reach the ClusterIP.

The pods are running and listening on port 8080, but the Service has no backends to forward traffic to.

Exam trap

The trap here is that candidates often assume a NetworkPolicy or readiness probe issue when they see 'Connection refused', but the empty endpoints list directly points to a selector mismatch, which is a fundamental Kubernetes networking concept tested in the CKA.

How to eliminate wrong answers

Option A is wrong because a NetworkPolicy can block traffic to pods or from specific sources, but it does not affect the Service's endpoint list; the endpoints would still be populated if the selector matched. Option B is wrong because ClusterIP is the correct type for in-cluster access; NodePort is used for external access and does not change internal connectivity. Option C is wrong because the readiness probe passes on all pods, as stated in the scenario, so pods would not be removed from endpoints; if the probe were failing, the pods would be removed, but the scenario explicitly says the readiness probe passes.

Full explanation →

681

MCQeasy

Which of the following describes the role of init containers in a pod?

A.They run in parallel with the main containers to provide additional services

B.They are used for liveness and readiness probes of the main container

C.They run to completion before any main containers start, and each init container must complete successfully before the next one starts

D.They run after the main containers have started to clean up resources

AnswerC

This option correctly describes the lifecycle of init containers, which are executed sequentially during Pod startup. Kubernetes guarantees that each init container must exit with a zero status code before the subsequent one begins. The primary application containers will only start initializing once all defined init containers have successfully completed their execution.

Why this answer

Init containers are specialized containers that run before the main application containers in a Pod. They are defined in the Pod spec under `initContainers` and execute sequentially: each init container must complete successfully (exit code 0) before the next one starts. Only after all init containers have finished does Kubernetes start the main containers defined in the `containers` array.

This ensures prerequisite setup tasks (e.g., waiting for a database, running migrations) are completed before the application starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or assume they run concurrently with main containers, but the CKA explicitly tests that init containers run sequentially to completion before any main containers start.

How to eliminate wrong answers

Option A is wrong because init containers run sequentially to completion before any main containers start, not in parallel with them. Option B is wrong because liveness and readiness probes are configured on the main containers (or sidecar containers) via `livenessProbe` and `readinessProbe` fields; init containers do not serve as probes. Option D is wrong because init containers run before the main containers, not after; cleanup tasks after main containers finish are typically handled by postStart or preStop lifecycle hooks, or by a separate sidecar container.

Full explanation →

682

MCQhard

A StatefulSet 'db' has 3 replicas. You scale it down to 1. In what order are the pods deleted?

A.db-0, db-1, db-2

B.Random order

C.All pods are deleted simultaneously

D.db-2, db-1, db-0

AnswerD

When scaling down a StatefulSet, Kubernetes terminates pods one at a time in reverse ordinal order, starting from the highest index down to the lowest. In this scenario, the controller first gracefully terminates db-2, waits for its complete removal, and then proceeds to terminate db-1 to reach the target of 1 replica (db-0). This predictable, step-by-step reduction ensures that distributed state is safely migrated or persisted.

Why this answer

When a StatefulSet is scaled down, pods are deleted in reverse ordinal order, starting from the highest index. This ensures that the StatefulSet's ordinal and identity guarantees are maintained, as each pod has a unique, stable identity. For a StatefulSet with 3 replicas (db-0, db-1, db-2), scaling to 1 deletes db-2 first, then db-1, leaving db-0 running.

Exam trap

The trap here is that candidates often confuse StatefulSet scaling behavior with Deployment scaling, where pods are deleted in random order or simultaneously, leading them to incorrectly choose options A, B, or C instead of the reverse ordinal deletion required by StatefulSet.

How to eliminate wrong answers

Option A is wrong because it suggests deleting pods in ascending ordinal order (db-0, db-1, db-2), which would violate the StatefulSet's ordered pod management policy; Kubernetes always deletes from the highest ordinal first to preserve identity and state. Option B is wrong because StatefulSet does not delete pods in random order; it follows a strict reverse ordinal sequence to ensure predictable pod termination. Option C is wrong because StatefulSet pods are never deleted simultaneously; they are deleted one at a time, waiting for each pod to fully terminate before proceeding to the next, to maintain data integrity and avoid race conditions.

Full explanation →

683

MCQeasy

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

A.To expose the Service externally via a cloud load balancer

B.To provide load balancing across pods

C.To map the Service to an external DNS name

D.To allow direct DNS resolution to pod IPs

AnswerD

By setting clusterIP: None, Kubernetes bypasses the allocation of a single virtual IP for the Service. Instead, the internal DNS server directly returns a list of A or AAAA records containing the individual IP addresses of all matching, healthy Pods, allowing clients to establish direct, peer-to-peer connections with specific Pods.

Why this answer

A headless Service (clusterIP: None) disables the virtual IP and load balancing, causing DNS queries to return the IP addresses of the backing pods directly. This allows clients to perform DNS-based service discovery and connect to specific pod IPs, which is essential for stateful applications like databases that require direct pod-to-pod communication.

Exam trap

The trap here is that candidates confuse a headless Service with a regular ClusterIP Service, assuming it still provides load balancing or external access, when in fact it is designed for direct pod-to-pod DNS resolution without a virtual IP.

How to eliminate wrong answers

Option A is wrong because a headless Service does not expose anything externally; external exposure is achieved via NodePort, LoadBalancer, or Ingress, not by setting clusterIP to None. Option B is wrong because headless Services explicitly disable load balancing; the kube-proxy does not create iptables rules for a headless Service, so traffic is not distributed across pods. Option C is wrong because mapping to an external DNS name is done via ExternalName Services, not headless Services; headless Services resolve to pod IPs within the cluster DNS.

Full explanation →

684

Multi-Selecthard

Which THREE of the following are correct about using a hostPath volume in Kubernetes? (Select THREE)

Select 3 answers

A.It is recommended for testing and development only

B.It can be used to access the Docker socket from a pod

C.It supports ReadWriteMany access mode across multiple nodes

D.It is suitable for production workloads that require persistence across nodes

E.It mounts a file or directory from the host node's filesystem

AnswersA, B, E

The official Kubernetes documentation steers users away from hostPath for production because it breaks the abstraction of node-independent pods and poses security risks if the path is sensitive. It is commonly used in development clusters for quick local testing, or for system-level agents that really do need host filesystem access, like a log collector reading /var/log. However, for persistent application data that must survive pod rescheduling or cluster upgrades, a PersistentVolumeClaim backed by remote storage is the correct, recommended approach.

Why this answer

Option E is correct because a hostPath volume mounts a file or directory directly from the host node's filesystem into the pod, which is its defining behavior. Option A is correct because hostPath volumes are explicitly recommended for testing and development only, since they tie pods to specific nodes and introduce security and portability risks. Option B is correct because a common use case is mounting the Docker socket (e.g., /var/run/docker.sock) from the host into a pod so the pod can interact with the container runtime.

Option C is incorrect because hostPath volumes are node-local and cannot provide ReadWriteMany access across multiple nodes. Option D is incorrect because hostPath is not suitable for production workloads needing persistence across nodes, as data is tied to a single node and not replicated or portable.

Exam trap

The trap here is that candidates may confuse hostPath with network-attached storage (like NFS or CSI drivers) that support multi-node access, or assume that local node storage is inherently production-ready without considering pod rescheduling and node failures.

Full explanation →

685

MCQeasy

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

A.contexts

B.namespaces

C.clusters

D.users

AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

686

MCQhard

You need to back up the etcd database for a kubeadm-created cluster. Which directory contains the etcd data?

A./etc/kubernetes/pki/etcd

B./var/lib/etcd

C./var/lib/kubelet

D./etc/etcd

AnswerB

/var/lib/etcd is the default etcd data directory for kubeadm-created clusters, configured as the hostPath mount for the etcd static pod and defined by the `--data-dir` flag. This directory contains the etcd member's key-value store, WAL (write-ahead log), and snapshots, representing the authoritative persistence layer for all cluster state. To back up etcd data, you would typically run `etcdctl snapshot save` while the cluster is running, or stop etcd and copy this directory for a cold backup; in either case, this path is the correct source of the data.

Why this answer

For a kubeadm-created cluster, etcd runs as a static Pod, and its data directory is mounted from the host path `/var/lib/etcd`. This is the default data directory used by etcd when started via kubeadm, and it stores all cluster state and configuration data. The CKA exam expects you to know this path for backup and restore operations.

Exam trap

The trap here is that candidates confuse the etcd data directory with the certificate directory (`/etc/kubernetes/pki/etcd`) because both are etcd-related and located under `/etc/kubernetes`, but only the data directory holds the actual database files.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/pki/etcd` contains the TLS certificates and keys for etcd communication, not the database files. Option C is wrong because `/var/lib/kubelet` is the kubelet's working directory for pod volumes, plugin state, and other kubelet data, not etcd data. Option D is wrong because `/etc/etcd` is not a standard directory in a kubeadm cluster; etcd configuration is typically embedded in the static Pod manifest or passed as command-line arguments, not stored in a dedicated `/etc/etcd` directory.

Full explanation →

687

MCQmedium

Which Ingress resource field is used to specify the hostname for which traffic should be routed?

A.spec.tls[].hosts

B.spec.defaultBackend

C.spec.host

D.spec.rules[].host

AnswerD

In an Ingress resource, the spec.rules[].host field is the correct location to specify the domain name for routing. The Ingress controller inspects the HTTP Host header of incoming requests and matches it against this field to apply the corresponding path-based routing rules.

Why this answer

In Kubernetes Ingress resources, host-based routing is defined under `spec.rules[].host`. Each rule can specify a hostname, and the Ingress controller uses this field to match the `Host` header of incoming HTTP requests, directing traffic to the appropriate backend service. This is the standard field for routing traffic based on hostname as defined in the Kubernetes Ingress API.

Exam trap

The trap here is that candidates confuse `spec.tls[].hosts` with the routing hostname, thinking TLS host fields also control traffic routing, when in fact they only associate TLS certificates with hostnames and do not affect request routing.

How to eliminate wrong answers

Option A is wrong because `spec.tls[].hosts` is used to specify hostnames that should be covered by a TLS certificate, not for routing traffic — it defines which hosts the TLS secret applies to, not where traffic is directed. Option B is wrong because `spec.defaultBackend` defines a fallback backend for traffic that does not match any rule, not a specific hostname for routing. Option C is wrong because there is no `spec.host` field in the Ingress spec; hostnames are specified per rule under `spec.rules[].host`.

Full explanation →

688

Multi-Selectmedium

Which TWO statements about Ingress in Kubernetes are correct?

Select 2 answers

A.Setting spec.ingressClassName to 'nginx' disables the default Ingress controller.

B.Ingress can terminate TLS connections for backend Services.

C.Ingress natively supports gRPC services without any additional configuration.

D.Ingress can provide Layer 4 (TCP/UDP) load balancing.

E.Ingress can route traffic to different Services based on the hostname in the HTTP Host header.

AnswersB, E

Ingress can terminate TLS connections for backend Services when a TLS block specifies a secret containing a certificate and private key. The Ingress controller decrypts HTTPS traffic at the edge and forwards plain HTTP to the backend Service. This offloads TLS handling from application Pods and centralizes certificate management.

Why this answer

Option B is correct because an Ingress resource can reference a TLS Secret via spec.tls, allowing the Ingress controller to terminate TLS connections and forward decrypted HTTP traffic to the backend Services. Option E is correct because Ingress rules use the host field to match the HTTP Host header and route requests to different backend Services accordingly. Option A is wrong because spec.ingressClassName selects which Ingress controller should handle the resource; it does not disable the default controller.

Option C is wrong because gRPC support is not native to Ingress and typically requires controller-specific annotations or a Gateway API/HTTPRoute setup. Option D is wrong because Ingress operates at Layer 7 (HTTP/HTTPS), while Layer 4 TCP/UDP load balancing requires a Service of type LoadBalancer or a Gateway API TCPRoute.

Exam trap

The trap here is that candidates confuse Ingress's Layer 7 capabilities with Layer 4 load balancing, or assume gRPC works out-of-the-box without understanding that Ingress controllers require explicit HTTP/2 support and protocol configuration for gRPC.

Full explanation →

689

MCQeasy

Which volume type is typically used to share configuration data with a pod as files, where the data is stored in the cluster as a resource?

A.secret

B.hostPath

C.configMap

D.emptyDir

AnswerC

ConfigMap volumes are the idiomatic Kubernetes mechanism for delivering non-sensitive configuration data, such as environment variables, command-line arguments, or entire configuration files, to containers. When mounted as a volume, each key in the ConfigMap becomes a file in the target directory and the file's content is the corresponding value, all managed by the kubelet into a local tmpfs that is updated atomically when the ConfigMap changes. This design gives pods a clean, portable way to share the same configuration across replicas or across different workloads, while keeping the config data decoupled from the container image and host filesystem.

Why this answer

A ConfigMap volume mounts ConfigMap data as files inside the pod.

Full explanation →

690

MCQmedium

A StatefulSet named 'web' uses volumeClaimTemplates to create PVCs for each replica. You scale the StatefulSet from 3 to 5 replicas. What happens to the PVCs?

A.New PVCs are created for the new replicas (web-3 and web-4).

B.All PVCs are deleted and recreated.

C.The PVCs are not created; you must create them manually.

D.Existing PVCs are reused for the new replicas.

AnswerA

When a StatefulSet is scaled up, the StatefulSet controller sequentially creates new pods and, for each pod, uses the volumeClaimTemplate to dynamically provision a dedicated PVC. The naming convention is <pvc-template-name>-<pod-name>, so scaling from 3 to 5 replicas creates new PVCs bound to web-3 and web-4. These PVCs are independent and persist across pod rescheduling.

Why this answer

When a StatefulSet is scaled up, each new replica (e.g., web-3, web-4) automatically gets a new PVC created from the volumeClaimTemplate. The PVC name follows the pattern <statefulset-name>-<volumeClaimTemplate-name>-<ordinal-index>, and the new PVCs are bound to newly provisioned PersistentVolumes. This ensures each pod has its own dedicated storage, preserving the identity and state of each replica.

Exam trap

The trap here is that candidates often assume PVCs are reused or need manual creation, but the StatefulSet controller automatically provisions new PVCs for each new replica, preserving the ordinal-based identity and storage isolation.

How to eliminate wrong answers

Option B is wrong because scaling a StatefulSet does not delete or recreate existing PVCs; only new PVCs are added for the new replicas. Option C is wrong because PVCs are automatically created from the volumeClaimTemplate when the StatefulSet is scaled up, so manual creation is not required. Option D is wrong because existing PVCs are not reused; each new replica gets a brand new PVC with a unique name and ordinal index.

Full explanation →

691

MCQeasy

You need to expose a Deployment named 'web' on port 80 inside the cluster. Which kubectl command creates a ClusterIP service?

A.kubectl expose deployment web --type=NodePort --port=80

B.kubectl expose deployment web --port=80

C.kubectl create service clusterip web --tcp=80

D.kubectl port-forward deployment/web 80:80

AnswerB

This command successfully creates a ClusterIP service named `web` that exposes the deployment's pods internally on port 80. Because no `--type` flag is explicitly provided, the `kubectl expose` command defaults to the `ClusterIP` service type. This is the standard and most secure way to enable internal service discovery within a Kubernetes cluster.

Why this answer

The `kubectl expose deployment web --port=80` command creates a ClusterIP service by default, which exposes the deployment on port 80 within the cluster. The `expose` command without specifying `--type` defaults to ClusterIP, making it the appropriate choice for internal cluster access.

Exam trap

The trap here is that candidates often assume `kubectl expose` requires an explicit `--type` flag, but the default is ClusterIP, and they may confuse `kubectl create service clusterip` (which lacks automatic selector binding) with `kubectl expose` (which automatically sets selectors from the target resource).

How to eliminate wrong answers

Option A is wrong because `--type=NodePort` creates a NodePort service, not a ClusterIP service, and exposes the deployment on a port accessible from outside the cluster via node IPs. Option C is wrong because `kubectl create service clusterip web --tcp=80` creates a ClusterIP service but does not link it to the 'web' deployment's pod selectors; it creates a standalone service without automatically setting the selector to match the deployment's labels, so it won't route traffic to the deployment's pods. Option D is wrong because `kubectl port-forward deployment/web 80:80` is a debugging command that forwards a local port to a pod, not a service creation command, and does not create any persistent service object.

Full explanation →

692

MCQmedium

You have a Pod that needs to run a database migration before the main application container starts. Which Kubernetes concept should you use?

A.Sidecar container

B.Init container

C.PostStart hook

D.Job

AnswerB

Init containers are specialized containers that run to completion sequentially before any app containers in the Pod are started. If an init container fails, Kubernetes restarts the Pod repeatedly until it succeeds, making it the ideal mechanism to block the main application until database migrations are successfully applied.

Why this answer

Init containers are designed to run to completion before the main application containers start, making them the ideal Kubernetes primitive for tasks like database migrations that must complete before the primary service begins. Unlike sidecars, init containers do not run concurrently with the main container, ensuring the migration finishes before the application container starts.

Exam trap

The trap here is that candidates confuse init containers with sidecar containers or PostStart hooks, not realizing that init containers are the only option that guarantees sequential execution before the main container starts, while sidecars run concurrently and PostStart hooks run after the main container has already started.

How to eliminate wrong answers

Option A is wrong because a sidecar container runs alongside the main container, not before it, and is typically used for auxiliary tasks like logging or proxying, not for sequential startup dependencies. Option C is wrong because a PostStart hook executes asynchronously after the main container starts, which could cause race conditions if the migration must complete before the application begins. Option D is wrong because a Job is a standalone workload that runs independently of the Pod lifecycle, not a mechanism to run a task before a specific Pod's main container starts.

Full explanation →

693

MCQhard

You create a CronJob that should run every day at midnight. The CronJob has a startingDeadlineSeconds of 100. If the CronJob controller is down for 2 minutes, what happens?

A.The job runs as soon as the controller recovers.

B.The job is missed and will not run until the next scheduled time.

C.The controller creates a Job with a backoff limit.

D.The job runs immediately but is delayed by 2 minutes.

AnswerB

Since the controller was down for 120 seconds, the gap between the scheduled midnight execution and the controller's recovery exceeds the configured startingDeadlineSeconds of 100 seconds. Consequently, Kubernetes classifies this execution as a missed deadline and skips it. The controller will now wait until the next scheduled daily occurrence at midnight to trigger the job.

Why this answer

The CronJob controller was down for 2 minutes (120 seconds), which exceeds the `startingDeadlineSeconds` of 100. According to Kubernetes CronJob behavior, if the controller misses the scheduled start time by more than `startingDeadlineSeconds`, the job is considered missed and will not be retroactively created. The controller will only run the next scheduled instance.

Exam trap

The trap here is that candidates assume the controller will always catch up on missed jobs after recovery, but Kubernetes explicitly drops jobs if the delay exceeds `startingDeadlineSeconds`, testing your understanding of the deadline's purpose as a hard cutoff.

How to eliminate wrong answers

Option A is wrong because the job does not run as soon as the controller recovers if the delay exceeds `startingDeadlineSeconds`; the controller only creates missed jobs within the deadline window. Option C is wrong because `backoffLimit` is a field on the Job spec that controls retries for failed Pods, not a mechanism for handling missed CronJob schedules. Option D is wrong because the job does not run immediately with a 2-minute delay; it is permanently skipped for that schedule, and the controller does not retroactively execute it beyond the deadline.

Full explanation →

694

Multi-Selecteasy

Which two of the following are valid service discovery methods in Kubernetes? (Choose two.)

Select 2 answers

A.Environment variables injected into pods

B.DNS resolution via CoreDNS

C.Manual /etc/hosts entries

D.Consul agent running as a sidecar

E.Using kubectl get endpoints

AnswersA, B

When a pod starts, the kubelet injects environment variables for every Service that already exists in the same namespace, with entries like MY_SERVICE_HOST and MY_SERVICE_PORT. This allows containers to locate Services without needing explicit configuration, but only those created before the pod's creation. Because the variables are static once injected, they do not update when new Services are added, making this a limited legacy discovery method that works only for a fixed set of Services.

Why this answer

Option A is correct because Kubernetes automatically injects environment variables (e.g., <SERVICE_NAME>_SERVICE_HOST and <SERVICE_NAME>_SERVICE_PORT) into containers at pod creation time for existing Services, providing a native service discovery mechanism. Option B is correct because CoreDNS is the default cluster DNS add-on that resolves Service names (e.g., my-svc.my-namespace.svc.cluster.local) and headless Service records to ClusterIPs or pod IPs, which is the primary service discovery method in Kubernetes. Option C is not a Kubernetes-native discovery method; /etc/hosts is managed by kubelet for pod hostname resolution and does not dynamically discover Services.

Option D describes a third-party service mesh/registry approach (Consul) that is not a built-in Kubernetes service discovery method. Option E, kubectl get endpoints, is an administrative query of the Endpoints API, not a runtime service discovery mechanism used by pods.

Exam trap

The trap here is that candidates may confuse external service discovery tools (like Consul) or manual configuration methods (like /etc/hosts) with Kubernetes-native mechanisms, or mistake a diagnostic command (kubectl get endpoints) for an actual runtime discovery method.

Full explanation →

695

MCQhard

A cluster has kube-proxy running in ipvs mode. An administrator creates a Service of type ClusterIP. Which of the following is true about how traffic is forwarded to the pods?

A.kube-proxy uses userspace mode to proxy traffic

B.kube-proxy uses iptables rules to randomly select a pod

C.kube-proxy does nothing; the cluster DNS does the load balancing

D.kube-proxy creates IPVS virtual servers that use scheduling algorithms like round-robin

AnswerD

When configured in IPVS mode, kube-proxy implements Netfilter hooks and programs IPVS virtual servers to handle Service traffic directly in kernel space. This mode supports sophisticated load-balancing algorithms such as round-robin (rr), least connection (lc), destination hashing (dh), and source hashing (sh). This architecture provides superior throughput and lower latency compared to iptables, especially in large-scale clusters with thousands of Services.

Why this answer

When kube-proxy runs in ipvs mode, it creates IPVS virtual servers for each ClusterIP Service. These virtual servers use kernel-level scheduling algorithms (e.g., round-robin, least connections) to forward traffic directly to the selected backend pods, bypassing iptables for per-packet decisions. This provides better performance and more sophisticated load-balancing policies compared to iptables mode.

Exam trap

The trap here is that candidates confuse kube-proxy modes (userspace, iptables, ipvs) and assume iptables rules are always used, or mistakenly think DNS handles load balancing, when in fact ipvs mode uses kernel-level virtual servers with explicit scheduling algorithms.

How to eliminate wrong answers

Option A is wrong because userspace mode is a legacy kube-proxy mode where traffic is proxied through a userspace process; in ipvs mode, kube-proxy does not use userspace proxying. Option B is wrong because iptables rules are used in iptables mode, not ipvs mode; in ipvs mode, kube-proxy creates IPVS virtual servers and does not rely on iptables for random pod selection. Option C is wrong because cluster DNS (CoreDNS) only resolves Service names to ClusterIPs and does not perform load balancing or traffic forwarding; kube-proxy is responsible for forwarding traffic to pods.

Full explanation →

696

Multi-Selectmedium

You run 'kubectl get pods' and see that a pod named 'db' is in 'CrashLoopBackOff'. Which TWO commands are most useful for diagnosing the issue? (Choose two)

Select 2 answers

A.kubectl top pod db

B.kubectl describe pod db

C.kubectl logs db

D.kubectl get pod db -o yaml

E.kubectl exec db -- /bin/sh

AnswersB, C

This command retrieves detailed lifecycle information directly from the Kubernetes API server, including the pod's current state, container statuses, and historical events. Crucially, it displays the "Last State" field, which reveals the exit code and termination message of the previous failed container run. This makes it an essential first-line troubleshooting tool for identifying configuration or startup failures.

Why this answer

Option B, 'kubectl describe pod db', is correct because it surfaces the pod's Events section, which shows scheduling failures, image pull errors, container restarts, and the exit codes/reasons behind the CrashLoopBackOff. Option C, 'kubectl logs db', is correct because it retrieves the container's stdout/stderr, revealing the application-level error or stack trace that caused the process to exit and restart repeatedly. Together these two commands cover both the kubelet-side view (describe) and the application-side view (logs) of why the container keeps crashing.

Option A, 'kubectl top pod db', only reports CPU/memory usage and cannot explain a crash loop, and it often fails anyway if the container isn't running. Option D, 'kubectl get pod db -o yaml', shows the pod spec and status but not the event history or application output needed to diagnose the crash. Option E, 'kubectl exec db -- /bin/sh', is not useful because the container is not staying up long enough to exec into, and it doesn't reveal the prior crash cause.

Exam trap

The trap here is that candidates often choose 'kubectl get pod -o yaml' thinking it shows runtime errors, but it only shows the desired and current state in YAML format, not the event history or container logs that are essential for diagnosing a CrashLoopBackOff.

Full explanation →

697

MCQmedium

A Node is reporting DiskPressure condition. Which action is most appropriate to resolve this without losing data?

A.kubectl delete node <node-name>

B.Add additional disk space to the node or clean up unused images and logs

C.kubectl drain <node-name> --ignore-daemonsets

D.Restart the kubelet service

AnswerB

The kubelet continuously monitors filesystem usage against eviction thresholds, and DiskPressure is cleared only when usage falls below the configured soft-eviction threshold. Adding physical storage increases available capacity, while cleaning up unused container images, stopped container writable layers, and journal/application logs directly reclaims space. After space is freed, kubelet automatically updates the condition and scheduling on the node resumes.

Why this answer

DiskPressure indicates that the node's disk usage has exceeded the eviction threshold (default 85% for imagefs.available and nodefs.available). Adding disk space or cleaning up unused container images (via `crictl rmi` or `docker image prune`) and logs (via log rotation or `journalctl --vacuum`) directly frees up space without affecting running workloads or causing data loss, addressing the root cause.

Exam trap

The trap here is that candidates confuse DiskPressure with node unavailability and choose `kubectl drain` (Option C) to evacuate pods, not realizing that draining does not resolve the disk space issue and can cause data loss for stateful workloads.

Why the other options are wrong

Deleting the node removes it from cluster; does not fix disk pressure.

Drain evicts pods but does not free disk space; disk pressure persists.

Restarting kubelet does not free disk space; pressure will remain.

Full explanation →

698

Multi-Selecthard

Which THREE of the following are true about NetworkPolicy in Kubernetes? (Select 3)

Select 3 answers

A.NetworkPolicy can define rules based on DNS names

B.NetworkPolicy supports both ingress and egress rules

C.NetworkPolicy can select pods from other namespaces using namespaceSelector

D.NetworkPolicy is a cluster-scoped resource

E.By default, if no NetworkPolicy applies to a pod, all traffic to that pod is allowed

AnswersB, C, E

NetworkPolicy is designed to control both directions of traffic. The spec contains an ingress section that restricts inbound connections to selected pods, and an egress section that restricts outbound connections from those pods. Each section is independently evaluated: an empty list under ingress means no inbound traffic is allowed, while an empty egress list blocks all outbound traffic, effectively creating default-deny behavior.

Why this answer

Option B is correct because a NetworkPolicy spec can include both an ingress array and an egress array, allowing you to control inbound and outbound traffic for the selected pods (with policyTypes declaring which directions are enforced). Option C is correct because the podSelector within an ingress/egress rule can be combined with a namespaceSelector, and when both are used in the same peer element they match pods in the namespaces selected by namespaceSelector, enabling cross-namespace pod selection. Option E is correct because Kubernetes NetworkPolicy is additive and default-allow: if no NetworkPolicy selects a given pod, that pod is not isolated and all ingress and egress traffic is permitted.

Option A is not correct because NetworkPolicy peers are defined by ipBlock CIDRs, podSelector, and namespaceSelector — not by DNS names. Option D is not correct because NetworkPolicy is a namespaced resource (it lives in a namespace and selects pods within that namespace, though rules can reference other namespaces).

Exam trap

The CKA exam often tests the misconception that NetworkPolicy is cluster-scoped, but it is actually namespaced, and candidates frequently forget that egress rules require explicit allowance for DNS traffic to avoid breaking name resolution.

Full explanation →

699

MCQeasy

What does the 'volumeMode: Block' setting in a PersistentVolume spec indicate?

A.The volume will be formatted with a filesystem automatically

B.The volume will have encryption enabled by default

C.The volume will be presented as a raw block device to the pod

D.The volume will be mounted using NFS protocol

AnswerC

When volumeMode is set to Block, Kubernetes integrates the volume into the pod as a raw block device without any filesystem layer. This allows high-performance applications, such as databases or custom storage engines, to read and write directly to the block storage. The device is exposed inside the container as a path in the dev filesystem rather than a mounted directory.

Why this answer

Setting 'volumeMode: Block' in a PersistentVolume spec tells Kubernetes to present the volume as a raw block device (e.g., /dev/sdb) inside the pod, rather than mounting a filesystem. This is defined in the Kubernetes PersistentVolume API and is used for applications that need direct access to the underlying storage, such as databases or software that manage their own filesystems.

Exam trap

The trap here is that candidates confuse 'volumeMode: Block' with automatic filesystem formatting or encryption, when in fact it specifically means no filesystem is created and the device is exposed raw to the pod.

How to eliminate wrong answers

Option A is wrong because 'volumeMode: Block' explicitly skips filesystem formatting; a filesystem is only automatically created when volumeMode is set to 'Filesystem' (the default). Option B is wrong because encryption is not enabled by default with 'volumeMode: Block'; encryption is configured separately via StorageClass parameters or CSI drivers, not through the volumeMode field. Option D is wrong because NFS protocol is a network filesystem mount type, not related to block device presentation; NFS volumes use 'volumeMode: Filesystem' by default and are mounted as a directory.

Full explanation →

700

MCQeasy

A PersistentVolumeClaim named 'my-pvc' is created and remains in 'Pending' state. Which command should the administrator use to investigate the reason?

A.kubectl get pv

B.kubectl get pvc my-pvc -o yaml

C.kubectl describe pod my-pvc

D.kubectl describe pvc my-pvc

AnswerD

This is the correct command because it retrieves detailed metadata, status conditions, and the event log specifically for the my-pvc claim. The events section will explicitly show errors such as missing StorageClasses, dynamic provisioning failures, or selector mismatches that explain why the PVC remains unbound.

Why this answer

`kubectl describe pvc my-pvc` provides detailed events and status information for the PVC, including any errors or conditions that prevent it from binding to a PersistentVolume (PV). A 'Pending' state typically indicates that the PVC cannot find a matching PV or that the storage class is not available, and the describe command surfaces these reasons in the 'Events' section.

Exam trap

The trap here is that candidates often confuse `get` with `describe`, assuming `get -o yaml` shows all details, but `describe` is the standard troubleshooting command for surfacing events and human-readable error messages that `get` omits.

How to eliminate wrong answers

Option A is wrong because `kubectl get pv` lists all PersistentVolumes but does not show the specific reason why a particular PVC is pending; it lacks PVC-specific events and conditions. Option B is wrong because `kubectl get pvc my-pvc -o yaml` outputs the PVC's current YAML manifest, which includes status fields but does not display the detailed event history or human-readable error messages that `describe` provides. Option C is wrong because `kubectl describe pod my-pvc` attempts to describe a pod named 'my-pvc', which does not exist (the resource is a PVC, not a pod), and would return an error or describe an unrelated resource.

Full explanation →

701

MCQmedium

You have a Deployment with 3 replicas. One of the pods is in 'Pending' state. 'kubectl describe pod' shows: 'Warning FailedScheduling 0/4 nodes are available: 1 node(s) had taint {key1: value1}, that the pod didn't tolerate, 3 node(s) didn't match pod anti-affinity rules.' Which two issues are preventing the pod from being scheduled?

A.Taint toleration mismatch and pod anti-affinity conflicts

B.Pod anti-affinity and node selector issues

C.Node selector and taint toleration mismatch

D.Resource constraints and taint toleration mismatch

AnswerA

The event log explicitly reports a taint toleration mismatch, meaning the node carries taints the pod does not tolerate, and simultaneously reports a pod anti-affinity conflict, meaning the pod's scheduling constraints prevent it from co-locating with pods that match its anti-affinity selector. Both of these conditions together are present in the pod's unschedulable event. This answer correctly identifies the two distinct scheduling constraints that block the pod, so it is the right choice.

Why this answer

The error message explicitly states two distinct scheduling failures: '1 node(s) had taint {key1: value1}, that the pod didn't tolerate' and '3 node(s) didn't match pod anti-affinity rules.' These correspond directly to a taint toleration mismatch and pod anti-affinity conflicts. No other issues (node selector, resource constraints) are mentioned in the describe output.

Exam trap

The CKA exam often tests the ability to read the exact error message from `kubectl describe pod` and map each clause to a specific scheduling issue, rather than assuming generic problems like resource limits or node selectors.

How to eliminate wrong answers

Option B is wrong because the error message does not mention 'node selector' — it only references taint toleration and anti-affinity rules, so a node selector issue is not present. Option C is wrong because it includes 'node selector' which is not indicated in the error, and while taint toleration mismatch is correct, the second issue is anti-affinity, not node selector. Option D is wrong because 'resource constraints' (e.g., CPU/memory insufficient) would appear as 'Insufficient cpu' or 'Insufficient memory' in the describe output, not as a taint or anti-affinity message.

Full explanation →

702

MCQmedium

A pod named 'web' in the 'default' namespace is in Running state, but users report that the application is not responding. You run 'kubectl exec web -- curl -v http://localhost:8080' and see 'Connection refused'. The pod's container is listening on port 8080. Which of the following is the MOST likely cause?

A.The pod's readiness probe is failing, causing the endpoint to be removed from the service.

B.The application inside the container is not actually listening on port 8080, or it is bound to a different interface.

C.A NetworkPolicy is blocking traffic from localhost to port 8080.

D.The container's network namespace is not properly configured, so localhost does not resolve.

AnswerB

Connection refused means the TCP connection attempt was actively rejected, which typically happens when no process is listening on the specified port. It could be that the application is listening on a different port, or it is bound only to 127.0.0.1 inside the container, but 'localhost' should resolve to 127.0.0.1, so binding to 127.0.0.1 would still be reachable. However, if the application is listening on a different port or not at all, you get connection refused. Checking the application logs and the actual listening ports inside the container is necessary.

Why this answer

A connection refused error when curling localhost inside a pod indicates that no process is listening on the target port. The application may have crashed, be configured to listen on a different port, or not be started at all. Checking the container logs and running 'netstat -tuln' or 'ss -tuln' inside the container will reveal the actual listening ports.

This is a common troubleshooting step to verify application configuration.

Exam trap

The trap here is assuming that a Running pod means the application is healthy and listening on the expected port, when in fact the process may have failed or be misconfigured.

Full explanation →

703

MCQeasy

Given the following YAML manifests in the same namespace: ```yaml apiVersion: v1 kind: Pod metadata: name: my-pod labels: app: my-app spec: containers: - name: app image: nginx ports: - containerPort: 8080 --- apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - port: 80 targetPort: 8080 ``` A pod in the same namespace tries to reach my-service on port 80. What is the most likely outcome?

A.The connection succeeds but reaches the pod on port 80.

B.The connection fails because the endpoints list is empty.

C.The connection is randomly dropped due to missing port specification.

D.The connection succeeds and reaches the pod on port 8080.

AnswerD

The Service selects the pod via the matching `app: my-app` label, and its `targetPort: 8080` forwards traffic to the container's declared `containerPort`. kube-proxy programs the cluster IP so requests to port 80 are DNAT'd to the pod's IP on 8080, satisfying the same-namespace reachability constraint.

Why this answer

The Service my-service is configured with port: 80 and targetPort: 8080. Therefore, traffic sent to the Service on port 80 is forwarded to the pod's container port 8080, and the connection succeeds, reaching the pod on port 8080. If targetPort were not set, it would default to port 80, causing the connection to fail because the pod listens on 8080.

Exam trap

The trap here is that candidates assume the Service's `port` automatically maps to the container's listening port, but Kubernetes defaults `targetPort` to the same value as `port`, not to the container's port, so a mismatch causes connection failures unless explicitly configured.

How to eliminate wrong answers

Option A is wrong because the connection would not reach the pod on port 80 unless the Service's `targetPort` is explicitly set to 80 or omitted (defaulting to `port`), but the pod is listening on 8080, so traffic would be dropped or rejected. Option B is wrong because the endpoints list is not empty; the Service selects the pod via labels, so endpoints exist unless the pod is not running or labels mismatch. Option C is wrong because Kubernetes does not randomly drop connections due to missing port specification; if `targetPort` is omitted, it defaults to the `port` value, and traffic is forwarded deterministically to that port on the pod.

Full explanation →

704

MCQeasy

Which of the following is a core control plane component of Kubernetes?

A.kubelet

B.CoreDNS

C.kube-apiserver

D.CRI-O

AnswerC

The kube-apiserver is the central administrative hub of the Kubernetes control plane, exposing the HTTP API that lets users, external components, and internal parts communicate. It validates and configures data for state objects, processes REST operations, and acts as the sole gateway to the etcd datastore.

Why this answer

The kube-apiserver is the front-end of the Kubernetes control plane and the only component that directly interacts with the etcd datastore. It validates and processes all REST API requests, making it the core control plane component responsible for exposing the Kubernetes API and managing the cluster state.

Exam trap

The trap here is that candidates often confuse node-level components (kubelet, CRI-O) or cluster add-ons (CoreDNS) with core control plane components, because all are essential for a working cluster but only the kube-apiserver, kube-controller-manager, kube-scheduler, and etcd are considered core control plane components.

How to eliminate wrong answers

Option A is wrong because kubelet is a node-level agent that runs on each worker node, not a control plane component; it communicates with the API server to ensure containers are running in pods. Option B is wrong because CoreDNS is a cluster add-on that provides DNS-based service discovery, but it is not part of the core control plane (it runs as a Deployment in the kube-system namespace). Option D is wrong because CRI-O is a container runtime interface implementation that runs on nodes to manage containers, not a control plane component.

Full explanation →

705

Multi-Selecteasy

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

Select 2 answers

A.etcd

B.kubelet

C.kube-proxy

D.container runtime

E.kube-apiserver

AnswersA, E

etcd is the control plane's distributed key-value store, holding all cluster state and configuration. The API server reads and writes every object through it, making etcd a required control plane component rather than a worker node process.

Why this answer

Option A, etcd, is correct because it is the control plane's distributed key-value store that persistently holds all cluster state and configuration data, which the API server reads and writes. Option E, kube-apiserver, is correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the entry point through which all other components interact with the cluster. The unmarked options do not belong: kubelet (B) is a node agent that runs on each worker node to manage pods and containers, kube-proxy (C) is a node-level network proxy implementing Service networking rules, and the container runtime (D) is the node software (e.g., containerd or CRI-O) that actually runs containers — all three are node components, not control plane components.

Exam trap

The trap here is that candidates often confuse node-level components like kubelet and kube-proxy with control plane components, because they are essential for cluster operation but run on worker nodes, not on the control plane nodes.

Full explanation →

706

Multi-Selecteasy

You are troubleshooting a node that shows 'NotReady' status. Which TWO commands can help you investigate the kubelet state?

Select 2 answers

A.kubectl get nodes

B.journalctl -u docker

C.journalctl -u kubelet

D.systemctl status kubelet

E.kubectl describe pod

AnswersC, D

journalctl -u kubelet is the correct first place to look because the kubelet is the component that actually reports NodeReady status to the API server and runs the node's static pods and system components. Kubelet logs will show concrete errors such as failed to GET /healthz, admission rejections, CNI plugin failures, or inability to connect to the API server, making this the most direct source of truth for diagnosing a NotReady node.

Why this answer

journalctl -u kubelet (C) retrieves kubelet logs from the systemd journal, showing errors and warnings. systemctl status kubelet (D) displays the current status of the kubelet service, including whether it is running, enabled, and recent log entries. The other options: 'kubectl get nodes' (A) shows node status but not kubelet details; 'journalctl -u docker' (B) shows container runtime logs, not kubelet; 'kubectl describe pod' (E) is for pod details, not node-level kubelet troubleshooting.

Full explanation →

707

Multi-Selectmedium

Which TWO of the following are valid volumeBindingMode values for a StorageClass?

Select 2 answers

A.Lazy

B.WaitForFirstConsumer

C.Immediate

D.OnDemand

E.Deferred

AnswersB, C

WaitForFirstConsumer is a valid volumeBindingMode that delays both provisioning and binding of a PersistentVolumeClaim until a pod that references the claim has been scheduled. This allows the Kubernetes scheduler to consider the pod's node, zone, and topology constraints, ensuring that a dynamically provisioned volume is created in the same topology segment as the pod. It is essential for storage solutions where volumes are tied to specific availability zones or nodes.

Why this answer

In Kubernetes, a StorageClass's volumeBindingMode field controls when volume binding and dynamic provisioning occur, and it accepts exactly two values. Option B, WaitForFirstConsumer, is correct because it delays binding and provisioning until a Pod using the PVC is scheduled, allowing the scheduler to pick a node that satisfies both the Pod's and the volume's topology constraints. Option C, Immediate, is correct because it is the default mode that binds and provisions the volume as soon as the PersistentVolumeClaim is created, without regard to Pod scheduling.

Options A (Lazy), D (OnDemand), and E (Deferred) are not recognized by the Kubernetes API and would cause validation errors, so they are not valid volumeBindingMode values.

Exam trap

The trap here is that candidates may confuse 'Lazy' or 'Deferred' with `WaitForFirstConsumer` due to similar-sounding names, or assume 'OnDemand' is a valid mode because it sounds like dynamic provisioning, but only `Immediate` and `WaitForFirstConsumer` are defined in the Kubernetes API.

Full explanation →

708

MCQhard

You have a Deployment with 3 replicas. You create a headless service (clusterIP: None) with a label selector. Which of the following is true about DNS resolution for this service?

A.DNS returns the IP addresses of all pods that match the selector.

B.DNS does not resolve the service name at all.

C.DNS returns the service name as a CNAME to the pod names.

D.DNS resolves the service name to a single ClusterIP.

AnswerA

With a headless service (clusterIP: None), the DNS name for the service is not backed by a virtual IP. Instead, CoreDNS/kube-dns creates an A record for each ready pod endpoint that matches the service's selector, so a DNS query for the service name returns the IP addresses of all 3 pod replicas.

Why this answer

A headless service (clusterIP: None) does not allocate a ClusterIP. Instead, DNS returns the IP addresses of all pods matching the label selector via A/AAAA records. This allows direct pod-to-pod communication without load balancing, commonly used for stateful workloads like databases.

Exam trap

The trap here is that candidates assume all services have a ClusterIP and that DNS always returns a single IP, but headless services bypass this entirely, returning multiple pod IPs instead.

How to eliminate wrong answers

Option B is wrong because DNS does resolve the headless service name; it returns the pod IPs rather than failing. Option C is wrong because DNS returns A/AAAA records with pod IPs, not a CNAME to pod names (though pod DNS names are created via StatefulSet, not a headless service alone). Option D is wrong because a headless service explicitly sets clusterIP: None, so no ClusterIP is assigned; DNS never returns a single ClusterIP.

Full explanation →

709

MCQeasy

Which command creates a kubeconfig file that can be used to authenticate as a specific user?

A.kubectl config set-context

B.kubectl config set-credentials

C.kubectl config create-user

D.kubectl config set-cluster

AnswerB

This is the correct command because it creates or updates the user entry in the kubeconfig with the necessary authentication credentials, such as --client-certificate, --client-key, --token, or --username/--password. Running this command ensures that a named user with valid credentials is available for contexts to reference. Without it, you only have cluster and context definitions but no authenticated identity to actually connect to the API server.

Why this answer

The `kubectl config set-credentials` command creates or updates a user entry in a kubeconfig file, allowing you to specify authentication credentials such as a client certificate, token, or username/password for a specific user. This is the correct way to define a user identity that can later be associated with a context via `kubectl config set-context`.

Exam trap

The trap here is that candidates confuse `set-credentials` with `set-context`, thinking that creating a context automatically includes user credentials, when in fact the user must be defined separately before being referenced in a context.

How to eliminate wrong answers

Option A is wrong because `kubectl config set-context` only defines a context (cluster, namespace, and user association) but does not create or store user credentials. Option C is wrong because `kubectl config create-user` is not a valid kubectl command; kubectl does not have a `create-user` subcommand. Option D is wrong because `kubectl config set-cluster` only configures cluster details (e.g., server URL, CA certificate) and has nothing to do with user authentication.

Full explanation →

710

MCQeasy

Which component is responsible for running containers on a node?

A.kubelet

B.kube-scheduler

C.container runtime

D.kube-proxy

AnswerC

The container runtime is the low-level software that actually runs containers on a node. It implements the Kubernetes CRI (e.g., containerd, CRI-O) and uses an OCI-compliant runtime like runc to create namespaces, set up cgroups, and execute container processes as the kernel sees them. When the kubelet requests a pod sandbox or container, the runtime pulls images, mounts filesystems, and starts the user process — making it the direct executor of container workloads.

Why this answer

The container runtime is the software responsible for actually running containers on a node. It pulls container images, creates container namespaces, and manages the container lifecycle (start, stop, delete). In Kubernetes, the kubelet delegates container execution to the container runtime via the CRI (Container Runtime Interface), but the runtime itself performs the low-level operations using technologies like runc or containerd.

Exam trap

The trap here is that candidates often confuse the kubelet's role as the node agent with the actual execution of containers, but the kubelet only orchestrates the runtime — it does not run containers itself.

How to eliminate wrong answers

Option A is wrong because the kubelet is the node agent that communicates with the control plane and manages pod lifecycle, but it does not directly run containers — it instructs the container runtime to do so. Option B is wrong because the kube-scheduler is a control plane component that assigns pods to nodes based on resource availability and constraints, not a component that runs containers on a node. Option D is wrong because kube-proxy is a network proxy that maintains network rules and handles service-to-pod traffic routing on each node, not container execution.

Full explanation →

711

MCQmedium

You are debugging a DNS issue in the cluster. Which of the following tools is commonly used to test DNS resolution from within a Pod?

A.ping

B.tcpdump

C.curl

D.nslookup

AnswerD

nslookup is a dedicated network administration tool specifically designed to query Domain Name System servers to obtain mapping or domain name resource records. In a Kubernetes environment, it allows administrators to directly query the CoreDNS service IP for specific internal records, such as Service A-records or Headless Service SRV records. This direct querying capability makes it the standard utility for isolating and verifying DNS resolution issues within a cluster.

Why this answer

`nslookup` is a dedicated DNS lookup utility that queries DNS servers directly, making it the standard tool for testing DNS resolution from within a Pod. It sends DNS queries to the cluster's DNS service (e.g., CoreDNS or kube-dns) and returns the resolved IP addresses, allowing you to verify that DNS records for Services, Pods, or external hosts are correctly configured and reachable.

Exam trap

The trap here is that candidates often confuse network connectivity tools (like `ping` or `curl`) with DNS-specific tools, assuming that if a hostname is reachable via `ping`, DNS is working, but `ping` can succeed via other mechanisms (e.g., local hosts file or cached entries) and does not validate DNS resolution.

How to eliminate wrong answers

Option A is wrong because `ping` tests network connectivity using ICMP echo requests, not DNS resolution; it cannot query DNS records or verify that a hostname resolves correctly. Option B is wrong because `tcpdump` is a packet capture tool that analyzes network traffic at the packet level, not a DNS resolution tool; it requires deep packet inspection and is not designed for simple DNS lookups. Option C is wrong because `curl` is used to transfer data with URLs (e.g., HTTP/HTTPS), and while it may trigger DNS resolution internally, it does not provide direct DNS query results and can fail for reasons unrelated to DNS (e.g., HTTP errors or firewall rules).

Full explanation →

712

MCQmedium

You deploy a pod with the following YAML: apiVersion: v1 kind: Pod metadata: name: test-pod spec: containers: - name: test image: nginx resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" The pod starts, but after a few minutes it is killed with OOMKilled. What is the MOST likely reason?

A.The memory limit is lower than the memory request

B.The node has swap enabled

C.The container's memory usage exceeds the configured limit

D.The container is using too much CPU

AnswerC

When a container's memory consumption, specifically its Resident Set Size (RSS), exceeds the `memory.limit_in_bytes` enforced by its cgroup, the Linux kernel's Out-Of-Memory (OOM) killer is invoked. This mechanism is designed to protect the host system from memory exhaustion by terminating processes that have surpassed their allocated memory resources. In this specific scenario, the container was terminated precisely because its application attempted to allocate or utilize memory beyond the 128Mi limit, triggering the OOM killer to reclaim system resources.

Why this answer

OOMKilled occurs when a container exceeds its memory limit. In this YAML, the memory limit is set to 128Mi. If the nginx container's memory usage surpasses 128Mi, the Linux kernel's Out-Of-Memory (OOM) killer terminates the container process, resulting in an OOMKilled status.

This is a direct enforcement of the resource limit configured in the pod spec.

Exam trap

Candidates often confuse CPU limits with memory limits. Exceeding CPU limits results in CPU throttling (the container is slowed down but not killed), whereas exceeding memory limits results in the container being terminated immediately with an OOMKilled (Exit Code 137) status. Additionally, note that the Kubernetes API server will reject any Pod creation attempt where requests are higher than limits, making Option A structurally impossible.

How to eliminate wrong answers

Option A is wrong because having a memory limit lower than the memory request is allowed; Kubernetes only requires that limits are not lower than requests for CPU, but for memory, it is permitted and does not cause OOMKilled. Option B is wrong because swap is typically disabled in Kubernetes nodes (kubelet default is --fail-swap-on=true), and even if enabled, OOMKilled is triggered by exceeding the memory limit, not by swap usage. Option D is wrong because OOMKilled is specifically a memory-related termination; excessive CPU usage leads to CPU throttling (via CFS quotas), not container termination with OOMKilled.

Full explanation →

713

Multi-Selectmedium

Which TWO statements are true about Ingress in Kubernetes?

Select 2 answers

A.Ingress can terminate TLS connections

B.Ingress can expose multiple Services under the same IP address

C.IngressClass is a mandatory field in Ingress spec

D.Ingress is the only way to expose Services externally

E.Ingress works without an Ingress controller

AnswersA, B

Ingress can terminate TLS because the Ingress spec supports a tls section that references a Secret containing the certificate and private key. When configured, the Ingress controller performs HTTPS termination, decrypting traffic at the edge and forwarding plain HTTP to backend Services. This is a built-in feature of most controllers, such as NGINX, and is managed by the controller itself.

Why this answer

Option A is correct because an Ingress resource can specify a TLS block with a secretName referencing a Kubernetes TLS Secret, allowing the Ingress controller to terminate TLS connections at the edge before forwarding traffic to backend Services. Option B is correct because a single Ingress resource can define multiple rules and paths (host- and path-based routing) that map to different backend Services, all reachable through the same Ingress controller IP address. Option C is not correct because IngressClass is not a mandatory field in the Ingress spec; it can be set via the ingressClassName field or the deprecated kubernetes.io/ingress.class annotation, and defaults may apply.

Option D is not correct because Services can also be exposed externally via NodePort, LoadBalancer, or externalIPs without using Ingress. Option E is not correct because an Ingress resource has no effect on its own; an Ingress controller (such as NGINX or Traefik) must be running to implement the routing rules.

Exam trap

This certification often tests the misconception that IngressClass is mandatory or that Ingress can function without a controller, leading candidates to overestimate the Ingress resource's autonomy.

Full explanation →

714

MCQmedium

You run 'kubectl get pods' and see a pod in 'CrashLoopBackOff'. What command would you run to see the reason for the crash?

A.kubectl top pod <pod-name>

B.kubectl describe pod <pod-name>

C.kubectl rollout status deployment <deployment-name>

D.kubectl get events --field-selector involvedObject.name=<pod-name>

AnswerB

kubectl describe pod surfaces the container's last terminated state, exit code and events, which reveal why the process exited and triggered the restart loop. Logs show application output but not the termination reason, so describe is the direct diagnostic for CrashLoopBackOff.

Why this answer

B is correct because `kubectl describe pod <pod-name>` provides detailed information about the pod, including the container state, restart count, and the last termination reason (e.g., 'Error' or 'OOMKilled') along with its exit code. To view the actual stdout/stderr logs of the crashed container, you would use `kubectl logs <pod-name> --previous`.

Exam trap

The CKA exam often tests your ability to troubleshoot failing pods. Candidates sometimes confuse `kubectl describe pod` (which shows metadata, events, and container exit codes/termination reasons) with `kubectl logs <pod-name> --previous` (which retrieves the actual application logs from the failed container). Both are critical troubleshooting steps, but `describe` is the primary tool for checking the high-level termination reason and exit code.

How to eliminate wrong answers

Option A is wrong because `kubectl top pod` shows real-time CPU and memory usage metrics, not crash reasons or container exit statuses. Option C is wrong because `kubectl rollout status deployment` checks the rollout progress of a deployment (e.g., whether new ReplicaSets are available), not the crash details of an individual pod. Option D is wrong because while `kubectl get events` can show pod-related events, the field selector `involvedObject.name=<pod-name>` filters events by the pod's name but may miss the container-level termination reason (which is stored in the pod's status, not always in events), and it does not provide the structured exit code and reason as `kubectl describe` does.

Full explanation →

715

MCQeasy

Which of the following is a core control plane component responsible for persisting cluster state?

A.kube-apiserver

B.kube-scheduler

C.kube-controller-manager

D.etcd

AnswerD

etcd is the consistent, highly-available distributed key-value store that acts as the cluster’s single source of truth. It persists every Kubernetes object — Secrets, ConfigMaps, Pod specs, and cluster configuration — using the Raft consensus algorithm to replicate writes across all etcd members. This is the only core control-plane component that actually stores data, making it critical for backup and disaster recovery.

Why this answer

etcd is the core control plane component responsible for persisting cluster state. It is a distributed, consistent key-value store that stores all cluster data, including configuration, state, and metadata. The kube-apiserver is the only component that interacts directly with etcd, ensuring that all state changes are recorded durably.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage component because it is the only component that talks to etcd, but the actual persistence layer is etcd itself.

How to eliminate wrong answers

Option A is wrong because kube-apiserver is the front-end for the Kubernetes control plane that exposes the API and validates requests, but it does not persist data itself; it reads from and writes to etcd. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, not for storing cluster state. Option C is wrong because kube-controller-manager runs controller processes that regulate cluster state (e.g., ensuring desired replicas), but it relies on the API server to read/write state from etcd and does not persist data directly.

Full explanation →

716

MCQmedium

A developer runs 'kubectl run nginx --image=nginx --expose --port=80'. What Kubernetes resources are created?

A.Only a pod named 'nginx'

B.A pod named 'nginx' and a ClusterIP service named 'nginx'

C.A pod named 'nginx' and a LoadBalancer service named 'nginx'

D.A deployment named 'nginx' and a NodePort service named 'nginx'

AnswerB

Executing kubectl run with the --expose flag creates a Pod and concurrently provisions a ClusterIP Service sharing the exact same name. By default, this Service acts as an internal load balancer, mapping its own port directly to the container port defined in the Pod specification.

Why this answer

The `kubectl run nginx --image=nginx --expose --port=80` command creates a pod named 'nginx' and automatically generates a ClusterIP service named 'nginx' that exposes port 80. The `--expose` flag triggers the creation of a service of type ClusterIP (the default service type) to provide stable network access to the pod.

Exam trap

The trap here is that candidates often assume `kubectl run` always creates a Deployment (as it did in older Kubernetes versions) or that `--expose` creates a LoadBalancer, but the CKA exam tests the current default behavior where `kubectl run` creates a pod and `--expose` creates a ClusterIP service.

How to eliminate wrong answers

Option A is wrong because it ignores the `--expose` flag, which explicitly instructs kubectl to create a service alongside the pod. Option C is wrong because `kubectl run` with `--expose` creates a ClusterIP service, not a LoadBalancer service; a LoadBalancer would require `--type=LoadBalancer` or a separate `kubectl expose` command with that type. Option D is wrong because `kubectl run` without `--generator` or `--restart` flags creates a standalone pod, not a deployment, and the service type defaults to ClusterIP, not NodePort.

Full explanation →

717

MCQeasy

Which DNS record type does Kubernetes use to resolve a Service's ClusterIP?

A.PTR record

B.SRV record

C.CNAME record

D.A record

AnswerD

An A record, or Address record, is the fundamental DNS record type used to map a hostname directly to an IPv4 address. For a Kubernetes Service, CoreDNS creates an A record that maps the service's fully qualified domain name (e.g., `my-service.my-namespace.svc.cluster.local`) to its stable ClusterIP, which is an IPv4 address. This direct, one-to-one mapping is precisely what enables pods within the cluster to resolve service names to their corresponding network addresses for communication.

Why this answer

Kubernetes uses A records to resolve a Service's ClusterIP. When a DNS query is made for a Service name (e.g., `my-svc.my-namespace.svc.cluster.local`), the cluster's DNS server (typically CoreDNS) returns an A record containing the Service's ClusterIP address. This allows pods to reach the Service via its stable virtual IP.

Exam trap

The trap here is that candidates confuse SRV records (used for headless Services with named ports) with the standard A record resolution for ClusterIP Services, or mistakenly think CNAME records are used for internal Service resolution.

How to eliminate wrong answers

Option A is wrong because PTR records are used for reverse DNS lookups (IP to hostname), not for resolving a Service's ClusterIP. Option B is wrong because SRV records are used to locate specific services with port information (e.g., for headless Services with named ports), not for standard ClusterIP resolution. Option C is wrong because CNAME records alias one hostname to another; Kubernetes uses A records (or AAAA for IPv6) for ClusterIP Services, not CNAMEs, which are typically used for external DNS aliasing.

Full explanation →

718

MCQhard

A NetworkPolicy with podSelector: {} and policyTypes: [Ingress] is applied to a namespace. What is the effect on pods in that namespace?

A.All ingress traffic is denied unless explicitly allowed by another policy.

B.The policy has no effect because no rules are defined.

C.All ingress traffic is allowed.

D.All egress traffic is denied.

AnswerA

An empty `podSelector: {}` in a NetworkPolicy selects all pods within the policy's namespace. When `policyTypes: [Ingress]` is specified without any `ingress` rules, the policy's effect on the selected pods is to deny all incoming traffic by default. This effectively creates a default-deny ingress posture for all pods in the namespace, unless another NetworkPolicy explicitly permits specific ingress connections to those pods.

Why this answer

A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. When `policyTypes: [Ingress]` is set without any ingress rules, it defaults to denying all ingress traffic that is not explicitly allowed by another policy. This is because Kubernetes NetworkPolicy implements an implicit deny for the specified traffic direction when no rules are provided, effectively isolating the pods from inbound connections.

Exam trap

The trap here is that candidates often assume an empty rules list means 'no effect' or 'allow all', but Kubernetes NetworkPolicy defaults to deny for the specified policyTypes when no rules are defined, making it a powerful isolation tool.

How to eliminate wrong answers

Option B is wrong because a NetworkPolicy with `podSelector: {}` and `policyTypes: [Ingress]` does have an effect: it denies all ingress traffic by default, even without explicit rules. Option C is wrong because the absence of ingress rules in a policy with `policyTypes: [Ingress]` results in a deny-all behavior for ingress, not an allow-all. Option D is wrong because the policy only specifies `policyTypes: [Ingress]`, so it has no effect on egress traffic; egress remains allowed by default unless another policy denies it.

Full explanation →

719

MCQhard

A Pod is stuck in Pending state. Running 'kubectl describe pod' shows '0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, 2 node(s) had taint {node-role.kubernetes.io/master: }'. The Pod does not have tolerations. What is the most likely cause?

A.The scheduler is not running.

B.The Pod requests more CPU than any node can provide.

C.The Pod has a node selector that doesn't match any node.

D.The Pod does not have tolerations for the control-plane or master taints.

AnswerD

Control-plane and master nodes are typically configured with taints like node-role.kubernetes.io/control-plane:NoSchedule to prevent user workloads from running on them. Because the Pod lacks the corresponding tolerations in its specification, the scheduler filters out these nodes, leaving the Pod in a Pending state with a taint-related scheduling failure event.

Why this answer

The Pod is stuck in Pending state because it does not have tolerations for the taints present on the nodes. The error message explicitly states that 1 node has the control-plane taint and 2 nodes have the master taint. By default, Pods without matching tolerations cannot be scheduled onto tainted nodes.

Since all available nodes are tainted, the scheduler has no eligible node to place the Pod, leaving it in Pending.

Exam trap

The trap here is that candidates may confuse taints/tolerations with node selectors or resource constraints, but the error message explicitly lists taints as the reason, making it a direct match to the toleration requirement.

How to eliminate wrong answers

Option A is wrong because if the scheduler were not running, the Pod would remain in Pending with a different error message (e.g., 'no matching node' or 'scheduler error'), not the specific taint-based message shown. Option B is wrong because the error message does not mention insufficient CPU or memory; it explicitly lists taints as the reason for node unavailability. Option C is wrong because the error message does not mention a node selector mismatch; if a node selector were the issue, the message would indicate '0/3 nodes are available: 3 node(s) didn't match node selector', not taint-related messages.

Full explanation →

720

MCQeasy

A developer deployed a Pod that is stuck in Pending state. The cluster has one worker node with taint 'node.kubernetes.io/disk-pressure:NoSchedule'. The Pod does not specify any tolerations. What is the most likely cause?

A.The Pod was evicted due to resource pressure.

B.The Pod requests more CPU than available on the node.

C.The scheduler failed to communicate with the API server.

D.The node has a taint that the Pod does not tolerate.

AnswerD

The node is marked with a 'node.kubernetes.io/disk-pressure' taint with a 'NoSchedule' effect. Because the Pod's manifest does not define a matching toleration for this specific taint, the kube-scheduler is forced to bypass this node, leaving the Pod in a Pending state due to unschedulability.

Why this answer

A Pod stuck in Pending state indicates the scheduler cannot find a suitable node. The cluster has a worker node with the taint 'node.kubernetes.io/disk-pressure:NoSchedule', and the Pod has no tolerations. Since taints with effect NoSchedule prevent scheduling of Pods that do not tolerate them, the Pod cannot be placed on that node, leaving it in Pending.

Exam trap

CNCF often tests the distinction between taints/tolerations and resource constraints, so the trap here is that candidates may confuse a taint-based scheduling block with a resource shortage, especially when the taint name includes 'disk-pressure' which sounds like a resource issue.

How to eliminate wrong answers

Option A is wrong because eviction occurs when a Pod is already running and the node experiences resource pressure, not when a Pod is stuck in Pending; eviction would move the Pod to a different state (e.g., Failed or Evicted). Option B is wrong because insufficient CPU would cause the scheduler to report a '0/1 nodes are available: insufficient cpu' event, but the question explicitly states the node has a disk-pressure taint, and the Pod has no tolerations, making the taint the primary blocking factor. Option C is wrong because scheduler-to-API-server communication failures typically result in scheduler errors or 'no persistent volumes available' messages, not a simple Pending state; the scheduler communicates via the API server to list nodes and bind Pods, and a failure would produce different symptoms.

Full explanation →

721

MCQmedium

You need to upgrade a Kubernetes cluster from v1.28 to v1.29 using kubeadm. After upgrading the control plane, what should you do on each worker node?

A.kubeadm upgrade node config --kubelet-version v1.29.0

B.kubectl delete node <node>; kubeadm upgrade node

C.kubectl drain <node>; kubeadm upgrade node; kubectl uncordon <node>

D.kubeadm upgrade node; kubectl uncordon <node>

AnswerC

This is the correct per-node upgrade sequence: kubectl drain <node> first cordons the node and evicts its workloads—typically using --ignore-daemonsets in practice—then kubeadm upgrade node applies the new kubeadm and kubelet configuration to the node's local files, and finally kubectl uncordon <node> marks it schedulable again so new pods can be placed. Without draining, the kubelet may be restarted while pods are still running, and there is no graceful transition for the workloads. The uncordon step is essential after the upgrade, otherwise the node would remain unschedulable and workloads would not be scheduled back to it.

Why this answer

The standard kubeadm upgrade workflow for worker nodes requires first draining the node to safely evict all pods, then running 'kubeadm upgrade node' to upgrade the kubelet and kube-proxy configuration, and finally uncordoning the node to make it schedulable again. This sequence ensures minimal disruption to workloads and follows the official Kubernetes upgrade documentation.

Exam trap

The trap here is that candidates may assume 'kubeadm upgrade node' alone handles pod eviction, but it only upgrades the node's components and does not automatically drain pods, making the drain step essential to avoid workload disruption.

How to eliminate wrong answers

Option A is wrong because 'kubeadm upgrade node config --kubelet-version v1.29.0' is not a valid command; kubeadm does not support a --kubelet-version flag for the upgrade node subcommand, and the correct approach is to use 'kubeadm upgrade node' which automatically handles the kubelet configuration. Option B is wrong because deleting the node object with 'kubectl delete node' is unnecessary and disruptive; it removes the node from the cluster's control plane, requiring re-registration, whereas the correct process uses drain and uncordon to maintain node membership. Option D is wrong because it omits the critical 'kubectl drain' step before upgrading the node; upgrading without draining can cause running pods to be terminated abruptly, leading to service disruption and potential data loss.

Full explanation →

722

Multi-Selectmedium

You need to create a Kubernetes ServiceAccount named 'build-bot' and ensure that pods using this ServiceAccount can authenticate to the Kubernetes API using a long-lived token. Which TWO steps are necessary? (Choose TWO.)

Select 2 answers

A.Create a Secret of type 'Opaque' with the token data

B.Run 'kubectl create token build-bot'

C.Use the TokenRequest API to generate a token

D.Create a ServiceAccount object named 'build-bot'

E.Create a Secret with type 'kubernetes.io/service-account-token' and reference the ServiceAccount via annotation

AnswersD, E

The foundational step is to create a ServiceAccount object, which you can do with `kubectl create serviceaccount build-bot` or by applying a YAML manifest with `kind: ServiceAccount` and the desired name. Kubernetes does not automatically carve out a ServiceAccount for you—it must be explicitly created before any pod or process can assume that identity. Once the ServiceAccount exists, the controller-manager automatically provisions a long-lived token secret for it (unless you explicitly opt out), so the ServiceAccount immediately has a usable credential. Without this object, all other claims about generating or attaching tokens are invalid because there is no identity to bind them to.

Why this answer

Creating a ServiceAccount named 'build-bot' is the foundational step; without the ServiceAccount object, no pods can be assigned a service account identity. Option E is correct because a Secret of type 'kubernetes.io/service-account-token' with an annotation referencing the ServiceAccount causes the Kubernetes controller manager to automatically generate and populate a long-lived token, which pods can mount and use to authenticate to the API server.

Exam trap

CNCF often tests the distinction between long-lived tokens (created via the legacy Secret-based mechanism) and short-lived tokens (generated via the TokenRequest API or 'kubectl create token'), leading candidates to incorrectly select options that produce ephemeral credentials.

Full explanation →

723

MCQeasy

Which kubectl command will expose a deployment named 'web-app' as a NodePort service on port 80?

A.kubectl expose pod web-app --type=NodePort --port=80

B.kubectl create deployment web-app --expose --port=80

C.kubectl create service nodeport web-app --port=80

D.kubectl expose deployment web-app --type=NodePort --port=80

AnswerD

This command correctly targets the `deployment` resource named `web-app` and dynamically generates a NodePort service. It automatically extracts the deployment's pod template labels to populate the service's selector, ensuring seamless routing of external traffic on the specified port.

Why this answer

The `kubectl expose deployment web-app --type=NodePort --port=80` command creates a Service from an existing Deployment named 'web-app', setting the service type to NodePort and mapping port 80 on the node to the target port on the pods. This is the standard way to expose a Deployment as a NodePort service in Kubernetes.

Exam trap

The trap here is that candidates often confuse `kubectl expose` with `kubectl create service` or misuse the `--expose` flag on `kubectl create deployment`, not realizing that `kubectl expose` is the correct command to create a service from an existing resource and that the `--type=NodePort` flag is required for NodePort exposure.

How to eliminate wrong answers

Option A is wrong because it attempts to expose a pod named 'web-app' rather than a deployment, and the pod name does not match the deployment name; also, exposing a pod directly is not the intended method for managing a scalable service. Option B is wrong because `kubectl create deployment` with `--expose` creates a new deployment and a ClusterIP service (not NodePort) simultaneously, and it does not allow specifying the service type as NodePort. Option C is wrong because `kubectl create service nodeport` requires a `--tcp` flag to specify the port mapping (e.g., `--tcp=80:80`) and does not automatically link to an existing deployment; it creates a standalone service without selecting the deployment's pods.

Full explanation →

724

Multi-Selecteasy

Which TWO commands can be used to check the expiration of certificates managed by kubeadm?

Select 2 answers

A.kubeadm upgrade plan

B.kubectl get certificates

C.openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity

D.kubeadm certs renew --all

E.kubeadm certs check-expiration

AnswersC, E

The openssl x509 command reads the actual X.509 certificate file at /etc/kubernetes/pki/apiserver.crt and decodes it. With -noout it suppresses the base64 PEM output, and -text prints the structured certificate fields; piping to grep -A2 'Validity' extracts the Not Before and Not After dates, which directly reveal the expiration timestamp. This method works at the filesystem level and is independent of kubeadm's state, making it a reliable diagnostic for any certificate file.

Why this answer

Option E, `kubeadm certs check-expiration`, is correct because it is the dedicated kubeadm subcommand that lists all kubeadm-managed certificates (in /etc/kubernetes/pki and /etc/kubernetes/pki/etcd) along with their expiration dates, residual time, and CA certificate validity. Option C, `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep -A2 Validity`, is correct because it directly parses the X.509 certificate file and prints its Validity period (Not Before / Not After), which is a valid way to inspect the expiration of any individual kubeadm-managed certificate. Option A, `kubeadm upgrade plan`, is not correct because it reports available Kubernetes version upgrades and only incidentally warns about certificate expiry, not as its purpose.

Option B, `kubectl get certificates`, is not correct because there is no built-in `certificates` resource in Kubernetes (that would require cert-manager CRDs, which are unrelated to kubeadm PKI). Option D, `kubeadm certs renew --all`, is not correct because it renews certificates rather than checking their expiration.

Exam trap

The trap here is that candidates confuse `kubeadm certs renew --all` (which performs renewal) with `kubeadm certs check-expiration` (which only checks expiration), or they mistakenly think `kubectl get certificates` is a valid command for checking kubeadm-managed certificates, when in fact Kubernetes has a `CertificateSigningRequest` resource but not a generic `certificates` resource for PKI files.

Full explanation →

725

Multi-Selecthard

Which THREE of the following are true about the interaction between PersistentVolumeClaims and pods?

Select 3 answers

A.A PVC is namespace-scoped and can only be used by pods in the same namespace

B.A PVC can only be used by a single pod at a time

C.When a pod is deleted, its attached PVC is automatically deleted

D.A PVC must be created before a pod that references it can be scheduled

E.Multiple pods can use the same PVC if the access mode allows

AnswersA, D, E

A PersistentVolumeClaim is a namespaced resource, meaning it exists within a specific Kubernetes namespace. A pod can only reference a PVC by name within its own namespace; if a pod attempts to use a PVC from another namespace, the claim will not resolve. This namespacing mirrors other Kubernetes objects like ConfigMaps and Secrets. Thus, to share a volume across namespaces, you must use a distributed filesystem with subpaths or a ClusterRole, not cross-namespace PVC references.

Why this answer

Option A is correct because PersistentVolumeClaims are namespace-scoped API objects, so a pod can only reference a PVC that exists in its own namespace. Option D is correct because a pod that references a PVC requires that claim to exist and be bound (or bindable) before the pod can be successfully scheduled and started. Option E is correct because a PVC's access modes determine multi-pod use: ReadWriteMany or ReadOnlyMany allow multiple pods to mount the same claim, while ReadWriteOnce restricts it to a single node.

Option B is wrong because a PVC can be shared by multiple pods when the access mode permits it, such as ReadWriteMany. Option C is wrong because deleting a pod does not delete its PVC; the claim persists until it is explicitly deleted, and its reclaim policy governs the underlying PersistentVolume.

Exam trap

The trap here is that candidates often confuse PVCs with ephemeral volumes like emptyDir, assuming PVCs are automatically cleaned up with the pod, but Kubernetes explicitly separates PVC lifecycle from pod lifecycle to preserve data.

Full explanation →

726

Multi-Selecthard

Which THREE statements about NetworkPolicy are correct?

Select 3 answers

A.To allow traffic from a specific namespace, you can use a namespaceSelector in the ingress rule.

B.If no NetworkPolicy exists, all traffic is denied by default.

C.A NetworkPolicy with podSelector: {} selects all pods in the namespace.

D.The field 'podSelector.matchLabels' is used to select pods based on labels.

E.NetworkPolicy is a cluster-scoped resource.

AnswersA, C, D

A namespaceSelector matches pods by their namespace's labels, so an ingress rule containing it permits traffic originating from pods in the selected namespace. This satisfies the stem's requirement for allowing traffic from a specific namespace.

Why this answer

Option A is correct because an ingress rule's 'from' clause can include a namespaceSelector that matches namespaces by their labels, thereby permitting traffic originating from pods in those namespaces. Option C is correct because an empty podSelector (podSelector: {}) matches every pod in the NetworkPolicy's own namespace, effectively applying the policy to all pods there. Option D is correct because podSelector uses a LabelSelector whose matchLabels field selects pods by exact key/value label pairs.

Option B is wrong because the absence of any NetworkPolicy means all ingress and egress traffic is allowed by default; traffic is only denied once a policy selects the pod. Option E is wrong because NetworkPolicy is a namespaced resource, not cluster-scoped, and only affects pods within its own namespace.

Exam trap

A common misconception is that NetworkPolicy defaults to deny-all when no policy exists, but the actual default is allow-all; the trap is that candidates confuse the 'default deny' behavior that occurs once a policy selects a pod (if no rule allows traffic) with the cluster-wide default.

Full explanation →

Certified Kubernetes Administrator CKA (CKA) — Questions 676–726