KCNA Kubernetes Fundamentals Practice Test 1 — 15 Questions

Question 1

An application requires a unique identifier per replica, stored in an environment variable. Which Kubernetes resource should be used to inject this identifier into each pod without manual updates?

Accepted Answer

StatefulSet with an environment variable derived from the pod name.. A StatefulSet provides stable, unique network identities and ordinal pod names (e.g., web-0, web-1), which can be exposed to containers via the downward API as environment variables. This allows each replica to derive a unique identifier from its pod name without manual intervention. Deployments, DaemonSets, and Jobs do not provide the same stable per-replica identity.

Answer

Deployment with pod anti-affinity to schedule each pod on a different node.

Answer

DaemonSet with a node name environment variable.

Answer

Job with a completion index environment variable.

Question 2

A pod in a ReplicaSet is failing with 'CrashLoopBackOff'. 'kubectl logs pod' shows 'Error: listen tcp :8080: bind: address already in use'. What is the most likely cause?

Accepted Answer

The container's process is not terminating quickly enough on SIGTERM, causing a port conflict on restart.. The error 'address already in use' on port 8080 indicates that when the container restarts, the previous process is still holding the port. This typically happens when the application does not handle SIGTERM properly and does not shut down within the terminationGracePeriodSeconds (default 30s), so the old process lingers while the new one tries to bind to the same port, causing a CrashLoopBackOff.

Answer

The readiness probe is misconfigured.

Answer

The container image is missing the application binary.

Answer

The pod is using hostPort and two pods on the same node conflict.

Question 3

Which TWO of the following are valid ways to expose a set of pods as a network service within a Kubernetes cluster?

Accepted Answer

Create a Service of type ClusterIP.. A Service of type ClusterIP exposes a set of pods as a network service within the cluster by assigning a stable virtual IP address and DNS name. Traffic to this IP is load-balanced across the pods matching the Service's label selector, enabling internal cluster communication without external exposure. An Ingress resource does not directly expose pods, but it routes external HTTP/HTTPS traffic to an internal Service (e.g., ClusterIP or NodePort), which then forwards to the pods. Therefore, both D and E are valid ways to expose pods as a network service. In contrast, a StatefulSet manages pod identity and storage, not network exposure; an ExternalName Service provides a DNS alias but does not route traffic to pods; and a ConfigMap stores configuration data, not pod IPs.

Answer

Create a StatefulSet with pod hostnames.

Answer

Create a Service of type ExternalName.

Answer

Create a ConfigMap with pod IPs.

Question 4

Which THREE of the following are required for a Kubernetes pod to be considered healthy and ready to serve traffic?

Accepted Answer

The startup probe has succeeded.. A startup probe must succeed before the kubelet considers the container started. Until the startup probe succeeds, the readiness and liveness probes are not active, so the pod cannot be marked healthy or ready. This is defined in the Kubernetes API for startup probes, which delay the start of other probes until the application has initialized.

Answer

The pod has at least one endpoint in its Service's endpoints list.

Answer

The liveness probe has succeeded.

Question 5

A team notices that a pod remains in 'CrashLoopBackOff' state after deployment. The application logs show 'Error: unable to bind to port 8080'. What is the most likely cause?

Accepted Answer

The container's port is already in use on the host node.. The error 'unable to bind to port 8080' indicates that the container process cannot open port 8080 for listening. The most likely cause is that another process on the host node is already using port 8080, preventing the container from binding to it. This is a classic port conflict scenario, where the host's network namespace has a port already allocated, and the container (even with its own network namespace) may be using host networking or the port is mapped from the host.

Answer

The pod's resource limits are too low.

Answer

An environment variable has a typo in the Deployment spec.

Answer

The readiness probe is misconfigured.

Question 6

A DevOps engineer wants to ensure that a critical application pod is rescheduled on a different node if its current node fails. The pod should be scheduled with a preference for nodes in a specific availability zone but can run elsewhere if needed. Which scheduling mechanism should be used?

Accepted Answer

Use a Deployment with a preferred nodeAffinity rule.. A Deployment with a preferred nodeAffinity rule is correct because it allows the pod to be rescheduled on a different node if the current node fails, while expressing a preference for nodes in a specific availability zone. The 'preferred' (soft) rule ensures scheduling flexibility—the pod can run elsewhere if no zone-matching nodes are available—which aligns with the requirement for high availability without strict zone constraints.

Answer

Use a StatefulSet with podAntiAffinity.

Answer

Run a static pod defined in the kubelet configuration.

Answer

Create a DaemonSet with a nodeSelector for the zone.

Question 7

Refer to the exhibit. A pod is created with the above manifest. The container runs nginx listening on port 80, but the liveness probe is configured to check port 8080. What will happen?

Accepted Answer

The liveness probe will fail, causing the container to be restarted.. The liveness probe is configured to check port 8080, but the container only listens on port 80. Since the probe will never receive a successful HTTP response from port 8080, it will fail repeatedly. According to Kubernetes behavior, after the failure threshold is reached (default: 3 failures with a 10-second interval), kubelet will restart the container to attempt to recover it. This is the intended mechanism for detecting and remediating deadlocked or unresponsive applications.

Answer

The pod will fail to start because the probe port mismatches the container port.

Answer

The liveness probe will fail, but the pod will still be marked as Ready.

Answer

The pod will run successfully because the probe is not required.

Question 8

A StatefulSet named 'web' with 3 replicas is deployed in the 'production' namespace. The first two pods are running, but the third pod 'web-2' is pending with the error shown. What is the most likely cause?

Accepted Answer

The pod anti-affinity rule prevents more than one pod per node, and there are only 3 nodes. The error indicates that the third pod 'web-2' is pending due to a scheduling conflict. Pod anti-affinity rules, when configured with a 'requiredDuringSchedulingIgnoredDuringExecution' policy, prevent more than one pod from the same StatefulSet from being scheduled on the same node. With only 3 nodes available and the first two pods already occupying distinct nodes, the third pod cannot be placed, causing it to remain pending.

Answer

The StatefulSet requires a headless Service that does not exist

Answer

The pod has a resource request that cannot be satisfied by any node

Answer

There are not enough nodes in the cluster to schedule the third pod

Question 9

Refer to the exhibit. The nginx Pod is created, but the Pod never becomes Ready. The container starts and runs. What is the most likely reason?

Accepted Answer

The liveness probe is failing because /healthz endpoint does not exist, causing the container to restart.. The liveness probe is configured to check the /healthz endpoint, but the default nginx container does not serve a /healthz endpoint. This causes the liveness probe to fail, and Kubernetes restarts the container according to the probe's failure threshold. Since the container keeps restarting, it never reaches the Ready state, even though the container starts and runs initially.

Answer

The nginx:latest image does not exist.

Answer

The containerPort is not matching the actual port nginx listens on.

Answer

The readiness probe is failing because the root path is not returning 200.

Question 10

Match each Kubernetes scheduler concept to its description.

Accepted Answer

NodeAffinity: Constraints on which nodes a pod can be scheduled based on node labels.. NodeAffinity and NodeSelector both use node labels but differ in expressiveness. PodAffinity schedules relative to other pods. Taints/Tolerations control which pods can be placed on nodes. Common confusion: swapping NodeAffinity with PodAffinity or Taints/Tolerations.

Answer

NodeAffinity: Ensures pods are scheduled together with other pods on the same node.

Answer

PodAffinity: Repels pods from nodes unless they have a specific label.

Question 11

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff with an OOMKilled message, which means the container was terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeded its memory limit. Increasing the memory limit in the container's resource specification allows the container to use more memory before being killed, directly addressing the root cause.

Answer

Delete the namespace and redeploy all workloads

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Question 12

You deploy a new version of your application by updating the container image in the Deployment manifest. The rollout seems to be progressing, but after a few minutes you notice that the new Pods are failing and the old Pods are still running. What is the most likely reason?

Accepted Answer

The new Pods are failing readiness probes, so the Deployment pauses the rollout and keeps the old replicas. When a new Pod fails its readiness probe, the Deployment controller considers the new ReplicaSet unhealthy and pauses the rollout. The controller keeps the old ReplicaSet running to maintain the desired number of available replicas, preventing traffic disruption until the new Pods pass their probes or the rollout is manually resumed.

Answer

The Deployment was created with 'kubectl create deployment' instead of 'kubectl apply'

Answer

The new Pods are not receiving traffic because the Service selector doesn't match

Answer

The Deployment's update strategy is set to 'Recreate'

Question 13

Which THREE of the following are valid attributes in a Kubernetes Pod specification? (Select 3)

Accepted Answer

volumes. Option A (volumes) is correct because a Pod spec can declare a `volumes` list at the pod level, defining storage volumes that containers then mount via `volumeMounts`. Option D (nodeSelector) is correct because `nodeSelector` is a pod-level field that constrains scheduling by matching key/value labels on nodes. Option E (containers) is correct because `containers` is a required field in the Pod spec's `spec` section, listing the container definitions that run in the pod. Option B (ports) is not a valid top-level Pod spec attribute; ports are declared inside a container as `ports` (with `containerPort`), not at the pod level. Option C (clusterIP) is not a Pod attribute; it is a field of a Service spec that assigns the virtual IP for a Service.

Answer

ports

Answer

clusterIP

Question 14

A developer creates a Deployment with the following YAML snippet:

```yaml
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
```

What will happen if the label 'app: frontend' is omitted from the pod template's metadata?

Accepted Answer

The Deployment will fail to create because the selector and template labels mismatch. The Deployment's `spec.selector.matchLabels` must match the pod template's labels. If `app: frontend` is omitted from the template metadata, the selector (which is immutable after creation) will not match any pods, causing the Deployment controller to fail to create pods and report a `SelectorTemplateMismatch` error. Kubernetes validates this at admission time, rejecting the Deployment creation.

Answer

The Deployment will create pods with a random label

Answer

The pods will be created but will not be part of the Deployment

Answer

The pods will be created but will not have networking

Question 15

What is the smallest deployable unit in Kubernetes?

Accepted Answer

Pod. The Pod is the smallest deployable unit in Kubernetes because it encapsulates one or more containers that share the same network namespace, storage volumes, and lifecycle. Containers are not directly scheduled onto nodes; instead, Kubernetes always wraps them into Pods, which are the atomic unit of scheduling and execution. This design ensures that co-located containers (e.g., a sidecar and its main app) can communicate via localhost and share resources without additional orchestration.

Answer

Node

Answer

Container

Answer

Deployment