KCNA Practice Test 19 — 15 Questions

Question 1

Which command would you use to get the logs of a pod named 'backend' in the 'production' namespace?

Accepted Answer

kubectl logs -n production pod/backend. Both option C (`kubectl logs -n production pod/backend`) and option D (`kubectl logs backend --namespace=production`) are valid and functionally equivalent. kubectl accepts the pod name with or without the `pod/` prefix, and flags can appear before or after the resource argument. Options A (`kubectl log`, singular) and B (`kubectl get logs`) are invalid commands. Since two options are correct, the question is ambiguous as written.

Answer

kubectl log pod backend -n production

Answer

kubectl get logs backend -n production

Question 2

Which TWO of the following are true about Kubernetes Services? (Select 2)

Accepted Answer

Services can distribute traffic across Pods using labels and selectors.. Option B is correct because a Kubernetes Service uses label selectors to identify the set of backing Pods (typically via Endpoints/EndpointSlices) and load-balances traffic across them, providing a single access point regardless of how many Pod replicas exist. Option D is correct because a Service is assigned a stable virtual IP (ClusterIP) and a DNS name (e.g., my-svc.my-namespace.svc.cluster.local) that remain constant even as the underlying Pods are created, deleted, or rescheduled with new IPs. Option A is wrong because replication and scaling are handled by controllers such as ReplicaSets or Deployments, not by Services. Option C is wrong because Services can also be exposed externally via NodePort, LoadBalancer, or ExternalName types, not only internally. Option E is wrong because persistent storage is provided by PersistentVolumes and PersistentVolumeClaims, which are independent of Services.

Answer

Services automatically handle Pod replication and scaling.

Answer

Services can only expose Pods internally within the cluster.

Answer

Services are required for Pods to have persistent storage.

Question 3

Which field in a Pod's container specification defines the minimum amount of CPU guaranteed to the container?

Accepted Answer

resources.requests.cpu. In Kubernetes, the `resources.requests.cpu` field specifies the minimum amount of CPU guaranteed to a container. This value is used by the scheduler to ensure the node has enough allocatable CPU, and by the kubelet to enforce CPU shares via the Completely Fair Scheduler (CFS) in the Linux kernel.

Answer

spec.containers.cpu

Answer

resources.limits.cpu

Answer

spec.nodeSelector

Question 4

Which control plane component is responsible for persisting the entire cluster state?

Accepted Answer

etcd. etcd is the distributed key-value store that serves as the single source of truth for the entire cluster state, including all objects (Pods, Services, ConfigMaps, etc.) and their desired and current status. The kube-apiserver is the only component that directly communicates with etcd, ensuring that all state changes are persisted durably and consistently. Without etcd, the cluster would have no record of its configuration or running workloads.

Answer

kube-controller-manager

Answer

kube-apiserver

Answer

kube-scheduler

Question 5

Your organization runs a cloud-native e-commerce platform on Kubernetes. The platform consists of several microservices: a frontend service, an order service, a payment service, and a shipping service. All services communicate via HTTP REST APIs. Recently, during a flash sale event, the platform experienced a cascading failure. The order service became overwhelmed with requests and started responding slowly. This caused the frontend service to time out waiting for order responses, and eventually the frontend service crashed due to exhausted thread pools. The payment and shipping services were unaffected because they are called asynchronously via a message queue. You need to redesign the system to prevent such cascading failures in the future. Which approach is the most effective?

Accepted Answer

Implement circuit breakers in the frontend service for calls to the order service. Implementing circuit breakers in the frontend service for calls to the order service prevents cascading failures by monitoring failure rates and automatically tripping the circuit when the order service becomes slow or unresponsive. This stops the frontend from exhausting its thread pools waiting for timeouts, allowing it to fail fast and return a fallback response. Circuit breakers are a proven resilience pattern in cloud-native architectures, especially for synchronous HTTP REST calls where latency spikes can propagate.

Answer

Scale up the frontend service to handle more concurrent requests

Answer

Convert all inter-service communication to synchronous calls with retries

Answer

Increase the timeout values in the frontend service configuration

Question 6

A Kubernetes Deployment is configured with 'strategy.type: RollingUpdate'. The team wants to ensure that during an update, no more than 25% of pods are unavailable at any time. Which specification should be added?

Accepted Answer

strategy.rollingUpdate.maxUnavailable: 25%. In a RollingUpdate strategy, `maxUnavailable` defines the maximum number of pods that can be unavailable during the update relative to the desired replica count, and `maxSurge` defines how many extra pods can be created above the desired count. Setting `strategy.rollingUpdate.maxUnavailable: 25%` directly enforces the requirement that no more than 25% of pods are down at any point. The default is 25%, but the question asks which specification to *add* to guarantee it explicitly.

Answer

spec.minReadySeconds: 30

Answer

spec.replicas: 4

Answer

strategy.rollingUpdate.maxSurge: 25%

Question 7

Which TWO components run on every worker node in a Kubernetes cluster?

Accepted Answer

kubelet. kubelet (B) is correct because it is the primary node agent that runs on every worker node, registering the node with the API server and managing pod lifecycles by ensuring containers described in PodSpecs are running and healthy. kube-proxy (D) is also correct because it runs on every worker node to maintain network rules (via iptables, IPVS, or nftables) that implement Kubernetes Service abstraction and enable pod-to-pod and external communication. In contrast, kube-scheduler (A), etcd (C), and kube-apiserver (E) are control plane components that typically run on master/control-plane nodes, not on every worker node, so they do not belong in this answer.

Answer

kube-scheduler

Answer

etcd

Answer

kube-apiserver

Question 8

You create a Pod with a liveness probe that uses an HTTP GET on port 8080, path /healthz. The probe fails after the container starts. What will happen to the Pod?

Accepted Answer

The container will be restarted automatically. A liveness probe is designed to determine if a container is still running properly. When an HTTP GET liveness probe fails, kubelet considers the container unhealthy and automatically restarts it according to the Pod's restart policy (defaulting to Always). This ensures the container can recover from transient failures without manual intervention.

Answer

The Pod will be marked as Unhealthy and removed from Service endpoints

Answer

The Pod will be evicted from the node

Answer

The Pod will be deleted and recreated on a different node

Question 9

Which THREE of the following are components of the GitOps workflow? (Choose three.)

Accepted Answer

A CI/CD pipeline that validates changes before merging. GitOps relies on a Git repository as single source of truth, a CI/CD pipeline to validate changes, and an operator to sync the cluster.

Answer

A configuration management database (CMDB)

Answer

A manual approval process for every change

Question 10

Which TWO of the following are valid ways to expose a Deployment as a Service?

Accepted Answer

Run 'kubectl expose deployment my-deployment --port=80 --target-port=8080'. Option A is correct because 'kubectl expose deployment my-deployment --port=80 --target-port=8080' is the imperative command that creates a Service of type ClusterIP (by default) targeting the Deployment's pods, with the Service port 80 forwarding to container port 8080. Option E is correct because a Service is decoupled from the Deployment and selects its backing pods via 'spec.selector' matching the Deployment's pod template labels (e.g., app=my-deployment), so authoring a Service YAML with the correct selector is a valid declarative way to expose the Deployment. Option B is incorrect because 'spec.serviceName' is not a valid Deployment field; the closest concept, 'serviceName', belongs to StatefulSet's spec and is used for headless Service governance, not for exposing a Deployment. Option C is incorrect because 'kubectl run' creates a new Pod (or with newer versions a Pod), not a Deployment, and '--expose' would expose that newly created resource rather than an existing Deployment. Option D is incorrect because a Deployment's manifest has no 'service' section; Services are separate API objects (kind: Service) and cannot be embedded in a Deployment spec.

Answer

Edit the Deployment and set 'spec.serviceName'

Answer

Run 'kubectl run my-deployment --image=nginx --expose'

Answer

Add a 'service' section to the Deployment's YAML manifest

Question 11

Which component of the control plane is the only one that directly interacts with etcd?

Accepted Answer

kube-apiserver. The kube-apiserver is the only component of the Kubernetes control plane that directly interacts with etcd. It acts as the front-end for the control plane, exposing the Kubernetes API, and all reads and writes to the cluster's state stored in etcd must go through the API server. Other components like the kube-controller-manager and kube-scheduler only communicate with etcd indirectly via the kube-apiserver, never directly.

Answer

kube-controller-manager

Answer

kube-scheduler

Answer

kubelet

Question 12

What is the Container Runtime Interface (CRI)?

Accepted Answer

An API between kubelet and container runtime. The Container Runtime Interface (CRI) is a plugin interface that enables the kubelet to use a variety of container runtimes without needing to recompile the kubelet. It defines a gRPC API (protocol buffers) for the kubelet to communicate with the container runtime, covering operations like pod lifecycle management and image management. Option D correctly identifies this as the API between the kubelet and the container runtime.

Answer

A tool for building container images

Answer

A standard for container runtime logs

Answer

A specification for container images

Question 13

A pod has a liveness probe that returns failure. What action will Kubernetes take?

Accepted Answer

The container will be restarted. When a liveness probe fails, Kubernetes interprets this as the container being in a deadlock or unresponsive state from which it cannot recover without a restart. The kubelet on the node where the pod is running directly restarts the container according to the pod's restart policy (defaulting to Always). This is a container-level action, not a pod-level action, so the pod itself remains on the same node.

Answer

The service endpoint will be removed

Answer

The pod will be deleted

Answer

The pod will be rescheduled to another node

Question 14

Which TWO of the following are valid uses of Kubernetes Namespaces? (Select 2)

Accepted Answer

Enforcing network policies per namespace. Option B is correct because Kubernetes NetworkPolicy objects are namespaced resources, so network policies are defined and applied per namespace to control ingress and egress traffic for the pods within that namespace. Option C is correct because namespaces provide logical partitioning of cluster resources, allowing teams to run dev, staging, and prod workloads in the same physical cluster with separate names, quotas, and access controls. Option A is not correct because CPU and memory limits are set on Pods/Containers (via resources.requests/limits) or enforced cluster-wide per namespace using ResourceQuota and LimitRange objects, not as a namespace-level setting itself. Option D is not correct because namespaces do not isolate node resources; node-level isolation is achieved through taints, tolerations, node affinity, or separate node pools. Option E is not correct because namespaces do not provide authentication; RBAC handles authorization, while authentication is performed by the API server via tokens, certificates, or external identity providers, with RoleBindings scoped to a namespace.

Answer

Setting CPU and memory limits at the namespace level

Answer

Isolating node resources for different workloads

Answer

Enabling RBAC authentication for users in a namespace

Question 15

In a YAML manifest for a Deployment, which field defines the number of pod replicas?

Accepted Answer

spec.replicas. In a Kubernetes Deployment manifest, the `spec.replicas` field is the correct place to define the desired number of pod replicas. This field is a top-level attribute under the Deployment's `spec` object, and the ReplicaSet controller uses this integer value to ensure the specified number of Pods are running at all times.

Answer

spec.strategy.replicas

Answer

metadata.replicas

Answer

spec.template.replicas