Pass the Linux Foundation Kubernetes and Cloud Native KCNA Questions and answers with Dumpstech

Thekubeletis the primary node agent in Kubernetes. It runs on every worker node (and often on control-plane nodes too if they run workloads) and is responsible for ensuring that containers described byPodSpecsare actually running and healthy on that node. The kubelet continuously watches the Kubernetes API (via the control plane) for Pods that have been scheduled to its node, then it collaborates with the node’s container runtime (through CRI) to pull images, create containers, start them, and manage their lifecycle. It also mounts volumes, configures the Pod’s networking (working with the CNI plugin), and reports Pod and node status back to the API server.

Option D captures the core: “an agent on each node that makes sure containers are running in a Pod.” That includes executing probes (liveness, readiness, startup), restarting containers based on the Pod’s restartPolicy, and enforcing resource constraints in coordination with the runtime and OS.

Why the other options are wrong: A describes the Kubernetes Dashboard (or similar UI tools), not kubelet. B describeskube-proxy, which programs node-level networking rules (iptables/ipvs/eBPF depending on implementation) to implement Service virtual IP behavior. C describes thekube-scheduler, which selects a node for Pods that do not yet have an assigned node.

A useful way to remember kubelet’s role is:scheduler decides where,kubelet makes it happen there. Once the scheduler binds a Pod to a node, kubelet becomes responsible for reconciling “desired state” (PodSpec) with “observed state” (running containers). If a container crashes, kubelet will restart it according to policy; if an image is missing, it will pull it; if a Pod is deleted, it will stop containers and clean up. This node-local reconciliation loop is fundamental to Kubernetes’ self-healing and declarative operation model.

=========

A service mesh is most valuable when service-to-service communication becomes complex at large scale—many services, many teams, and often multiple clusters. That’s whyDis the best fit:thousands of distributed applications across multiple clusters. In that scenario, the operational burden of securing, observing, and controlling east-west traffic grows dramatically. A service mesh (e.g., Istio, Linkerd) addresses this by introducing a dedicated networking layer (usually sidecar proxies such as Envoy) that standardizes capabilities across services without requiring each application to implement them consistently.

The common “mesh” value-adds are:mTLSfor service identity and encryption, fine-grainedtraffic policy(retries, timeouts, circuit breaking),traffic shifting(canary, mirroring), and consistenttelemetry(metrics, traces, access logs). Those features become increasingly beneficial as the number of services and cross-service calls rises, and as you add multi-cluster routing, failover, and policy management across environments. With thousands of applications, inconsistent libraries and configurations become a reliability and security risk; the mesh centralizes and standardizes these behaviors.

In smaller environments (A or C), you can often meet requirements with simpler approaches: Kubernetes Services, Ingress/Gateway, basic mTLS at the edge, and application-level libraries. A single large cluster (B) can still benefit from a mesh, but addingmultiple clustersincreases complexity: traffic management across clusters, identity trust domains, global observability correlation, and consistent policy enforcement. That’s where mesh architectures typically justify their additional overhead (extra proxies, control plane components, operational complexity).

So, the “most benefit” scenario is the largest, most distributed footprint—D.

=========

In a highly available (HA) Kubernetes control plane using anexternal etcd topology, you typically runthree control plane nodesandthree separate etcd nodes, totalingsix hosts, makingDcorrect. HA design relies on quorum-based consensus: etcd uses Raft and requires a majority of members available to make progress. Runningthreeetcd members is the common minimum for HA because it tolerates one member failure while maintaining quorum (2/3).

In the external etcd topology, etcd is decoupled from the control plane nodes. This separation improves fault isolation: if a control plane node fails or is replaced, etcd remains stable and independent; likewise, etcd maintenance can be handled separately. Kubernetes API servers (often multiple instances behind a load balancer) talk to the external etcd cluster for storage of cluster state.

Options A and B propose four hosts, but they break common HA/quorum best practices. Two etcd nodes do not form a robust quorum configuration (a two-member etcd cluster cannot tolerate a single failure without losing quorum). One control plane node is not HA for the API server/scheduler/controller-manager components. Option C describes astacked etcdtopology (control plane + etcd on same hosts), which can be HA with three hosts, but the question explicitly saysexternal etcd, not stacked. In stacked topology, you often use three control plane nodes each running an etcd member. In external topology, you usethree control plane + three etcd.

Operationally, external etcd topology is often used when you want dedicated resources, separate lifecycle management, or stronger isolation for the datastore. It can reduce blast radius but increases infrastructure footprint and operational complexity (TLS, backup/restore, networking). Still, for the canonical HA external-etcd pattern, the expected answer issix hosts:3 control plane + 3 etcd.

=========

To view logs from thepreviously terminated instanceof a container, you use kubectl logs -p. To select a specific container in a multi-container Pod, you use -c . Combining both gives the correct command for “previous logs from the ruby container in Pod web-1,” which is optionA: kubectl logs -p -c ruby web-1.

The -p (or --previous) flag instructs kubectl to fetch logs for the prior container instance. This is most useful when the container has restarted due to a crash (CrashLoopBackOff) or was terminated and restarted. Without -p, kubectl logs shows logs for the currently running container instance (or the most recent if it’s completed, depending on state).

Option B is close but wrong for the question: it selects the ruby container (-c ruby) but does not request the previous instance snapshot, so it returns current logs, not the prior-terminated logs. Option C is missing the -c container selector and is also malformed: kubectl logs -p expects the Pod name (and optionally container); ruby is not a flag positionally correct here. Option D has argument order incorrect and mixes Pod and container names in the wrong places.

Operationally, this is a common Kubernetes troubleshooting workflow: if a container restarts quickly, current logs may be short or empty, and the actionable crash output is in the previous instance logs. Using kubectl logs -p often reveals stack traces, fatal errors, or misconfiguration messages. In multi-container Pods, always pair -p with -c to ensure you’re looking at the right container.

Therefore, the verified correct answer isA.

=========

The true statement isC: the default namespace exists when a new cluster is created. Namespaces are a Kubernetes mechanism for partitioning cluster resources into logical groups. When you set up a cluster, Kubernetes creates some initial namespaces (including default, and commonly kube-system, kube-public, and kube-node-lease). The default namespace is where resources go if you don’t specify a namespace explicitly.

Option A is false because namespaces are not hierarchical; Kubernetes does not support “namespaces inside namespaces.” Option B is false because within a given namespace, resource names must be unique per resource kind. You can’t have two Deployments with the same name in the same namespace. Youcanhave a Deployment named web in one namespace and another Deployment named web in a different namespace—namespaces provide that scope boundary. Option D is false because not all objects are namespaced. Many resources arecluster-scoped(for example, Nodes, PersistentVolumes, ClusterRoles, ClusterRoleBindings, and StorageClasses). Namespaces apply only to namespaced resources.

Operationally, namespaces support multi-tenancy and environment separation (dev/test/prod), RBAC scoping, resource quotas, and policy boundaries. For example, you can grant a team access only to their namespace and enforce quotas that prevent them from consuming excessive CPU/memory. Namespaces also make organization and cleanup easier: deleting a namespace removes most namespaced resources inside it (subject to finalizers).

So, the verified correct statement isC: the default namespace exists upon cluster creation.

=========

Kubernetes stores its cluster state (API objects) inetcd, makingAcorrect. etcd is a distributed, strongly consistent key-value store that serves as the source of truth for the Kubernetes control plane. When you create or update objects such as Pods, Deployments, ConfigMaps, Secrets, or Nodes, thekube-apiservervalidates the request and then persists the desired state into etcd. Controllers and the scheduler watch the API for changes (which ultimately reflect etcd state) and reconcile the cluster to match that desired state.

etcd’s consistency guarantees are crucial. Kubernetes relies on accurate, up-to-date state to make scheduling decisions, enforce RBAC/admission policies, coordinate leader elections, and ensure controllers behave correctly. etcd uses the Raft consensus algorithm to replicate data among members and requires quorum for writes, enabling fault tolerance when deployed in HA configurations (commonly three or five members).

The other options are incorrect in Kubernetes’ standard architecture. ZooKeeper is a distributed coordination system used by some other platforms, but Kubernetes does not use it as its primary datastore. Redis is an in-memory data store used for caching or messaging, not as Kubernetes’ authoritative state store. “ControlPlaneStore” is not a standard Kubernetes component.

Operationally, etcd health is one of the most important determinants of cluster reliability. Slow disk I/O or unstable networking can degrade etcd performance and cause API latency spikes. Backup and restore procedures for etcd are critical disaster-recovery practices, and securing etcd (TLS, access restrictions) is essential because it may contain sensitive data (e.g., Secrets—often base64-encoded, and optionally encrypted at rest depending on configuration).

Therefore, the verified Kubernetes datastore isetcd, optionA.

=========

The Cloud Native Security “4C’s” model is commonly presented asCode, Container, Cluster, Cloud, ordered from the layer you control most directly to the one you control least—thereforeDis correct. The idea is defense-in-depth across layers, recognizing that responsibilities are shared between developers, platform teams, and cloud providers.

Codeis where users have the most direct control: application logic, dependencies, secure coding practices, secrets handling patterns, and testing. This includes validating inputs, avoiding vulnerabilities, and scanning dependencies. Next is theContainerlayer: building secure images, minimizing image size/attack surface, using non-root users, setting file permissions, and scanning images for known CVEs. Container security is about ensuring the artifact you run is trustworthy and hardened.

Then comes theClusterlayer: Kubernetes configuration and runtime controls, including RBAC, admission policies (OPA/Gatekeeper), Pod Security standards, network policies, runtime security, audit logging, and node hardening practices. Cluster controls determine what can run and how workloads interact. Finally, theCloudlayer includes the infrastructure and provider controls—IAM, VPC/networking, KMS, managed control plane protections, and physical security—which users influence through configuration but do not fully own.

The model’s value is prioritization: start with what you control most (code), then harden the container artifact, then enforce cluster policy and runtime protections, and finally ensure cloud controls are configured properly. This layered approach aligns well with Kubernetes security guidance and modern shared-responsibility models.

D (three etcd members)is correct. etcd is a distributed key-value store that uses the Raft consensus algorithm. High availability in consensus systems depends on maintaining aquorum(majority) of members to continue serving writes reliably. With3 members, the cluster can tolerate1 failureand still have 2/3 available—enough for quorum.

Two members is a common trap: with 2, a single failure leaves 1/2, which is not a majority, so the cluster cannot safely make progress. That means 2-member etcd is not HA; it is fragile and can be taken down by one node loss, network partition, or maintenance event. Five members can tolerate 2 failures and is a valid HA configuration, but it is not theminimum. Six is even-sized and generally discouraged for consensus because it doesn’t improve failure tolerance compared to five (quorum still requires 4), while increasing coordination overhead.

In Kubernetes, etcd reliability directly affects the API server and the entire control plane because etcd stores cluster state: object specs, status, controller state, and more. If etcd loses quorum, the API server will be unable to persist or reliably read/write state, leading to cluster management outages. That’s why the minimum HA baseline is three etcd members, often across distinct failure domains (nodes/AZs), with strong disk performance and consistent low-latency networking.

So, the smallest etcd topology that provides true fault tolerance is3 members, which corresponds to optionD.

=========

ACI/CD pipelineis a core practice/tooling approach that enables organizations to deliver softwarefaster and more securely, soDis correct. CI (Continuous Integration) automates building and testing code changes frequently, reducing integration risk and catching defects early. CD (Continuous Delivery/Deployment) automates releasing validated builds into environments using consistent, repeatable steps—reducing manual errors and enabling rapid iteration.

Security improves because automation enables standardized checks on every change: static analysis, dependency scanning, container image scanning, policy validation, and signing/verification steps can be integrated into the pipeline. Instead of relying on ad-hoc human processes, security controls become repeatable gates. In Kubernetes environments, pipelines commonly build container images, run tests, publish artifacts to registries, and then deploy via manifests, Helm, or GitOps controllers—keeping deployments consistent and auditable.

Option A (Kubernetes) is a platform that helps run and manage workloads, but by itself it doesn’t guarantee secure high-velocity delivery. It provides primitives (rollouts, declarative config, RBAC), yet the delivery workflow still needs automation. Option B (apt-get) is a package manager for Debian-based systems and is not a delivery pipeline. Option C (Docker Images) are artifacts; they improve portability and repeatability, but they don’t provide the end-to-end automation of building, testing, promoting, and deploying across environments.

In cloud-native application delivery, the pipeline is the “engine” that turns code changes into safe production releases. Combined with Kubernetes’ declarative deployment model (Deployments, rolling updates, health probes), a CI/CD pipeline supports frequent releases with controlled rollouts, fast rollback, and strong auditability. That is exactly what the question is targeting. Therefore, the verified answer isD.

=========

Aheadless Serviceis created by setting spec.clusterIP: None, soBis correct. Normally, a Service gets aClusterIP, and kube-proxy (or an alternative dataplane) implements virtual-IP-based load balancing to route traffic from that ClusterIP to the backend Pods. A headless Service intentionallydisablesthat virtual IP allocation. Instead of giving you a single stable VIP, Kubernetes publishes DNS records that resolve directly to theendpoints(the Pod IPs) behind the Service.

This is especially important for workloads that needdirect endpoint discoveryor stable per-Pod identities, such as StatefulSets. With a headless Service, clients can discover all Pod IPs (or individual Pod DNS names in StatefulSet patterns) and implement their own selection, quorum, or leader/follower logic. Kubernetes DNS (CoreDNS) responds differently for headless Services: rather than returning a single ClusterIP, it returns multiple A/AAAA records (one per endpoint) or SRV records for named ports, enabling richer service discovery behavior.

The other options are invalid. “headless” is not a magic value for clusterIP; the API expects either an actual IP address assigned by the cluster or the special literalNone. 0.0.0.0 and localhost are not valid ways to request headless semantics. Kubernetes uses None specifically to signal “do not allocate a ClusterIP.”

Operationally, headless Services are used to: (1) expose each backend instance individually, (2) support stateful clustering and stable DNS names, and (3) avoid load balancing when the application or client library must choose endpoints itself. The key is that the Service still provides a stableDNS name, but the resolution yieldsendpoints, not a VIP.

=========