KCNA Practice Test 41 — 15 Questions

Question 1

Which THREE of the following are valid reasons to use a StatefulSet instead of a Deployment? (Select 3)

Accepted Answer

The application requires stable unique network identifiers that persist across rescheduling.. Option B is correct because StatefulSets give each Pod a stable, unique network identity via a headless Service and predictable DNS names (pod-0, pod-1, etc.) that persist across rescheduling, which Deployments do not guarantee. Option D is correct because StatefulSets use volumeClaimTemplates to bind a dedicated PersistentVolumeClaim to each Pod, so each replica keeps its own persistent storage across rescheduling, unlike a Deployment where all replicas typically share or lack per-Pod PVCs. Option E is correct because StatefulSets provide ordered, graceful deployment and scaling (0..N-1) and reverse-order termination with graceful shutdown, which is essential for clustered stateful apps. Option A is not a reason to use a StatefulSet because unordered, rapid scaling is exactly what Deployments handle well. Option C is not a reason because stateless, arbitrarily replicable workloads are the canonical use case for Deployments, not StatefulSets.

Answer

The application needs to be scaled up and down quickly without regard to order.

Answer

The application is stateless and can be replicated arbitrarily.

Question 2

Which Kubernetes object provides stable network endpoints and load balancing for a set of Pods?

Accepted Answer

Service. A Service is the Kubernetes abstraction that defines a logical set of Pods and a policy for accessing them, providing a stable IP address and DNS name that remains constant even as Pods are created or destroyed. Services use label selectors to identify target Pods and perform Layer 4 (TCP/UDP) load balancing across them, either via iptables, IPVS, or eBPF rules in kube-proxy.

Answer

NetworkPolicy

Answer

Deployment

Answer

Ingress

Question 3

Which Kubernetes resource can be used to assign a pod to a specific node?

Accepted Answer

Node affinity rules in the pod spec. Node affinity rules in the pod spec are a set of constraints that define which nodes a pod can be scheduled on, based on node labels. This is a native Kubernetes scheduling feature that allows you to attract pods to specific nodes using required or preferred matching rules, such as `requiredDuringSchedulingIgnoredDuringExecution`. This directly answers the question of assigning a pod to a specific node.

Answer

A NetworkPolicy

Answer

A Service account

Answer

A ConfigMap

Question 4

Your application requires persistent storage that must be available across pod restarts and rescheduling. What is the recommended approach?

Accepted Answer

Use a PersistentVolumeClaim (PVC) and mount it into the pod. PersistentVolumeClaim (PVC) is the recommended approach because it decouples storage provisioning from pod lifecycle, ensuring data persists across pod restarts and rescheduling. PVCs request storage from a PersistentVolume (PV) that is backed by a physical storage system (e.g., NFS, cloud block storage), and the pod mounts this volume, allowing the data to survive even if the pod is deleted and recreated on a different node.

Answer

Store data in the container's writable layer

Answer

Use hostPath volume

Answer

Use an emptyDir volume

Question 5

A user reports that they can access a service by its ClusterIP but not by its DNS name from within the cluster. What is the most likely cause?

Accepted Answer

The CoreDNS pod is not running or is misconfigured. Accessing a service by ClusterIP works because it relies on iptables/IPVS rules managed by kube-proxy, which are independent of DNS. However, DNS name resolution within the cluster is handled by CoreDNS, which translates service names to ClusterIPs. If CoreDNS is not running or misconfigured, DNS queries for the service name will fail, while direct ClusterIP access remains functional. This is the most likely cause because the symptom specifically points to a DNS resolution failure.

Answer

The kube-proxy is not running on the node

Answer

The service is of type NodePort

Answer

The service selector does not match any pods

Question 6

Which Kubernetes control plane component is responsible for storing the cluster state and configuration data?

Accepted Answer

etcd. etcd is the distributed key-value store that serves as Kubernetes' single source of truth for all cluster state and configuration data. It stores objects like Pods, Services, Deployments, and Secrets, and is the only component that holds persistent state. The kube-apiserver reads from and writes to etcd, but etcd itself is the storage backend.

Answer

kube-controller-manager

Answer

kube-apiserver

Answer

kube-scheduler

Question 7

Which of the following is a core component of the three pillars of observability?

Accepted Answer

Logs. The three pillars of observability are logs, metrics, and traces. Logs are discrete, timestamped records of events that provide detailed context about what happened in a system, making them a foundational pillar. Alerting, SLIs, and dashboards are downstream consumers or derived artifacts built on top of these pillars, not pillars themselves.

Answer

Alerting

Answer

SLIs

Answer

Dashboards

Question 8

A service of type ClusterIP is created but pods cannot reach it using the service name. The pods are in the same namespace. What is a likely cause?

Accepted Answer

CoreDNS is not running or misconfigured. When a ClusterIP service cannot be reached by its DNS name from pods in the same namespace, the most common cause is that CoreDNS (the cluster DNS resolver) is not running or is misconfigured. Kubernetes relies on CoreDNS to resolve service names to ClusterIP addresses; if CoreDNS is down or its configuration is incorrect, DNS queries for the service name will fail, even though the service itself and its endpoints are healthy.

Answer

The service is not exposed externally

Answer

The service port does not match the container port

Answer

The selector does not match any pod labels

Question 9

Which of the following is a correct YAML structure for a Service of type ClusterIP?

Accepted Answer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
    - port: 80. It defines a Kubernetes Service of kind Service with apiVersion v1, which is the correct API group for core Service objects. The spec includes a selector to target pods with label app: myapp and a port mapping with port 80, which is the standard structure for a ClusterIP Service (the default type when type is omitted). The selector field is required to route traffic to matching pods, and the ports array correctly specifies the service port.

Answer

apiVersion: v1
kind: Pod
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
    - port: 80

Answer

apiVersion: apps/v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: myapp
  ports:
    - port: 80

Answer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  app: myapp
  ports:
    - port: 80

Question 10

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

Accepted Answer

Install container runtime and Kubernetes tools, then run kubeadm init on the control plane, then install a pod network plugin, then run kubeadm join on worker nodes.. First install runtime and Kubernetes tools, then init control plane, add network plugin, and join workers.

Answer

Install container runtime and Kubernetes tools, then install a pod network plugin, then run kubeadm init on the control plane, then run kubeadm join on worker nodes.

Answer

Run kubeadm init on the control plane, then install container runtime and Kubernetes tools, then install a pod network plugin, then run kubeadm join on worker nodes.

Answer

Install container runtime and Kubernetes tools, then run kubeadm init on the control plane, then run kubeadm join on worker nodes, then install a pod network plugin.

Question 11

What is the role of etcd in a Kubernetes cluster?

Accepted Answer

It stores the cluster state and configuration. etcd is a distributed, consistent key-value store that serves as Kubernetes' primary data store. It holds the entire cluster state, including all object definitions (Pods, Services, Deployments, etc.), configuration data, and secrets. The kube-apiserver is the only component that interacts directly with etcd, ensuring that all state changes go through a consistent, transactional backend. Without etcd, the cluster would have no persistent record of its desired or current state.

Answer

It manages network policies

Answer

It schedules pods onto nodes

Answer

It provides DNS resolution for services

Question 12

A Prometheus alert rule fires when the error rate exceeds 5% for 5 minutes. The alert is sent to Alertmanager. What must be configured in Alertmanager to ensure the alert is deduplicated, grouped, and routed to the correct team?

Accepted Answer

A route configuration. A route configuration in Alertmanager defines how alerts are grouped, deduplicated, and routed to specific receivers (e.g., email, Slack, PagerDuty) based on label matchers. The route tree determines which team receives which alerts, and grouping parameters control deduplication and batching. Without a route, Alertmanager cannot direct alerts to the correct team.

Answer

An inhibition rule

Answer

A recording rule

Answer

A silence rule

Question 13

Which command would you use to view the logs of a container named 'nginx' in a Pod named 'web-pod'?

Accepted Answer

kubectl logs web-pod -c nginx. The `kubectl logs` command retrieves container logs from a Pod, and when a Pod contains multiple containers, the `-c` flag is required to specify which container's logs to view. Here, `kubectl logs web-pod -c nginx` explicitly targets the 'nginx' container within the 'web-pod' Pod, which is the standard Kubernetes API approach for fetching container stdout/stderr streams.

Answer

kubectl logs web-pod nginx

Answer

kubectl describe pod web-pod

Answer

kubectl exec web-pod -- cat /var/log/nginx/access.log

Question 14

What is the primary advantage of using Helm to package a Kubernetes application?

Accepted Answer

It provides a templating engine to parameterize Kubernetes manifests. Helm's primary advantage is its templating engine, which lets you parameterize Kubernetes manifests with values files so the same chart can be reused across environments (dev, staging, prod) with different configurations. It also provides packaging, versioning, and release management, but templating is the core value proposition. The other options describe functionality handled by other tools.

Answer

It automatically scales applications based on load

Answer

It enforces security policies on deployments

Answer

It manages network policies between services

Question 15

A pod has both resource requests and limits defined. The container is using more CPU than the request but less than the limit. What will happen?

Accepted Answer

The container will continue to run normally. When a container's CPU usage exceeds its request but stays below its limit, Kubernetes treats the container as running within its allowed range. The request guarantees baseline resources, while the limit caps usage; as long as usage is below the limit, no throttling or eviction occurs. The container continues to run normally because CPU limits are enforced via CFS quotas only when usage reaches the limit, and requests are used for scheduling and QoS classification.

Answer

The container will be evicted from the node

Answer

The container will be throttled

Answer

The container will be terminated