CKA Practice Test 23 — 15 Questions

Question 1

Which THREE statements about NetworkPolicy are correct?

Accepted Answer

To allow traffic from a specific namespace, you can use a namespaceSelector in the ingress rule.. A NetworkPolicy ingress rule can use a `namespaceSelector` to allow traffic from pods in a specific namespace. Option C is correct because an empty `podSelector: {}` selects all pods in the namespace. Option D is correct because `podSelector.matchLabels` is used to select pods based on specific labels. Options B and E are incorrect: B is false because without any NetworkPolicy, all traffic is allowed; E is false because NetworkPolicy is namespaced, not cluster-scoped.

Answer

If no NetworkPolicy exists, all traffic is denied by default.

Answer

NetworkPolicy is a cluster-scoped resource.

Question 2

You need to create a ServiceAccount named 'deployer' and grant it permission to create Deployments in namespace 'app'. Which YAML snippet correctly creates the necessary RBAC resources?

Accepted Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io. It creates a ServiceAccount named 'deployer' in the 'app' namespace, a Role in the same namespace with rules allowing 'create' on 'deployments' (which belong to the 'apps' API group), and a RoleBinding that binds the ServiceAccount to that Role. This grants the ServiceAccount permission to create Deployments only within the 'app' namespace, which is the required scope.

Answer

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: ClusterRole
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: ClusterRole
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Answer

apiVersion: v1
kind: ServiceAccount
metadata:
  name: deployer
  namespace: app
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: default
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: deployer
  namespace: app
subjects:
- kind: ServiceAccount
  name: deployer
  namespace: app
roleRef:
  kind: Role
  name: deployer
  apiGroup: rbac.authorization.k8s.io

Question 3

A pod remains in Pending state. You run 'kubectl describe pod mypod' and see the following event: '0/3 nodes are available: 2 node(s) had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 1 node(s) didn't match pod anti-affinity rules.' What is the best action to schedule the pod?

Accepted Answer

Modify the pod's anti-affinity rules or remove the conflicting pod on the third node. The pod is unschedulable because one node has a pod anti-affinity rule conflict, and the other two nodes have a control-plane taint. The best action is to modify the pod's anti-affinity rules (e.g., relax the requiredDuringSchedulingIgnoredDuringExecution constraint) or remove the conflicting pod on the third node, as this directly resolves the scheduling conflict without affecting the control-plane taint or replicas.

Answer

Increase the number of replicas

Answer

Remove the node.kubernetes.io/control-plane taint from the control plane nodes

Answer

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

Question 4

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the most likely cause?

Accepted Answer

The pod does not tolerate the node's taint.. The pod is stuck in 'Pending' because the scheduler cannot find a node that satisfies its scheduling constraints. The 'kubectl describe pod' output explicitly states that 1 node has a taint (node-role.kubernetes.io/master) that the pod does not tolerate. By default, pods do not tolerate the master taint, so they are not scheduled onto master nodes unless a toleration is added. This is the direct cause of the pending state.

Answer

The pod is missing resource requests.

Answer

The node is cordoned.

Answer

The kubelet is not running on the node.

Question 5

Which THREE are valid steps when upgrading a Kubernetes cluster using kubeadm? (Select 3)

Accepted Answer

Upgrade kubelet and kubectl on the node.. After upgrading kubeadm on the control plane, you must upgrade kubelet and kubectl on each node to match the target Kubernetes version. The kubelet is the primary node agent that communicates with the control plane, and kubectl is the CLI tool used to interact with the cluster. Without upgrading these components, the node may fail to register or report an incompatible version, causing the node to be in a NotReady state.

Answer

Upgrade the container runtime to a compatible version.

Answer

Run 'kubeadm upgrade apply' on the worker node.

Question 6

Which THREE of the following are valid steps to troubleshoot a node that is in 'NotReady' state?

Accepted Answer

Check the kubelet status using 'systemctl status kubelet' on the node. Options A, B, and C are valid troubleshooting steps to investigate a NotReady node. Option A checks if kubelet is running, Option B examines kubelet logs for errors, and Option C shows node conditions. Option D (restarting kubelet) is a remediation action, not a troubleshooting step. Option E (deleting and rejoining) is a recovery step.

Answer

Restart the kubelet using 'systemctl restart kubelet'

Answer

Delete the node object and rejoin it to the cluster

Question 7

Which kubeconfig context is currently active?

Accepted Answer

kubectl config current-context. `kubectl config current-context` is the dedicated kubectl command that displays the name of the currently active context from the kubeconfig file. The active context determines which cluster, user, and namespace are used by default for kubectl commands, making this the precise way to identify the active context.

Answer

kubectl config view

Answer

kubectl cluster-info

Answer

kubectl config get-contexts

Question 8

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?

Accepted Answer

Create an EncryptionConfiguration resource specifying a provider like 'aescbc' and configure the kube-apiserver with --encryption-provider-config.. Kubernetes supports encrypting secrets and other resources at rest via an EncryptionConfiguration object, which is passed to the kube-apiserver using the --encryption-provider-config flag. This mechanism encrypts data before it is written to etcd, ensuring that even if the etcd storage is compromised, the data remains unreadable without the encryption key.

Answer

Use LUKS to encrypt the disk partition where etcd data is stored.

Answer

Use TLS certificates to encrypt communication between etcd and the API server.

Answer

Configure etcd to use encryption at rest by setting --experimental-encryption-provider.

Question 9

You are troubleshooting a DNS issue in the cluster. You exec into a pod and run 'nslookup kubernetes.default.svc.cluster.local'. The command returns 'server can't find kubernetes.default.svc.cluster.local: NXDOMAIN'. What is the MOST likely cause?

Accepted Answer

The CoreDNS pod(s) are not running or are misconfigured. NXDOMAIN indicates that the DNS server does not have a record for that name. The most common cause is that the CoreDNS pod(s) are not running or are misconfigured. Option A would cause a timeout not NXDOMAIN. Option B would cause a different error (connection refused). Option D might cause partial resolution but not NXDOMAIN for the entire service name.

Answer

The kube-dns service does not exist

Answer

The pod's /etc/resolv.conf points to an external DNS server instead of the cluster DNS

Answer

The pod's network policy blocks DNS traffic

Question 10

Which kubectl command is used to drain a node before performing maintenance?

Accepted Answer

kubectl drain node01. The `kubectl drain` command is the correct tool for safely evicting all pods from a node before maintenance. It marks the node as unschedulable (similar to `cordon`) and then gracefully terminates pods, respecting PodDisruptionBudgets, ensuring workloads are rescheduled to other nodes without disruption.

Answer

kubectl cordon node01

Answer

kubectl taint node node01 key=value:NoExecute

Answer

kubectl delete node node01

Question 11

Which TWO network plugins (CNI) are commonly used in Kubernetes clusters? (Select TWO)

Accepted Answer

Calico. Calico is a widely adopted CNI plugin that provides network policy enforcement using IP-in-IP or VXLAN encapsulation and leverages BGP for routing. It supports both overlay and non-overlay networking, making it suitable for on-premises and cloud deployments.

Answer

CoreDNS

Answer

kube-proxy

Answer

Docker

Question 12

You have a multi-node Kubernetes cluster. After upgrading the kubelet on a worker node, the node remains in 'NotReady' state. Which TWO actions should you take to troubleshoot? (Choose TWO.)

Accepted Answer

Check the node conditions using 'kubectl describe node '. 'kubectl describe node ' shows node conditions, including the 'Ready' status and any underlying issues like 'NetworkUnavailable', 'MemoryPressure', or 'KubeletNotReady'. This command provides a high-level view of why the node is NotReady, such as a kubelet version mismatch or resource exhaustion. It is the standard first step in diagnosing node health.

Answer

Check the pod logs on the node

Answer

Check the kube-apiserver logs on the control plane

Answer

Reboot the node

Question 13

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?

Accepted Answer

The CSI driver is not installed or malfunctioning.. When `volumeBindingMode: WaitForFirstConsumer` is set, the PV is not provisioned until a pod using the PVC is scheduled to a node. If the PV is never provisioned after scheduling, the most likely cause is that the CSI driver is not installed or malfunctioning, because the dynamic provisioning request is sent to the CSI driver, and without a functioning driver, the PV creation will fail silently or not occur at all.

Answer

The PVC is not bound to a PV because no PV exists.

Answer

The pod does not have the correct node selector.

Answer

The StorageClass uses 'Immediate' binding mode.

Question 14

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?

Accepted Answer

Ingress resource with a TLS certificate. An Ingress resource with a TLS certificate is the correct choice because it provides a stable IP address (via the underlying LoadBalancer or NodePort Service) and terminates TLS at the ingress controller, allowing the web application to serve HTTPS traffic without modifying the Deployment. This meets the requirements of exposing the application externally with a fixed IP and TLS termination.

Answer

LoadBalancer Service

Answer

ClusterIP Service

Answer

NodePort Service

Question 15

Which THREE of the following are valid considerations when using resource requests and limits? (Select 3)

Accepted Answer

Requests are used by the scheduler to decide which node can accommodate the Pod.. The Kubernetes scheduler uses resource requests (CPU and memory) to determine node suitability for a Pod. The scheduler checks if the sum of requests for all Pods on a node, plus the new Pod's requests, is less than or equal to the node's allocatable capacity. Limits are not used for scheduling decisions.

Answer

Limits must be equal to requests for a Pod to be scheduled.

Answer

CPU limits guarantee the Pod will get that amount of CPU.