KCNA Container Orchestration — Timed 15 Questions

Question 1

A team deploys a microservice that requires sticky sessions. The service runs on Kubernetes with multiple replicas. Which Kubernetes resource should be used to ensure requests from a client are consistently routed to the same pod?

Accepted Answer

Service with sessionAffinity: ClientIP. Option B is correct because setting `sessionAffinity: ClientIP` on a Kubernetes Service ensures that all requests from the same client IP are routed to the same Pod. This is the standard Kubernetes mechanism for implementing sticky sessions without requiring changes to the application or ingress layer.

Answer

Headless Service

Answer

Ingress with default settings

Answer

Deployment with hostNetwork: true

Question 2

A Kubernetes cluster is experiencing network latency. The team suspects that the number of services and endpoints is causing iptables performance degradation. Which CNI plugin or network policy approach is most likely to improve performance?

Accepted Answer

Use an eBPF-based CNI plugin like Cilium. C is correct because eBPF-based CNI plugins like Cilium bypass the traditional iptables chains entirely, using a kernel-level BPF (Berkeley Packet Filter) program to handle service load balancing and network policy enforcement. This eliminates the O(n) scaling issue of iptables rules with the number of services and endpoints, significantly reducing latency in large clusters.

Answer

Switch to Flannel with host-gw backend

Answer

Use Calico with iptables mode

Answer

Apply a default-deny NetworkPolicy

Question 3

A developer wants to ensure that a pod runs only on nodes with SSDs. Which mechanism should be used?

Accepted Answer

Add a nodeSelector with disktype: ssd. Option C is correct because `nodeSelector` is a simple and direct mechanism in Kubernetes to constrain a pod to run only on nodes that have a specific label, such as `disktype=ssd`. By labeling nodes with SSDs and adding the corresponding `nodeSelector` in the pod spec, the scheduler ensures the pod is placed exclusively on those nodes. This approach is straightforward and does not require complex scheduling constraints or resource management.

Answer

Apply a taint to nodes without SSDs and add tolerations to the pod

Answer

Use pod anti-affinity

Answer

Define a ResourceQuota

Question 4

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. Option B is correct because 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 5

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. Option B is correct because 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 6

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 7

Which THREE of the following are correct statements about Kubernetes Deployments?

Accepted Answer

A Deployment manages ReplicaSets. A Deployment manages ReplicaSets, which in turn manage Pods. This is the core abstraction: the Deployment controller creates and updates ReplicaSets to achieve the desired state, and each ReplicaSet ensures a specified number of Pod replicas are running. This layered architecture enables features like rolling updates and rollbacks without the Deployment directly interacting with individual Pods.

Answer

Deployments support canary deployments natively

Answer

A Deployment directly manages Pods

Question 8

A DevOps team notices that a new deployment of a web application is not receiving traffic even though the pods are running. The deployment has a selector matching the pod labels, and a Service of type ClusterIP exists. What is the most likely cause?

Accepted Answer

The Service's targetPort does not match the container's containerPort.. The most likely cause is that the Service's targetPort does not match the container's containerPort. In Kubernetes, a Service routes traffic to pods by forwarding packets to the port specified in the Service's `targetPort` field. If this does not match the `containerPort` defined in the pod's container spec, the traffic will be dropped because the kube-proxy will forward packets to a closed port on the pod, resulting in no connectivity even though the pods are running.

Answer

The pods do not have a readiness probe defined.

Answer

The Service type should be NodePort to receive traffic.

Answer

The Service is not exposed via an Ingress.

Question 9

An administrator needs to ensure that Pods from two different Deployments cannot communicate with each other. Which Kubernetes resource should be used?

Accepted Answer

NetworkPolicy. NetworkPolicy is the correct resource because it acts as a firewall for Kubernetes Pods, controlling ingress and egress traffic at the IP address and port level using layer 3/4 rules. By applying a NetworkPolicy that denies all traffic between the Pods of the two Deployments (e.g., using podSelector and ingress/egress rules with an empty `from` or `to` block), the administrator can enforce network isolation. This is the native Kubernetes mechanism for restricting Pod-to-Pod communication within a cluster.

Answer

RBAC Role

Answer

PodSecurityPolicy

Answer

ResourceQuota

Question 10

A developer wants to run a one-time task that creates a database schema and then exits. Which Kubernetes workload type is most appropriate?

Accepted Answer

Job. A Job is the correct choice because it is designed for finite, one-time tasks that run to completion, such as creating a database schema. Unlike long-running workloads, a Job creates one or more Pods and ensures they terminate successfully after the task finishes, making it ideal for batch processing or initialization tasks.

Answer

DaemonSet

Answer

StatefulSet

Answer

Deployment

Question 11

An application requires stable network identities and persistent storage. Which workload type should be used?

Accepted Answer

StatefulSet. StatefulSet is the correct workload type because it provides stable, unique network identities (via headless Services and ordinal hostnames) and persistent storage (via PersistentVolumeClaims that persist across Pod rescheduling). This makes it ideal for stateful applications like databases, where each Pod requires a stable identity and dedicated storage that survives restarts.

Answer

Deployment

Answer

DaemonSet

Answer

Job

Question 12

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 is a valid method to expose pods to external traffic because it provisions an external load balancer (e.g., AWS ELB, GCP LB) that assigns a public IP address, routing external traffic to the Service's ClusterIP and then to the pods. This is a standard Kubernetes Service type defined in the ServiceSpec, making it correct for external exposure.

Answer

Headless Service

Answer

ClusterIP Service

Answer

Ingress

Question 13

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 14

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 15

A company is deploying a microservices application on Kubernetes. They want to ensure that configuration data, such as database URLs and feature flags, can be updated without rebuilding container images. Which Kubernetes resource should they use?

Accepted Answer

ConfigMaps. ConfigMaps are the correct Kubernetes resource for decoupling configuration data (like database URLs and feature flags) from container images. They allow you to inject configuration as environment variables or mounted volumes without rebuilding or redeploying the container image, enabling runtime updates.

Answer

Secrets

Answer

Services

Answer

Deployments