KCNA Timed Practice Test 2 — 10 Questions

Question 1

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 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

Which THREE are key benefits of using a service mesh in a cloud-native architecture? (Choose 3)

Accepted Answer

Mutual TLS (mTLS) encryption between services.. Option B is correct because a service mesh, such as Istio or Linkerd, transparently enables mutual TLS (mTLS) encryption between service sidecar proxies without requiring application code changes. This ensures all inter-service communication is encrypted and authenticated, which is a core security benefit in a zero-trust cloud-native architecture.

Answer

Persistent storage management for stateful applications.

Answer

Automatic horizontal scaling of pods.

Question 4

Match each cloud native concept to its definition.

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

What is the primary purpose of a Kubernetes Service?

Accepted Answer

To provide a stable network endpoint for a set of Pods. A Service provides a stable endpoint for a set of Pods, enabling discovery and load balancing across them.

Answer

To manage rolling updates of Pods

Answer

To schedule Pods onto Nodes

Answer

To store configuration data for Pods

Question 9

You need to store a database password securely and make it available to a Pod as an environment variable. Which Kubernetes resource should you create?

Accepted Answer

Secret. Secrets are designed to store sensitive data, such as passwords, and can be exposed to Pods via environment variables or volumes.

Answer

PersistentVolume

Answer

ConfigMap

Answer

ServiceAccount

Question 10

Two pods, 'app-v1' and 'app-v2', both have a label 'app: myapp'. A Service 'my-service' has a selector 'app: myapp'. How many endpoints will the Service initially have?

Accepted Answer

2. Option A is correct because the Service's selector 'app: myapp' matches both pods 'app-v1' and 'app-v2', which both carry the label 'app: myapp'. The Service controller automatically creates endpoints for all pods matching the selector, regardless of their readiness state, unless a headless service or custom endpoint logic is involved. Initially, both pods are considered ready by default (unless a readiness probe fails), so the Service will have two endpoints.

Answer

1

Answer

0

Answer

Depends on pod readiness