KCNA Container Orchestration Practice Test 4 — 15 Questions

Question 1

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?

Choose an answer to begin — your selection is scored in the full session.

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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

Question 9

Based on the exhibit, why is the pod web-pod not running?

Accepted Answer

The container image is not available in the registry.. The pod's status indicates an ImagePullBackOff error, which occurs when the kubelet fails to pull the specified container image from the registry. This typically means the image name or tag is incorrect, the registry is unreachable, or the image does not exist in the registry. The exhibit shows the pod is stuck in a waiting state with the reason 'ErrImagePull' or 'ImagePullBackOff', directly pointing to a missing or inaccessible image.

Answer

A network policy is blocking the image pull.

Answer

The node does not have enough memory.

Answer

The pod was not scheduled onto a node.

Question 10

Drag and drop the steps for a rolling update of a Kubernetes Deployment into the correct order.

Accepted Answer

1. Change the image, 2. Apply the change, 3. Monitor the rollout, 4. Verify the health, 5. Rollback if issues. Change the image, apply, monitor rollout, verify health, and rollback if issues arise.

Answer

1. Change the image, 2. Monitor the rollout, 3. Apply the change, 4. Verify the health, 5. Rollback if issues

Answer

1. Apply the change, 2. Change the image, 3. Monitor the rollout, 4. Verify the health, 5. Rollback if issues

Answer

1. Change the image, 2. Apply the change, 3. Verify the health, 4. Monitor the rollout, 5. Rollback if issues

Question 11

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 12

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 13

Match each Kubernetes command (kubectl) to its primary function.

Accepted Answer

kubectl get: List one or more resources. The correct matches are: kubectl get for listing resources, kubectl describe for detailed info, and kubectl apply for applying configurations. Common confusions include swapping the functions of kubectl delete and kubectl logs.

Answer

kubectl delete: Print logs for a container in a pod

Answer

kubectl logs: Delete resources

Question 14

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 15

You are designing a microservices application that requires each service to be independently deployable and scalable. The services communicate over HTTP and need service discovery. Which orchestration feature BEST addresses the need for service discovery?

Accepted Answer

Kubernetes Service. Kubernetes Service is the correct choice because it provides a stable network endpoint (IP address and DNS name) for a set of pods, enabling service discovery via DNS or environment variables. This allows microservices to locate and communicate with each other over HTTP without hardcoding IP addresses, which is essential for independent deployability and scalability.

Answer

Horizontal Pod Autoscaler

Answer

ConfigMap

Answer

PersistentVolume