KCNA Hard Questions — 25 Difficult Questions

Question 1

An application running in a Kubernetes cluster needs to securely access a third-party API. The API key must be stored in the cluster and mounted into the Pod as an environment variable. Which is the best practice?

Accepted Answer

Create a Secret with the API key and use envFrom or valueFrom in the Pod spec.. Option C is correct: Secrets should be used for sensitive data like API keys. They are base64 encoded and can be mounted as env vars. Option A is wrong because ConfigMaps are for non-sensitive data. Option B is wrong because storing secrets in plaintext in the image is insecure. Option D is wrong because storing secrets in annotations is not designed for that purpose and is insecure.

Answer

Store the API key in a ConfigMap and reference it in the Pod spec.

Answer

Embed the API key directly in the container image.

Answer

Store the API key in a Pod annotation and read it with kubectl.

Question 2

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 3

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 4

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 5

A pod is running but you need to view the contents of a file '/var/log/app.log' inside the container to debug an issue. Which kubectl command allows you to do this without modifying the pod?

Accepted Answer

kubectl exec pod-name -- cat /var/log/app.log. Option C is correct because `kubectl exec pod-name -- cat /var/log/app.log` runs the `cat` command inside the container without modifying the pod or its state. This allows you to view the file contents directly from the container's filesystem, which is essential for debugging when the application logs are not written to stdout/stderr and thus not accessible via `kubectl logs`.

Answer

kubectl logs pod-name -c container-name --tail=100

Answer

kubectl cp pod-name:/var/log/app.log -

Answer

kubectl attach pod-name

Question 6

When using a Service of type ClusterIP, how do pods reach the service?

Accepted Answer

Via the service's cluster IP and port. A Service of type ClusterIP exposes a stable virtual IP (the cluster IP) and port within the cluster. Pods reach the Service by sending traffic to this cluster IP and port, which is then load-balanced by kube-proxy (using iptables, IPVS, or eBPF rules) to one of the backing pod endpoints. This is the default and most fundamental Service type in Kubernetes.

Answer

Via the node's IP address and a high port

Answer

Via an external load balancer

Answer

Directly via the pod's IP address

Question 7

A Service of type ClusterIP is created for a Deployment, but Pods in other namespaces cannot reach it. What is the most likely cause?

Accepted Answer

The Pods in other namespaces are using the short Service name without the namespace suffix. The most likely cause is that Pods in other namespaces are using the short Service name (e.g., `my-service`) without appending the namespace suffix (e.g., `my-service.other-namespace.svc.cluster.local`). Kubernetes DNS resolves short names only within the same namespace; cross-namespace resolution requires the fully qualified domain name (FQDN) or at least the `..svc` form. Without this, the DNS lookup fails, making the Service unreachable from other namespaces.

Answer

NetworkPolicies are blocking cross-namespace traffic

Answer

The Service is not publishing the correct port

Answer

The Service selector does not match the Pod labels

Question 8

A user reports that a web application is not accessible via its Service. The Service is of type ClusterIP. Which TWO steps should be taken to troubleshoot?

Accepted Answer

Verify that the kube-proxy is running on the node. Option A is correct because kube-proxy is the component responsible for implementing the ClusterIP Service abstraction by managing iptables or IPVS rules on each node. If kube-proxy is not running, traffic destined for the Service's ClusterIP will not be forwarded to the backend pods, making the Service unreachable from within the cluster.

Answer

Check that the container runtime is working

Answer

Check the kube-apiserver status

Answer

Restart all nodes in the cluster

Question 9

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 10

You have a microservices application where Service A needs to discover the IP of Service B. Both services run in the same Kubernetes cluster. Which approach is the most Kubernetes-native way for Service A to reach Service B?

Accepted Answer

Use the Kubernetes DNS service to resolve the Service name 'service-b'. Kubernetes has a built-in DNS service (typically CoreDNS) that automatically creates DNS records for Services. When Service A resolves the name 'service-b' (or 'service-b.<namespace>.svc.cluster.local'), the DNS returns the cluster IP of Service B's Service object, which then load-balances traffic to the healthy Pods. This is the most Kubernetes-native approach because it leverages the platform's own service discovery mechanism without external dependencies.

Answer

Use an external service registry like Consul or etcd

Answer

Hardcode the cluster IP of Service B in the configuration of Service A

Answer

Use environment variables injected by the Kubernetes API into each pod

Question 11

A Kubernetes cluster has two nodes: control-plane and worker. The worker node runs several pods. The control-plane node becomes unreachable. What is the immediate impact on the pods running on the worker node?

Accepted Answer

Pods continue running, but new pods cannot be scheduled. When the control-plane node becomes unreachable, the kube-controller-manager cannot communicate with the kubelet on the worker node, so it stops performing scheduling and reconciliation. However, the kubelet on the worker node continues to run existing pods based on the last known desired state stored locally, and the pods themselves are managed by the container runtime (e.g., containerd) independently of the control-plane. Therefore, pods continue running normally, but no new pods can be scheduled because the scheduler, which runs on the control-plane, is unavailable.

Answer

All pods are immediately terminated

Answer

Pods are rescheduled to the control-plane node

Answer

The worker node is automatically cordoned

Question 12

A user reports that they cannot connect to a Service from within the cluster. The Service is of type ClusterIP. Running 'kubectl get endpoints service-name' shows no endpoints. What is the most likely cause?

Accepted Answer

The Service's pod selector does not match any running pods. If endpoints are empty, the Service selector does not match any pods, or the pods are not ready.

Answer

The Service is not associated with a namespace

Answer

The Service is exposed on the wrong port

Answer

The kube-proxy is not running on the node

Question 13

A user reports that they cannot connect to a database service named 'db-service' from another pod in the same namespace. The service selector matches the database pod's labels. Which command would you run FIRST to troubleshoot the service's endpoints?

Accepted Answer

kubectl get endpoints db-service. Option B is correct because `kubectl get endpoints db-service` directly shows whether the service has any endpoints (i.e., pod IPs) associated with it. If the endpoints list is empty, it indicates that the service's label selector is not matching any pods, which is the most common cause of connectivity failure. This is the fastest way to verify the fundamental prerequisite for service-to-pod traffic.

Answer

kubectl describe pod db-service

Answer

kubectl exec -it <some-pod> -- curl db-service

Answer

kubectl logs db-service

Question 14

A pod has resource requests of 512Mi memory and 500m CPU, and limits of 1Gi memory and 1 CPU. The node has 4Gi memory and 2 CPU cores. If the pod tries to use 700m CPU, what will happen?

Accepted Answer

The pod will be allowed to use 700m CPU. The pod's CPU request is 500m, and its CPU limit is 1 CPU (1000m). When the pod attempts to use 700m CPU, it is below the limit of 1000m, so it is allowed to burst up to that amount. Kubernetes uses the CPU request for scheduling and the limit for throttling; since 700m is within the limit, no throttling occurs. The pod is not evicted or terminated because it has not exceeded its memory limit or violated any resource constraints.

Answer

The pod will be throttled to 500m CPU

Answer

The pod will be evicted from the node

Answer

The pod will be terminated for exceeding the limit

Question 15

You need to deploy a batch job that processes a queue and runs to completion. The job should run exactly once and create exactly one pod per work item, but some items may fail. Which Kubernetes resource is best suited?

Accepted Answer

Job. A Job with a specified number of completions and parallelism can run pods to completion, handling failures by restarting or marking as failed.

Answer

Deployment

Answer

CronJob

Answer

DaemonSet

Question 16

A user creates a Service of type ClusterIP with a selector matching pods labeled 'app: myapp'. However, a pod named 'myapp-pod' with label 'app: myapp' is not receiving traffic. What is a possible reason?

Accepted Answer

The pod's readiness probe is failing. Services target pods by selector; if the pod is not ready due to failing readiness probes, it won't receive traffic.

Answer

The Service type should be NodePort

Answer

The pod is in a different namespace

Answer

The pod's container port is not defined

Question 17

An application requires that a pod must not be scheduled on the same node as another pod from the same Deployment. Which configuration should be used?

Accepted Answer

Pod anti-affinity with requiredDuringSchedulingIgnoredDuringExecution and topologyKey: kubernetes.io/hostname. Pod anti-affinity with a requiredDuringSchedulingIgnoredDuringExecution rule and a topologyKey of 'kubernetes.io/hostname' ensures that pods are not co-located on the same node.

Answer

Node affinity with requiredDuringSchedulingIgnoredDuringExecution

Answer

Pod affinity with a preferredDuringSchedulingIgnoredDuringExecution

Answer

Taints and tolerations

Question 18

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. Option B is correct. Initially 3 old pods. maxSurge=1 allows up to 4 total pods. maxUnavailable=1 allows at least 2 available pods. After new ReplicaSet has 2 ready, controller would have scaled down old ReplicaSet to 1 (making total 3: 2 new + 1 old). Node failure kills the old pod. New ReplicaSet remains at 2. Total running = 2 (both new). Option A would only happen if no old pods were killed. Option C would require both old pods still running. Option D would be too many.

Answer

4 pods running

Answer

3 pods running

Answer

1 pod running

Question 19

Which TWO are characteristics of the microservices architecture that are supported by container orchestration?

Accepted Answer

Independent deployment of each service. Options A and D are correct. Microservices decompose an application into loosely coupled services (A) that can be deployed independently (D). Option B is false — microservices should be loose coupling. Option C is false — microservices favor decentralized data management. Option E is false — microservices are typically small, not monolithic.

Answer

Tight coupling between services to ensure performance

Answer

Monolithic codebase with centralized deployment

Answer

Use of a single, shared database for all services

Question 20

Which of the following is a characteristic of immutable infrastructure?

Accepted Answer

Infrastructure components are never changed after deployment; they are replaced. Immutable infrastructure means that instead of modifying existing servers, new instances are created from an image and old ones are replaced.

Answer

Infrastructure is version-controlled using Git

Answer

Servers are updated in-place with configuration management tools

Answer

Containers are used to ensure portability