CNCF · Free Practice Questions · Last reviewed May 2026
48real exam-style questions organised by domain, each with the correct answer highlighted and a plain-English explanation of why it's right — and why the others are wrong.
A user reports that their application cannot resolve DNS names for services in the cluster. The application runs in a pod with dnsPolicy: ClusterFirst. What is the most likely cause?
The CoreDNS deployment has 0 ready replicas.
CoreDNS is the default cluster DNS provider in Kubernetes, responsible for resolving internal service names and external domains. If the CoreDNS deployment has zero ready replicas, there are no active pods to handle DNS queries sent to the kube-dns service IP. Consequently, any pod attempting to resolve a DNS name will experience a timeout or resolution failure.
The pod's dnsPolicy is set to Default instead of ClusterFirst.
The node's network plugin is misconfigured, blocking UDP port 53.
The pod's /etc/resolv.conf contains incorrect nameserver entries.
Based on the exhibit, the pod is in CrashLoopBackOff. Which command should you run NEXT to identify the root cause?
kubectl describe node node-1
kubectl top pod api-6f4d7b9d4c-abcde -n production
kubectl get deployment api -n production -o yaml
kubectl logs api-6f4d7b9d4c-abcde -n production --previous
kubectl logs api-6f4d7b9d4c-abcde -n production --previous is the correct command because it fetches the stdout/stderr from the previous, now-terminated container instance in the pod. In a CrashLoopBackOff, the currently restarted container usually has no useful logs — it may not have started, or it immediately restarted before writing anything — while the last crashed instance carries the actual error that triggered the restart. This gives you the application-level failure message (e.g., uncaught exception, missing config, listen EADDRINUSE) needed to fix the root cause; pair it with kubectl describe pod to see the last exit code and restart count.
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 NetworkPolicy is blocking traffic from the test pod to the service IP.
The service type should be NodePort to allow in-cluster access.
The readiness probe is failing on all pods, causing them to be removed from service endpoints.
The pods have label 'app: payment-service' instead of 'app: payment', so the service selector does not match.
A Service's spec.selector uses exact key-value matching to choose backing pods. If the selector is app: payment and the pods are labeled app: payment-service, the values are different, so the Endpoints controller does not add any pod IP to the Service's backend. Label matching is exact, not substring-based, so the Service will have no endpoints and in-cluster clients cannot connect to it.
Based on the exhibit, what is the most likely cause of the pod not running?
The volume driver is not installed on node-1.
The pod has exceeded its resource limits.
The node 'node-1' is experiencing disk pressure.
The Secret 'my-secret' does not exist in the namespace.
The exhibit's event message contains the exact Kubernetes error string: the secret `my-secret` could not be found in the pod's namespace, so the kubelet is unable to inject the environment variable or volume content required by the container spec. Every Secret reference is namespaced, and the kubelet queries the API server for the secret exactly as it appears in the pod manifest; any typo, wrong namespace, or omitted resource will immediately produce this failure. Because the error is explicit and points to a missing API object, the most likely cause is that `my-secret` simply does not exist in the namespace where the Pod is running.
You are tasked with troubleshooting a production Kubernetes cluster. A user reports that they cannot access a web application running in the cluster. The application is deployed as a Deployment named 'frontend' with 2 replicas, exposed via a Service of type LoadBalancer. You have kubectl access to the cluster. You run 'kubectl get pods -l app=frontend' and see both pods are Running and Ready. You run 'kubectl get svc frontend' and see the Service has an external IP of 192.168.1.100. However, when you curl http://192.168.1.100 from a machine outside the cluster, you get a connection timeout. You are able to curl the pod IPs directly from within the cluster and get a response. Which of the following is the most likely cause of the issue?
The Service selector does not match the pod labels.
The cloud provider's load balancer is not properly configured or the security group/firewall is blocking traffic to the node ports.
When internal cluster communication works but external traffic times out, the issue lies in the external network path. Misconfigured cloud load balancers or restrictive security groups/firewalls blocking the NodePort range (typically 30000-32767) prevent external packets from reaching the cluster nodes.
The NodePort service type is not enabled in the cluster.
The Ingress resource is missing or misconfigured.
You run kubectl get nodes and see one node is NotReady. The kubelet is running on the node. What is the most likely cause?
The kubelet is not installed
Network connectivity issue between kubelet and API server
This is the correct answer. The kubelet is responsible for reporting the node's status to the API server through periodic heartbeat updates. When there is a network connectivity issue between the kubelet and the API server, the API server's node controller does not receive these updates for longer than the node-monitor-grace-period (default 40 seconds). As a result, the node is marked as NotReady, even though the kubelet process itself continues to run locally and can still manage containers on the node.
The node has been cordoned
The API server is down
Want more Troubleshooting practice?
Practice this domain13% of exam · 6 sample questions below
Which control plane component is responsible for storing the cluster state and configuration?
etcd
etcd is a distributed, consistent, and highly available key-value store that serves as Kubernetes' backing store for all cluster data. It persistently stores the entire cluster state, including configuration data, metadata for all Kubernetes objects like Pods, Deployments, and Services, and the desired state of the system. Its robust consistency model is critical for ensuring that all control plane components operate on a single, unified source of truth.
kube-controller-manager
kube-apiserver
kube-scheduler
An administrator creates a ServiceAccount named 'monitor' in the 'default' namespace. They want any pod using this ServiceAccount to be able to list pods cluster-wide. Which RBAC resource should be created and bound to this ServiceAccount?
ClusterRole and RoleBinding in the default namespace
ClusterRole and RoleBinding in kube-system
ClusterRole and ClusterRoleBinding
To grant cluster-wide permissions to a ServiceAccount, you must pair a ClusterRole with a ClusterRoleBinding. Because a ClusterRoleBinding is a non-namespaced resource, it applies the permissions defined in the ClusterRole across all namespaces in the cluster, as well as to cluster-scoped resources like Nodes and PersistentVolumes.
Role and RoleBinding in the default namespace
You want to upgrade the control plane from v1.28.0 to v1.29.0 using kubeadm. After upgrading kubeadm on the control plane node, which command should you run first?
kubeadm upgrade plan
Running `kubeadm upgrade plan` is the recommended first step when upgrading a Kubernetes control plane. This command analyzes your cluster to check if it can be upgraded, detects the current component versions, and displays the available target versions along with the exact configuration changes that will be applied. It ensures there are no version compatibility blockers before you commit to the actual upgrade process.
kubeadm upgrade apply v1.29.0
kubeadm upgrade node
kubeadm upgrade diff
Which component runs on every node in a Kubernetes cluster and ensures containers are running in a pod?
kubelet
The kubelet is the Kubernetes node agent that runs on every node, including control-plane nodes. It registers the node with the API server, watches for Pod objects bound to that node, and continually drives the actual state of containers toward the desired PodSpec. It performs liveness, readiness, and startup probes and reports pod/node status back to the API server. Because it is the component that owns the pod lifecycle on a node, it is the only component in this list that is a required Kubernetes component on every node.
kube-scheduler
container runtime
kube-proxy
A user reports that they can't authenticate to the cluster using a kubeconfig file. Running 'kubectl config view' shows the current context points to a user with client certificate and key. Which command checks the expiration date of the client certificate?
kubeadm upgrade plan --certificate-expiration
kubectl config view --raw | grep client-certificate
openssl x509 -in /etc/kubernetes/admin.conf -text -noout
kubeadm certs check-expiration
This subcommand is the authoritative way to inspect the lifetimes of all certificates managed by kubeadm, including the CA, apiserver, controller-manager, scheduler, kubelet, and the client certificate embedded in admin.conf. It prints a table showing the expiration date and remaining days for each component, giving immediate insight into whether certificate expiry is causing authentication problems. For kubeadm-based clusters, this is the correct first tool for diagnosing certificate-related authentication issues.
An admin runs 'kubectl get pods' and sees a pod in 'Pending' state for a long time. 'kubectl describe pod' shows '0/1 nodes are available: 1 node has memory pressure'. Which is the most likely cause?
The node's disk is full.
The pod's image pull secret is missing.
The node is under memory pressure and cannot admit the pod.
The scheduler's filter plugin rejects nodes reporting MemoryPressure, so the pod stays Pending with the '0/1 nodes are available' message. The node cannot admit new pods until memory pressure clears or the pod requests are reduced.
The pod requires more CPU than any node can provide.
Want more Cluster Architecture, Installation and Configuration practice?
Practice this domain10% of exam · 6 sample questions below
Which of the following service types exposes a service on a static port on each node's IP address?
ExternalName
NodePort
NodePort allocates a static port from the default range 30000–32767 and opens it on every node's IP, forwarding traffic to the service. This satisfies the stem's requirement for exposure on a fixed port per node, unlike ClusterIP (internal only) or LoadBalancer (cloud-provisioned external IP).
LoadBalancer
ClusterIP
You run 'kubectl get svc my-service -o yaml' and see 'type: ClusterIP'. The service has no endpoints. What is the most likely cause?
The service type is ClusterIP, which does not support endpoints.
The service's port does not match the container port.
The service is misconfigured and needs to be deleted and recreated.
No pods with labels matching the service selector are running and ready.
The endpoint controller only publishes Backends for pods that match the Service's selector and have their Ready condition set to True. If no pod carries the label/value pair defined in the selector, or if all matching pods are still Pending/Running with failing readiness probes, the Endpoints object stays empty. This is the canonical root cause of a Service with type ClusterIP but no endpoints.
You have a Service named 'my-service' in namespace 'ns1'. Another pod in namespace 'ns2' needs to resolve 'my-service' using DNS. What FQDN should the pod use?
my-service.svc.cluster.local
my-service.cluster.local
my-service.ns1.svc.cluster.local
This is the correct Fully Qualified Domain Name (FQDN) for a Kubernetes service. It adheres to the standard format: `<service-name>.<namespace-name>.svc.<cluster-domain>`. Here, `my-service` is the service name, `ns1` is its namespace, `svc` denotes it as a service, and `cluster.local` is the default cluster domain. This FQDN provides an unambiguous and universally resolvable address for the service from any pod within the cluster, regardless of the querying pod's own namespace.
my-service.ns2.svc.cluster.local
An Ingress resource is created with the following spec:
spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80
The backend service 'api-service' is in the same namespace as the Ingress. What must be true for the Ingress to route traffic to the service?
The Ingress controller must be configured to use the NodePort of the service.
The service 'api-service' must be of type NodePort.
The service 'api-service' must have a valid ClusterIP and at least one endpoint.
Ingress routing resolves the backend through the Service, so the Service needs a valid ClusterIP and at least one ready endpoint. Without endpoints, kube-proxy has no pod to forward to and requests fail, regardless of correct Ingress path and host configuration.
The Ingress must have an IngressClass annotation.
What is the default DNS name for a service named 'my-svc' in namespace 'default'?
my-svc.default.cluster.local
my-svc.svc.cluster.local
my-svc.default.svc.cluster.local
my-svc.default.svc.cluster.local is the canonical fully-qualified domain name for a Service named 'my-svc' created in the 'default' namespace. The pattern is '<service-name>.<namespace>.svc.cluster.local', and it maps to the cluster IP of that Service. This is the DNS name that kube-dns/CoreDNS exposes and that pods use to reach the service via stable cluster-local DNS.
my-svc.cluster.local
A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?
It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.
It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.
This is the correct behavior of the command. It binds to port 8080 on the local loopback interface and securely tunnels any connection made to localhost:8080 through the API server to port 80 of the specified Service, which then routes it to the backing Pods.
It exposes the service as a NodePort on port 8080.
It creates a new service of type LoadBalancer on port 8080.
Want more Services and Networking practice?
Practice this domain8% of exam · 6 sample questions below
Which kubectl command will show the rollout history of a Deployment named 'web-app'?
kubectl describe deployment web-app
kubectl rollout status deployment web-app
kubectl rollout history deployment web-app
kubectl rollout history deployment web-app is correct because it is the dedicated kubectl subcommand for viewing the Deployment's rollout history. It lists all revisions with their change-cause annotations (if set), and can be combined with --revision to inspect a specific revision; this history is actually derived from the underlying ReplicaSets created for each change to the pod template.
kubectl get deployment web-app -o yaml
You have a DaemonSet that is supposed to run on all nodes, but you notice it is not running on a node with a taint 'dedicated=monitoring:NoSchedule'. What must be added to the DaemonSet's pod template to make it run on that node?
Add the annotation 'scheduler.alpha.kubernetes.io/tolerations'
A nodeSelector with key 'dedicated' and value 'monitoring'
Set the priorityClassName to 'system-node-critical'
A toleration with key 'dedicated', value 'monitoring', effect 'NoSchedule'
To allow DaemonSet pods to schedule on nodes carrying the 'dedicated=monitoring:NoSchedule' taint, you must define a matching toleration in the Pod template spec. This toleration explicitly permits the scheduler to place the pods on these tainted nodes, ensuring complete cluster-wide coverage for the DaemonSet.
You have a Deployment 'db' with 3 replicas. Each pod writes to a PersistentVolumeClaim (PVC). A StatefulSet is required for stable network identities and ordered pod management. Which of the following is a key characteristic that differentiates a StatefulSet from a Deployment?
StatefulSets support rolling updates but not canary deployments
StatefulSets automatically create a Service for each pod
StatefulSets cannot use PersistentVolumeClaims
StatefulSets maintain a sticky identity for each pod, including stable hostnames and persistent storage
StatefulSets are designed to provide a stable, unique identity to each pod they manage, which is crucial for stateful applications. This identity includes a stable network hostname, typically in the format `$(pod-name).$(headless-service-name)`, and persistent storage that remains associated with the pod's ordinal index even if the pod is rescheduled to a different node. This ensures data integrity and consistent application behavior across pod lifecycle events.
You have a CronJob that runs a batch job every 5 minutes. The job takes about 2 minutes to complete. However, if a job takes longer than 5 minutes, you want to prevent a new job from starting until the previous one finishes. Which CronJob field should you configure?
successfulJobsHistoryLimit
concurrencyPolicy: Forbid
Setting `concurrencyPolicy: Forbid` ensures that if a scheduled job is still running when the next interval arrives, the CronJob controller skips the new execution. This guarantees that only one instance of the batch job runs at any given time, preventing overlapping executions.
suspend: true
startingDeadlineSeconds
Which of the following describes the role of init containers in a pod?
They run in parallel with the main containers to provide additional services
They are used for liveness and readiness probes of the main container
They run to completion before any main containers start, and each init container must complete successfully before the next one starts
This option correctly describes the lifecycle of init containers, which are executed sequentially during Pod startup. Kubernetes guarantees that each init container must exit with a zero status code before the subsequent one begins. The primary application containers will only start initializing once all defined init containers have successfully completed their execution.
They run after the main containers have started to clean up resources
You need to schedule a pod to a specific node named 'worker-2' for testing purposes. Which field should you set in the pod spec?
schedulerName
affinity
nodeSelector
nodeName
nodeName is the only field that directly assigns a pod to a specific node by its exact Node resource name. When nodeName is set, the kubelet on that node sees the pod in the API server and attempts to run it, completely bypassing the scheduling process. This is a hard assignment: the pod will never be scheduled elsewhere, and if the node does not exist or is not ready, the pod stays Pending or fails.
Want more Workloads and Scheduling practice?
Practice this domainA DevOps team needs to provide persistent storage to a set of pods that all require read-write access to the same data simultaneously. Which volume type should they use?
PersistentVolumeClaim with ReadWriteMany
A PersistentVolumeClaim configured with the ReadWriteMany (RWX) access mode allows a volume to be mounted as read-write by many nodes concurrently. This is the correct choice for enabling multiple pods distributed across different nodes in a cluster to simultaneously access and modify the same persistent storage backend.
hostPath
emptyDir
PersistentVolumeClaim with ReadWriteOnce
A pod is unable to start because the PersistentVolumeClaim it references is still in 'Pending' state. What is the most likely cause?
The PersistentVolumeClaim's storage class does not exist or cannot provision a volume
When a PersistentVolumeClaim references a non-existent or misconfigured StorageClass, the dynamic volume provisioner cannot fulfill the request. Consequently, the PVC remains stuck in a Pending state indefinitely. Because the Pod's volume mount depends on a successfully bound PVC, the Kubernetes scheduler cannot assign the Pod to a node, preventing it from starting.
The pod's YAML has a syntax error
The pod is using a hostPath volume
The node has insufficient CPU resources
A cluster administrator needs to provide storage to a pod that must read and write files, but the data does not need to persist beyond the pod's lifecycle. Which volume type should be used?
hostPath
emptyDir
An emptyDir volume is created when a Pod is assigned to a node and exists solely for the lifetime of that Pod on that node. It provides a clean, read-write directory that is automatically deleted when the Pod terminates, making it the ideal choice for transient scratch space, multi-container sharing, or caching. Since the data does not need to survive Pod deletion, this lightweight, ephemeral storage mechanism perfectly satisfies the requirements.
configMap
PersistentVolumeClaim
A team is designing a storage solution for a Cassandra cluster on Kubernetes. Each pod must have its own dedicated storage, and the cluster must be able to scale up and down dynamically. Which Kubernetes resource should be used to manage the storage?
ReplicaSet with emptyDir volumes
DaemonSet with hostPath volumes
StatefulSet with a volumeClaimTemplate
StatefulSets are specifically designed for stateful applications like Cassandra that require stable network identifiers and persistent, dedicated storage. By utilizing a volumeClaimTemplate, Kubernetes automatically provisions a unique PersistentVolumeClaim (PVC) for each Pod replica, ensuring that even if a Pod is rescheduled, it reconnects to its exact corresponding volume.
Deployment with a single PersistentVolume shared by all pods
A cluster uses a CSI driver for dynamic provisioning. An administrator creates a StorageClass with 'volumeBindingMode: WaitForFirstConsumer' and a PVC. The pod using the PVC is scheduled to a node. However, the PV is never provisioned. What is the most likely cause?
The PVC is not bound to a PV because no PV exists.
The CSI driver is not installed or malfunctioning.
The StorageClass references a CSI provisioner (e.g., csi.contoso.com), and Kubernetes relies on the external-provisioner sidecar to send CreateVolume RPCs to the CSI driver controller. If that driver controller is not installed, the DaemonSet pods are CrashLooping, or the CSI socket is unavailable, the provisioner cannot create the backend volume, so no PV is bound and the PVC remains Pending with events like 'Failed to provision volume with storage class'. Inspecting the csi-controller logs and the driver DaemonSet status will confirm the malfunction.
The pod does not have the correct node selector.
The StorageClass uses 'Immediate' binding mode.
A developer wants to mount a ConfigMap as a volume in a pod. However, the pod should only see specific keys from the ConfigMap, not all keys. What is the best approach?
Use the ConfigMap to set environment variables instead of a volume mount.
Use the 'items' field in the ConfigMap volume definition to specify which keys to include.
The `items` field within a ConfigMap volume definition is the precise and recommended method for selectively exposing specific keys as files inside a container. By specifying `key` and `path` for each desired entry, only the relevant data from the ConfigMap is mounted into the pod's filesystem, preventing unnecessary data exposure. This approach ensures minimal resource usage and adheres to the principle of least privilege by only providing what is strictly required. For example, `items: [{key: "app-config.yaml", path: "config.yaml"}]` mounts only the `app-config.yaml` key as `config.yaml`.
Mount the entire ConfigMap and use a startup script to remove unwanted files.
Create a new ConfigMap with only the needed keys.
Want more Storage practice?
Practice this domain12% of exam · 6 sample questions below
A DevOps engineer notices that the kubelet on a node is unable to register with the Kubernetes API server. The kubelet logs show 'Failed to get bootstrap CA certificate' and the node is not yet part of the cluster. What is the most likely cause?
The kubelet configuration file has incorrect node IP.
The node's RBAC permissions are misconfigured.
The API server is not running.
The bootstrap token used for TLS bootstrapping has expired.
Bootstrap tokens used in TLS bootstrapping are intentionally short-lived and can expire, especially if they were created for a one-time node registration. When a token expires, the API server rejects the kubelet's authentication attempt, returning a 401 Unauthorized, and the kubelet cannot complete the bootstrap sequence or download the CA certificate. This precisely matches the observed symptom of a bootstrap CA retrieval failure, making it the correct root cause.
A Kubernetes cluster has been running for months. Recently, some pods are reporting 'FailedScheduling' due to insufficient memory. The administrator wants to add a new node with 32GB RAM. However, after joining the node, the new node shows 'NotReady' and the kubelet logs indicate 'Failed to update node status: context deadline exceeded'. What is the most likely cause?
The kubelet is not configured with the correct node IP.
The new node does not have enough disk space for container images.
There is a network connectivity issue between the new node and the control plane.
A 'context deadline exceeded' error explicitly indicates that a gRPC or HTTP request timed out before receiving a response. In this scenario, network latency, packet loss, or misconfigured firewalls/security groups between the new node and the control plane prevent the kubelet from successfully posting its lease updates to the API server within the allocated timeframe.
The API server is overloaded and cannot handle the node update request.
An administrator is tasked with setting up a new Kubernetes cluster using kubeadm. They have two nodes: one control plane and one worker. After initializing the control plane with 'kubeadm init', the worker node fails to join with the error 'error execution phase preflight: [preflight] Some fatal errors occurred: [ERROR CRI]: container runtime is not running'. What should the administrator check first?
Ensure that containerd is installed and running on the worker node.
The kubelet on the worker node communicates with the container runtime through the Container Runtime Interface (CRI), typically over a Unix socket such as /run/containerd/containerd.sock. If containerd is not installed, the service is stopped, or the socket is missing, kubelet will fail with a CRI connection error and never start pods. Run `systemctl status containerd` and check the socket path configured in kubelet (--container-runtime-endpoint) to confirm the runtime is active.
Verify that the control plane node is healthy.
Check if the join token has expired.
Install a network plugin like Calico on the control plane.
A team is configuring etcd for a multi-node Kubernetes cluster. They want to ensure that etcd data is encrypted at rest. Which approach should they use?
Use LUKS to encrypt the disk partition where etcd data is stored.
Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.
An EncryptionConfiguration resource defines the order and type of providers (such as aescbc, aesgcm, secretbox, or kms) for protecting specific API resource types. The kube-apiserver must be started with --encryption-provider-config=/path/to/encryption-config.yaml, and when it writes data like Secrets to etcd it encrypts that data using the chosen provider (aescbc uses AES-CBC with a randomly generated IV and a 32-byte key). This is the canonical, Kubernetes-native mechanism for encryption at rest and is exactly what the CKA objectives expect.
Use TLS certificates to encrypt communication between etcd and the API server.
Configure etcd to use encryption at rest by setting --experimental-encryption-provider.
During a 'kubeadm init', the administrator sees the message 'Your Kubernetes control-plane has been initialized successfully!' but the 'kubectl get nodes' shows the control plane node as 'NotReady'. What is the most likely missing step?
Generate a join token for worker nodes.
Install a CNI plugin such as Calico or Flannel.
Kubernetes requires a Container Network Interface (CNI) plugin to establish the pod network. Until a CNI provider like Calico or Flannel is deployed, CoreDNS pods will remain in a Pending state, and the control plane node will report a status of NotReady due to the missing network configuration.
Copy the kubeconfig to the user's home directory.
Check that the kubelet is running on the control plane node.
A user tries to create a pod with the YAML file that requests 2 CPUs as a limit. The cluster has a ResourceQuota named 'compute-quota' with limits.cpu: 2. The user sees the above error. What is the likely issue?
The pod is requesting 2 CPUs as a request, but the quota limits requests.
The pod is being created in the wrong namespace.
The pod is trying to use more CPU than the node capacity.
The current total CPU limit usage in the namespace is 1, and adding a pod with limit 2 would exceed the quota of 2.
This is correct because the namespace has a hard ResourceQuota limit of 2 CPUs (limits.cpu: 2) and currently has 1 CPU already allocated to existing pods. Attempting to create a new pod requesting a limit of 2 CPUs would bring the total requested limit to 3. This exceeds the hard quota of 2, causing the ResourceQuota admission controller to reject the pod creation request.
Want more Cluster Architecture, Installation & Configuration practice?
Practice this domain7% of exam · 6 sample questions below
A Kubernetes cluster has a deployment with 3 replicas. After a node failure, you notice that only 2 pods are running, and the deployment has not rescheduled the missing pod. What is the most likely cause?
The deployment has a resource quota that prevents new pods
The pod's terminationGracePeriodSeconds is set to 0
The node controller has not yet evicted the pod
When a node becomes unreachable, the node controller waits for a default grace period of five minutes (configured via the --pod-eviction-timeout flag) before marking the pods for eviction. During this window, the control plane keeps the pods in a Terminating or Unknown state on the failed node and does not reschedule them. Only after this timeout expires will the deployment controller spin up a replacement pod on a healthy node.
The deployment's replicas field is set to 2
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?
Random pods
Pods with the highest ordinals (4 and 3)
Correct. The StatefulSet controller honors the ordinal ordering by deleting pods with the highest index numbers first. For a 5-pod StatefulSet (ordinals 0 through 4) scaling from 5 to 3 replicas, pods 4 and 3 are removed because they are the highest ordinals. This preserves the sequential identity of the remaining pods (0, 1, 2) and their associated storage, which is the core behavior of StatefulSet lifecycle management.
Pods with the lowest ordinals (0 and 1)
Pods with the highest resource usage
A cluster administrator wants to ensure that no pods are scheduled on the master node(s). Which approach is the best practice?
Add a taint to the master node
Applying a NoSchedule or NoExecute taint to the master (control plane) node ensures that the Kubernetes scheduler will not place any pods on it unless they have a matching toleration. While modern Kubernetes clusters apply this taint by default to protect control plane resources, manually adding or verifying this taint is the standard declarative method to enforce this scheduling restriction.
Delete the master node from the cluster
Use a resource quota on the master namespace
Set nodeSelector on the master node
A developer wants to deploy a pod that will run only once to initialize a database schema. Which Kubernetes resource should they use?
DaemonSet
Job
A Job controller creates one or more pods and tracks them until a specified number successfully terminate. For a one-time task, a simple Job with default completions=1 runs once to completion, and the workload is not recreated if it exits with code 0. It is the native Kubernetes API for exactly-once batch processing.
Deployment
CronJob
You are managing a Kubernetes cluster that hosts a microservices application. One of the services, 'payment-processor', is critical and must always be available. It has a Deployment with 3 replicas, each requesting 1 CPU and 2Gi memory. Recently, the team added a new service 'data-analyzer' that runs as a DaemonSet on all nodes, consuming significant CPU and memory. After the addition, you notice that 'payment-processor' pods are occasionally being evicted, and new pods are slow to be scheduled. You check node resource usage and find that some nodes are overcommitted. You want to ensure that 'payment-processor' pods are never evicted and are scheduled before less critical workloads. Which action should you take?
Add a taint to nodes that have low resources and add tolerations only to 'payment-processor' pods
Increase the resource requests for 'payment-processor' pods to guarantee resources
Create a PriorityClass with a high value and assign it to the 'payment-processor' Deployment
Creating a PriorityClass with a high integer value and assigning it to the 'payment-processor' Deployment is the most effective solution. Pods with higher priority are preferentially scheduled by the kube-scheduler. Crucially, if a high-priority 'payment-processor' pod cannot be scheduled due to insufficient resources on any node, the scheduler will attempt to preempt (evict) lower-priority pods on suitable nodes to free up the necessary resources, thereby ensuring the critical workload runs.
Use node affinity to ensure 'payment-processor' pods run on dedicated nodes
Your team is deploying a new application that consists of a web frontend and a backend API. The frontend must be accessible from outside the cluster, and the backend should only be accessible from within the cluster. The cluster has multiple namespaces: 'frontend' and 'backend'. You have been asked to design the deployment. The frontend Deployment should have 5 replicas, and the backend Deployment should have 3 replicas. Additionally, you need to ensure that the frontend pods can communicate with the backend pods using a stable DNS name. You also want to isolate the backend from other namespaces. Which set of resources should you create?
Frontend: Deployment, Service (NodePort); Backend: Deployment, Service (ClusterIP); no NetworkPolicy
Frontend: Deployment, Service (ClusterIP); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace
Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (LoadBalancer); NetworkPolicy to allow only frontend to backend
Frontend: Deployment, Service (LoadBalancer); Backend: Deployment, Service (ClusterIP); NetworkPolicy to allow ingress from frontend namespace and deny others
This architecture correctly leverages a LoadBalancer Service to route external public traffic to the frontend deployment, while keeping the backend isolated using an internal-only ClusterIP Service. Additionally, the NetworkPolicy enforces strict zero-trust security by explicitly allowing ingress traffic only from the frontend namespace while dropping all other non-compliant cluster traffic.
Want more Workloads & Scheduling practice?
Practice this domain10% of exam · 6 sample questions below
A cluster has multiple namespaces: 'frontend', 'backend', and 'monitoring'. A pod in the 'frontend' namespace needs to reach a Service named 'db-service' in the 'backend' namespace. The 'db-service' Service is of type ClusterIP. Which DNS name should the pod use?
db-service.svc.cluster.local
db-service
db-service.backend.cluster.local
db-service.backend.svc.cluster.local
db-service.backend.svc.cluster.local is the fully qualified domain name Kubernetes automatically creates for the Service named db-service in the backend namespace. Any Pod in any namespace, including frontend, can use this FQDN because it contains every component needed by CoreDNS to locate the ClusterIP. It is the canonical cross-namespace address and avoids relying on search domains or local-only short names.
A pod is running with the default DNS policy. The cluster DNS service is at 10.96.0.10. The node's /etc/resolv.conf has nameserver 8.8.8.8. When the pod tries to resolve an external hostname like 'example.com', which DNS server will it query first?
The node's DNS server (8.8.8.8)
There is no DNS resolution; the pod cannot resolve external names by default
The cluster DNS service (10.96.0.10)
With the default `ClusterFirst` DNS policy, the `kubelet` configures the pod's `/etc/resolv.conf` to list the cluster DNS service IP (e.g., 10.96.0.10, which is the default `kube-dns` or `CoreDNS` service IP in many clusters) as the primary nameserver. All DNS queries originating from the pod are initially sent to this cluster DNS service. The service then resolves internal cluster names directly and forwards external name queries to upstream DNS servers.
The pod's own /etc/resolv.conf which contains the node's DNS
An administrator notices that traffic to a Service is not being forwarded to any pod. The Service has selector 'app: web' and there are pods with that label. However, 'kubectl get endpoints' shows no endpoints. What is the most likely cause?
The Service port name does not match the container port name.
The Service type is ClusterIP.
The Service targetPort is not specified.
The pods are not in Ready state (e.g., failing readiness probes).
Readiness probes determine whether a pod is included in the Service's EndpointSlices. The endpoint controller monitors pod readiness and only adds pods whose readiness probe is currently passing; pods failing readiness (or running a container that never becomes ready) are excluded. If all matching pods fail their readiness probe, the endpoint list is empty, and traffic to the Service's ClusterIP or DNS name is dropped. This directly explains why traffic is not reaching the application when the selector matches but no endpoints exist.
A Kubernetes cluster uses Calico as the CNI plugin. Two pods on different nodes cannot communicate, but pods on the same node can. Network policies are not enforced. What is the most likely cause?
Calico is not configured with an overlay network.
A NetworkPolicy is blocking inter-node traffic.
The pods are using different Service types.
The nodes' firewalls are blocking required ports for Calico (e.g., BGP port 179 or VXLAN port 4789).
Calico relies on specific control and data plane ports to establish inter-node connectivity, such as TCP port 179 for BGP routing or UDP port 4789 for VXLAN encapsulation. If host-level firewalls block these ports, nodes cannot exchange routing information or encapsulate cross-node pod traffic, breaking inter-node pod communication.
A company wants to expose a web application running as a Deployment with 3 replicas to external users. They need a stable IP address that does not change and the ability to terminate TLS. Which resource should they use?
LoadBalancer Service
ClusterIP Service
Ingress resource with a TLS certificate
An Ingress resource, coupled with an Ingress controller, provides a robust solution for exposing web applications externally by offering HTTP/S routing, virtual hosting, and crucially, built-in TLS termination. It allows defining rules to route external traffic to specific services based on hostnames or URL paths, and can manage TLS certificates (stored as Kubernetes Secrets) to encrypt traffic from the client to the Ingress controller, ensuring secure communication.
NodePort Service
Which TWO of the following are valid reasons to use a Headless Service?
To provide a single stable IP address for the service.
To expose a service externally via a cloud load balancer.
To enable a client to discover all pod IPs for a StatefulSet.
When a StatefulSet creates pods, a headless service provides a stable DNS name for each pod (e.g., podname.servicename.namespace.svc.cluster.local) and also allows the service's own DNS name to return a list of A records for all matching pod IPs. Clients can then obtain the entire set of pod addresses directly, which is exactly what stateful peers need to discover one another and join the cluster without a proxy.
To enable DNS to return individual pod IPs for stateful applications.
In a headless service, the DNS controller sets the service's A record set to the IP addresses of the underlying pods rather than a single virtual IP. For stateful applications, this means DNS resolution returns unique IPs for each pod, letting app logic query and connect to each member individually instead of sending traffic to a shared load-balancing address. The absence of a ClusterIP makes this possible because kube-proxy does not intercept or translate the DNS answers.
To provide load-balanced access to a set of pods.
Want more Services & Networking practice?
Practice this domainThe CKA exam is performance-based — there are no multiple-choice questions. It is a hands-on lab exam completed within 120 minutes. You complete practical tasks in a live or simulated environment. Courseiva practice questions cover the underlying concepts.
Hands-on labs and command-line tasks in a live Kubernetes cluster. Courseiva provides concept checks and scenario questions to support lab preparation.
The exam covers 8 domains: Troubleshooting, Cluster Architecture, Installation and Configuration, Services and Networking, Workloads and Scheduling, Storage, Cluster Architecture, Installation & Configuration, Workloads & Scheduling, Services & Networking. Questions are weighted by domain — higher-weight domains appear more on your actual exam.
No. These are original exam-style practice questions written against the official CNCF CKA exam objectives. They are not copied from the real exam. Courseiva focuses on genuine understanding, not memorisation of braindumps.
Courseiva tracks your accuracy per domain and routes you toward weak areas automatically. Free, no account required.