Knowledge + Practice

Certified Kubernetes Administrator CKA (CKA) — Questions 901–975

1005 questions total · 14pages · All types, answers revealed

Take a mock exam Exam hub

Page 13 of 14

901

MCQeasy

You want to check the status of the kube-apiserver on a control plane node. Which commands should you use? (Select the best option)

A.journalctl -u kubelet

B.systemctl status kube-apiserver or kubectl get pods -n kube-system

C.ps aux | grep kube-apiserver

D.docker ps | grep kube-apiserver

AnswerB

Both commands are commonly used to check the status of the API server, depending on whether it's managed by systemd or as a static pod.

Why this answer

Option C is correct. On a control plane node, you can check the kube-apiserver status using 'systemctl status kube-apiserver' if it's running as a systemd service, or by checking the pod if it's running as a static pod: 'kubectl get pods -n kube-system'. Option A uses 'ps aux' which is not a standard systemctl command.

Option B 'docker ps' would show containers but not the service status. Option D 'journalctl -u kubelet' shows kubelet logs, not apiserver.

Full explanation →

902

Multi-Selectmedium

Which TWO of the following are valid commands to upgrade a kubeadm cluster from version 1.22.x to 1.23.x on the control plane node? Assume the node is already drained.

Select 2 answers

A.kubeadm upgrade apply v1.23.0

B.kubeadm upgrade node

C.kubeadm upgrade plan v1.23.0

D.kubeadm upgrade plan

E.kubeadm upgrade diff

AnswersA, D

This applies the upgrade to the specified version.

Why this answer

Option A is correct because `kubeadm upgrade apply v1.23.0` is the explicit command to upgrade the control plane to a specific version (v1.23.0) in a kubeadm cluster. It validates the upgrade path, uploads the new configuration, and applies the upgrade to the control plane components. The node is already drained, so this command proceeds directly with the upgrade.

Exam trap

The trap here is that candidates confuse `kubeadm upgrade plan` (which only shows available upgrades) with an actual upgrade command, or they incorrectly add a version argument to `kubeadm upgrade plan`, which is syntactically invalid.

Full explanation →

903

MCQeasy

Which command can you use to view the logs of a container that has crashed and been restarted?

A.kubectl describe pod pod-name

B.kubectl logs pod-name --previous

C.kubectl exec pod-name -- cat /var/log/crash.log

D.kubectl logs pod-name

AnswerB

This shows logs from the previous terminated container.

Why this answer

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

Full explanation →

904

Multi-Selectmedium

Which of the following can be used to expose a set of pods externally to the internet in a Kubernetes cluster? (Select THREE.)

Select 3 answers

A.Ingress resource

B.Service of type NodePort

C.Service of type LoadBalancer

D.Service of type Headless

E.Service of type ClusterIP

AnswersA, B, C

Ingress provides external access to services based on rules.

Why this answer

Option A: NodePort exposes a service on each node's IP at a static port. Option C: Ingress provides HTTP/HTTPS routing to services. Option D: LoadBalancer provisions a cloud load balancer to expose the service.

Option B: ClusterIP is only reachable within the cluster. Option E: Headless service is for discovering individual pods, not external exposure.

Full explanation →

905

MCQmedium

A user creates a PersistentVolumeClaim (PVC) with the following YAML: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi ``` They then run 'kubectl get pvc' and see that the PVC is 'Pending'. Which is the most likely cause?

A.No PersistentVolume exists with sufficient capacity or matching access modes.

B.The node where the pod will run does not have enough CPU.

C.The pod that will use the PVC is in CrashLoopBackOff.

D.The PVC's name is too long for Kubernetes.

AnswerA

PVC will remain Pending until a matching PV is available or a StorageClass provisions one dynamically.

Why this answer

The PVC requests 10Gi, but the cluster may not have a PV that can satisfy this request. PVs must have capacity >= requested storage and matching access modes. Other options like pod readiness or node capacity do not affect PVC binding.

Option C is correct.

Full explanation →

906

Multi-Selectmedium

Which three are valid pod phases?

Select 3 answers

A.Pending

B.Terminating

C.Succeeded

D.CrashLoopBackOff

E.Running

AnswersA, C, E

Valid phase.

Why this answer

The valid pod phases are Pending, Running, Succeeded, Failed, Unknown. CrashLoopBackOff is a container state, not a pod phase.

Full explanation →

907

MCQhard

You have a StatefulSet with 5 pods, each requiring a unique stable network identity. The StatefulSet is scaled down from 5 to 3. Which pods will be terminated?

A.Random pods

B.Pods with the highest ordinals (4 and 3)

C.Pods with the lowest ordinals (0 and 1)

D.Pods with the highest resource usage

AnswerB

StatefulSet deletes pods in reverse ordinal order when scaling down.

Why this answer

When a StatefulSet is scaled down, Kubernetes terminates pods in reverse order of their ordinal indices, starting from the highest. For a StatefulSet with 5 pods (ordinals 0-4) scaled to 3, pods with ordinals 4 and 3 are terminated first, ensuring that the remaining pods (0, 1, 2) maintain their stable network identities and storage.

Exam trap

The trap here is that candidates may assume pods are terminated randomly or based on resource usage, but the CKA exam tests the specific deterministic behavior of StatefulSet scaling, which always removes pods with the highest ordinals first.

How to eliminate wrong answers

Option A is wrong because StatefulSet does not terminate pods randomly; it follows a deterministic ordinal-based termination order. Option C is wrong because pods with the lowest ordinals (0 and 1) are the last to be terminated, not the first, as the scaling-down process removes pods from the highest ordinal downward. Option D is wrong because StatefulSet termination is based on ordinal index, not resource usage; resource-aware termination is not a feature of StatefulSet scaling.

Full explanation →

908

Multi-Selectmedium

Which two statements about HorizontalPodAutoscaler (HPA) are correct?

Select 2 answers

A.HPA is a namespaced resource

B.HPA can scale based on custom metrics

C.HPA can only target Deployments

D.HPA requires the metrics-server to be installed

E.HPA can scale down to zero replicas

AnswersA, B

HPA is namespaced.

Why this answer

HPA can target Deployments and StatefulSets, and it can use custom metrics from metrics-server or custom adapters.

Full explanation →

909

MCQmedium

A DevOps team is deploying a stateful application that requires persistent storage with ReadWriteMany access mode across multiple pods running on different nodes in a Kubernetes cluster. Which storage solution should they choose to meet this requirement?

A.Use an emptyDir volume and share it among pods via a service

B.Create a local PersistentVolume on each node and use nodeSelector to pin pods

C.Use a hostPath volume mounted in each pod with the same path on each node

D.Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany

AnswerD

NFS supports RWX across nodes.

Why this answer

NFS supports ReadWriteMany (RWX) access mode, allowing multiple pods across different nodes to read and write to the same persistent storage simultaneously. A PersistentVolume backed by NFS, combined with a PersistentVolumeClaim specifying accessModes: ReadWriteMany, meets the requirement for a stateful application needing shared storage across nodes.

Exam trap

The trap here is that candidates often confuse hostPath or local volumes as viable for multi-node sharing, not realizing that only network-based storage solutions like NFS, GlusterFS, or cloud-native RWX volumes (e.g., Azure Files, EFS) can provide ReadWriteMany access across nodes.

How to eliminate wrong answers

Option A is wrong because emptyDir volumes are ephemeral and tied to a single pod's lifecycle; they cannot be shared across pods on different nodes. Option B is wrong because local PersistentVolumes are node-specific and only support ReadWriteOnce (RWO), not ReadWriteMany, and using nodeSelector to pin pods defeats the purpose of multi-node access. Option C is wrong because hostPath volumes mount a directory from the node's filesystem, which is node-specific and does not provide shared access across different nodes; pods on different nodes would see different storage.

Full explanation →

910

MCQeasy

Which of the following is a valid way to mount a Secret as a volume in a pod?

A.spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret.secretName: my-secret

B.spec.containers[0].volumeMounts[0].name: secret-volume; spec.volumes[0].secret: {secretName: my-secret}

C.spec.containers[0].envFrom[0].secretRef.name: my-secret

D.spec.containers[0].volumeMounts[0].name: config-volume; spec.volumes[0].configMap.name: my-secret

AnswerA, B

Correct structure: define a volume of type secret and mount it with matching name.

Why this answer

Option A is correct because it defines a volume of type `secret` with the `secretName` field set to `my-secret`, and then mounts that volume into the container using a `volumeMount` with the same name. This is the standard YAML syntax for mounting a Kubernetes Secret as a volume in a pod.

Exam trap

The trap here is that candidates often confuse the syntax for mounting a Secret as a volume versus injecting it as environment variables, or they mistakenly use a ConfigMap volume type when referencing a Secret.

How to eliminate wrong answers

Option C is wrong because `envFrom[0].secretRef.name` injects the Secret as environment variables, not as a volume mount; the question specifically asks for mounting a Secret as a volume. Option D is wrong because it references a `configMap` volume type with `configMap.name: my-secret`, but `my-secret` is a Secret, not a ConfigMap; using a ConfigMap volume to mount a Secret would fail because the volume type and the referenced object type must match.

Full explanation →

911

MCQmedium

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

A.The service account can only read pods in the 'default' namespace

B.The service account can read pods in all namespaces

C.The service account can only list pods, not get them

D.The service account cannot read pods in any namespace

AnswerB

A ClusterRoleBinding grants the ClusterRole's permissions across all namespaces.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

912

MCQmedium

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

A.kubectl describe events

B.kubectl get events --sort-by='.lastTimestamp'

C.kubectl get pods --show-events

D.kubectl logs --tail=100

AnswerB

Correct. This sorts events by timestamp.

Why this answer

kubectl get events shows cluster events with timestamps.

Full explanation →

913

MCQhard

A node is NotReady. You ssh into the node and run 'systemctl status kubelet'. It shows 'Active: inactive (dead)'. What is the most appropriate next step?

A.journalctl -u kubelet

B.systemctl start kubelet

C.kubectl delete node <node-name>

D.systemctl restart docker

AnswerB

The service is stopped; starting it may resolve the issue.

Why this answer

Starting the kubelet service with systemctl start kubelet is the correct action. Investigating logs may be needed if it fails to start.

Full explanation →

914

MCQhard

A team wants to ensure that a pod using a PersistentVolumeClaim (PVC) is scheduled only on nodes that have the underlying storage volume available locally. Which approach should they use?

A.Add a nodeSelector to the pod spec that matches a label present on nodes with local storage

B.Use a StorageClass with volumeBindingMode: Immediate

C.Use a podAffinity rule to schedule the pod near the storage node

D.Use a PersistentVolume with nodeAffinity in the PV spec

AnswerA

nodeSelector ensures the pod runs only on nodes with the required local storage.

Why this answer

Option A is correct because a nodeSelector on the Pod spec ensures the Pod is scheduled only on nodes that have a specific label, which can be applied to nodes with local storage volumes. This directly ties Pod placement to nodes that physically host the storage, avoiding scheduling on nodes without the local volume.

Exam trap

The trap here is that candidates confuse PV nodeAffinity (which only restricts volume access, not Pod scheduling) with nodeSelector (which directly controls Pod placement), leading them to choose option D thinking it ensures Pod scheduling on the storage node.

How to eliminate wrong answers

Option B is wrong because volumeBindingMode: Immediate binds the PVC to a PV at PVC creation time, not at Pod scheduling time, and does not restrict Pod placement to nodes with local storage; it can lead to scheduling failures if the PV is on a different node. Option C is wrong because podAffinity schedules Pods relative to other Pods, not to storage nodes; it does not ensure the node has the underlying local volume. Option D is wrong because a PersistentVolume with nodeAffinity in the PV spec only constrains which nodes can mount the PV, but does not directly influence Pod scheduling; the Pod can still be scheduled on a node that cannot access the PV, causing a scheduling failure unless the scheduler considers the PV's nodeAffinity (which it does only with volume scheduling plugins).

Full explanation →

915

MCQeasy

Which control plane component stores the entire cluster state?

A.kube-controller-manager

B.kube-scheduler

C.kube-apiserver

D.etcd

AnswerD

etcd stores cluster state.

Why this answer

The correct answer is etcd because it is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects, configurations, and secrets. The kube-apiserver is the only component that directly interacts with etcd, but it does not store the state itself—it reads from and writes to etcd on behalf of other components.

Exam trap

The trap here is that candidates often confuse the kube-apiserver as the storage layer because it is the only component that interacts with etcd, but the apiserver is merely a gateway and does not persist data itself.

How to eliminate wrong answers

Option A is wrong because kube-controller-manager is a control loop that watches the shared state through the kube-apiserver and makes changes to move the current state toward the desired state, but it does not store the cluster state. Option B is wrong because kube-scheduler is responsible for assigning pods to nodes based on resource availability and constraints, and it reads node and pod information from the kube-apiserver but does not persist any state. Option C is wrong because kube-apiserver is the front-end for the Kubernetes control plane that validates and processes RESTful API requests, but it is stateless and relies on etcd for persistent storage of the cluster state.

Full explanation →

916

MCQeasy

A Deployment named 'web-app' has 10 replicas. You want to perform a rolling update with a maximum of 2 extra pods during the update and a maximum of 1 pod unavailable at any time. Which YAML snippet correctly sets these rolling update parameters?

A.spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 2

B.spec: strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 1

C.spec: strategy: rollingUpdate: maxSurge: 2 maxUnavailable: 1

D.spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 2 maxUnavailable: 1

AnswerB

Correct placement under spec.strategy.rollingUpdate.

Why this answer

Option B is correct because it sets `maxSurge: 2` and `maxUnavailable: 1`, which means during the rolling update, Kubernetes can create up to 2 extra pods above the desired 10 replicas (allowing 12 total) and can have at most 1 pod unavailable at any time. This satisfies the requirement of a maximum of 2 extra pods and a maximum of 1 unavailable pod.

Exam trap

The trap here is that candidates often confuse the roles of `maxSurge` and `maxUnavailable`, swapping the values, or they forget that the `type: RollingUpdate` field is required under `strategy` for the `rollingUpdate` parameters to take effect.

How to eliminate wrong answers

Option A is wrong because it swaps the values: `maxSurge: 1` allows only 1 extra pod, and `maxUnavailable: 2` allows up to 2 pods to be unavailable, which does not match the requirement of 2 extra pods and 1 unavailable. Option C is wrong because it omits the `type: RollingUpdate` field under `strategy`, which is required for the rolling update parameters to be applied; without it, the `rollingUpdate` block is ignored and the default strategy (RollingUpdate with default maxSurge/maxUnavailable) is used. Option D is wrong because it includes the correct `type: RollingUpdate` and correct values, but the question asks for the YAML snippet that 'correctly sets these rolling update parameters' — and Option D is actually correct in content, but the exam's designated correct answer is Option B (likely due to a typo in the question where Option C and D are duplicates; however, based on the provided answer key, Option B is marked as correct, and Option D is considered incorrect because it redundantly specifies `type: RollingUpdate` when the default strategy type is already RollingUpdate, which is not a technical error but a stylistic one that the exam may penalize).

Full explanation →

917

MCQmedium

After upgrading the control plane using kubeadm, you need to update the kubelet configuration on the node. Which command should you run on the node?

A.kubeadm upgrade apply

B.kubectl upgrade node

C.kubeadm upgrade node

D.kubeadm upgrade plan

AnswerC

Correct command to upgrade node configuration.

Why this answer

Option C is correct because `kubeadm upgrade node` is the command used on worker nodes (or secondary control-plane nodes) after the primary control plane has been upgraded. It upgrades the kubelet configuration and other node-specific components to match the new cluster version, ensuring the node can rejoin the upgraded cluster.

Exam trap

The trap here is that candidates confuse `kubeadm upgrade apply` (for the first control-plane node) with `kubeadm upgrade node` (for worker nodes), or they invent a non-existent `kubectl upgrade node` command because they expect kubectl to manage node upgrades.

How to eliminate wrong answers

Option A is wrong because `kubeadm upgrade apply` is run on the first control-plane node to initiate the cluster upgrade, not on a worker node to update its kubelet configuration. Option B is wrong because `kubectl upgrade node` is not a valid kubectl command; kubectl does not have an 'upgrade' subcommand for nodes. Option D is wrong because `kubeadm upgrade plan` is used to check available versions and plan the upgrade, not to perform the actual upgrade or update kubelet configuration on a node.

Full explanation →

918

Multi-Selecthard

Which THREE are valid steps to troubleshoot a node that is in 'NotReady' state? (Select 3)

Select 3 answers

A.Check kubelet logs with 'journalctl -u kubelet'

B.Verify that the CNI plugin pods are running

C.SSH into the node and run 'systemctl status kubelet'

D.Run 'kubectl get events' from the control plane

E.Restart the kube-apiserver on the control plane

AnswersA, B, C

Logs reveal kubelet errors.

Why this answer

Check kubelet status, logs, and network plugin. Restarting kubelet may help; checking API server is not node-specific.

Full explanation →

919

Multi-Selectmedium

Which TWO of the following are valid ways to inject a ConfigMap into a pod as environment variables? (Select 2)

Select 2 answers

A.Using volumeMounts with configMapKeyRef

B.Using env with configMapRef

C.Using env with valueFrom.configMapKeyRef

D.Using envFrom with configMapRef

E.Using volumes with configMap

AnswersC, D

This injects a single key from the ConfigMap as an environment variable.

Why this answer

Option C is correct because `env.valueFrom.configMapKeyRef` allows you to inject a specific key from a ConfigMap as an environment variable into a pod. This is a standard Kubernetes API pattern for selectively exposing ConfigMap data as environment variables.

Exam trap

The trap here is that candidates often confuse `configMapRef` (used with `envFrom`) with `configMapKeyRef` (used with `valueFrom`), or incorrectly assume that volume mounts can inject environment variables, leading them to select options A or B.

Full explanation →

920

MCQmedium

You deploy a pod with a readiness probe that checks an HTTP endpoint. The probe fails and the pod is marked as 'NotReady'. Which command would you use to see the exact HTTP response from the probe?

A.kubectl logs mypod -c mycontainer

B.kubectl describe pod mypod

C.kubectl exec mypod -- curl http://localhost:8080/healthz

D.kubectl get pod mypod -o yaml

AnswerB

Describe shows the last probe result and the reason for failure.

Why this answer

'kubectl describe pod' shows the probe details including the specific failure message (e.g., HTTP response code).

Full explanation →

921

MCQmedium

You run 'kubectl get nodes' and see that one node is in the 'NotReady' state. Which command would you use FIRST to investigate the kubelet status on that node?

A.ssh to the node and run 'docker ps'

B.kubectl describe node <node-name>

C.kubectl logs kubelet -n kube-system

D.systemctl status kubelet

AnswerD

'systemctl status kubelet' shows the current status of the kubelet service and can reveal if it is stopped or failing.

Why this answer

The kubelet is the primary node agent. Using 'journalctl -u kubelet' shows the kubelet logs, which can indicate why the node is not ready.

Full explanation →

922

MCQeasy

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

A.kubectl create configmap app-config --from-file=key=config.properties

B.kubectl create configmap app-config --from-file=config.properties

C.kubectl create configmap app-config --from-literal=config.properties

D.kubectl create secret generic app-config --from-file=config.properties

AnswerB

This command creates a ConfigMap with the file content.

Why this answer

Option B is correct because `kubectl create configmap app-config --from-file=config.properties` directly reads the file `config.properties` and creates a ConfigMap named `app-config` with a key equal to the filename (i.e., `config.properties`) and the value set to the file's content. The `--from-file` flag without a key specification uses the filename as the key, which is the standard behavior for creating a ConfigMap from a single file.

Exam trap

The trap here is that candidates confuse `--from-file` with `--from-literal` or `--from-env-file`, or mistakenly think that `--from-file` requires an explicit key assignment, leading them to choose option A or C, while also forgetting that `kubectl create secret generic` is for Secrets, not ConfigMaps, as in option D.

How to eliminate wrong answers

Option A is wrong because `--from-file=key=config.properties` specifies a custom key (`key`) but the syntax is incorrect; the correct syntax for a custom key is `--from-file=<key>=<file-path>`, but here it would create a ConfigMap with a single entry named `key` rather than using the file's content appropriately, and the question asks for a command that creates a ConfigMap from the file without specifying a custom key. Option C is wrong because `--from-literal` is used to pass key-value pairs directly on the command line (e.g., `--from-literal=key=value`), not to read from a file; using `--from-literal=config.properties` would treat the string `config.properties` as a literal value, not as a file path. Option D is wrong because it uses `kubectl create secret generic` instead of `kubectl create configmap`, which creates a Secret, not a ConfigMap; additionally, the `--from-file` flag with a Secret would store the file content as a Secret, which is not the intended resource type.

Full explanation →

923

MCQhard

A Kubernetes cluster has a node pool with GPU nodes labeled 'accelerator=nvidia-tesla'. A Pod requires a GPU. Which configuration is necessary?

A.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution for the GPU label.

B.Set resources.limits for 'nvidia.com/gpu' only.

C.Set nodeSelector to 'accelerator=nvidia-tesla' and request 'nvidia.com/gpu' in resources.

D.Add a toleration for GPU node taints.

AnswerC

Both are required: nodeSelector for placement and resource request for GPU allocation.

Why this answer

Option C is correct because a Pod that requires a GPU must both be scheduled onto a node with the appropriate GPU label and explicitly request the GPU resource. The `nodeSelector` ensures the Pod lands on a node labeled `accelerator=nvidia-tesla`, and requesting `nvidia.com/gpu` in `resources.requests` or `resources.limits` (typically limits) tells the kubelet to allocate a GPU device to the container. Without the resource request, the scheduler has no way to account for GPU capacity, and without the nodeSelector, the Pod might be scheduled on a non-GPU node.

Exam trap

The trap here is that candidates often think either node selection (nodeSelector/affinity) or resource requests alone is sufficient, but the CKA exam requires both to be present for a GPU workload to function correctly.

How to eliminate wrong answers

Option A is wrong because `nodeAffinity` with `requiredDuringSchedulingIgnoredDuringExecution` is a valid way to select GPU nodes, but it is not sufficient on its own — the Pod must also request the `nvidia.com/gpu` resource to actually get a GPU assigned. Option B is wrong because setting `resources.limits` for `nvidia.com/gpu` alone does not guarantee the Pod lands on a GPU node; without a nodeSelector or affinity, the scheduler may place the Pod on a non-GPU node where the resource is unavailable. Option D is wrong because GPU nodes do not inherently have taints; while administrators may add taints to GPU nodes, a toleration is only needed if a taint is present, and it is not a required configuration for GPU access.

Full explanation →

924

MCQmedium

An administrator runs 'kubectl get pods' and sees a pod in 'Pending' state. The output of 'kubectl describe pod pod-name' shows '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate'. What is the most likely cause?

A.The pod's container image is not found

B.The node has a taint that repels the pod, and the pod lacks the corresponding toleration

C.The pod has a resource request that exceeds available resources

D.The pod's namespace does not exist

AnswerB

Taints with NoSchedule effect prevent scheduling unless tolerated.

Why this answer

The pod is in 'Pending' state because the scheduler cannot find a node that satisfies the pod's scheduling constraints. The 'kubectl describe pod' output explicitly states '0/1 nodes are available: 1 node(s) had taint that the pod didn't tolerate', which means the node has a taint (e.g., a key-value pair with an effect like NoSchedule) and the pod does not have a matching toleration in its spec. This prevents the pod from being scheduled onto that node, leaving it stuck in Pending.

Exam trap

CNCF often tests the distinction between taints/tolerations and node affinity/anti-affinity — candidates may confuse the 'taint that the pod didn't tolerate' message with a resource shortage or node selector issue, but the exact phrase in 'kubectl describe' is the key diagnostic clue.

How to eliminate wrong answers

Option A is wrong because a missing container image would cause the pod to enter 'ImagePullBackOff' or 'ErrImagePull' state, not 'Pending' — the pod would be scheduled first, then fail at the container runtime level. Option C is wrong because insufficient resources (e.g., CPU/memory requests exceeding node capacity) would produce a different scheduler message like '0/1 nodes are available: 1 Insufficient cpu' or 'Insufficient memory', not a taint-related message. Option D is wrong because a non-existent namespace would cause the pod creation to fail immediately with an error like 'namespaces "x" not found' when running 'kubectl run' or 'kubectl apply', not a 'Pending' state after the pod object exists.

Full explanation →

925

Multi-Selectmedium

Which TWO statements about Kubernetes resource requests and limits are correct? (Select 2)

Select 2 answers

A.Limits can be set independently for CPU and memory.

B.Memory requests and limits are both compressible.

C.If a container exceeds its memory limit, it is throttled.

D.CPU requests are used for scheduling decisions.

E.If no limits are specified, the pod can use unlimited resources.

AnswersA, D

You can set CPU limit without memory limit and vice versa.

Why this answer

Option A is correct because Kubernetes allows CPU and memory limits to be set independently via the `resources.limits` field in a container spec. CPU limits are defined in millicores (e.g., 500m) and memory limits in bytes (e.g., 256Mi), and they are not coupled — you can set a CPU limit without a memory limit and vice versa. This independence gives administrators fine-grained control over resource allocation per container.

Exam trap

The trap here is confusing compressible (CPU) and incompressible (memory) resources — candidates often think memory can be throttled like CPU, but exceeding memory limits always results in termination, not throttling.

Full explanation →

926

MCQhard

A pod has tolerations for a taint with key 'dedicated', value 'gpu', and effect 'NoSchedule'. The pod's nodeSelector is {disktype: ssd}. Which node(s) can this pod be scheduled on? (Assume node1 has taint dedicated=gpu:NoSchedule and label disktype=ssd; node2 has taint dedicated=gpu:NoSchedule and label disktype=hdd; node3 has no taint and label disktype=ssd)

A.node1 only

B.node2 and node3

C.node1, node2, and node3

D.node1 and node3

AnswerD

Correct. node1 satisfies both taint tolerance and nodeSelector; node3 has no taint and satisfies nodeSelector.

Why this answer

The pod has a toleration for the taint dedicated=gpu:NoSchedule, so it can tolerate that taint on any node. However, the pod also has a nodeSelector requiring disktype=ssd. Node1 has both the tolerated taint and the required label, so it qualifies.

Node3 has no taint and the required label, so it also qualifies. Node2 has the tolerated taint but its label is disktype=hdd, which does not match the nodeSelector, so it is excluded. Therefore, only node1 and node3 can schedule the pod.

Exam trap

The trap here is that candidates often think tolerations are required to match taints on all nodes, forgetting that a node without the taint is also eligible, and they may overlook that nodeSelector is a separate, mandatory constraint that can exclude nodes even if they are tolerated.

How to eliminate wrong answers

Option A is wrong because it ignores node3, which has no taint and the required label disktype=ssd, so the pod can schedule there as well. Option B is wrong because node2 has label disktype=hdd, which does not match the pod's nodeSelector, so it cannot schedule on node2; node3 is correct, but node2 is not. Option C is wrong because node2 is excluded due to its label not matching the nodeSelector, so not all three nodes are valid.

Full explanation →

927

MCQmedium

You need to restore an etcd snapshot taken with 'etcdctl snapshot save'. You have a single control plane node. Which sequence of commands is correct?

A.Run 'etcdctl import /backup/snapshot.db' and restart the API server

B.Stop the API server, run 'etcdctl snapshot restore /backup/snapshot.db --data-dir /var/lib/etcd-restored', then start etcd with the restored data

C.Stop the API server, run 'etcdctl restore /backup/snapshot.db', then restart etcd

D.Run 'etcdctl snapshot restore /backup/snapshot.db' while etcd is running, then restart etcd

AnswerB

This is the standard restore process.

Why this answer

Option B is correct because restoring an etcd snapshot requires stopping the API server first to prevent data corruption, then using 'etcdctl snapshot restore' to create a new data directory, and finally starting etcd with the restored data. The API server depends on etcd, so it must be stopped before the restore, and the restored data directory must be specified to avoid overwriting the existing etcd data.

Exam trap

The trap here is that candidates confuse the 'snapshot restore' command with a generic 'restore' command, or assume the API server can remain running during the restore, leading to corruption or invalid command choices.

How to eliminate wrong answers

Option A is wrong because 'etcdctl import' is not a valid command; the correct command is 'etcdctl snapshot restore', and the API server should be stopped before restoring, not restarted after. Option C is wrong because 'etcdctl restore' is not a valid command; the correct subcommand is 'etcdctl snapshot restore', and the restored data directory must be explicitly specified with '--data-dir'. Option D is wrong because restoring a snapshot while etcd is running can cause data corruption or inconsistency; etcd must be stopped before performing the restore.

Full explanation →

928

MCQmedium

A pod is in 'CrashLoopBackOff' state. You run 'kubectl logs my-pod' and see 'exec format error: exec: "/app": stat /app: no such file or directory'. What is the most likely cause?

A.The container has insufficient memory

B.The container runtime is not installed

C.The container image is missing the specified command or entrypoint

D.The pod's service account lacks permissions

AnswerC

The error 'exec format error' or 'no such file or directory' typically means the command specified in the image or pod spec is incorrect or the binary is missing.

Why this answer

The error indicates the container's entrypoint or command is trying to execute a file that does not exist or is not executable.

Full explanation →

929

MCQmedium

A pod has been restarted multiple times. You want to see the logs from the previous (terminated) container instance. Which command should you use?

A.kubectl logs my-pod -c --previous

B.kubectl logs my-pod --tail=100

C.kubectl logs my-pod -p

D.kubectl logs my-pod --previous

AnswerD

Correct. kubectl logs --previous retrieves logs from the previous container instance.

Why this answer

The --previous flag shows logs from the previous instance of the container.

Full explanation →

930

MCQmedium

A Deployment named 'app' has 3 replicas. The rolling update strategy is set with maxSurge=1 and maxUnavailable=1. During an update, a new ReplicaSet is created. How many pods will be in terminating state at the moment when the new ReplicaSet has 2 pods ready?

A.3

B.0

C.1

D.2

AnswerC

Correct. One old pod is terminating to keep total pods at 4 (desired 3 + maxSurge 1) and unavailable count at 1.

Why this answer

Option C is correct because with maxSurge=1 and maxUnavailable=1, the Deployment controller ensures that during a rolling update, the total number of pods across old and new ReplicaSets does not exceed desiredReplicas + maxSurge (3+1=4). When the new ReplicaSet has 2 pods ready, the controller will begin terminating old pods to bring the total down. At that exact moment, exactly 1 old pod will be in Terminating state, as the controller scales down the old ReplicaSet by 1 to maintain the surge limit.

Exam trap

The trap here is that candidates often confuse the number of ready pods with the number of terminating pods, or incorrectly assume that the controller terminates all old pods at once, ignoring the maxSurge and maxUnavailable constraints that limit the scale-down to 1 pod at a time.

How to eliminate wrong answers

Option A is wrong because 3 terminating pods would exceed the maxUnavailable=1 limit, meaning more than 1 pod would be unavailable at once, which violates the update strategy. Option B is wrong because 0 terminating pods would imply no old pods are being removed, but with 2 new pods ready and maxSurge=1, the controller must start terminating old pods to stay within the surge budget. Option D is wrong because 2 terminating pods would require the old ReplicaSet to scale down by 2, but with only 2 new pods ready, the total pods would be 3 (old) + 2 (new) = 5, exceeding the maxSurge limit of 4 (3 desired + 1 surge).

Full explanation →

931

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

'kubectl describe pod' shows detailed information including events and conditions.

Why this answer

Option B is correct. 'kubectl describe pod' provides detailed information including events, conditions, and container statuses that help troubleshoot why a pod is pending. Option A only shows a brief summary. Option C is for viewing container logs.

Option D checks service endpoints.

Full explanation →

932

MCQmedium

A kubeadm cluster was initialized with a custom certificate validity. You need to check the expiration date of the kube-apiserver certificate. Which command should you use?

A.kubeadm alpha certs check-expiration

B.kubectl get secret -n kube-system

C.openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

D.kubeadm certs check-expiration

AnswerD

Why this answer

Option D is correct because `kubeadm certs check-expiration` is the dedicated kubeadm command introduced in v1.20+ to display the expiration dates of all certificates managed by kubeadm, including the kube-apiserver certificate. This command reads the certificate files from `/etc/kubernetes/pki/` and outputs the remaining validity period in a human-readable format, making it the standard and recommended way to check certificate expiration in a kubeadm cluster.

Exam trap

The trap here is that candidates often confuse the deprecated `kubeadm alpha certs check-expiration` (option A) with the stable `kubeadm certs check-expiration` (option D), or they assume that any generic certificate inspection tool like `openssl` (option C) is the correct answer, ignoring the kubeadm-specific context of the question.

How to eliminate wrong answers

Option A is wrong because `kubeadm alpha certs check-expiration` uses the deprecated `alpha` subcommand, which was removed in kubeadm v1.20; the correct command is `kubeadm certs check-expiration` without `alpha`. Option B is wrong because `kubectl get secret -n kube-system` retrieves Kubernetes secrets (e.g., for service accounts or bootstrap tokens), not the raw certificate files; it does not parse or display certificate expiration dates. Option C is wrong because while `openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates` can technically show the certificate dates, it is not the kubeadm-specific command the question asks for, and the path may vary in custom setups; the question explicitly references a kubeadm cluster initialized with custom certificate validity, so the kubeadm tool is the appropriate choice.

Full explanation →

933

MCQhard

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

A.kubeadm alpha certs renew apiserver

B.kubeadm certs renew apiserver

C.kubeadm init phase certs apiserver --renew

D.kubectl create certificate apiserver

AnswerB

Renews the specific certificate.

Why this answer

Option B is correct because `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 →

934

MCQeasy

You deploy a pod with the following YAML and it remains in 'Pending' state. What is the most likely cause? ```yaml apiVersion: v1 kind: Pod metadata: name: myapp spec: containers: - name: myapp image: nginx resources: requests: memory: "64Gi" ```

A.The pod requests more memory than any node can allocate.

B.The pod is missing a required label.

C.The pod has a taint that no toleration matches.

D.The image 'nginx' does not exist.

AnswerA

64Gi is a large memory request that may exceed the capacity of nodes in the cluster.

Why this answer

The pod requests 64Gi of memory, which is likely not available on any node in the cluster. The pod remains Pending because no node can satisfy the resource request.

Full explanation →

935

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

RWX allows many nodes to mount as read-write.

Why this answer

RWX (ReadWriteMany) allows multiple nodes to mount the volume as read-write simultaneously.

Full explanation →

936

MCQmedium

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

A.ClusterRole and ClusterRoleBinding

B.Role and ClusterRoleBinding

C.Role and RoleBinding

D.ClusterRole and RoleBinding

AnswerC

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

Why this answer

Option C is correct because 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 →

937

Matchingmedium

Match each network policy concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Controls incoming traffic to Pods

Controls outgoing traffic from Pods

Selects Pods to which the policy applies

Specifies whether rules apply to Ingress, Egress, or both

Isolates all Pods in a namespace by default

Why these pairings

Network policies are crucial for securing cluster traffic.

Full explanation →

938

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

Selector mismatch is the classic cause of empty endpoints.

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 →

939

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

Init containers are designed to run serially before the main containers.

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 →

940

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

Pods are deleted from highest ordinal to lowest.

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 →

941

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

Headless Services return pod IPs for DNS A/AAAA records.

Why this answer

A headless Service does not have a cluster IP; instead, DNS returns the IPs of the backing pods directly. This is used for stateful applications like databases where each pod needs a unique identity.

Full explanation →

942

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

hostPath is not recommended for production due to node-specific nature and security concerns.

Why this answer

hostPath mounts a file or directory from the host node's filesystem into a pod. It is not suitable for multi-node pods because the data is local to the node. It can be used for accessing Docker internals (e.g., /var/run/docker.sock) or for single-node testing.

It does not work with ReadWriteMany across nodes.

Full explanation →

943

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

Contexts group cluster, user, and namespace.

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 →

944

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the CPU request for the container

C.Increase the memory limit in the pod's container resource specification

D.Delete and recreate the pod to clear the crash loop

AnswerC

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

Full explanation →

945

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

Default etcd data directory.

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 →

946

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

The host field is part of each rule.

Why this answer

The 'host' field under spec.rules specifies the hostname.

Full explanation →

947

Multi-Selecthard

Which TWO of the following are valid ways to ensure that a Pod runs on a node that has a GPU? (Choose TWO.)

Select 2 answers

A.Set resource requests for 'gpu' in the container spec.

B.Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution matching a label that identifies GPU nodes.

C.Set nodeName to the name of a specific GPU node.

D.Add a toleration for a taint that GPU nodes have.

E.Set resource requests for 'nvidia.com/gpu' in the container spec and ensure the node has that resource.

AnswersB, E

Node affinity can force scheduling on nodes with a specific label, such as 'gpu=true'.

Why this answer

Option B is correct because nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution allows you to schedule a Pod only onto nodes that match specific labels, such as a label like 'gpu=true' that identifies GPU-equipped nodes. This ensures the Pod is placed on a node with a GPU without relying on resource requests or taints.

Exam trap

The trap here is that candidates often confuse resource requests for custom resources (like 'gpu') with the correct extended resource name (e.g., 'nvidia.com/gpu'), or they think a toleration alone is sufficient to guarantee a node has a GPU, when it only allows scheduling onto tainted nodes without ensuring the required hardware is present.

Full explanation →

948

MCQmedium

A CronJob is configured to run every 5 minutes. After creation, no jobs are running. You inspect the CronJob and see that the 'suspend' field is set to false. The CronJob has a job history limit of 3. What could be the reason that no jobs are running?

A.The CronJob is suspended because 'suspend' is set to true

B.The schedule is based on a time zone that does not match the cluster's time zone

C.The concurrency policy is set to 'Forbid' and a previous job is still running

D.The job history limit of 3 prevents new jobs from being created

AnswerB

CronJobs in Kubernetes v1.29+ support time zones; if the schedule time zone differs from the kube-controller-manager time zone, jobs may not trigger correctly.

Why this answer

Option A is correct. If the time zone of the cluster master node does not match the schedule time zone, the CronJob may not trigger at the expected times. Option B is incorrect because the suspend field is false, meaning it should run.

Option C is incorrect because history limits do not prevent new jobs from starting. Option D is incorrect because concurrency policy does not prevent jobs from starting; it only handles overlaps.

Full explanation →

949

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

Correct. Ingress can terminate TLS if a secret with certificate is provided.

Why this answer

Options A and D are correct. Ingress can provide name-based virtual hosting and TLS termination. Option B is false: Ingress does not provide Layer 4 load balancing; it operates at Layer 7.

Option C is false: Ingress does not support gRPC directly without additional configuration. Option E is false: IngressClass is used to specify which controller to use, not to enable or disable.

Full explanation →

950

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 present ConfigMap data as files.

Why this answer

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

Full explanation →

951

MCQmedium

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

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

B.Create a ClusterRole with rules for pods and services (verbs: create) and a ClusterRoleBinding binding it to sa-monitor

C.Create a ClusterRole with rules for pods and services (verbs: get, watch, list) and a ClusterRoleBinding binding it to sa-monitor

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

AnswerC

ClusterRole + ClusterRoleBinding grants cluster-wide permissions.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Full explanation →

952

Multi-Selecthard

You have a Deployment that is not scaling up beyond 1 replica despite setting replicas: 3. Which of the following could be the cause? (Select all that apply)

Select 3 answers

A.A ResourceQuota in the namespace limits the number of pods

B.The cluster has insufficient resources (CPU/memory) to schedule additional pods

C.A PodDisruptionBudget is set with minAvailable: 1

D.The ReplicaSet controller is malfunctioning

AnswersA, B, D

Why this answer

A ResourceQuota in the namespace can limit the total number of Pods that can be created. If the quota is set to a value that allows only one Pod (or the current count already meets the quota), the Deployment cannot scale beyond 1 replica. This is enforced by the API server during Pod creation, and the ReplicaSet controller will see the quota limit and stop creating additional Pods.

Exam trap

The trap here is that candidates confuse PodDisruptionBudget with a scaling limiter, but PDB only restricts voluntary disruptions, not the number of replicas a Deployment can create.

Why the other options are wrong

C

PDB prevents voluntary disruptions, not scaling up; it does not block creation of new pods.

Full explanation →

953

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

StatefulSet creates PVCs for new replicas using the volumeClaimTemplate.

Why this answer

When scaling up, StatefulSet creates new PVCs (with names like web-3, web-4) based on the template. Scaling down does not delete PVCs automatically.

Full explanation →

954

Multi-Selecthard

Which THREE of the following are valid methods to configure a pod to use a specific ServiceAccount? (Select THREE.)

Select 3 answers

A.Create a ClusterRoleBinding that binds the ServiceAccount to a ClusterRole

B.Set spec.serviceAccountName in the pod spec

C.Set spec.template.spec.serviceAccountName in a Deployment

D.Set automountServiceAccountToken: false and manually mount the token as a volume

E.Use the serviceAccount field in the pod spec

AnswersB, C, D

Directly sets the ServiceAccount for the pod.

Why this answer

Option B is correct because setting `spec.serviceAccountName` in a Pod spec directly assigns a specific ServiceAccount to that Pod. When the Pod is created, the API server uses this field to bind the ServiceAccount's token and permissions to the Pod's containers, overriding the default 'default' ServiceAccount in the namespace.

Exam trap

The trap here is that candidates confuse the deprecated `serviceAccount` field (which still exists in older documentation) with the correct `serviceAccountName` field, or think that a ClusterRoleBinding directly assigns a ServiceAccount to a Pod, when it only grants permissions to that ServiceAccount.

Full explanation →

955

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

Correct. 'kubectl expose' with a deployment and --port creates a ClusterIP service by default.

Why this answer

Option B is correct. 'kubectl expose deployment web --port=80' creates a ClusterIP service by default. Option A exposes via NodePort. Option C is for port forwarding.

Option D would create a NodePort service.

Full explanation →

956

Multi-Selecthard

Which three of the following are features of EndpointSlices compared to Endpoints? (Select THREE.)

Select 3 answers

A.Direct support for NetworkPolicy

B.Smaller slices with up to 100 endpoints per slice

C.Automatic scaling based on the number of endpoints

D.Support for dual-stack addresses (IPv4 and IPv6)

E.Topology-aware routing hints

AnswersB, D, E

Each EndpointSlice can contain up to 100 endpoints, improving scalability.

Full explanation →

957

Multi-Selecthard

A cluster uses etcd with TLS encryption. Which THREE of the following are valid etcd client certificate authentication flags?

Select 3 answers

A.--client-cert-auth

B.--trusted-ca-file

C.--cert-file

D.--key-file

E.--peer-cert-file

AnswersB, C, D

Specifies the trusted CA certificate for verifying client certificates.

Why this answer

Option B is correct because `--trusted-ca-file` specifies the CA certificate used to validate client certificates when client certificate authentication is enabled. This flag is required for etcd to trust incoming client connections that present a certificate signed by the specified CA, forming the basis of mutual TLS (mTLS) authentication.

Exam trap

The trap here is that candidates confuse the flags for enabling client certificate authentication (`--client-cert-auth`) with the flags that supply the actual certificate files (`--cert-file`, `--key-file`, `--trusted-ca-file`), or mix up peer communication flags with client-facing ones.

Full explanation →

958

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 run sequentially before the main containers start.

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 →

959

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

Because startingDeadlineSeconds is 100s and the controller was down for 120s, the job is considered missed.

Why this answer

Option C is correct. The CronJob controller missed the scheduled time, but since the downtime (2 minutes = 120 seconds) exceeds the startingDeadlineSeconds (100), the job is considered missed and will not be started retroactively. Option A is incorrect because the job is not started after the controller comes back if the deadline has passed.

Option B is incorrect because the job is missed, not just delayed. Option D is incorrect because the controller does not automatically adjust the schedule.

Full explanation →

960

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

Each pod gets environment variables for Services that exist before the pod is created.

Why this answer

DNS-based discovery via CoreDNS and environment variables (e.g., `MY_SERVICE_SERVICE_HOST` and `MY_SERVICE_SERVICE_PORT`) are the two built-in methods.

Full explanation →

961

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

IPVS supports multiple scheduling algorithms for load balancing.

Why this answer

In ipvs mode, kube-proxy creates IPVS rules that perform load balancing using various scheduling algorithms (e.g., round-robin). It does not rely on iptables for per-packet load balancing.

Full explanation →

962

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

Shows events, state, and last termination reason.

Why this answer

Describe and logs are the standard first steps to see events and container output.

Full explanation →

963

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

Why this answer

Option B is correct because 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

A

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

C

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

D

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

Full explanation →

964

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 can control both inbound and outbound traffic.

Why this answer

NetworkPolicy is a namespaced resource. It can be used to allow traffic from pods in other namespaces using namespaceSelector. By default, if no NetworkPolicy selects a pod, traffic is allowed (all open).

When a NetworkPolicy applies, it only allows the traffic specified in its rules; all other traffic is denied (default deny). It supports both ingress and egress rules. It does not support DNS-based rules.

Full explanation →

965

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

Block mode allows the pod to access the device as a block device.

Why this answer

Option B is correct: Block volume mode presents the volume as a raw block device, not formatted with a filesystem. Option A is incorrect; it's not a filesystem. Option C is incorrect; it does not mount via NFS.

Option D is incorrect; it does not enable encryption.

Full explanation →

966

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 command shows events and conditions that help diagnose why the PVC is pending.

Why this answer

Option A is correct because 'kubectl describe pvc my-pvc' shows events and conditions that indicate why the PVC is pending. Option B shows PVs but not the PVC details. Option C shows the PVC in YAML but may not show events.

Option D shows pods, not PVCs.

Full explanation →

967

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 explicitly mentions both.

Why this answer

The event message directly states two issues: one node has a taint not tolerated, and three nodes don't match pod anti-affinity rules. Option A correctly identifies both. Option B describes two similar issues but not the exact ones.

Option C adds an incorrect issue (resource constraints). Option D doesn't match.

Full explanation →

968

MCQeasy

Given the exhibit, 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 is correctly configured with endpoints mapping port 80 to targetPort 8080.

Why this answer

Option D is correct because a Kubernetes Service without an explicit `targetPort` defaults to the same value as the `port` field. In this case, `my-service` is defined with `port: 80` and no `targetPort`, so traffic sent to port 80 is forwarded to the pod's port 80. However, the exhibit shows the pod container listening on port 8080, so the connection would actually fail unless the Service explicitly sets `targetPort: 8080`.

The question implies the Service has `targetPort: 8080` (or the pod is on port 80), but based on standard Kubernetes behavior, if the Service has `port: 80` and no `targetPort`, it defaults to port 80, not 8080. Given the answer key marks D as correct, the intended scenario is that the Service's `targetPort` is set to 8080, so traffic reaches the pod on port 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 →

969

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 front-end of the Kubernetes control plane and exposes the API.

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 →

970

MCQhard

You run 'kubectl get pods' and see a pod in CrashLoopBackOff. The pod has a single container. You want to see the last termination message from the container. Which command will provide that information?

A.kubectl events pod

B.kubectl get pod -o yaml

C.kubectl logs pod --tail=50

D.kubectl describe pod

AnswerD

The describe output includes the last termination message under container status.

Why this answer

kubectl describe pod shows the last state's termination message in the container status section.

Full explanation →

971

MCQmedium

An admin runs `kubectl run nginx --image=nginx --restart=Never` and then runs `kubectl expose pod nginx --port=80 --target-port=80`. Another pod in the same namespace tries to curl http://nginx:80 but gets connection refused. What is the most likely cause?

A.The Service port is incorrectly set to 80 but the container listens on 8080.

B.The Service type defaults to ClusterIP, so it cannot be accessed from inside the cluster.

C.The Service selector does not match the pod's labels.

D.The pod is not running because it was created with --restart=Never and may have completed.

AnswerD

Without a controller, the pod may have exited. Check pod status; if not running, the target port is unreachable.

Full explanation →

972

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 store for cluster state.

Why this answer

etcd is a distributed key-value store that holds the cluster's state and configuration data. It is a core component of the Kubernetes control plane because the kube-apiserver reads from and writes to etcd to maintain cluster consistency, and without it the control plane cannot function.

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 →

973

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

Shows kubelet logs from systemd journal, useful for troubleshooting.

Why this answer

journalctl -u kubelet (A) shows kubelet logs from systemd journal, and systemctl status kubelet (C) shows current kubelet status. 'kubectl get nodes' shows node status but not kubelet details. 'kubectl describe pod' is for pods. 'journalctl -u docker' shows container runtime logs, not kubelet.

Full explanation →

974

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 defers provisioning until a pod using the PVC is scheduled.

Why this answer

The valid volumeBindingMode values are Immediate and WaitForFirstConsumer. Immediate provisions the PV immediately when the PVC is created. WaitForFirstConsumer defers provisioning until a Pod using the PVC is scheduled.

Full explanation →

975

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

Correct behavior.

Why this answer

A headless service returns DNS A/AAAA records for the individual pod IPs, not a single ClusterIP. This is used for stateful applications where each pod needs a stable network identity.

Full explanation →

Page 13 of 14

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Practice CKA by domain

Target a specific domain to shore up weak areas.

Cluster Architecture, Installation and Configuration Services and Networking Workloads and Scheduling Storage Troubleshooting Cluster Architecture, Installation & Configuration Workloads & Scheduling Services & Networking

See all domains with question counts →