KCNA Kubernetes Fundamentals — Timed 20 Questions

Question 1

A developer deploys a pod that continuously restarts. 'kubectl describe pod' shows the container exits with code 137. What is the most likely cause?

Accepted Answer

The container is exceeding its memory limit and being OOM-killed.. Exit code 137 (128 + 9) indicates the container was killed by SIGKILL. In Kubernetes, this most commonly occurs when the container exceeds its memory limit, triggering the OOM (Out-Of-Memory) killer. The kubelet enforces the resource limits specified in the pod spec, and when memory usage surpasses the limit, the kernel terminates the process with SIGKILL, resulting in exit code 137.

Answer

The liveness probe is failing and restarting the container.

Answer

The init container is failing and blocking the main container.

Answer

The pod is hitting a resource quota limit at the namespace level.

Question 2

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 persistent storage per replica. The pod name (e.g., pod-0, pod-1) can be exposed via the Downward API or hostname. Option A is correct. Option B is wrong because Deployments create identical pods without ordering. Option C is wrong because DaemonSets run one pod per node. Option D is wrong because Jobs are for batch processing.

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 3

A pod is stuck in 'Pending' state. 'kubectl describe pod' shows '0/4 nodes are available: 4 node(s) had taint {node.kubernetes.io/unreachable: }, that the pod didn't tolerate.' What is the most likely cause?

Accepted Answer

All nodes are unreachable or have been cordoned.. The taint `node.kubernetes.io/unreachable` is automatically added by the node controller when a node becomes unreachable (e.g., network failure, kubelet stops heartbeating). The error shows all 4 nodes have this taint and the pod has no matching toleration, meaning the scheduler cannot place the pod. This directly indicates all nodes are unreachable or have been cordoned (which also adds the `node.kubernetes.io/unschedulable` taint, but here the specific taint is `unreachable`).

Answer

All nodes have disk pressure.

Answer

The pod has a toleration that matches the taint.

Answer

The nodes do not have enough CPU or memory.

Question 4

A team wants to minimize downtime during a Deployment rollout. Which strategy ensures that new pods are created before old pods are terminated?

Accepted Answer

Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=0.. Option C is correct because setting `maxSurge=1` and `maxUnavailable=0` in a RollingUpdate strategy ensures that one additional pod is created above the desired replica count before any existing pod is terminated. This guarantees zero downtime by maintaining full capacity during the rollout, as new pods become ready before old ones are removed.

Answer

Set strategy type to 'Recreate'.

Answer

Set strategy type to 'RollingUpdate' with maxSurge=0, maxUnavailable=1.

Answer

Set strategy type to 'RollingUpdate' with maxSurge=1, maxUnavailable=1.

Question 5

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 6

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.

Answer

Create a StatefulSet with pod hostnames.

Answer

Create a Service of type ExternalName.

Answer

Create a ConfigMap with pod IPs.

Question 7

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.. Option A is correct because 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 8

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 9

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 10

A developer creates a pod that needs to securely access a database password stored in the cluster. Which Kubernetes resource should be used to inject the password as an environment variable?

Accepted Answer

Secret. A Secret is the correct Kubernetes resource for injecting sensitive data like a database password into a Pod as an environment variable. Secrets store base64-encoded data and are designed specifically for confidential information, unlike ConfigMaps which store non-sensitive configuration. When mounted as environment variables, Secrets ensure the password is not exposed in plaintext in the Pod specification or image layers.

Answer

ServiceAccount

Answer

ConfigMap

Answer

PersistentVolumeClaim

Question 11

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taints that the pod didn't tolerate, 3 nodes had insufficient memory'. What is the most likely issue?

Accepted Answer

The pod's resource requests exceed available memory on three nodes.. Option C is correct because the scheduler event explicitly states '3 nodes had insufficient memory', which directly indicates that the pod's resource requests (specifically memory) exceed the available allocatable memory on those three nodes. The fourth node is unavailable due to taints, leaving zero schedulable nodes, hence the 'Pending' state.

Answer

The node with the taint has a toleration mismatch.

Answer

The pod's image pull is failing.

Answer

The pod was evicted due to resource pressure.

Question 12

A cluster has a node with the taint 'node-role.kubernetes.io/control-plane:NoSchedule'. A pod must be scheduled on this node for a special workload. Which action is required?

Accepted Answer

Add a toleration to the pod spec.. Option C is correct because a taint on a node causes the scheduler to avoid placing pods on that node unless the pod explicitly tolerates the taint. By adding a toleration in the pod spec that matches the taint key, effect, and optionally the value, the pod becomes eligible to be scheduled on the tainted node. This is the standard Kubernetes mechanism for allowing pods to run on control-plane or other specially tainted nodes.

Answer

Use a nodeSelector to select the node.

Answer

Remove the taint from the node.

Answer

Use podAffinity to attract the pod to the node.

Question 13

Which TWO statements about Kubernetes namespaces are true?

Accepted Answer

Namespaces are used to divide cluster resources between multiple users or teams.. Option D is correct because namespaces are a fundamental mechanism in Kubernetes for dividing cluster resources among multiple users or teams, enabling multi-tenancy and resource management through policies like Role-Based Access Control (RBAC) and ResourceQuotas. Option E is correct because ResourceQuotas are Kubernetes objects that can be applied to a namespace to enforce aggregate limits on CPU, memory, and other resources, preventing any single team from exhausting cluster capacity.

Answer

All Kubernetes objects are namespaced.

Answer

Namespaces automatically isolate services in different namespaces from communicating.

Answer

Namespaces provide network isolation between pods by default.

Question 14

Which THREE of the following are valid ways to expose a set of pods as a network service in Kubernetes?

Accepted Answer

Creating a Service of type NodePort.. A Service of type NodeType exposes the pods on a static port on each node's IP address, making the service accessible externally. This is a valid method for exposing a set of pods as a network service in Kubernetes.

Answer

Creating a headless Service (clusterIP: None).

Answer

Creating a Deployment with a label selector.

Question 15

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 16

Refer to the exhibit. A pod 'my-pod' shows repeated 'BackOff' events after the container starts. Which is the most likely cause?

Accepted Answer

The application crashes shortly after starting.. The 'BackOff' event in Kubernetes indicates that the container has started but repeatedly crashes, causing the kubelet to increase the restart delay. Option D is correct because an application that crashes shortly after starting will trigger this restart loop, as the container exits with a non-zero exit code, leading to exponential backoff.

Answer

The image 'myapp:v2' does not exist.

Answer

The container exceeds its memory limit.

Answer

The liveness probe is failing.

Question 17

A development team deploys a microservice that crashes every few minutes. The deployment uses a single replica, and the pod restarts repeatedly. Which Kubernetes feature should be enabled to ensure the service remains available during failures?

Accepted Answer

Increase the replicas in the Deployment to at least 2. Increasing the replicas to at least 2 ensures that if one pod crashes, the other replica(s) can continue serving traffic, maintaining availability. With only a single replica, the service becomes unavailable every time the pod restarts. This is the most direct way to provide redundancy and fault tolerance for a stateless microservice.

Answer

Move the deployment to a separate namespace

Answer

Store the application configuration in a ConfigMap

Answer

Add a readiness probe to the pod

Question 18

A DevOps engineer needs to expose a set of pods running an HTTP API to external clients. The pods are stateless and should be load-balanced. Which Kubernetes resource should they use?

Accepted Answer

Service of type LoadBalancer. A Service of type LoadBalancer is the correct choice because it provisions an external load balancer (e.g., an AWS ELB or Azure LB) that distributes incoming traffic across the pods, exposing the stateless HTTP API to external clients. This resource automatically assigns a public IP and handles load balancing without requiring manual proxy configuration, making it ideal for external access to stateless workloads.

Answer

StatefulSet with a headless Service

Answer

Ingress resource without a Service

Answer

Service of type ClusterIP

Question 19

An administrator notices that a pod in a Deployment is stuck in CrashLoopBackOff. The pod logs show 'Error: failed to start container: exec: "app": executable file not found in $PATH'. What is the most likely cause?

Accepted Answer

The container image does not contain the binary specified in the pod's command field. The error 'exec: "app": executable file not found in $PATH' indicates that the container image does not contain the binary or script specified in the pod's command field (e.g., `command: ["app"]`). This typically happens when the image is built without the expected executable, the command path is incorrect, or the image tag points to a different version. The container fails to start because the runtime cannot locate the entrypoint.

Answer

The image registry credentials are missing

Answer

The liveness probe is misconfigured and killing the container

Answer

The container is running as a non-root user without proper permissions

Question 20

A team uses a Deployment with 3 replicas and a RollingUpdate strategy. They update the container image. During the update, one of the new pods fails to start. What will happen by default?

Accepted Answer

The update pauses, keeping the remaining old replicas running. By default, a Deployment with a RollingUpdate strategy uses a `maxUnavailable` of 25% and a `maxSurge` of 25%. When a new pod fails to start (e.g., CrashLoopBackOff or ImagePullBackOff), the ReplicaSet controller will not create additional new pods beyond the surge limit, and the update will effectively pause because the new ReplicaSet cannot reach its desired replica count. The old ReplicaSet remains running with its existing pods, ensuring availability is maintained.

Answer

The entire update is rolled back and all old pods are deleted

Answer

The Deployment automatically rolls back to the previous image

Answer

The failed pod is terminated and not retried