Free Linux Foundation KCNA Practice Exam with Questions & Answers | Set: 2

A defining requirement of container networking in orchestrated environments is enablingworkloads to communicate across hosts, not just within a single machine. That’s whyBis correct: a key feature of a container network is allowing containers (Pods) running onseparate hoststo communicate.

In Kubernetes, this idea becomes the Kubernetes network model: every Pod gets an IP address, and Pods should be able to communicate with other Pods across nodes without needing NAT (depending on implementation details). Achieving that across a cluster requires a networking layer (typically implemented by a CNI plugin) that can route traffic between nodes so that Pod-to-Pod communication works regardless of placement. This is crucial because schedulers dynamically place Pods; you cannot assume two communicating components will land on the same node.

Option C is true in a trivial sense—containers on the same host can communicate—but that capability alone is not the key feature that makes orchestration viable at scale. Cross-host connectivity is the harder and more essential property. Option A describes application-layer behavior (like API gateways or reverse proxies) rather than the foundational networking capability. Option D describes storage optimization, unrelated to container networking.

From a cloud native architecture perspective, reliable cross-host networking enables microservices patterns, service discovery, and distributed systems behavior. Kubernetes Services, DNS, and NetworkPolicies all depend on the underlying ability for Pods across the cluster to send traffic to each other. If your container network cannot provide cross-node routing and reachability, the cluster behaves like isolated islands and breaks the fundamental promise of orchestration: “schedule anywhere, communicate consistently.”

=========

In Prometheus, aGaugeis the metric type used to represent a value that canincrease and decreaseover time, soBis correct. Gauges are suited for “current state” measurements such as current memory usage, number of active sessions, queue depth, temperature, or CPU usage—anything that can move up and down as the system changes.

This contrasts with aCounter(A), which is monotonically increasing (it only goes up, except when a process restarts and the counter resets to zero). Counters are ideal for totals like total HTTP requests served, total errors, or bytes sent, and you typically use rate()/irate() in PromQL to convert counters into per-second rates.

ASummary(C) andHistogram(D) are used for distributions, commonly request latency. Histograms record observations into buckets and can produce percentiles using functions like histogram_quantile(). Summaries compute quantiles on the client side and expose them directly, along with counts and sums. Neither of these is the simplest “single value that goes up and down” type.

In Kubernetes observability, Prometheus is often used to scrape metrics from cluster components (API server, kubelet) and applications. Choosing the right metric type matters operationally: use gauges for instantaneous measurements, counters for event totals, and histograms/summaries for latency distributions. That’s why Prometheus documentation and best practices emphasize understanding metric semantics—because misusing types leads to incorrect alerts and dashboards.

So for a single numeric value that can go up and down, the correct metric type isGauge, optionB.

=========

Bis correct: the OCI’s main purpose is to createopen, vendor-neutral industry standardsforcontainer image formatsandcontainer runtimes. Standardization is critical in container orchestration because portability is a core promise: you should be able to build an image once and run it across different environments and runtimes without rewriting packaging or execution logic.

OCI defines (at a high level) two foundational specs:

Image specification: how container images are packaged (layers, metadata, manifests).

Runtime specification: how to run a container (filesystem setup, namespaces/cgroups behavior, lifecycle).These standards enable interoperability across tooling. For example, higher-level runtimes (like containerd or CRI-O) rely on OCI-compliant components (often runc or equivalents) to execute containers consistently.

Why the other options are not the best answer:

A(accelerating adoption) might be an indirect outcome, but it’s not the OCI’s core charter.

Cis contradictory (“industry standards” but “for private purposes”)—OCI is explicitly about open standards.

D(improving security) can be helped by standardization and best practices, but OCI is not primarily a security standards body; its central function isformat and runtime interoperability.

In Kubernetes specifically, OCI is part of the “plumbing” that makes runtimes replaceable. Kubernetes talks to runtimes via CRI; runtimes execute containers via OCI. This layering helps Kubernetes remain runtime-agnostic while still benefiting from consistent container behavior everywhere.

Therefore, the correct choice isB: OCI creates open standards around container formats and runtimes.

=========

The correct answer isA: kubectl get pods. Kubernetes does not manage “containers” as standalone top-level objects; the primary schedulable unit is thePod, and containers run inside Pods. Therefore, the practical way to list what’s running in a namespace is to list the Pods in that namespace. kubectl get pods shows Pods and their readiness, status, restarts, and age—giving you the canonical view of running workloads.

If you need the container-level details (images, container names), you typically use additional commands and output formatting:

kubectl describe pod to view container specs, images, states, and events

kubectl get pods -o jsonpath=... or -o wide to surface more fields

kubectl get pods -o=json to inspect .spec.containers and .status.containerStatuses

But among the provided options, kubectl get pods is the only real kubectl command that lists the running workload objects in the current namespace.

The other options are not valid kubectl subcommands: kubectl ls, kubectl ps, and kubectl show pods are not standard Kubernetes CLI operations. Kubernetes intentionally centers around the API resource model, so listing resources uses kubectl get . This also aligns with Kubernetes’ declarative nature: you observe and manage the state via API objects, not by directly enumerating OS-level processes.

So while the question says “running containers,” the Kubernetes-correct interpretation is “containers in running Pods,” and the appropriate listing command in the namespace iskubectl get pods, optionA.

=========

Ahybrid cloudarchitecture combinespublic cloudandprivate/on-premisesenvironments, often spanning multiple infrastructure domains while maintaining some level of portability, connectivity, and unified operations. OptionCcaptures the commonly accepted definition: services run acrosspublic and private clouds, includingon-premises data centers, soCis correct.

Hybrid cloud is not limited to a single cloud provider (which is why A is too restrictive). Many organizations adopt hybrid cloud to meet regulatory requirements, data residency constraints, latency needs, or to preserve existing investments while still using public cloud elasticity. In Kubernetes terms, hybrid strategies often include running clusters both on-prem and in one or more public clouds, then standardizing deployment through Kubernetes APIs, GitOps, and consistent security/observability practices.

Option B is incorrect because excluding data centers in different availability zones is not a defining property; in fact, hybrid deployments commonly use multiple zones/regions for resilience. Option D is a distraction: serverless inclusion or exclusion does not define hybrid cloud. Hybrid is about the combination ofinfrastructure environments, not a specific compute model.

A practical cloud-native view is that hybrid architectures introduce challenges around identity, networking, policy enforcement, and consistent observability across environments. Kubernetes helps because it provides a consistent control plane API and workload model regardless of where it runs. Tools like service meshes, federated identity, and unified monitoring can further reduce fragmentation.

So, the most accurate definition in the given choices isC: hybrid cloud combines public and private clouds, including on-premises infrastructure, to run services in a coordinated architecture.

=========

The correct answer isC (Platform Engineers). In modern DevOps and platform operating models, platform engineering teams build and maintain theshared delivery capabilitiesthat product/application teams use to ship software safely and quickly. This includes CI/CD pipeline templates, standardized build and test automation, artifact management (registries), deployment tooling (Helm/Kustomize/GitOps), secrets management patterns, policy guardrails, and paved-road workflows that reduce cognitive load for developers.

While application developers (B) write the application code and often contribute pipeline steps for their service, the “build, automate, and offer tooling for developer teams” responsibility maps directly to platform engineering: they provide the internal platform that turns Kubernetes and cloud services into a consumable product. This is especially common in Kubernetes-based organizations where you want consistent deployment standards, repeatable security checks, and uniform observability.

Cluster operators (D) typically focus on the health and lifecycle of the Kubernetes clusters themselves: upgrades, node pools, networking, storage, cluster security posture, and control plane reliability. They may work closely with platform engineers, but “continuous delivery tools for developer teams” is broader than cluster operations. Application users (A) are consumers of the software, not builders of delivery tooling.

In cloud-native application delivery, this division of labor is important: platform engineers enablehigher velocity with safetyby automating the software supply chain—builds, tests, scans, deploys, progressive delivery, and rollback. Kubernetes provides the runtime substrate, but the platform team makes it easy and safe for developers to use it repeatedly and consistently across many services.

Therefore,Platform Engineers (C)is the verified correct choice.

=========

kube-proxyis the Kubernetes component responsible for implementingService networkingon nodes, commonly by programming operating system packet filtering / forwarding rules (like iptables or IPVS), which makesAcorrect.

Kubernetes Services provide stable virtual IPs and ports that route traffic to a dynamic set of Pod endpoints. kube-proxy watches the API server for Service and EndpointSlice/Endpoints updates and then configures the node’s networking so that traffic to a Service is correctly forwarded to one of the backend Pods. In iptables mode, kube-proxy installs NAT and forwarding rules; in IPVS mode, it programs kernel load-balancing tables. In both cases, it leverages OS-level packet handling to efficiently steer traffic. This is the “packet filtering if available” concept referenced in the question.

kube-proxy’s work affects both “inside” and “outside” paths in typical setups. Internal cluster clients reach Services via ClusterIP and DNS, and kube-proxy rules forward that traffic to Pods. For external traffic, paths often involve NodePort or LoadBalancer Services or Ingress controllers that ultimately forward into Services/Pods—again relying on node-level service rules. While some modern CNI/eBPF dataplanes can replace or bypass kube-proxy, the classic Kubernetes architecture still defines kube-proxy as the component implementing Service connectivity.

The other options are not networking dataplane components:kubeletruns Pods and reports status;etcdstores cluster state;kube-controller-managerruns control loops for API objects. None of these handle node-level packet routing for Services. Therefore, the correct verified answer isA: kube-proxy.

B (the Site Reliability Engineering team)is correct. In cloud-native organizations, SREs are commonly responsible for thereliability, availability, and operational healthof workloads across platforms (multiple clusters, regions, clouds, and supporting services). While responsibilities vary by company, the classic SRE charter is to apply software engineering to operations: build automation, standardize runbooks, manage incident response, define SLOs/SLIs, and continuously improve system reliability.

Maintaining workloads “across different platforms” implies cross-cutting operational ownership: deployments need to behave consistently, rollouts must be safe, monitoring and alerting must be uniform, and incident practices must work across environments. SRE teams typically own or heavily influence the observability stack (metrics/logs/traces), operational readiness, capacity planning, and reliability guardrails (error budgets, progressive delivery, automated rollback triggers). They also collaborate closely with platform engineering and application teams, but SRE is often the group that ensures production workloads meet reliability targets.

Why other options are less correct:

Thecloud provider (A)maintains the underlying cloud services, but not your application workloads’ correctness, SLOs, or operational processes.

Developers (C)do maintain application code and may own on-call in some models, but the question asks “usually” in cloud-native environments; SRE is the widely recognized function for workload reliability across platforms.

Support Engineering (D)typically focuses on customer support and troubleshooting from a user perspective, not maintaining platform workload reliability at scale.

So, the best and verified answer isB: SRE teams commonly maintain and ensure reliability of workloads across cloud-native platforms.

=========

Vertical scalingmeans changing theresources allocated to a single instanceof an application (more or less CPU/memory), which is whyCis correct. In Kubernetes terms, this corresponds to adjusting container resourcerequests and limits(for CPU and memory). Increasing resources can help a workload handle more load per Pod by giving it more compute or memory headroom; decreasing can reduce cost and improve cluster packing efficiency.

This differs fromhorizontal scaling, which changes thenumber of instances(replicas). Option D describes horizontal scaling: adding/removing replicas of the same workload, typically managed by a Deployment and often automated via the Horizontal Pod Autoscaler (HPA). Option B describes scaling theinfrastructure layer(nodes) which is cluster/node autoscaling (Cluster Autoscaler in cloud environments). Option A is not a standard scaling definition.

In practice, vertical scaling in Kubernetes can be manual (edit the Deployment resource requests/limits) or automated using theVertical Pod Autoscaler (VPA), which can recommend or apply new requests based on observed usage. A key nuance is that changing requests/limits often requires Pod restarts to take effect, so vertical scaling is less “instant” than HPA and can disrupt workloads if not planned. That’s why many production teams prefer horizontal scaling for traffic-driven workloads and use vertical scaling to right-size baseline resources or address memory-bound/cpu-bound behavior.

From a cloud-native architecture standpoint, understanding vertical vs horizontal scaling helps you design for elasticity: use vertical scaling to tune per-instance capacity; use horizontal scaling for resilience and throughput; and combine with node autoscaling to ensure the cluster has sufficient capacity. The definition the question is testing is simple:vertical scaling = change resources per application instance, which is optionC.

The correct answer isB: Pod Disruption Budgets (PDBs). A PDB is a policy object that limits how many Pods of an application can be voluntarily disrupted at the same time. “Voluntary disruptions” include actions such as draining a node for maintenance (kubectl drain), cluster upgrades, or an administrator deleting Pods. The core purpose is to preserveavailabilityby ensuring that a minimum number (or percentage) of replicas remain running and ready while those planned disruptions occur.

A PDB is typically defined with either minAvailable (e.g., “at least 3 Pods must remain available”) or maxUnavailable (e.g., “no more than 1 Pod can be unavailable”). Kubernetes uses this budget when performing eviction operations. If evicting a Pod would violate the PDB, the eviction is blocked (or delayed), which forces maintenance workflows to proceed more safely—either by draining more slowly, scaling up first, or scheduling maintenance in stages.

Why the other options are not correct: topology spread constraints (A) influencescheduling distributionacross failure domains but don’t directly protect against voluntary disruptions. Taints and tolerations (C) controlwherePods can schedule, not how many can be disrupted. Resource requests/limits (D) controlCPU/memory allocationand do not guard availability during drains or deletions.

PDBs also work best when paired with Deployments/StatefulSets that maintain replicas and with readiness probes that accurately represent whether a Pod can serve traffic. PDBs do not preventinvoluntarydisruptions (node crashes), but they materially reduce risk during planned operations—exactly what the question is targeting.

=========