CKA Practice Test 5 — 10 Questions

Question 1

An administrator needs to initialize a new Kubernetes control plane node using kubeadm. Which of the following is the correct command to initialize the control plane with a specific pod network CIDR of 10.244.0.0/16?

Accepted Answer

kubeadm init --pod-network-cidr=10.244.0.0/16. Option A is correct because `kubeadm init` uses the `--pod-network-cidr` flag to specify the CIDR range for the pod network, which is required by many CNI plugins (e.g., Flannel defaults to 10.244.0.0/16). This flag tells kubeadm to configure the control plane components (like the controller manager) to allocate pod IPs from this range.

Answer

kubeadm init --cidr=10.244.0.0/16

Answer

kubeadm init --network-cidr=10.244.0.0/16

Answer

kubeadm init --service-cidr=10.244.0.0/16

Question 2

Which TWO of the following are valid methods to add a worker node to an existing Kubernetes cluster that was initialized with kubeadm?

Accepted Answer

Use kubeadm token create and then kubeadm join with the token. Option A is correct because `kubeadm token create` generates a bootstrap token that is used by `kubeadm join` to authenticate the new node with the control plane. This is the standard, documented method for adding worker nodes to a cluster initialized with kubeadm, leveraging TLS bootstrap and the Bootstrap Token Authentication protocol.

Answer

Use kubectl create node command from the control plane

Answer

Install kubelet on the worker node and it will automatically join the cluster

Answer

Run kubeadm init on the worker node and then join

Question 3

A company deploys a web application with multiple replicas in a Kubernetes cluster. Users report intermittent connectivity issues. The application pods are exposed via a ClusterIP Service. To ensure stable connectivity, which action should be taken?

Accepted Answer

Set service.spec.sessionAffinity to ClientIP. Intermittent connectivity issues with multiple replicas often stem from requests being distributed across different pods, which can break session state if the application is not stateless. Setting `service.spec.sessionAffinity` to `ClientIP` ensures that all requests from a given client IP are routed to the same pod, providing stable connectivity for stateful sessions without changing the service type or removing the ClusterIP.

Answer

Change the Service type to NodePort

Answer

Remove the ClusterIP Service and use headless service

Answer

Add a readiness probe to the pods

Question 4

Which TWO of the following are valid reasons to use a Headless Service?

Accepted Answer

To enable a client to discover all pod IPs for a StatefulSet.. Option C is correct because a Headless Service (with `clusterIP: None`) does not provide a single stable IP or load balancing. Instead, it returns DNS A/AAAA records for all pod IPs that match the service's selector. This is essential for StatefulSets, where each pod has a unique identity and clients need to discover and connect to specific pods directly, such as in a database cluster.

Answer

To provide a single stable IP address for the service.

Answer

To expose a service externally via a cloud load balancer.

Answer

To provide load-balanced access to a set of pods.

Question 5

A DevOps team wants to ensure that a critical application Pod is always scheduled on a node that has SSD storage. They have labeled one node with 'disk=ssd'. Which scheduling approach should they use to guarantee this placement?

Accepted Answer

Add a nodeSelector with disk=ssd to the Pod spec.. Option D is correct because a `nodeSelector` is the simplest and most direct way to guarantee that a Pod is scheduled only on nodes that have a specific label. By adding `nodeSelector: disk: ssd` to the Pod spec, Kubernetes will ensure the Pod is placed exclusively on nodes with the `disk=ssd` label, which matches the labeled node. This approach is straightforward and meets the requirement without additional complexity.

Answer

Set nodeName in the Pod spec to the node name.

Answer

Use nodeAffinity with requiredDuringSchedulingIgnoredDuringExecution and a matchExpression for disk=ssd.

Answer

Add a toleration for a taint that the node has.

Question 6

Which THREE of the following are true about Network Policies in Kubernetes?

Accepted Answer

They are namespaced resources.. Network Policies are namespaced resources in Kubernetes, meaning they are defined within a specific namespace and only apply to pods in that namespace. This is confirmed by the Kubernetes API, where NetworkPolicy is a namespaced resource under the networking.k8s.io/v1 API group, and it cannot be applied cluster-wide without additional tooling like a cluster-scoped policy engine.

Answer

They can block traffic at the node level.

Answer

They can modify packet contents.

Question 7

After applying this NetworkPolicy, a pod in the default namespace tries to curl an external website (e.g., google.com) and fails. What is the reason?

Accepted Answer

The Egress rule is defined but has no allow rules, so all egress is denied.. Option A is correct because the NetworkPolicy defines an Egress rule with an empty `rules` array, which means no egress traffic is explicitly allowed. In Kubernetes, when a NetworkPolicy selects a pod, it defaults to denying all traffic of the specified direction unless explicitly allowed. Since the Egress rule has no allow rules, all outbound traffic from the selected pods, including HTTP/HTTPS requests to external websites like google.com, is blocked by the policy.

Answer

The Ingress rule blocks all incoming traffic, preventing DNS responses.

Answer

The policy is applied to all namespaces, causing a conflict.

Answer

The policy only applies to pods with specific labels.

Question 8

Drag and drop the steps to upgrade a Kubernetes cluster using kubeadm into the correct order.

Question 9

Drag and drop the steps to troubleshoot a CrashLoopBackOff pod into the correct order.

Question 10

Drag and drop the steps to troubleshoot a Node that is in NotReady state into the correct order.