KCNA Practice Test 39 — 15 Questions

Question 1

Refer to the exhibit. How many containers are defined in this Pod?

Accepted Answer

2. The exhibit shows a Pod manifest with two container definitions under the `containers` field: one named `nginx` and one named `sidecar`. In Kubernetes, the number of containers in a Pod is determined by counting the entries in the `spec.containers` list, not including init containers or ephemeral containers unless explicitly specified. Therefore, the correct answer is 2.

Answer

1

Answer

3

Answer

0

Question 2

A Deployment manages 3 replicas of a pod. During a rolling update, one of the new pods enters CrashLoopBackOff. What happens next?

Accepted Answer

The Deployment pauses the rollout and waits for manual intervention. By default, a Deployment's rolling update strategy has a `progressDeadlineSeconds` setting (default 600 seconds) and a `maxUnavailable`/`maxSurge` configuration. When a new pod enters CrashLoopBackOff, the Deployment's controller detects that the update is not making progress (the new ReplicaSet cannot reach the desired replica count with healthy pods). After the progress deadline expires, the Deployment marks the rollout as failed and pauses the update, requiring manual intervention (e.g., `kubectl rollout undo` or fixing the pod template). This behavior is governed by the Deployment controller's reconciliation loop and the `Progressing` condition.

Answer

The Deployment deletes all pods and recreates them

Answer

The Deployment automatically reverts to the previous ReplicaSet

Answer

The Deployment continues the rollout, ignoring the failure

Question 3

A Deployment is created with `replicas: 3`. After applying the manifest, only 2 pods are running and one is in Pending state. What is the most likely reason?

Accepted Answer

There are insufficient resources on the nodes. When a Pod remains in Pending state, it means the scheduler cannot find a node that satisfies the Pod's resource requirements (CPU, memory, or other constraints). Since two Pods are running successfully, the Deployment configuration (image, name, selector) is valid, and the issue is that the cluster lacks sufficient capacity to schedule the third replica. The scheduler continuously evaluates node resources and will leave the Pod pending until resources become available or the request is adjusted.

Answer

The Service selector does not match

Answer

The Deployment name is misspelled

Answer

The container image is invalid

Question 4

A pod is stuck in 'Pending' state. Which of the following is NOT a common cause for a pod to remain Pending?

Accepted Answer

The container runtime is not functioning on the node. A non-functioning container runtime on a node typically results in pod states like CrashLoopBackOff or Error, not prolonged 'Pending' state. Pending state occurs when a pod cannot be scheduled. Insufficient resources (A), node selector mismatch (B), and unbound PVCs (D) are common causes of scheduling failures that keep a pod in Pending. Container runtime issues affect pod execution after scheduling, not the scheduling process itself. Therefore, C is NOT a common cause for a pod to remain Pending.

Answer

Insufficient CPU or memory resources available in the cluster

Answer

The node selector in the pod spec does not match any node labels

Answer

The pod's PVC is not yet bound to a PV

Question 5

Which of the following is a correct way to assign a pod to a specific node using a nodeSelector?

Accepted Answer

spec: nodeSelector: disktype: ssd. `nodeSelector` is a simple pod scheduling constraint that uses a key-value pair in the `spec.nodeSelector` field to match node labels. The correct YAML syntax is `spec: nodeSelector: disktype: ssd`, where `disktype` is the label key and `ssd` is the value, ensuring the pod is scheduled only on nodes with that exact label.

Answer

spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: ...

Answer

spec: nodeName: "node1"

Answer

spec: nodeSelector: [disktype: ssd]

Question 6

Which THREE are valid ways to provide configuration data to a pod in Kubernetes?

Accepted Answer

Mount a ConfigMap as a volume. A ConfigMap is a Kubernetes API object designed to store non-confidential configuration data in key-value pairs. Mounting a ConfigMap as a volume makes its data available as files in the pod's filesystem, allowing applications to read configuration without hardcoding it into the container image or pod spec. This approach decouples configuration from containerized applications, following the principle of immutable infrastructure.

Answer

Use an init container to write configuration to a shared volume

Answer

Hardcode environment variables in the pod spec that contain sensitive data

Question 7

Which component of Kubernetes is responsible for maintaining the desired state of the cluster?

Accepted Answer

kube-controller-manager. The kube-controller-manager is the component that runs controller processes, which are responsible for regulating the state of the cluster. It continuously watches the current state via the kube-apiserver and takes corrective actions to match the desired state defined in the cluster's control loop, such as ensuring the correct number of pods are running.

Answer

kube-scheduler

Answer

kubelet

Answer

kube-apiserver

Question 8

Which of the following is a container runtime that implements the Container Runtime Interface (CRI)?

Accepted Answer

containerd. containerd is a high-level container runtime that directly implements the Container Runtime Interface (CRI) by exposing a gRPC API that kubelet can call to manage pods and containers. It was originally extracted from Docker and is now the default runtime in many Kubernetes distributions, providing image transfer, container lifecycle management, and storage/network attachment without requiring Docker as an intermediary.

Answer

Docker

Answer

runc

Answer

kubelet

Question 9

You need to run a stateful application that requires stable network identities and persistent storage per pod. Which Kubernetes resource is BEST suited?

Accepted Answer

StatefulSet. StatefulSet is the correct choice because it is specifically designed for stateful applications that require stable, unique network identifiers (e.g., pod names like `web-0`, `web-1`) and persistent storage that persists across pod rescheduling. Each pod in a StatefulSet gets a dedicated PersistentVolumeClaim, and the ordinal index ensures consistent identity, which is critical for databases like Cassandra or MySQL.

Answer

DaemonSet

Answer

Job

Answer

Deployment

Question 10

A Deployment is rolling out a new version. The rollout has stalled, and 'kubectl rollout status deployment/myapp' shows 'Waiting for deployment rollout to finish: 2 out of 5 new replicas have been updated...'. The Deployment's spec.strategy.rollingUpdate.maxUnavailable is set to 25% and maxSurge is 25%. What is the maximum number of Pods that could be unavailable during this rollout?

Accepted Answer

2. With maxUnavailable=25% and maxSurge=25%, the maximum number of unavailable Pods during a rolling update is calculated as the ceiling of 25% of the desired replicas (5), which is 2. This means up to 2 Pods can be unavailable at any time, ensuring the rollout can proceed while maintaining availability.

Answer

1

Answer

3

Answer

0

Question 11

Which TWO of the following components are part of the Kubernetes control plane? (Select 2)

Accepted Answer

kube-apiserver. The Kubernetes control plane is responsible for maintaining the desired state of the cluster and making global decisions. The kube-apiserver is the front-end for the control plane, exposing the Kubernetes API, and etcd is the consistent and highly-available key-value store used as the backing store for all cluster data. Both are essential control plane components.

Answer

container runtime

Answer

kubelet

Answer

kube-proxy

Question 12

Which TWO of the following are valid ways to expose environment variables from a ConfigMap to a pod?

Accepted Answer

env.valueFrom.configMapKeyRef. Environment variables from a ConfigMap can be exposed to a pod using envFrom to inject all key-value pairs as environment variables, or using env.valueFrom.configMapKeyRef to inject a specific key as an environment variable. Using volumes and volumeMounts mounts the ConfigMap as files in the filesystem, not as environment variables. Option B (env.value) is for static values, not references. Option C (secretKeyRef) is for Secrets, not ConfigMaps.

Answer

volumes and volumeMounts

Answer

env.value

Answer

env.valueFrom.secretKeyRef

Question 13

You need to provide configuration data as environment variables to a pod, but the data is not sensitive. Which object should you use?

Accepted Answer

ConfigMap. A ConfigMap is the correct Kubernetes object for providing non-sensitive configuration data as environment variables to a pod. ConfigMaps are designed to decouple configuration artifacts from image content to keep containers portable, and they support injection via environment variables, command-line arguments, or volume mounts. Unlike Secrets, ConfigMaps store data in plaintext (base64-encoded only for transport) and are intended for data that does not require encryption at rest or in transit.

Answer

Secret

Answer

ServiceAccount

Answer

PersistentVolume

Question 14

What is the primary purpose of a liveness probe in a container?

Accepted Answer

To check if the container is still alive; restart if not. The primary purpose of a liveness probe is to determine whether a container is still running and healthy. If the probe fails, the kubelet kills the container and restarts it according to the pod's restart policy, ensuring self-healing. This is distinct from readiness probes, which control traffic routing, and resource checks, which are handled by metrics servers or cAdvisor.

Answer

To check resource usage like CPU and memory

Answer

To check if the container is ready to serve traffic

Answer

To check if the pod is scheduled on the correct node

Question 15

You want to create a new Namespace called 'staging' and apply a ResourceQuota to it. Which of the following YAML snippets correctly defines a ResourceQuota that limits total memory to 10Gi and total CPU to 5 cores in namespace 'staging'?

Accepted Answer

apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: staging
spec:
  hard:
    limits.cpu: "5"
    limits.memory: 10Gi. It defines a ResourceQuota with `limits.cpu` and `limits.memory` under `spec.hard`, which restricts the total CPU and memory that all pods in the namespace can consume. The values are specified as strings ("5" for CPU and 10Gi for memory), which is the correct format for ResourceQuota resources in Kubernetes.

Answer

apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
  namespace: staging
spec:
  hard:
    requests.cpu: "5"
    requests.memory: 10Gi

Answer

apiVersion: v1
kind: LimitRange
metadata:
  name: staging-limits
  namespace: staging
spec:
  limits:
  - default:
      cpu: 5
      memory: 10Gi
    defaultRequest:
      cpu: 1
      memory: 1Gi

Answer

apiVersion: v1
kind: ResourceQuota
metadata:
  name: staging-quota
spec:
  hard:
    cpu: 5
    memory: 10Gi