CKA Practice Test 47 — 15 Questions

Question 1

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

Accepted Answer

Environment variables injected into pods. Option A is correct because Kubernetes automatically injects environment variables (e.g., _SERVICE_HOST and _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.

Answer

Manual /etc/hosts entries

Answer

Consul agent running as a sidecar

Answer

Using kubectl get endpoints

Question 2

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

Accepted Answer

Ingress resource. An Ingress resource (A) exposes HTTP/HTTPS routes from outside the cluster to Services inside the cluster, acting as a layer-7 entry point with rules and TLS termination, so it can publish a set of pods to the internet. A Service of type NodePort (B) exposes the Service on each node's IP at a static port (default range 30000-32767), making the pods reachable externally via any node IP and that port. A Service of type LoadBalancer (C) provisions an external load balancer (e.g., via a cloud provider) that routes internet traffic to the Service's endpoints, directly exposing the pods externally. A headless Service (D) sets clusterIP: None and returns pod IPs directly via DNS for direct pod addressing, but it does not provide an external entry point. A Service of type ClusterIP (E) only assigns a virtual IP reachable within the cluster, so it is not externally accessible without additional components like Ingress or NodePort.

Answer

Service of type Headless

Answer

Service of type ClusterIP

Question 3

Which two of the following are correct statements about EndpointSlices?

Accepted Answer

EndpointSlices are automatically created by the EndpointSlice controller.. Option C is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have a selector, keeping them in sync with the matching Pods. Option E is correct because each EndpointSlice is limited to a default maximum of 100 endpoints, a value controlled by the --max-endpoints-per-slice flag on the kube-controller-manager, which improves scalability and reduces update churn compared to the single Endpoints object. Option A is wrong because EndpointSlices back Services of all types with selectors (ClusterIP, NodePort, LoadBalancer, and headless), not only LoadBalancer. Option B is wrong because EndpointSlices do not entirely replace the Endpoints resource; the legacy Endpoints API still exists and is maintained for compatibility, with EndpointSlices serving as the more scalable alternative. Option D is wrong because EndpointSlices graduated to stable (GA) in Kubernetes 1.21, so they are no longer an alpha feature requiring a feature gate.

Answer

EndpointSlices are only used for services of type LoadBalancer.

Answer

EndpointSlices replace the Endpoints resource entirely.

Answer

EndpointSlices are an alpha feature and must be enabled via feature gate.

Question 4

Which TWO statements about Headless services are correct? (Select TWO)

Accepted Answer

DNS queries for a headless service return the IP addresses of the backing pods. Option E is correct because a headless service is defined by explicitly setting the spec.clusterIP field to "None" in the Service manifest, which tells Kubernetes not to allocate a virtual IP. Option D is correct because, with no ClusterIP, kube-dns/CoreDNS resolves the service name directly to the individual pod IPs (A/AAAA records) of the endpoints rather than to a single service VIP. Options A and B are wrong because a headless service has no ClusterIP and therefore no kube-proxy VIP-based round-robin load balancing; clients connect directly to pod IPs. Option C is wrong because a headless service does not strictly require a selector — a selectorless headless service is valid and is commonly used with manually managed Endpoints or EndpointSlices.

Answer

A headless service assigns a ClusterIP to the service

Answer

Headless services provide round-robin load balancing across pods

Answer

Headless services require a selector that matches at least one pod

Question 5

Which TWO statements about EndpointSlices are true? (Choose 2)

Accepted Answer

EndpointSlices are automatically created and managed by the EndpointSlice controller. Option B is correct because the EndpointSlice controller in the Kubernetes control plane (kube-controller-manager) automatically creates and manages EndpointSlice objects for Services that have selectors, keeping them in sync with the matching Pods. Option D is correct because EndpointSlices natively support dual-stack networking by including an addressType field (IPv4, IPv6, or FQDN) and can represent endpoints of both IP families for a Service. Option A is wrong because EndpointSlices back Services of any type that use selectors, including ClusterIP, NodePort, and LoadBalancer, not just ClusterIP. Option C is wrong because EndpointSlices were introduced as an alpha feature in Kubernetes 1.16 and became GA in 1.21; older versions still rely solely on Endpoints, so they do not replace Endpoints in all versions. Option E is wrong because the default maximum is 100 endpoints per EndpointSlice, but this is a configurable limit (via --max-endpoints-per-slice on the controller manager), so stating a fixed cap of 100 as an absolute truth is inaccurate.

Answer

EndpointSlices are only used for Services of type ClusterIP

Answer

EndpointSlices replace Endpoints in all Kubernetes versions

Answer

EndpointSlices can contain up to 100 endpoints each

Question 6

Which THREE of the following are valid methods for service discovery in Kubernetes?

Accepted Answer

Environment variables (e.g., SERVICE_NAME_SERVICE_HOST). Environment variables (B) are a valid service-discovery mechanism because kubelet injects variables such as SERVICE_NAME_SERVICE_HOST and SERVICE_NAME_SERVICE_PORT for each Service into Pods at creation time, letting containers locate dependencies without an external registry. DNS lookups using CoreDNS (D) are the canonical discovery method: CoreDNS serves records like ..svc.cluster.local and SRV records for named ports, resolving Service ClusterIPs and headless endpoints. Kubernetes API queries (E) are valid because clients can list/watch Service and Endpoints/EndpointSlice objects via kubectl or direct API calls to discover backends dynamically. kubectl port-forward (A) merely tunnels a local port to a Pod or Service for debugging and does not provide in-cluster discovery, while Ingress rules (C) only expose HTTP/HTTPS routes from outside the cluster and are not a discovery mechanism for workloads.

Answer

kubectl port-forward

Answer

Ingress rules

Question 7

Which TWO of the following statements about StorageClass are correct? (Select two.)

Accepted Answer

A StorageClass can be used for dynamic provisioning of PersistentVolumes.. Option D is correct because a StorageClass defines a provisioner (for example, kubernetes.io/aws-ebs or a CSI driver) that Kubernetes uses to dynamically provision PersistentVolumes when a PersistentVolumeClaim requests that class, so it is the standard mechanism for dynamic provisioning. Option E is correct because StorageClass supports the volumeBindingMode field, whose valid values are Immediate and WaitForFirstConsumer; WaitForFirstConsumer delays binding until a Pod using the PVC is scheduled, which is essential for topology-aware volumes. Option A is wrong because 'kubernetes.io/no-provisioner' is only used for the special case of local static volumes, not a general requirement for static provisioning, and static PVs are typically matched to PVCs by capacity, access modes, and selector rather than by a no-provisioner StorageClass. Option B is wrong because StorageClass is a cluster-scoped resource, not namespaced. Option C is wrong because the default reclaimPolicy for a dynamically provisioned volume is Delete, not Retain.

Answer

A StorageClass must have a provisioner field set to 'kubernetes.io/no-provisioner' to use static provisioning.

Answer

A StorageClass is a namespaced resource.

Answer

The reclaimPolicy in a StorageClass defaults to Retain.

Question 8

Which THREE of the following are common causes for a pod to remain in 'Pending' state?

Accepted Answer

Node taints that the pod does not tolerate. A pod stays in Pending when the Kubernetes scheduler cannot place it on any node, and node taints that the pod does not tolerate (option A) cause the scheduler to filter out those nodes, leaving the pod unscheduled. Insufficient CPU or memory resources on any node (option D) is a classic scheduling failure: the scheduler's resource-fit predicate rejects every node, so the pod remains Pending. A PersistentVolumeClaim that is not bound (option E) also blocks scheduling, because a pod referencing an unbound PVC cannot be assigned to a node until the volume is provisioned and bound. By contrast, Image pull backoff (option B) occurs after scheduling, when the kubelet cannot pull the image, so the pod is in Waiting/ContainerCreating rather than Pending. Container OOMKilled (option C) is a runtime termination state that happens after the container starts, so it does not cause a Pending pod.

Answer

Image pull backoff

Answer

Container OOMKilled

Question 9

Which TWO statements are true about Ingress in Kubernetes?

Accepted Answer

Ingress can terminate TLS connections. 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.

Answer

IngressClass is a mandatory field in Ingress spec

Answer

Ingress is the only way to expose Services externally

Answer

Ingress works without an Ingress controller

Question 10

Which THREE statements about PersistentVolumeClaims (PVCs) are correct?

Accepted Answer

A PVC binds to a PersistentVolume that satisfies its storage request and access modes.. Option B is correct because the PersistentVolume controller matches a PVC to a PV whose capacity meets or exceeds the PVC's spec.resources.requests.storage and whose access modes (e.g., ReadWriteOnce, ReadWriteMany) satisfy the PVC's spec.accessModes, then binds them. Option C is correct because a PVC can request a larger size by editing spec.resources.requests.storage, and the resize succeeds only if the bound StorageClass has allowVolumeExpansion: true and the underlying CSI driver supports expansion. Option E is correct because access modes are enforced by the PV/PVC binding: a PVC requesting ReadWriteMany that binds to a PV supporting ReadWriteMany can be mounted read-write by multiple Pods simultaneously (e.g., NFS or CephFS). Option A is wrong because the reclaim policy (Retain, Delete, Recycle) is defined on the PersistentVolume or inherited from the StorageClass, not on the PVC. Option D is wrong because a PVC is a namespaced resource, unlike the cluster-scoped PersistentVolume.

Answer

A PVC defines the reclaim policy for the underlying PersistentVolume.

Answer

A PVC is a cluster-scoped resource.

Question 11

Which TWO of the following are valid access modes for a PersistentVolume in Kubernetes? (Select two.)

Accepted Answer

ReadWriteOnce. ReadWriteOnce (C) is a valid PersistentVolume access mode, meaning the volume can be mounted as read-write by a single node at a time. ReadWriteMany (D) is also valid, allowing the volume to be mounted as read-write by many nodes simultaneously. These are two of the four standard Kubernetes access modes, alongside ReadOnlyMany and ReadWriteOncePod. WriteMany (A) is not a valid mode because the read/write distinction is missing. ReadOnlySingle (B) is invalid since the correct read-only mode is ReadOnlyMany. ReadWriteOncePerNode (E) is not a real access mode; the per-node semantics are already covered by ReadWriteOnce.

Answer

WriteMany

Answer

ReadOnlySingle

Answer

ReadWriteOncePerNode

Question 12

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

Accepted Answer

It is recommended for testing and development only. 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.

Answer

It supports ReadWriteMany access mode across multiple nodes

Answer

It is suitable for production workloads that require persistence across nodes

Question 13

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

Accepted Answer

WaitForFirstConsumer. 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.

Answer

Lazy

Answer

OnDemand

Answer

Deferred

Question 14

You run 'kubectl get pods' and see that a pod is in CrashLoopBackOff. Which THREE of the following are valid next steps? (Select 3)

Accepted Answer

Run 'kubectl describe pod pod-name' to check events. Option A is correct because 'kubectl describe pod pod-name' surfaces the pod's Events section, which shows why the kubelet restarted the container (e.g., OOMKilled, failed liveness probe, image pull issues) and the backoff timing. Option B is correct because 'kubectl logs pod-name' retrieves the container's stdout/stderr, which typically contains the application error that caused the process to exit and enter CrashLoopBackOff; adding --previous shows logs from the prior crashed instance. Option C is correct because the jsonpath query reads .status.containerStatuses[0].state.waiting.reason, which directly returns the waiting reason such as CrashLoopBackOff along with the last termination state, confirming the container's current status. Option D is not appropriate because 'kubectl top pod' only reports live CPU/memory usage from the metrics server and does not explain why the container is crash-looping. Option E is not a valid diagnostic step because deleting the pod merely recreates it (or removes it if managed by a controller) without revealing the root cause, so it does not help troubleshoot the failure.

Answer

Run 'kubectl top pod pod-name'

Answer

Run 'kubectl delete pod pod-name'

Question 15

Which TWO of the following are required fields in a PersistentVolumeClaim spec? (Select TWO)

Accepted Answer

accessModes. Option C (accessModes) is correct because a PersistentVolumeClaim must declare how the volume will be mounted (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany), and this field is mandatory in the PVC spec. Option E (resources.requests.storage) is correct because the claim must specify the amount of storage it requests (e.g., 5Gi), which the control plane uses to bind a matching PersistentVolume. Option A (storageClassName) is not required since it can be omitted, in which case the default StorageClass is used or binding falls back to matching without a class. Option B (selector) is optional and only used to further constrain which PersistentVolumes can satisfy the claim via label matching. Option D (volumeMode) is optional and defaults to Filesystem when not specified.

Answer

storageClassName

Answer

selector

Answer

volumeMode