KCNA Kubernetes Fundamentals — 30 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

Question 16

Which three of the following are valid methods to create or update resources in Kubernetes? (Choose three.)

Accepted Answer

kubectl apply -f manifest.yaml. Option A (kubectl apply -f manifest.yaml) is correct because apply performs a declarative create-or-update by comparing the manifest against the live object and issuing the appropriate PATCH, making it the standard idempotent method to create or update resources. Option D (kubectl create -f manifest.yaml) is correct because create is a valid imperative command that submits the manifest to the API server to create the resource (it fails if the object already exists, but it is still a valid creation method). Option E (Using the Kubernetes REST API directly) is correct because kubectl itself is just a client of the API server, and any client can POST/PUT/PATCH to endpoints like /api/v1/namespaces/{ns}/pods to create or update resources. Option B (kubectl update -f manifest.yaml) is not valid because kubectl has no 'update' subcommand; the analogous operations are apply, replace, edit, or patch. Option C (kubectl replace -f manifest.yaml) is a real command but it only replaces an existing resource and fails if the object does not already exist, so it is not a general create-or-update method.

Answer

kubectl update -f manifest.yaml

Answer

kubectl replace -f manifest.yaml

Question 17

What is the primary purpose of Kubernetes?

Accepted Answer

To orchestrate containers across a cluster of machines. Kubernetes is a container orchestration platform designed to automate the deployment, scaling, and management of containerized applications across a cluster of machines. Its primary purpose is to ensure that containers run reliably and efficiently by handling scheduling, load balancing, self-healing, and rolling updates, which is why option D is correct.

Answer

To provide a graphical interface for managing containers

Answer

To replace virtual machines with containers

Answer

To compile container images from source code

Question 18

A Deployment named 'web-app' has been running with 3 replicas. After a configuration change, you notice that only 2 pods are ready. You run 'kubectl describe deployment web-app' and see 'Replicas: 3 desired | 3 total | 3 up-to-date | 2 available'. What is the most likely cause?

Accepted Answer

The pods have a failing readiness probe. The key detail is that 3 pods are desired, 3 are up-to-date, but only 2 are available. This indicates the pods are running but not passing their readiness probes, so they are not included in the Service's endpoints. A failing readiness probe prevents traffic from being routed to a pod, even if it is otherwise healthy, which matches the symptom of fewer available pods than desired.

Answer

The Deployment's resource requests exceed node capacity

Answer

The Service selector does not match the pod labels

Answer

The kubelet on one node is not functioning

Question 19

You need to update a Deployment's container image from nginx:1.14 to nginx:1.16 and ensure zero downtime. Which kubectl command should you use?

Accepted Answer

kubectl set image deployment/my-deployment nginx=nginx:1.16. `kubectl set image` directly updates the container image in the Deployment's pod template, triggering a rolling update. Kubernetes Deployments handle zero-downtime updates by default via a rolling update strategy, which gradually replaces old pods with new ones while keeping the service available.

Answer

kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.16"}]}}}}'

Answer

kubectl edit deployment my-deployment --image=nginx:1.16

Answer

kubectl update deployment my-deployment --image=nginx:1.16

Question 20

A developer creates a Service of type ClusterIP in namespace 'default'. They attempt to reach the Service from another pod in the same namespace using the Service name 'my-svc'. The connection fails. What is the most likely cause?

Accepted Answer

The cluster DNS service (CoreDNS) is not running or misconfigured. The most likely cause is that the cluster DNS service (CoreDNS) is not running or misconfigured. When a pod attempts to reach a Service by its DNS name (e.g., 'my-svc'), Kubernetes relies on CoreDNS to resolve that name to the ClusterIP. If CoreDNS is down, misconfigured, or the pod's DNS resolver is not pointing to it, the name resolution fails, causing the connection to fail even if the Service itself is correctly configured.

Answer

The Service port does not match the container port

Answer

The Service type should be NodePort

Answer

The Service selector does not match any pod labels