KCNA Practice Test 47 — 15 Questions

Question 1

A microservices application has multiple services that need to discover each other by name. Which Kubernetes object provides built-in service discovery via DNS?

Accepted Answer

Service. A Kubernetes Service object provides built-in service discovery via DNS. When a Service is created, the cluster's DNS (typically CoreDNS) automatically assigns it a DNS name in the format `..svc.cluster.local`, allowing other microservices to resolve the Service by name without hardcoding IP addresses or using external service registries.

Answer

Ingress

Answer

Namespace

Answer

ConfigMap

Question 2

A pod has resource requests: cpu: 250m, memory: 512Mi and limits: cpu: 500m, memory: 1Gi. If the container tries to use 600m CPU and 700Mi memory, what will happen?

Accepted Answer

The container will be throttled for CPU, but will not be killed because memory is within limits. CPU is a compressible resource: exceeding the CPU limit (500m) causes throttling, not termination. Memory is a non-compressible resource, and since the container's memory usage (700Mi) is below its limit (1Gi), it will not be killed. The container will be CPU-throttled but allowed to continue running.

Answer

The container will be allowed to use the extra resources because limits are only soft constraints

Answer

The container will be throttled for CPU and may be terminated if it continues to exceed the limit

Answer

The container will be killed immediately because it exceeded its CPU limit

Question 3

In GitOps with ArgoCD, what does 'self-healing' refer to?

Accepted Answer

Automatically reverting manual changes to match the Git repository. In ArgoCD, self-healing refers to the automatic reconciliation of the live cluster state with the desired state defined in Git. When a manual change is made to a resource in the cluster (e.g., editing a Deployment), ArgoCD detects the drift and automatically reverts the resource to match the Git repository. This ensures that Git remains the single source of truth and prevents configuration drift.

Answer

Automatically scaling applications based on metrics

Answer

Automatically restarting failed pods

Answer

Automatically updating the Git repository when changes are made in the cluster

Question 4

You run 'kubectl get pods' and see that a pod named 'web-frontend' is in 'Pending' state for more than 5 minutes. What is the most likely cause?

Accepted Answer

There are insufficient resources on any node to schedule the pod. A pod stuck in 'Pending' state for an extended period typically indicates that the scheduler cannot find a suitable node to run the pod. The most common reason is insufficient resources (CPU, memory, or ephemeral storage) on any available node, causing the scheduler to leave the pod unscheduled. This is confirmed by running 'kubectl describe pod web-frontend' and checking the 'Events' section for 'FailedScheduling' messages.

Answer

The container image does not exist

Answer

The pod's readiness probe is failing

Answer

The pod's liveness probe is failing

Question 5

Which TWO of the following are responsibilities of the kubelet on a worker node?

Accepted Answer

Ensuring containers are running as specified in the PodSpec. Option D is correct because the kubelet is the node agent that watches for PodSpecs assigned to its node and actively reconciles the actual container state to match the desired state, restarting or starting containers via the container runtime (e.g., containerd or CRI-O) so they run as specified. Option E is correct because the kubelet registers its node with the control plane by creating/updating the Node object through the API server, and it periodically reports node status and heartbeats. Option A is wrong because etcd is the cluster's distributed key-value store, written to by the API server, not by the kubelet. Option B is wrong because Pod scheduling is performed by the kube-scheduler, which selects a node and binds the Pod; the kubelet only runs Pods already assigned to it. Option C is wrong because Service network rules (iptables/IPVS or eBPF load-balancing) are implemented by the kube-proxy, not the kubelet.

Answer

Storing cluster state in etcd

Answer

Scheduling Pods onto the node

Answer

Implementing network rules for Services

Question 6

Which THREE of the following are benefits of using a service mesh? (Choose 3.)

Accepted Answer

Security. A service mesh provides security benefits (B) by enforcing mutual TLS (mTLS) between workloads, issuing and rotating service identities/certificates, and applying fine-grained authorization policies without changing application code. It delivers observability (C) through sidecar proxies that automatically collect metrics (e.g., request rate, latency, error rates), distributed traces, and access logs across service-to-service calls. It also offers traffic management (E) via features such as dynamic routing, load balancing, retries, timeouts, circuit breaking, and canary or blue/green deployments. The remaining options are unrelated: database management (A) is handled by database systems or DBaaS platforms, not a service mesh, and code compilation (D) is a build-time developer/CI activity that a service mesh does not perform.

Answer

Database management

Answer

Code compilation

Question 7

Which TWO are valid reasons to use a Namespace in Kubernetes?

Accepted Answer

To enforce network policies that restrict traffic between Pods in different Namespaces.. Option A is correct because Namespaces provide a boundary for scoping resources, and NetworkPolicy objects are namespaced resources that select Pods within a namespace; policies can allow or deny ingress/egress traffic to Pods in other namespaces, so namespaces are a valid way to organize and enforce network segmentation between teams or environments. Option C is correct because Namespaces provide logical isolation of cluster resources (Pods, Services, ConfigMaps, etc.) and enforce unique names within each namespace, so two teams can each create a Service named 'web' in their own namespace without collision. Option B is not a reason to use Namespaces, since namespaces do not reduce control-plane API calls; if anything, managing more namespaces adds API objects. Option D is not correct because namespaces are an organizational and isolation construct and do not reduce network latency or improve application performance. Option E is not correct because environment variables for containers are supplied via Pod specs, ConfigMaps, or Secrets, not by namespaces themselves.

Answer

To reduce the number of API calls to the control plane.

Answer

To improve application performance by reducing latency.

Answer

To store environment variables for containers.

Question 8

Which THREE of the following are benefits of using container orchestration? (Choose three.)

Accepted Answer

High availability through automated failover. Option A is correct because container orchestration platforms such as Kubernetes continuously monitor node and pod health and automatically reschedule or failover workloads to healthy nodes, providing high availability without manual intervention. Option D is correct because orchestrators implement self-healing by detecting failed or unhealthy containers (for example, via liveness probes in Kubernetes) and automatically restarting or replacing them to maintain the desired state. Option E is correct because orchestrators support automatic scaling of applications based on demand, such as Kubernetes Horizontal Pod Autoscaler adjusting replica counts according to CPU utilization or custom metrics. Option B is not a benefit of orchestration itself; decomposing applications into microservices is an architectural design choice that can be deployed on orchestration but is not provided by it. Option C is also not a benefit of orchestration; simplified flat networking is a characteristic of some container network plugins (like flannel or Calico overlay networks), not an inherent benefit of the orchestration layer.

Answer

Decomposition of applications into microservices

Answer

Simplified networking with flat network topology

Question 9

Which TWO of the following are valid container runtimes that implement the CRI? (Choose two.)

Accepted Answer

CRI-O. CRI-O (option B) is a lightweight container runtime purpose-built by Red Hat specifically to implement the Kubernetes Container Runtime Interface (CRI), so it directly satisfies the requirement. containerd (option D) also natively implements the CRI plugin, which is why Kubernetes can use it as a container runtime without any additional shim. Kata Containers (option A) is a runtime that provides VM-isolated containers but is typically plugged in via a CRI implementation such as containerd's CRI plugin or CRI-O, not as a standalone CRI runtime itself. Docker (option C) predates the CRI and does not implement it natively; it required the deprecated dockershim adapter to work with Kubernetes. rkt (option E) was an alternative container runtime that never implemented the CRI and has since been discontinued.

Answer

Kata Containers

Answer

Docker

Answer

rkt

Question 10

What is context propagation in distributed tracing?

Accepted Answer

Carrying trace context (trace ID, span ID) across services. Context propagation is the mechanism by which trace context — primarily the trace ID and the current span ID — is passed from one service to the next across network calls, so all spans belonging to the same request are stitched into a single distributed trace. This is typically done via HTTP headers (e.g., W3C `traceparent`) or message metadata. Without it, each service would create an isolated trace and the end-to-end picture would be lost.

Answer

Sampling traces to reduce data volume

Answer

Visualizing traces in a user interface

Answer

Storing trace data in a centralized database

Question 11

Which component is responsible for ensuring that the containers in a pod are running as specified?

Accepted Answer

kubelet. The kubelet is the primary node agent that runs on each worker node. It receives PodSpec definitions from the API server (or from a local file/HTTP source for static pods) and ensures that the containers described in those PodSpecs are actually running and healthy. It does this by interacting with the container runtime (e.g., containerd or CRI-O) via the CRI to start, stop, and restart containers as needed, continuously reconciling the actual state with the desired state.

Answer

kube-apiserver

Answer

kube-controller-manager

Answer

kube-proxy

Question 12

Which THREE of the following are core components of a Kubernetes worker node?

Accepted Answer

container runtime. The three core components of a Kubernetes worker node are the container runtime (C), kube-proxy (D), and kubelet (E). The container runtime (C) is required because it is the software (e.g., containerd, CRI-O) that actually pulls images and runs containers on the node. kubelet (E) is the primary node agent that registers the node with the control plane and manages Pods and their containers via the CRI. kube-proxy (D) implements the Service networking rules on the node, maintaining iptables/IPVS rules so that Service VIPs and load balancing work for Pods. Options A (etcd) and B (kube-apiserver) are not worker node components; they are control plane components, with etcd being the cluster's key-value datastore and kube-apiserver being the API front end.

Answer

etcd

Answer

kube-apiserver

Question 13

A team uses Helm to manage their Kubernetes applications. They need to upgrade a release and want to reuse the values from the previous release while overriding a specific value. Which helm command should they use?

Accepted Answer

helm upgrade --reuse-values my-release ./charts/app --set image.tag=v2. The --reuse-values flag tells Helm to reuse the last release's values and merge any provided overrides. This is the correct approach to preserve existing values while updating a specific one.

Answer

helm upgrade --reset-values my-release ./charts/app --set image.tag=v2

Answer

helm upgrade --atomic my-release ./charts/app --set image.tag=v2

Answer

helm upgrade --history-max 5 my-release ./charts/app --set image.tag=v2

Question 14

Which TWO statements are true about cloud-native architecture?

Accepted Answer

Infrastructure is treated as immutable. Option B is correct because cloud-native architecture treats infrastructure as immutable — servers and containers are provisioned from versioned images and replaced rather than patched in place, which enables consistent, reproducible deployments and supports practices like blue/green and rolling updates. Option D is correct because cloud-native design decomposes applications into loosely coupled microservices that can each be scaled independently (e.g., via Kubernetes Horizontal Pod Autoscaler or similar orchestration), so a hot service can scale out without scaling the entire application. Option A is incorrect because cloud-native favors small, independently deployable microservices over monolithic applications. Option C is incorrect because autoscaling driven by metrics is the default approach, not manual scaling. Option E is incorrect because cloud-native prefers stateless components with state externalized to managed data services, since statelessness improves scalability, resilience, and portability.

Answer

Applications are typically monolithic for simplicity

Answer

Manual scaling is the default approach

Answer

Stateful components are preferred for performance

Question 15

Which TWO components are part of the Kubernetes control plane?

Accepted Answer

etcd. etcd (C) is correct because it is the control plane's distributed key-value store that persistently holds all cluster state and configuration data, which the API server reads and writes. kube-apiserver (D) is correct because it is the central control plane component that exposes the Kubernetes API, validates and processes REST requests, and is the front end through which all other components communicate. The other options are node-level components, not control plane components: kube-proxy (A) implements Service networking rules on each node, kubelet (B) runs on each node and manages Pods/containers via the container runtime, and the container runtime (E) is the node software (e.g., containerd, CRI-O) that actually runs containers.

Answer

kube-proxy

Answer

kubelet

Answer

container runtime