KCNA Practice Test 4 — 10 Questions

Question 1

You have a Kubernetes cluster with multiple namespaces. You need to allow communication only from pods with label 'app: frontend' to pods with label 'app: backend' in the same namespace. Which resource should you use?

Accepted Answer

NetworkPolicy. A NetworkPolicy is used to control ingress and egress traffic to pods based on labels and other selectors. It can be used to restrict communication between pods.

Answer

RBAC Role

Answer

PodSecurityPolicy

Answer

Service

Question 2

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

Accepted Answer

Verify that the kube-proxy is running on the node. Option A is correct because kube-proxy is the component responsible for implementing the ClusterIP Service abstraction by managing iptables or IPVS rules on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the backend pods, making the Service unreachable from within the cluster.

Answer

Check that the container runtime is working

Answer

Check the kube-apiserver status

Answer

Restart all nodes in the cluster

Question 3

An administrator wants to ensure that a specific pod only runs on nodes that have solid-state drives (SSDs). Nodes with SSDs are labeled with 'disktype=ssd'. Which pod specification field should be used?

Accepted Answer

nodeSelector. The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes with specific labels. By setting `nodeSelector: { disktype: ssd }`, the scheduler will only place the Pod on nodes that have the label `disktype=ssd`, which matches the administrator's requirement exactly. This field is a hard constraint that does not support complex expressions, but it is ideal for straightforward label-based node selection.

Answer

container resource limits

Answer

tolerations

Answer

nodeAffinity

Question 4

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

Accepted Answer

Use the Kubernetes DNS service to resolve the Service name 'service-b'. Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Answer

Use an external service registry like Consul or etcd

Answer

Hardcode the cluster IP of Service B in the configuration of Service A

Answer

Use environment variables injected by the Kubernetes API into each pod

Question 5

What does SLA stand for in the context of service reliability?

Accepted Answer

Service Level Agreement. SLA stands for Service Level Agreement, a contract specifying expected service level.

Answer

Service Level Indicator

Answer

Service Level Availability

Answer

Service Level Objective

Question 6

Which TWO of the following are responsibilities of the kubelet? (Select 2)

Accepted Answer

Registering the node with the cluster and reporting node status. The kubelet is the node agent that ensures containers are running and healthy, and it reports node status to the control plane. kube-proxy handles network rules, and the scheduler assigns pods to nodes.

Answer

Scheduling pods onto nodes based on resource availability

Answer

Creating and managing network iptables rules for Services

Answer

Storing cluster configuration data

Question 7

Which of the following is used to logically isolate resources within a Kubernetes cluster?

Accepted Answer

Namespaces. Namespaces provide logical isolation for resources. Option C is correct.

Answer

Annotations

Answer

Selectors

Answer

Labels

Question 8

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

Accepted Answer

Pods continue running, but new pods cannot be scheduled. When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Answer

All pods are immediately terminated

Answer

Pods are rescheduled to the control-plane node

Answer

The worker node is automatically cordoned

Question 9

A user reports that they cannot connect to a Service from within the cluster. The Service is of type ClusterIP. Running 'kubectl get endpoints service-name' shows no endpoints. What is the most likely cause?

Accepted Answer

The Service's pod selector does not match any running pods. If endpoints are empty, the Service selector does not match any pods, or the pods are not ready.

Answer

The Service is not associated with a namespace

Answer

The Service is exposed on the wrong port

Answer

The kube-proxy is not running on the node

Question 10

A user reports that they cannot connect to a database service named 'db-service' from another pod in the same namespace. The service selector matches the database pod's labels. Which command would you run FIRST to troubleshoot the service's endpoints?

Accepted Answer

kubectl get endpoints db-service. Option B is correct because `kubectl get endpoints db-service` directly shows whether the service has any endpoints (i.e., pod IPs) associated with it. If the endpoints list is empty, it indicates that the service's label selector is not matching any pods, which is the most common cause of connectivity failure. This is the fastest way to verify the fundamental prerequisite for service-to-pod traffic.

Answer

kubectl describe pod db-service

Answer

kubectl exec -it <some-pod> -- curl db-service

Answer

kubectl logs db-service