CKA Practice Test 3 — 30 Questions

Question 1

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?

Accepted Answer

Pods with the highest ordinals (4 and 3). 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.

Answer

Random pods

Answer

Pods with the lowest ordinals (0 and 1)

Answer

Pods with the highest resource usage

Question 2

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?

Accepted Answer

Configure a PersistentVolume backed by NFS and a PersistentVolumeClaim with accessModes: ReadWriteMany. 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.

Answer

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

Answer

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

Answer

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

Question 3

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?

Accepted Answer

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

Answer

journalctl -u kubelet

Answer

kubectl delete node <node-name>

Answer

systemctl restart docker

Question 4

A Deployment's pod is stuck in Pending state. 'kubectl describe pod' shows Events: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory'. What is the likely fix?

Accepted Answer

Increase the memory limit of the pod or add more worker nodes. The error '3 Insufficient memory' indicates that three worker nodes lack the required memory to schedule the pod. Increasing the pod's memory limit (if it's set too high) or adding more worker nodes directly addresses the resource shortage. The control-plane node's taint is irrelevant because the pod is not trying to schedule there; the issue is insufficient memory on the available worker nodes.

Answer

Remove the taint from the control-plane node

Answer

Add a toleration for the control-plane taint to the pod spec

Answer

Set nodeSelector to schedule on control-plane nodes

Question 5

A user creates a PersistentVolumeClaim with a storage class 'ssd' that does not exist in the cluster. What will happen when the PVC is created?

Accepted Answer

The PVC will remain in Pending state.. When a PersistentVolumeClaim (PVC) references a StorageClass that does not exist in the cluster, the PVC cannot be dynamically provisioned because the provisioner associated with that StorageClass is missing. Without a matching StorageClass, the system cannot create a new PersistentVolume (PV) for the PVC, and since no existing PV matches the claim (or the PVC is set to use dynamic provisioning), the PVC will remain in a Pending state indefinitely until the StorageClass is created or the PVC is deleted.

Answer

The PVC will be deleted automatically after a timeout.

Answer

The PVC will be automatically bound to any available PV.

Answer

The cluster will create the storage class automatically.

Question 6

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

Accepted Answer

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

Answer

The Pod was evicted due to resource pressure.

Answer

The Pod requests more CPU than available on the node.

Answer

The scheduler failed to communicate with the API server.

Question 7

Which command retrieves the rollout history of a Deployment named 'web'?

Accepted Answer

kubectl rollout history deployment web. The `kubectl rollout history deployment web` command retrieves the revision history of the specified Deployment, showing each revision number and, with the `--revision` flag, the details of a specific revision. This is the standard Kubernetes command for viewing rollout history, as defined in the kubectl reference.

Answer

kubectl describe deployment web

Answer

kubectl get events --field-selector involvedObject.name=web

Answer

kubectl rollout status deployment web

Question 8

A StatefulSet named 'mysql' is deployed with 3 replicas. A developer reports that the pod 'mysql-0' is failing due to persistent volume issues. After fixing the underlying storage, they want to recreate 'mysql-0' while preserving its stable network identity. What is the correct approach?

Accepted Answer

Delete the pod 'mysql-0' using kubectl delete pod mysql-0, and let the StatefulSet controller recreate it. StatefulSet pods are managed by a controller that automatically recreates a pod with the same identity (name, hostname, and stable network identity) when it is deleted. Deleting the pod 'mysql-0' triggers the StatefulSet controller to create a new pod with the same ordinal index and persistent storage binding, preserving its stable network identity.

Answer

Delete the StatefulSet and recreate it with the same configuration

Answer

Use kubectl replace --force on the StatefulSet to recreate the pod

Answer

Scale the StatefulSet down to 0 replicas, then scale back up to 3

Question 9

A HorizontalPodAutoscaler (HPA) is configured for a Deployment with targetCPUUtilizationPercentage: 80. The current CPU utilization is 90%. The deployment has minReplicas: 3 and maxReplicas: 10. What will the HPA do?

Accepted Answer

It increases the number of replicas.. The HPA increases the number of replicas because the current CPU utilization (90%) exceeds the target of 80%. The HPA calculates the desired replica count using the formula: desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)], which yields ceil[3 * (90/80)] = ceil[3.375] = 4 replicas. This scales the deployment up to reduce per-pod CPU load, staying within the configured minReplicas (3) and maxReplicas (10).

Answer

It does nothing because the utilization is within the acceptable range.

Answer

It adds a new node to the cluster.

Answer

It decreases the number of replicas to reduce CPU usage.

Question 10

A pod 'my-pod' in the 'default' namespace cannot resolve the service 'db-service' in the 'production' namespace. Which DNS name should be used to reach the service from 'my-pod'?

Accepted Answer

db-service.production.svc.cluster.local. Kubernetes DNS resolves services across namespaces using the fully qualified domain name (FQDN) format `..svc.cluster.local`. Since 'my-pod' is in the 'default' namespace and 'db-service' is in the 'production' namespace, the short name 'db-service' will not resolve; the FQDN must include the namespace and the cluster domain suffix to reach the service.

Answer

db-service

Answer

db-service.production.pod.cluster.local

Answer

production.db-service.svc.cluster.local

Question 11

You have a Deployment with 4 replicas. During a rolling update, you want to ensure that only 2 pods are unavailable at any given time. Which field should you set in the Deployment spec?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable. The `spec.strategy.rollingUpdate.maxUnavailable` field specifies the maximum number of Pods that can be unavailable during a rolling update. Setting it to 2 ensures that at most 2 replicas are unavailable at any given time, which aligns with the requirement of having 4 replicas and allowing only 2 unavailable pods.

Answer

spec.updateStrategy.rollingUpdate.maxUnavailable

Answer

spec.replicas.maxUnavailable

Answer

spec.strategy.rollingUpdate.maxSurge

Question 12

A pod is in Pending state. You run 'kubectl describe pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 3 node(s) had taint {node.kubernetes.io/not-ready: }.'. What is the most likely reason?

Accepted Answer

The pod does not have tolerations for the taints on the available nodes. The pod is in Pending state because the scheduler cannot find a node that meets all scheduling constraints. The event explicitly states that 1 node has a taint `node-role.kubernetes.io/master` and 3 nodes have a taint `node.kubernetes.io/not-ready`, and the pod does not have corresponding tolerations. Without tolerations, the pod is not allowed to schedule on any of these nodes, leaving no available node.

Answer

The pod's container image pull failed

Answer

The cluster is out of CPU capacity

Answer

The pod's resource requests are too high for any node

Question 13

You have a Deployment that should have a rolling update with no downtime. You set maxSurge to 25% and maxUnavailable to 0%. With 4 replicas, how many pods will be created above the desired count during the update?

Accepted Answer

1. With maxSurge=25% and maxUnavailable=0%, the Deployment controller ensures that during a rolling update, the number of pods above the desired count is limited to 25% of the desired replicas, rounded up. For 4 replicas, 25% is 1, so at most 1 extra pod is created above the desired count, ensuring zero downtime by keeping all 4 original pods running until the new pod is ready.

Answer

2

Answer

4

Answer

0

Question 14

You create a Pod with an init container and a main container. The init container runs a script that writes to a shared volume. The main container reads from that volume. However, the Pod is stuck in 'Init:CrashLoopBackOff'. What is the most likely cause?

Accepted Answer

The init container's command is failing due to an error in the script. The 'Init:CrashLoopBackOff' status indicates that the init container is repeatedly failing and restarting. Since init containers run to completion before the main container starts, the most likely cause is that the script in the init container is failing due to an error, such as a syntax mistake, missing dependency, or incorrect command.

Answer

The init container is waiting for the main container to start

Answer

The main container has a resource limit that is too low

Answer

The shared volume is not mounted with the correct permissions

Question 15

What is the default kube-proxy mode in Kubernetes v1.29?

Accepted Answer

iptables. In Kubernetes v1.29, the default kube-proxy mode is `iptables`. This mode uses Linux iptables rules to handle service traffic, providing better performance and reliability than the older userspace mode. It is the default because it balances simplicity and efficiency for most cluster configurations.

Answer

nftables

Answer

userspace

Answer

ipvs

Question 16

You have a NetworkPolicy that selects pods with label 'role: db' in the 'default' namespace. The policy has no ingress rules defined. What is the effect on traffic to the selected pods?

Accepted Answer

All ingress traffic is denied. A NetworkPolicy with no ingress rules defaults to denying all ingress traffic to the selected pods. This is because Kubernetes NetworkPolicies are whitelist-based: if no ingress rules are specified, the policy implicitly denies all incoming traffic, even if other policies allow it. The selected pods with label 'role: db' will therefore receive no ingress traffic.

Answer

Only traffic from pods with label 'role: frontend' is allowed

Answer

Both ingress and egress traffic are denied

Answer

All ingress traffic is allowed

Question 17

A pod is stuck in Pending state. You run 'kubectl describe pod my-pod' and see the event: '0/4 nodes are available: 1 node(s) had taint {gpu: true} that the pod didn't tolerate, 3 node(s) had resource pressure.'. What is the most likely cause?

Accepted Answer

The pod needs a toleration for the gpu taint, and nodes have resource constraints.. The event message explicitly states that 1 node has a taint (gpu: true) that the pod does not tolerate, and 3 nodes have resource pressure (e.g., memory, disk, or PID exhaustion). A pod remains in Pending state when no node can satisfy its scheduling requirements; adding a toleration for the gpu taint would allow scheduling on that node, but the resource pressure on the other nodes must also be resolved (e.g., by freeing resources or increasing capacity).

Answer

The pod has a nodeSelector that doesn't match any node.

Answer

The pod is using a deprecated API version.

Answer

The pod's image pull secret is missing.

Question 18

A developer runs 'kubectl port-forward service/my-service 8080:80'. What does this command do?

Accepted Answer

It forwards incoming traffic on local port 8080 to port 80 on the service's ClusterIP.. `kubectl port-forward` creates a tunnel from a local port on the client machine to a specified port on a Kubernetes resource, in this case a Service. It forwards traffic received on localhost:8080 to the Service's ClusterIP on port 80, allowing the developer to access the service without exposing it externally.

Answer

It creates a proxy that routes traffic from the service's ClusterIP to the local machine on port 8080.

Answer

It exposes the service as a NodePort on port 8080.

Answer

It creates a new service of type LoadBalancer on port 8080.

Question 19

A NetworkPolicy named 'deny-all' is applied to a namespace with podSelector: {}. The policy has no ingress rules. What is the effect?

Accepted Answer

All ingress traffic to pods in the namespace is denied, but egress traffic is allowed.. A NetworkPolicy with `podSelector: {}` selects all pods in the namespace. With no ingress rules defined, the policy defaults to denying all ingress traffic to those pods, while egress traffic remains unrestricted unless explicitly denied by another policy. This is because Kubernetes NetworkPolicy is additive for ingress: if any policy selects a pod, the default allow for ingress is overridden, and only explicitly allowed ingress traffic is permitted.

Answer

All traffic to and from pods in the namespace is denied.

Answer

Only traffic from pods in the same namespace is allowed.

Answer

All traffic is allowed because podSelector: {} matches nothing.

Question 20

You create a Service of type LoadBalancer in a Kubernetes cluster that does not have an external load balancer provider (e.g., bare-metal). What will be the state of the EXTERNAL-IP field when you run 'kubectl get svc'?

Accepted Answer

. When a Service of type LoadBalancer is created in a Kubernetes cluster without an external load balancer provider (e.g., bare-metal or on-premises), the cloud-controller-manager component responsible for provisioning the external load balancer is absent or non-functional. As a result, the external IP address remains unassigned, and `kubectl get svc` displays `` for the EXTERNAL-IP field until a controller sets it. This state persists indefinitely unless an external tool like MetalLB is deployed to fulfill the LoadBalancer request.

Answer

The ClusterIP

Answer

The node's IP address

Answer

<none>