KCNA Container Orchestration — 30 Questions

Question 1

An application running in a Kubernetes pod needs to access a database that is deployed on a VM outside the cluster. The database IP is stable. Which is the best way to expose the database to the pod?

Accepted Answer

Create a Service of type ExternalName pointing to the database hostname. A Service of type ExternalName provides a DNS-based abstraction for external resources, mapping a Kubernetes service name to an external DNS name (the database hostname). This allows the pod to access the database via a stable in-cluster DNS name without needing to manage IP changes or network policies for external endpoints. It is the simplest and most Kubernetes-native way to expose a stable external IP to a pod.

Answer

Expose the database via Ingress

Answer

Use a Headless Service

Answer

Create an EndpointSlice manually with the pod IP

Question 2

A team notices that a ReplicaSet is not creating the desired number of pods. The ReplicaSet YAML is correctly configured with replicas: 3. The cluster has sufficient resources. What is the most likely cause?

Accepted Answer

The pod template references an invalid image pull secret. An invalid image pull secret in the pod template prevents the kubelet from authenticating with the container registry, causing the pod creation to fail. The ReplicaSet controller attempts to create pods, but the scheduler cannot pull the image, so the pods remain in a pending or ImagePullBackOff state, never reaching the desired count of 3.

Answer

The ReplicaSet is paused

Answer

The nodeSelector does not match any node

Answer

A ResourceQuota in the namespace limits the number of pods

Question 3

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

Accepted Answer

Service of type NodePort. A Service of type NodePort exposes a set of pods on a static port on each node's IP address, making the service accessible from outside the cluster. This is a valid Kubernetes resource for exposing pods as a network service, as it creates a mapping from a node port to the ClusterIP and then to the target pods.

Answer

NetworkPolicy

Answer

Ingress resource

Answer

Deployment with replicas

Question 4

Which TWO of the following are valid methods to expose a set of pods to external traffic in Kubernetes?

Accepted Answer

LoadBalancer Service. A LoadBalancer Service (option A) is correct because it provisions an external load balancer (via the cloud provider's controller) that routes external traffic to the backing pods, giving them a publicly reachable IP. A NodePort Service (option B) is also correct because it opens a static port (default range 30000–32767) on every node's IP, allowing external clients to reach the pods through :. A Headless Service (option C) is not correct because setting clusterIP: None only returns pod IPs directly via DNS for stateful/discovery use and provides no external exposure. A ClusterIP Service (option D) is not correct because it is only reachable from within the cluster on an internal virtual IP. Ingress (option E) is not correct on its own because it is an HTTP/HTTPS routing layer that still requires an externally exposed Service (typically LoadBalancer or NodePort) or ingress controller endpoint to receive external traffic.

Answer

Headless Service

Answer

ClusterIP Service

Answer

Ingress

Question 5

Your organization runs a microservices application in a Kubernetes cluster with 5 worker nodes. Each microservice is deployed as a Deployment with 3 replicas. Recently, users report intermittent timeouts when accessing the frontend service. The frontend communicates with a backend service via ClusterIP. You check the backend pods and find that one of the three replicas is in CrashLoopBackOff. The other two backend pods are healthy. The frontend deployment has no readiness or liveness probes. You notice that the frontend's connection pool to the backend has a timeout of 5 seconds. The crashing backend pod logs show an occasional NullPointerException that causes the container to restart, but the pod becomes ready after restart within 2 seconds. However, the frontend's connection pool does not evict unhealthy connections quickly. What is the best course of action to reduce timeouts?

Accepted Answer

Add a readiness probe to the backend Deployment that checks the application health endpoint.. The intermittent timeouts occur because the frontend's connection pool holds stale connections to the backend pod that is in CrashLoopBackOff. Although the pod restarts and becomes ready within 2 seconds, the frontend does not detect that the old connection is broken and continues to use it until the 5-second timeout expires. Adding a readiness probe to the backend Deployment ensures that Kubernetes only sends traffic to pods that pass the health check; when the pod fails the probe, it is removed from the ClusterIP's endpoints, preventing the frontend from routing requests to it and thus eliminating the timeouts.

Answer

Increase the number of backend replicas to 5 to absorb the failures.

Answer

Add a liveness probe to the frontend Deployment.

Answer

Increase the frontend connection pool timeout to 10 seconds.

Question 6

Drag and drop the steps to update a Kubernetes Secret and ensure Pods use the new value into the correct order.

Accepted Answer

Update the Secret → Verify the Secret update → Force Pod recreation if needed → Wait for new Pods to be ready → Verify the new value in the Pods. Update the Secret, verify, force Pod recreation if needed, wait for new Pods, and verify the new value.

Answer

Verify the Secret update → Update the Secret → Force Pod recreation if needed → Wait for new Pods to be ready → Verify the new value in the Pods

Answer

Update the Secret → Force Pod recreation if needed → Verify the Secret update → Wait for new Pods to be ready → Verify the new value in the Pods

Answer

Update the Secret → Wait for new Pods to be ready → Force Pod recreation if needed → Verify the new value in the Pods → Verify the Secret update

Question 7

Match each Kubernetes component to its role in the control plane.

Accepted Answer

API Server: The central component that exposes the Kubernetes API, handling all RESTful interactions.. The core control plane components are: API Server (central API gateway), etcd (distributed store), and Scheduler (pod-to-node assignment). Common confusions include mixing roles of etcd and the API Server or Scheduler.

Answer

API Server: A distributed key-value store used as Kubernetes' backing store.

Answer

etcd: Watches for newly created pods and assigns them to nodes.

Question 8

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 OOMKilled status indicates the container was terminated because it exceeded its memory limit. The most appropriate action is to increase the memory limit in the pod's container resource specification, which allows the container to use more memory without being killed by the Out-Of-Memory (OOM) killer. This resolves the root cause by providing sufficient memory for the workload.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 9

A developer creates a Deployment with replicas: 3 and strategy type: RollingUpdate with maxSurge: 1 and maxUnavailable: 1. During a rolling update, the Deployment controller creates a new ReplicaSet. After the new ReplicaSet has 2 pods ready, the node running one of the original ReplicaSet's pods fails. What is the MOST likely number of total pods running after the node failure, assuming no other actions?

Accepted Answer

2 pods running. Initially, the Deployment has 3 old pods. The rolling update starts: with maxSurge=1, the controller creates a new pod. Once it's ready, it terminates one old pod to keep desired replicas at 3. Then it creates another new pod. After the second new pod is ready, it terminates a second old pod. At this point, the new ReplicaSet has 2 ready pods, and the old ReplicaSet has only 1 pod remaining. The node running that last old pod fails, killing it. Thus, only the 2 new pods are running, giving a total of 2 pods.

Answer

4 pods running

Answer

3 pods running

Answer

1 pod running

Question 10

You have a microservices application where Service A needs to communicate with Service B running in a different namespace ('backend'). Both namespaces have a NetworkPolicy that denies all ingress by default. You create a NetworkPolicy in the 'backend' namespace allowing ingress from pods with label 'app: frontend'. What else is needed for Service A to reach Service B?

Accepted Answer

Add a label to the 'default' namespace matching the NetworkPolicy's namespaceSelector. A NetworkPolicy with only a podSelector in an ingress rule matches pods in the same namespace only. To allow cross-namespace traffic, you must include a namespaceSelector that selects the namespace of the source pods. By adding a label to the 'default' namespace and including a namespaceSelector matching that label in the NetworkPolicy, you enable Service A's pods to be allowed. Ensure Service A's pod also has the required label 'app: frontend'. Option A is wrong: a podSelector alone only matches pods in the same namespace. Option B is wrong: egress policies are not needed for inbound traffic. Option C is too permissive and unnecessary.

Answer

Ensure Service A's pod has the label 'app: frontend' on its pod spec

Answer

Add a similar NetworkPolicy in the 'default' namespace allowing egress to the 'backend' namespace

Answer

Change the NetworkPolicy to allow all ingress traffic from any source

Question 11

A user wants to ensure that a pod is automatically restarted if its main process crashes. Which Kubernetes controller should they use?

Accepted Answer

Deployment. A Deployment is the correct controller because it manages a ReplicaSet, which ensures a specified number of pod replicas are running at all times. If the main process in a pod crashes, the ReplicaSet detects the pod failure (via the kubelet's liveness probe or the pod's phase becoming 'Failed') and automatically creates a new pod to replace it, thereby restarting the application. This self-healing behavior is a core feature of Deployments, making them ideal for stateless applications that need continuous availability.

Answer

Job

Answer

DaemonSet

Answer

CronJob

Question 12

Which command would you use to view the logs of a specific container in a multi-container pod, using the short flag?

Accepted Answer

kubectl logs mypod -c mycontainer. The command `kubectl logs mypod -c mycontainer` uses the short flag `-c` to specify the container name in a multi-container pod. The long form `--container` also works, but the exam may specifically expect the short flag syntax. Option A uses `-p` which retrieves logs from a previous instance. Option D provides the container name as a positional argument, which is incorrect.

Answer

kubectl logs mycontainer -p mypod

Answer

kubectl logs mypod --container mycontainer

Answer

kubectl logs mypod mycontainer

Question 13

What is the role of etcd in a Kubernetes cluster?

Accepted Answer

It stores cluster state and configuration. etcd is a distributed, consistent key-value store that serves as Kubernetes' primary datastore for all cluster state and configuration data. It stores objects like pods, services, deployments, secrets, and configmaps, and is the source of truth for the entire cluster. The Kubernetes API server is the only component that communicates directly with etcd, ensuring strong consistency via the Raft consensus protocol.

Answer

It serves as the container runtime

Answer

It provides DNS-based service discovery

Answer

It schedules pods onto nodes

Question 14

An administrator wants to ensure that a Deployment named 'webapp' always has exactly 3 replicas running across distinct nodes to improve fault tolerance. Which field in the Deployment spec should they configure?

Accepted Answer

template.spec.affinity.podAntiAffinity. `podAntiAffinity` in the `template.spec.affinity` field allows you to enforce scheduling rules that prevent multiple pods from the same Deployment from running on the same node. By configuring a `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity rule with a topology key of `kubernetes.io/hostname`, the scheduler ensures that each of the 3 replicas is placed on a distinct node, thereby improving fault tolerance against node failures.

Answer

replicas: 3

Answer

strategy.type: Recreate

Answer

template.spec.nodeName

Question 15

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 16

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 failing with an 'OOMKilled' status, which indicates that the container's memory usage exceeded its configured memory limit. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being terminated by the Out-Of-Memory (OOM) killer, resolving the crash loop. This is the most direct and appropriate action to address the resource exhaustion.

Answer

Delete and recreate the pod to clear the crash loop

Answer

Increase the CPU request for the container

Answer

Delete the namespace and redeploy all workloads

Question 17

An administrator wants to ensure that a specific pod only runs on nodes that have solid-state drives (SSDs). Nodes with SSDs are labeled with 'disktype=ssd'. Which pod specification field should be used?

Accepted Answer

nodeSelector. The `nodeSelector` field in a Pod spec is the simplest and most direct way to constrain a Pod to nodes with specific labels. By setting `nodeSelector: { disktype: ssd }`, the scheduler will only place the Pod on nodes that have the label `disktype=ssd`, which matches the administrator's requirement exactly. This field is a hard constraint that does not support complex expressions, but it is ideal for straightforward label-based node selection.

Answer

container resource limits

Answer

tolerations

Answer

nodeAffinity

Question 18

A Kubernetes cluster has a Service named 'my-svc' in the 'default' namespace. Which command would correctly expose this service as an external endpoint using a cloud load balancer?

Accepted Answer

kubectl expose service my-svc --type=LoadBalancer --name=my-svc-lb. `kubectl expose service my-svc --type=LoadBalancer --name=my-svc-lb` creates a new Service of type LoadBalancer that inherits the selector and port configuration from the existing 'my-svc' Service, which provisions a cloud load balancer (e.g., AWS ELB, GCP TCP/UDP LB) to expose it externally. The `--type=LoadBalancer` flag is essential to request a cloud load balancer, and `--name` specifies the new Service's name to avoid overwriting the original.

Answer

kubectl expose deployment my-svc --type=LoadBalancer --name=my-svc-lb

Answer

kubectl expose service my-svc --name=my-svc-lb

Answer

kubectl expose service my-svc --port=80 --target-port=8080

Question 19

What is the purpose of a readiness probe in a Kubernetes pod?

Accepted Answer

To determine if the container is ready to serve traffic. A readiness probe in Kubernetes determines whether a container inside a pod is ready to start accepting traffic. If the probe fails, the pod is removed from the Service's endpoints, preventing traffic from being routed to an unready container. This is distinct from a liveness probe, which checks if the container is healthy and should be restarted.

Answer

To check if the pod has been scheduled on a node

Answer

To measure the CPU and memory usage of the container

Answer

To determine if the container is healthy and should be restarted

Question 20

Which TWO of the following are characteristics of immutable infrastructure? (Select two.)

Accepted Answer

Servers are never modified after they are deployed. Option A is correct because immutable infrastructure means that once a server (or container instance) is deployed, it is never patched, reconfigured, or otherwise modified in place; any change requires a new artifact. Option D is correct because the defining deployment pattern is to replace the entire server/instance with a freshly built image rather than updating the existing one, which is often implemented via blue/green or rolling replacements. Option B is incorrect because immutability is a principle that can be applied to virtual machines, physical hosts, and other resources, not just containers. Option C is incorrect because version-controlling and testing infrastructure is a characteristic of Infrastructure as Code practices, not a defining characteristic of immutable infrastructure itself. Option E is incorrect because applying configuration updates directly to running servers is the opposite of immutable infrastructure, which forbids in-place mutation.

Answer

Containers are used exclusively

Answer

Infrastructure is version-controlled and tested

Answer

Configuration updates are applied directly to running servers