Kubernetes and Cloud Native Associate KCNA (KCNA) — Questions 1–75

Why this answer

How to eliminate wrong answers

Option B is wrong because `$(APP_CONFIG_DATABASE_URL)` is not a valid Kubernetes syntax for referencing ConfigMap values; it resembles a shell variable substitution, not a Kubernetes environment variable reference. Option C is wrong because it uses `secretKeyRef`, which is for referencing Secrets, not ConfigMaps; ConfigMaps must use `configMapKeyRef`. Option D is wrong because `configMapRef` is not a valid field under `valueFrom`; the correct field is `configMapKeyRef`.

Why this answer

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes that deploys pre-packaged applications (charts) but is not an IaC tool; it manages releases and templates, not infrastructure state. Option B is wrong because kubectl is a command-line client for interacting with Kubernetes API directly, used for imperative or ad-hoc operations, not for declarative infrastructure provisioning or state management. Option C is wrong because Kustomize is a configuration customization tool that overlays patches on Kubernetes manifests without managing infrastructure state or provisioning resources outside of Kubernetes.

Why this answer

How to eliminate wrong answers

Option A is wrong because 'Backing services' (Factor IV) treats attached services (databases, caches, message queues) as disposable resources accessed via URL or binding, not about storing configuration. Option C is wrong because 'Processes' (Factor VI) concerns stateless execution and sharing nothing between processes, not configuration storage. Option D is wrong because 'Build, release, run' (Factor V) describes the strict separation of build, release, and run stages to ensure immutability, not the mechanism for injecting configuration.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because alerting on abnormal metrics is the responsibility of monitoring systems like Prometheus with Alertmanager, not the OpenTelemetry Collector, which focuses on data ingestion, processing, and export. Option B is wrong because long-term storage of traces is handled by backend systems (e.g., Jaeger, Tempo) or databases; the Collector is a pipeline component that forwards data, not a persistent store. Option D is wrong because manual instrumentation of application code is done using OpenTelemetry SDKs and APIs (e.g., for traces, metrics), while the Collector operates as a separate infrastructure component that receives already-instrumented telemetry.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules and forwarding traffic for Services, not managing container lifecycle. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is the software that actually runs containers, but it is not responsible for reconciling Pod manifests or ensuring desired state — that is the kubelet's job. Option D is wrong because kube-controller-manager runs as a control plane component (not on every node) and manages controllers like ReplicaSet and Node Controller, but does not directly interact with containers on individual nodes.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because `kubectl create service clusterip` requires a selector to match the pods, but the command does not specify `--clusterip` or a selector; it creates a service with no endpoints, leaving it non-functional. Option C is wrong because `kubectl run` creates a deployment or pod, not a service; it does not expose anything on a stable IP. Option D is wrong because `kubectl expose pod` targets a specific pod by name, not a set of pods with a label selector; it would expose only that single pod, not the entire set, and the pod name 'web' likely does not exist.

Why this answer

How to eliminate wrong answers

Option A is wrong because container orchestration does not inherently reduce memory usage; memory consumption depends on the container image and application, not the orchestration layer. Option C is wrong because orchestration still requires container images (e.g., Docker images stored in a registry) to run pods; it does not eliminate the need for images. Option D is wrong because orchestration does not make containers run faster; it adds a small overhead for scheduling and API calls, and performance is determined by the runtime and host OS, not the orchestrator.

Why this answer

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that exactly one pod runs on each node, not a specified number of replicas, and is used for node-level services like logging or monitoring. Option B is wrong because a Job runs a finite task to completion and does not maintain a continuous set of running replicas. Option C is wrong because a StatefulSet is designed for stateful applications requiring stable network identities and persistent storage, which is unnecessary for a stateless web application.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl log` is not a valid command; the correct verb is `logs`. Option B is wrong because it omits the `-c` flag, which is required to specify a container in a multi-container Pod; without it, `kubectl logs` defaults to the first container or fails if multiple containers exist. Option D is wrong because the argument order is reversed; the pod name must come first, followed by the `-c` flag and container name.

Why this answer

How to eliminate wrong answers

Option B is wrong because storing cluster state is the job of etcd, a distributed key-value store that runs on the control plane, not the kubelet. Option C is wrong because managing network rules for Services is handled by the kube-proxy component (which implements iptables or IPVS rules), not the kubelet. Option D is wrong because the kubelet does not run the container runtime; it communicates with the container runtime via the Container Runtime Interface (CRI) to manage containers, but the runtime itself (e.g., containerd) is a separate process.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because container resource limits (e.g., `resources.limits.cpu` and `resources.limits.memory`) control how much CPU and memory a container can consume, not where the Pod is scheduled. Option C is wrong because tolerations are used to allow Pods to schedule on nodes with taints, not to select nodes based on labels; tolerations enable scheduling on tainted nodes but do not actively select nodes by label. Option D is wrong because `nodeAffinity` is a more advanced feature that supports complex label matching (e.g., `requiredDuringSchedulingIgnoredDuringExecution` with `matchExpressions`), but the question asks for the field that should be used, and `nodeSelector` is the simplest and most appropriate for a single label match like `disktype=ssd`.

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because the cooldown period of 3 minutes only delays scaling actions, it does not prevent scaling entirely; if CPU usage remains high for longer than 3 minutes, the HPA would still scale. Option C is wrong because the HPA bases its scaling decision on the average CPU utilization relative to the resource request (500m), not the limit (1000m); with 800m usage, utilization is 160% of the request, which should trigger scaling. Option D is wrong because the cluster has ample capacity, as stated in the question, so insufficient nodes are not the issue.

Why this answer

How to eliminate wrong answers

Option A is wrong because Kubernetes does not provide a graphical interface natively; while tools like the Kubernetes Dashboard exist, they are optional add-ons, not the primary purpose. Option B is wrong because Kubernetes does not replace virtual machines with containers; it orchestrates containers that often run on top of VMs or bare metal, and VMs remain a separate abstraction layer. Option C is wrong because compiling container images from source code is the job of CI/CD tools (e.g., Docker build, Kaniko) or build systems, not Kubernetes itself.

Why this answer

How to eliminate wrong answers

Option B is wrong because the 12-factor app methodology was defined by Heroku engineers in 2011, not by the CNCF, and while the CNCF promotes cloud native patterns, it did not create that specific methodology. Option C is wrong because the CNCF does not provide cloud infrastructure services (e.g., compute, storage, networking) — that is the role of cloud providers like AWS, Azure, or GCP; the CNCF is a foundation that hosts projects, not a service provider. Option D is wrong because while the CNCF hosts Kubernetes, it also hosts dozens of other projects (e.g., Prometheus, Fluentd, Linkerd) and is not exclusive to Kubernetes; its mission is broader than any single project.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl expose deployment my-svc` attempts to expose a Deployment named 'my-svc', but the question specifies a Service named 'my-svc', not a Deployment; exposing a Deployment would create a new Service from scratch, not modify the existing one. Option B is wrong because `kubectl expose service my-svc --name=my-svc-lb` omits `--type=LoadBalancer`, so it creates a new Service of the default type ClusterIP, which is only reachable within the cluster and does not provision an external load balancer. Option C is wrong because `kubectl expose service my-svc --port=80 --target-port=8080` changes the port mapping but does not include `--type=LoadBalancer`, so the resulting Service remains ClusterIP (or inherits the original type) and does not become an external endpoint via a cloud load balancer.

Why this answer

How to eliminate wrong answers

Option A is wrong because it places the `-c web` flag before the pod name, which is syntactically incorrect; the `-c` flag must follow the pod name. Option C is wrong because it uses an invalid positional argument 'container' after the pod name; `kubectl logs` does not accept a literal 'container' keyword. Option D is wrong because it omits the `-c` flag entirely, so it would attempt to view logs from the pod's default container (or fail if the pod has multiple containers and no default is defined), not specifically from the container named 'web'.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because ConfigMaps are not immutable by default; they can be updated unless the `immutable` field is explicitly set to `true`. Option B is wrong because if the ConfigMap were referenced by a different name, the Pod would fail to start or mount, not silently use old data. Option D is wrong because the `Recreate` update strategy would terminate all Pods and create new ones, which would pick up the updated ConfigMap; it does not cause stale configuration.

Why this answer

How to eliminate wrong answers

Option B is wrong because running event-processing logic is the responsibility of event processors or stream processing frameworks (e.g., Apache Flink, Kafka Streams), not the event broker, which focuses on routing and delivery. Option C is wrong because transforming events into API calls is a function of an API gateway or integration layer, not the event broker; brokers handle event transport, not protocol translation. Option D is wrong because storing event schemas is typically managed by a schema registry (e.g., Confluent Schema Registry) that works alongside the broker, but the broker itself does not store schemas—it stores and forwards event data.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod would only temporarily restart the container; it would still hit the same memory limit and be OOMKilled again, perpetuating the crash loop. Option D is wrong because increasing the CPU request does not affect memory limits; OOMKilled is caused by exceeding memory, not CPU, so this change would not resolve the issue.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Flannel with host-gw backend only improves pod-to-pod routing by using direct host routes, but it does not address iptables performance degradation for service load balancing; Flannel still relies on iptables or IPVS for Service ClusterIP forwarding. Option B is wrong because Calico with iptables mode uses the same iptables data path that is already causing performance issues; it would not improve latency and may even worsen it with additional policy rules. Option D is wrong because applying a default-deny NetworkPolicy adds more iptables rules to enforce isolation, which increases the rule count and further degrades iptables performance, the opposite of what is needed.

Why this answer

Why this answer

How to eliminate wrong answers

Option B (StatefulSet) is wrong because StatefulSets are used for stateful applications that require stable, unique network identities and persistent storage, not for one-time batch jobs. Option C (DaemonSet) is wrong because DaemonSets ensure that a copy of a Pod runs on every (or selected) node in the cluster, typically for daemon-like services such as logging or monitoring, not for tasks that run to completion. Option D (Deployment) is wrong because Deployments manage a set of identical Pods with a desired replica count, ensuring they are always running and self-healing, which is the opposite of a one-time batch job that should terminate upon success.

Why this answer

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-scheduler is a control plane component responsible for assigning pods to nodes based on resource requirements and constraints, not for running containers on a node. Option B is wrong because kube-proxy is a network proxy that runs on each node, handling network rules (e.g., iptables or IPVS) for service abstraction and pod-to-service communication, not container lifecycle management. Option D is wrong because etcd is a distributed key-value store used as Kubernetes' backing store for all cluster data, not a node-level component that manages containers.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a Deployment is designed for long-running, stateless applications that must maintain a desired replica count indefinitely; it will restart Pods upon completion, which is the opposite of a terminating batch job. Option B is wrong because a DaemonSet ensures that a copy of a Pod runs on every (or selected) Node in the cluster, typically for cluster-wide services like logging or monitoring, not for a one-time batch task. Option C is wrong because a StatefulSet is intended for stateful applications that require stable, unique network identities and persistent storage, such as databases, and it maintains a sticky identity across restarts, which is unnecessary and inappropriate for a terminating queue-processing job.

Why this answer

Why this answer

How to eliminate wrong answers

Option B (kubelet) is wrong because kubelet is the primary node agent that manages Pod lifecycle (creating, stopping, and reporting Pod status) and mounts volumes, but it does not enforce network rules or implement Service abstractions. Option C (container runtime) is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for network policy or Service proxying. Option D (kube-scheduler) is wrong because kube-scheduler runs on the control plane, not worker nodes, and is responsible for assigning Pods to nodes based on resource availability and constraints, not for enforcing network rules.

Why this answer

How to eliminate wrong answers

Option B is wrong because tight coupling contradicts the core principle of microservices; it would create a monolithic dependency graph where a change in one service requires coordinated changes in others, negating the benefits of independent scaling and fault isolation. Option C is wrong because microservices explicitly allow polyglot programming — each service can be written in the language best suited for its task (e.g., Go for high-throughput services, Python for data processing) and communicate over standard protocols. Option D is wrong because sharing a single database creates tight coupling at the data layer, violating service autonomy; each microservice should own its private database (database-per-service pattern) to avoid schema conflicts and enable independent schema evolution.

Why this answer

How to eliminate wrong answers

Option A is wrong because a ReplicationController does not support rolling updates natively; it only ensures a specified number of Pod replicas are running, and updating its pod template requires manual deletion and recreation of Pods, causing downtime. Option C is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, and it is not designed for managing stateless application replicas with zero-downtime updates; its update strategy can be RollingUpdate or OnDelete, but it is not the feature intended for a Deployment like 'web-app'. Option D is wrong because StatefulSet's onDelete strategy requires manual Pod deletion to trigger updates, which does not provide automatic zero-downtime updates; StatefulSets are designed for stateful applications and their default update strategy is RollingUpdate, but the question asks about a Deployment, not a StatefulSet.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl expose` creates a Service to expose a Deployment or pod, but it does not update container images; it only manages network access. Option B is wrong because deleting and recreating the Deployment would cause a period of downtime while the new Deployment is being created and pods are scheduled, violating the requirement for no downtime. Option D is wrong because manually deleting pods one by one would cause the existing ReplicaSet to recreate them with the original image, not the new one, and this approach is not automated and risks downtime if pods are deleted faster than they are recreated.

Why this answer

How to eliminate wrong answers

Option B (kube-proxy) is wrong because it is a network proxy that runs on each node, handling service-to-Pod traffic routing using iptables or IPVS rules, not maintaining desired state. Option C (kubelet) is wrong because it is the node agent that ensures containers are running in a Pod as specified by the PodSpec, but it only acts on instructions from the API server and does not maintain the overall desired state of the cluster. Option D (etcd) is wrong because it is a distributed key-value store that holds the cluster's configuration and state data, but it is a passive storage backend and does not actively reconcile or maintain the desired state.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because a nodeSelector only matches node labels, not taints; it cannot override the scheduling restriction imposed by a NoSchedule taint. Option B is wrong because removing the taint would affect all pods and is unnecessary when only a specific pod needs to run on that node; it also violates the principle of least privilege. Option D is wrong because podAffinity attracts pods based on labels of other pods, not node-level taints, and does not bypass the NoSchedule effect.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because it uses a 1-minute rate window (`[1m]`), which does not align with the requirement to evaluate over a 5-minute period; this would cause the alert to trigger on short bursts rather than sustained latency. Option C is wrong because `avg(rate(...))` calculates the average rate across all buckets, which has no relation to percentile latency and cannot detect the 99th percentile threshold. Option D is wrong because `max(rate(...))` takes the maximum rate across buckets, which is not a percentile metric and would incorrectly alert on the highest bucket's rate rather than the 99th percentile latency.

Why this answer

How to eliminate wrong answers

Option A is wrong because a Deployment with ClusterIP Service and Ingress does not guarantee stable pod identities or persistent storage per pod; Deployments treat pods as ephemeral, and Ingress alone cannot enforce session affinity at the pod level. Option B is wrong because a Job is designed for batch processing and terminates after completion, making it unsuitable for a long-running application requiring persistent storage and session affinity; a LoadBalancer Service also does not provide stable pod identities. Option C is wrong because a DaemonSet runs one pod per node, which does not provide the ordered, stable pod identities needed for persistent storage and session affinity; NodePort Service exposes pods on a static port per node but does not ensure session stickiness or stable storage.

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl edit deployment nginx` opens the deployment manifest in an editor, which is interactive and does not automatically record the change in the rollout history unless you manually add an annotation; it also requires manual editing, which is error-prone and not the intended command for a simple image update with recording. Option B is wrong because `kubectl apply -f deployment.yaml` applies a manifest file, which would update the deployment only if the file is modified, but it does not inherently record the change in the rollout history unless the manifest includes an annotation; it also requires a separate file, making it less direct than the `--record` flag. Option D is wrong because it lacks the `--record` flag, so while it updates the container image, it does not annotate the change in the rollout history, failing to meet the requirement to 'record the change'.

Why this answer

How to eliminate wrong answers

Option B is wrong because cross-namespace service access is allowed by default in Kubernetes; there is no built-in network policy blocking it, and the issue is purely DNS resolution, not network-level access. Option C is wrong because the question states the connection fails due to DNS resolution, not because the service lacks endpoints; even if endpoints exist, the pod cannot resolve the short service name across namespaces. Option D is wrong because the service port configuration is irrelevant if the DNS name cannot be resolved; the connection fails before any port-level communication occurs.

Why this answer

How to eliminate wrong answers

Option A is wrong because NodePort exposes the application on a static port on each node's IP (range 30000-32767), not via a cloud load balancer, and does not provide a fixed external port like 80 or 443. Option C is wrong because ExternalName maps a Service to a DNS name (CNAME record) and does not expose any ports or provide load balancing; it is used for external service discovery, not for exposing an application externally. Option D is wrong because ClusterIP exposes the Service only on a cluster-internal IP, making it unreachable from outside the cluster without additional components like an Ingress or a proxy.

Why this answer

How to eliminate wrong answers

Option A is wrong because kube-controller-manager runs controller processes (e.g., Node Controller, Replication Controller) that regulate cluster state, but it does not run on every node nor manage per-node network rules. Option C is wrong because the container runtime (e.g., containerd, CRI-O) is responsible for pulling images and running containers, not for maintaining network rules for Pod communication. Option D is wrong because kubelet is the primary node agent that registers the node with the API server and manages Pod lifecycle (e.g., ensuring containers are running), but it does not handle network rule maintenance for Service-to-Pod traffic.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because the container runtime (e.g., containerd, CRI-O) is a separate component that runs containers, not kube-proxy. Option B is wrong because cluster configuration data is stored in etcd, a distributed key-value store, not in kube-proxy. Option D is wrong because monitoring pod health and restarting unhealthy containers is the responsibility of the kubelet, specifically through liveness probes and pod lifecycle management, not kube-proxy.

Why this answer

Why this answer

How to eliminate wrong answers

Option B is wrong because NetworkPolicy is a firewall rule that controls ingress/egress traffic at the pod level using IP blocks or label selectors, but it does not provide stable network endpoints or load balancing. Option C is wrong because Ingress is an API object that manages external HTTP/HTTPS routing to Services (typically via a controller like NGINX), but it does not itself provide stable endpoints or load balance directly to pods; it relies on a Service for that. Option D is wrong because EndpointSlice is a lower-level resource that tracks the actual pod IPs and ports backing a Service, but it is a data object consumed by kube-proxy, not a resource that provides stable endpoints or load balancing on its own.

Why this answer

How to eliminate wrong answers

Option A is wrong because an Ingress is not a resource that provides a stable IP/DNS for Pods directly; it is a layer 7 HTTP/HTTPS routing rule that exposes Services externally, relying on a Service to provide the stable endpoint. Option B is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to provide network endpoints or IP addresses. Option C is wrong because a Deployment manages the desired state and lifecycle of Pods (replicas, rolling updates) but does not assign a stable IP or DNS name; Pods managed by a Deployment get new IPs on restart.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because Kubernetes never automatically increases a resource limit; limits are static and defined in the Pod spec. Option C is wrong because Pod eviction occurs when a node is under memory pressure and the Pod's usage exceeds its request, not when a single container exceeds its limit (the container is killed in-place). Option D is wrong because memory limits are hard constraints enforced by the kernel's cgroup OOM killer, not soft constraints; the container cannot exceed the limit.

Why this answer

Why this order

Why this answer

How to eliminate wrong answers

Option A is wrong because Kubernetes does not compile source code; compilation is handled by build tools like Docker or language-specific compilers, while Kubernetes only runs the resulting container images. Option C is wrong because Kubernetes is designed for containers, not virtual machines; it can orchestrate VMs via providers like KubeVirt, but that is a specialized extension, not its primary purpose. Option D is wrong because Kubernetes abstracts physical servers into a cluster and manages container workloads, not the physical hardware itself; hardware management is the role of infrastructure tools like IPMI or provisioning systems.

Why this answer

Why this answer

How to eliminate wrong answers

Option A is wrong because `kubectl explain pod` only displays the API documentation for the Pod resource schema (fields and descriptions), not runtime details or events about a specific pod instance. Option B is wrong because `kubectl get pod <pod-name>` outputs a concise summary (name, status, restarts, age) but omits detailed container status, conditions, and events. Option C is wrong because `kubectl logs pod <pod-name>` retrieves only the stdout/stderr output from the pod's containers, not the pod's metadata, status, or Kubernetes events.

Why this answer

How to eliminate wrong answers

Option A is wrong because a Service of type ClusterIP does not require a port specification to be reachable by DNS; the port is needed for actual traffic routing, but DNS resolution depends on the Service object existing in the API server, not on port definitions. Option C is wrong because exposing a Service on a node port (NodePort type) is unrelated to DNS resolution within the cluster; ClusterIP Services are reachable internally without node ports, and DNS works regardless of the Service type. Option D is wrong because the container runtime (e.g., containerd, CRI-O) does not affect DNS resolution; DNS is handled by the cluster's network and DNS infrastructure, not by how containers are run.

Why this answer

How to eliminate wrong answers

Option A is wrong because a DaemonSet ensures that a copy of a Pod runs on all (or a subset of) nodes, typically for long-running services like log collectors or monitoring agents, not for one-time batch jobs. Option C is wrong because a Deployment manages a set of identical Pods to maintain a desired replica count for long-running, stateless applications, and it will restart Pods if they exit, which contradicts the requirement that the job should not be restarted. Option D is wrong because a StatefulSet is used for stateful applications that require stable, unique network identities and persistent storage, such as databases, and is not intended for ephemeral batch processing.