CKA Practice Test 46 — 15 Questions

Question 1

Which THREE of the following are valid taint effects that can be applied to a node? (Select 3)

Accepted Answer

NoSchedule. In Kubernetes, taints are applied to nodes with a taint effect that determines how the scheduler and kubelet react to pods lacking a matching toleration. Option C, NoSchedule, is correct because it instructs the scheduler to avoid placing new pods on the node unless they tolerate the taint, while existing pods remain running. Option D, PreferNoSchedule, is correct because it is a soft preference: the scheduler tries to avoid the node but may still place pods there if no better option exists. Option E, NoExecute, is correct because it not only prevents new pods from scheduling but also evicts already-running pods that do not tolerate the taint. Options A (NeverSchedule) and B (PreferSchedule) are not valid Kubernetes taint effects; the only supported effects are NoSchedule, PreferNoSchedule, and NoExecute.

Answer

NeverSchedule

Answer

PreferSchedule

Question 2

You need to grant a ServiceAccount named 'monitor-sa' in namespace 'monitoring' the ability to read Pods and Services across all namespaces. Which TWO resources are needed? (Choose TWO.)

Accepted Answer

ClusterRoleBinding binding the ClusterRole to the ServiceAccount. Option C is correct because reading Pods and Services across all namespaces requires a ClusterRole, which is a cluster-scoped resource whose rules (e.g., apiGroups: [""], resources: ["pods", "services"], verbs: ["get", "list", "watch"]) apply across the entire cluster. Option A is correct because a ClusterRole alone grants nothing; a ClusterRoleBinding must bind that ClusterRole to the ServiceAccount subject (kind: ServiceAccount, name: monitor-sa, namespace: monitoring) to actually confer the permissions cluster-wide. Option B is not needed because token secrets are only for obtaining a long-lived bearer token and are unrelated to RBAC authorization. Option D is wrong because a RoleBinding is namespace-scoped and would have to be created in every namespace individually, which does not satisfy the 'across all namespaces' requirement. Option E is wrong because a Role in the 'monitoring' namespace only grants permissions within that single namespace, not cluster-wide.

Answer

ServiceAccount token secret

Answer

RoleBinding in each namespace

Answer

Role in the 'monitoring' namespace

Question 3

Which TWO statements about DaemonSets are correct? (Select 2)

Accepted Answer

DaemonSets are often used for cluster daemons like log collectors or monitoring agents.. Option C is correct because DaemonSets are designed for node-level cluster services such as log collectors (e.g., Fluentd/Fluent Bit), monitoring agents (e.g., node-exporter), and CNI/storage daemons, where one pod per node is needed. Option E is correct because a DaemonSet's core behavior is to ensure that all nodes, or a subset selected via nodeSelector/affinity/tolerations, run a copy of a specified pod, with new nodes automatically getting the pod. Option A is incorrect because DaemonSets are standalone controllers managed directly by the DaemonSet controller, not by a parent Deployment. Option B is incorrect because DaemonSets do support rolling updates via updateStrategy: RollingUpdate (with maxUnavailable), as well as OnDelete. Option D is incorrect because DaemonSets do not use a desired replica count like Deployments or ReplicaSets; their pod count is determined by the number of matching nodes.

Answer

DaemonSets are typically managed by a parent Deployment.

Answer

DaemonSets do not support rolling updates.

Answer

DaemonSets have a desired number of replicas that the scheduler tries to maintain.

Question 4

Which TWO of the following are valid strategies for a Deployment's rolling update? (Select TWO.)

Accepted Answer

maxUnavailable: 0. In a Kubernetes Deployment's rollingUpdate strategy, maxUnavailable: 0 (option A) is valid because it guarantees that the number of available Pods never drops below the desired replica count during an update, forcing new Pods to become Ready before old ones are terminated. maxSurge: 1 (option B) is also valid because it allows the Deployment to temporarily exceed the desired replica count by one Pod, enabling new Pods to be created before old ones are removed. Both fields belong under spec.strategy.rollingUpdate and accept either an integer or a percentage. Option C (podManagementPolicy: OrderedReady) is a StatefulSet field, not a Deployment rolling-update parameter. Option D (scaleUp: 2) is not a Kubernetes Deployment field at all. Option E (type: Recreate) is a valid Deployment strategy type, but it is not a rolling-update strategy since it terminates all existing Pods before creating new ones.

Answer

podManagementPolicy: OrderedReady

Answer

scaleUp: 2

Answer

type: Recreate

Question 5

Which TWO of the following are valid methods to expose ConfigMap data to pods?

Accepted Answer

As environment variables. Option A is correct because a ConfigMap can be consumed via envFrom or valueFrom.configMapKeyRef in a container's env, injecting keys as environment variables. Option E is correct because a ConfigMap can be mounted as a volume, where each key becomes a file in the mounted directory, allowing applications to read configuration from the filesystem. Option B is incorrect because a Kubernetes Service provides network access to pods, not a mechanism to inject ConfigMap data. Option C is incorrect because container command arguments are set in the pod spec and are not a native ConfigMap exposure method, though values could be referenced indirectly. Option D is incorrect because annotations are metadata attached to objects and are not a supported way to expose ConfigMap data to containers.

Answer

As a Kubernetes Service

Answer

As a container command argument

Answer

As a Pod annotation

Question 6

Which TWO of the following will cause a pod to be rescheduled to a different node? (Select TWO.)

Accepted Answer

Node has a taint with effect NoExecute. Option A is correct because a taint with effect NoExecute on a node causes the node controller to evict pods that do not tolerate that taint, and the evicted pods are then recreated by their controller (e.g., Deployment/ReplicaSet) and rescheduled onto a different node. Option E is correct because when a higher-priority pod is scheduled and the cluster needs to free resources, the scheduler can preempt (evict) lower-priority pods; those preempted pods are deleted and their controllers recreate them, causing rescheduling to another node. Option B is not correct: increasing a pod's resource requests does not by itself trigger rescheduling — the change is not applied to an existing running pod (pod specs are largely immutable), and even if it were, it would not automatically move the pod to another node. Option C is not correct: updating node affinity on a running pod is not a supported in-place change and does not cause the kubelet/scheduler to relocate the pod; affinity is evaluated at scheduling time. Option D is not correct: a NoSchedule taint only prevents new pods from being scheduled onto the node; it does not evict or reschedule pods already running there.

Answer

The pod's resource requests are increased

Answer

The pod's node affinity is updated

Answer

Node has a taint with effect NoSchedule

Question 7

Which access mode allows a PersistentVolume to be mounted as read-write by multiple pods across different nodes?

Accepted Answer

ReadWriteMany (RWX). ReadWriteMany (RWX) is the correct access mode because it allows a PersistentVolume to be mounted as read-write by multiple pods simultaneously, even when those pods are scheduled on different nodes. This is the only access mode that supports concurrent read-write access across nodes, which is essential for shared storage solutions like NFS, GlusterFS, or CephFS.

Answer

ReadWriteOnce (RWO)

Answer

ReadWriteOncePod (RWOP)

Answer

ReadOnlyMany (ROX)

Question 8

Which three components are part of the Gateway API? (Choose three.)

Accepted Answer

GatewayClass. The Gateway API defines three core resource types: GatewayClass, Gateway, and HTTPRoute (along with other route types like TCPRoute and TLSRoute). Option B, GatewayClass, is correct because it is a cluster-scoped resource that identifies the controller implementing the Gateway API and defines the class of gateways available. Option C, Gateway, is correct because it represents an instance of a gateway that provisions the underlying load balancer or proxy and defines listeners for traffic. Option D, HTTPRoute, is correct because it is a route resource that attaches to a Gateway and specifies how HTTP traffic is matched and forwarded to backend Services. Option A, Ingress, is not part of the Gateway API; it is a separate, older Kubernetes API for HTTP routing. Option E, Service, is a core Kubernetes resource used as a backend target, not a component of the Gateway API itself.

Answer

Ingress

Answer

Service

Question 9

Which TWO of the following are valid ways to expose a ConfigMap to a pod? (Select TWO)

Accepted Answer

Mounting the ConfigMap as a volume. Option A is correct because a ConfigMap can be exposed to a pod by mounting it as a volume, which projects each key as a file inside the container's filesystem at a chosen mount path. Option E is correct because individual ConfigMap keys can be injected as environment variables using valueFrom.configMapKeyRef (or envFrom.configMapRef for all keys), letting the container read specific values as env vars. Option B is wrong because ConfigMaps are never automatically mounted at /etc/config; a volume mount must be explicitly declared in the pod spec with a mountPath. Option C is wrong because a ConfigMap holds configuration data, not a container image, so it cannot be used as an image. Option D is wrong because ConfigMap data is not automatically exposed as environment variables; it must be explicitly referenced via envFrom or configMapKeyRef.

Answer

The ConfigMap is automatically mounted at /etc/config in the container

Answer

Using the ConfigMap as a container image

Answer

The ConfigMap is automatically available as environment variables in the pod

Question 10

Which TWO of the following are valid ways to inject configuration data into a pod? (Select TWO.)

Accepted Answer

Mounting a ConfigMap as a volume. Option C is correct because a ConfigMap can be mounted as a volume into a pod, causing each key in the ConfigMap to appear as a file in the mounted directory, which is a standard Kubernetes mechanism for injecting configuration data. Option D is also correct because a ConfigMap's keys can be exposed as environment variables inside containers via envFrom or valueFrom.configMapKeyRef, directly injecting configuration values into the container's environment. Option A is not a valid injection method because kubectl edit modifies the pod's specification itself (and most pod fields are immutable after creation), not the configuration data consumed by the application. Option B is not a native configuration-injection mechanism; a sidecar fetching config from a remote API is an application-level pattern, not a Kubernetes-provided way to inject config into a pod. Option E is incorrect because a PersistentVolume provides storage, not a mechanism for injecting configuration data into a pod.

Answer

Editing the pod's spec directly via kubectl edit

Answer

Using a Sidecar container to fetch config from a remote API

Answer

Storing config in a PersistentVolume

Question 11

Which three are valid pod phases?

Accepted Answer

Pending. Option A (Pending) is a valid pod phase: it means the pod has been accepted by the Kubernetes API server but one or more containers are not yet running, typically because images are still being pulled or scheduling is incomplete. Option C (Succeeded) is valid: it indicates all containers in the pod terminated successfully with exit code 0 and the pod will not be restarted. Option E (Running) is valid: it means the pod has been bound to a node and all containers have been created, with at least one container still running or starting/restarting. The unmarked options do not belong because Terminating is not a pod phase (it is a deletion state reflected in metadata.deletionTimestamp), and CrashLoopBackOff is a container waiting reason, not a pod phase.

Answer

Terminating

Answer

CrashLoopBackOff

Question 12

Which TWO taint effects can be used to prevent a pod from being scheduled on a node unless it has a matching toleration?

Accepted Answer

NoExecute. NoSchedule (C) is correct because it is a taint effect that prevents new pods from being scheduled onto a tainted node unless the pod has a matching toleration; existing pods already running on the node are not evicted. NoExecute (B) is also correct because it not only prevents scheduling of pods without a matching toleration but also evicts already-running pods that do not tolerate the taint, making it a valid taint effect for blocking scheduling. PreferNoSchedule (A) is a soft preference, so the scheduler will try to avoid the node but may still place a pod there without a toleration, so it does not strictly prevent scheduling. FailSchedule (D) and NoAdmit (E) are not valid Kubernetes taint effects; the only supported effects are NoSchedule, PreferNoSchedule, and NoExecute.

Answer

PreferNoSchedule

Answer

FailSchedule

Answer

NoAdmit

Question 13

Which TWO of the following are components of the Ingress API? (Select TWO.)

Accepted Answer

rules. Option A, rules, is correct because the Ingress spec is fundamentally built around a list of rules that map incoming HTTP/HTTPS host and path requests to backend Services, making rules a core component of the Ingress API. Option E, tls, is correct because the Ingress resource includes a tls field that declares TLS configuration (hosts and secretName) so the ingress controller can terminate TLS for specified hosts. IngressClass (B) is a separate API resource used to select which controller implements an Ingress, not a component inside the Ingress object itself. Service (C) and Endpoints (D) are distinct core/v1 resources that Ingress rules reference as backends; they are not part of the Ingress API's own structure.

Answer

IngressClass

Answer

Service

Answer

Endpoints

Question 14

Which THREE of the following are characteristics of a Kubernetes StatefulSet? (Select THREE)

Accepted Answer

Pods are created and terminated in a predictable order (ordinal index). Option A is correct because a StatefulSet assigns each pod a stable ordinal index (0, 1, 2, ...) and creates, scales, and terminates pods in that strict ordered sequence, unlike a Deployment. Option B is correct because StatefulSets use volumeClaimTemplates to give each pod its own dedicated PersistentVolumeClaim, which is retained and reattached to the same ordinal pod even after rescheduling. Option D is correct because each StatefulSet pod receives a stable, unique network identity in the form of a predictable hostname (pod-name.service-name) backed by a headless Service, so DNS names remain consistent across restarts. Option C is incorrect because StatefulSet pods are never created in random order; ordering is deterministic by ordinal. Option E is incorrect because StatefulSet pods are deliberately not interchangeable — each has its own identity, hostname, and storage, which is the opposite of the interchangeable replicas in a Deployment.

Answer

Pods are created in random order

Answer

All pods in the StatefulSet are interchangeable

Question 15

Which ONE of the following is a valid field in a PodSpec for defining init containers?

Accepted Answer

initContainers. The `initContainers` field in the PodSpec is used to define init containers. The other options are separate PodSpec fields with different purposes: `volumes` for storage, `imagePullSecrets` for pulling private images, `restartPolicy` is a PodSpec field for restart behavior (not for defining init containers), and `containers` is for main application containers, not init containers.

Answer

volumes

Answer

imagePullSecrets

Answer

restartPolicy

Answer

containers