Linux Foundation Kubernetes and Cloud Native Associate KCNA Exam Questions

Answer : B

B (the Site Reliability Engineering team) is correct. In cloud-native organizations, SREs are commonly responsible for the reliability, availability, and operational health of 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:

The cloud 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 is B: SRE teams commonly maintain and ensure reliability of workloads across cloud-native platforms.

=========

Answer : C

In Kubernetes, resource management for containers is based on requests and limits. Requests represent the minimum amount of CPU or memory required for scheduling decisions, while limits define the maximum amount a container is allowed to consume at runtime. Understanding how Kubernetes behaves when only a limit is specified is important for predictable scheduling and resource utilization.

If a container specifies a resource limit but does not explicitly specify a resource request, Kubernetes applies a well-defined default behavior. In this case, Kubernetes automatically sets the request equal to the specified limit. This behavior ensures that the scheduler has a concrete request value to use when deciding where to place the Pod. Without a request value, the scheduler would not be able to make accurate placement decisions, as scheduling is entirely request-based.

This defaulting behavior applies independently to each resource type, such as CPU and memory. For example, if a container sets a memory limit of 512Mi but does not define a memory request, Kubernetes treats the memory request as 512Mi as well. The same applies to CPU limits. As a result, the Pod is scheduled as if it requires the full amount of resources defined by the limit.

Option A is incorrect because specifying only a limit does not cause a container to crash or enter CrashLoopBackOff. CrashLoopBackOff is related to application failures, not resource specification defaults. Option B is incorrect because Kubernetes allows containers to be created without explicit requests, relying on defaulting behavior instead. Option D is incorrect because Kubernetes never assigns random values for resource requests.

This behavior is clearly defined in Kubernetes resource management documentation and is especially relevant when admission controllers like LimitRange are not applying default requests. While valid, relying solely on limits can reduce cluster efficiency, as Pods may reserve more resources than they actually need. Therefore, best practice is to explicitly define both requests and limits.

Thus, the correct and verified answer is Option C.

Answer : B

In Kubernetes, Pods are inherently ephemeral. They can be created, destroyed, restarted, or rescheduled at any time, and each time this happens, a Pod may receive a new IP address. This dynamic behavior is essential for resilience and scalability, but it also creates a challenge for reliably accessing application workloads. The Service resource addresses this problem by providing a stable network endpoint for a group of Pods, making option B the correct answer.

A Service selects Pods using label selectors---typically the same labels applied by a Deployment---and exposes them through a consistent virtual IP address (ClusterIP) and DNS name. Regardless of how many Pods are running or whether individual Pods are replaced, the Service remains stable and automatically routes traffic to healthy Pods. This abstraction allows clients to communicate with an application without needing to track individual Pod IPs.

Deployments are responsible for managing the lifecycle of Pods, including scaling, rolling updates, and self-healing. However, Deployments do not provide networking or service discovery capabilities. Without a Service, consumers would need to directly reference Pod IPs, which would break as soon as Pods are rescheduled or updated.

Option A is incorrect because centralized configuration management is handled using ConfigMaps and Secrets, not Services. Option C is incorrect because automatic scaling based on CPU or memory is the responsibility of the Horizontal Pod Autoscaler (HPA), not Services. Option D is incorrect because persistent storage is managed using PersistentVolume and PersistentVolumeClaim resources, which are unrelated to Services.

Services can be configured for different access patterns, such as ClusterIP for internal communication, NodePort or LoadBalancer for external access, and headless Services for direct Pod discovery. Despite these variations, their core purpose remains the same: providing a reliable and stable way to access Pods managed by a Deployment.

Therefore, the correct and verified answer is Option B, which aligns with Kubernetes networking fundamentals and official documentation.

Answer : B

The correct answer is B: 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 preserve availability by 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) influence scheduling distribution across failure domains but don't directly protect against voluntary disruptions. Taints and tolerations (C) control where Pods can schedule, not how many can be disrupted. Resource requests/limits (D) control CPU/memory allocation and 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 prevent involuntary disruptions (node crashes), but they materially reduce risk during planned operations---exactly what the question is targeting.

=========

Answer : C

To retrieve CPU and memory consumption for nodes or Pods, you use kubectl top, so C is correct. kubectl top nodes shows per-node resource usage, and kubectl top pods shows per-Pod (and optionally per-container) usage. This data comes from the Kubernetes resource metrics pipeline, most commonly metrics-server, which scrapes kubelet/cAdvisor stats and exposes them via the metrics.k8s.io API.

It's important to recognize that kubectl top provides current resource usage snapshots, not long-term historical trending. For long-term metrics and alerting, clusters typically use Prometheus and related tooling. But for quick operational checks---''Is this Pod CPU-bound?'' ''Are nodes near memory saturation?''---kubectl top is the built-in day-to-day tool.

Option A (kubectl cluster-info) shows general cluster endpoints and info about control plane services, not resource usage. Option B (kubectl version) prints client/server version info. Option D (kubectl api-resources) lists resource types available in the cluster. None of those report CPU/memory usage.

In observability practice, kubectl top is often used during incidents to correlate symptoms with resource pressure. For example, if a node is high on memory, you might see Pods being OOMKilled or the kubelet evicting Pods under pressure. Similarly, sustained high CPU utilization might explain latency spikes or throttling if limits are set. Note that kubectl top requires metrics-server (or an equivalent provider) to be installed and functioning; otherwise it may return errors like ''metrics not available.''

So, the correct command for retrieving node/Pod CPU and memory usage is kubectl top.

=========

Answer : D

In Kubernetes, Pods are the smallest deployable units and represent one or more containers that share networking and storage. While Pods can be created directly, Kubernetes strongly encourages users to manage Pods indirectly through higher-level workload resources. Among the options provided, creating Pods through workload resources like Deployments is a fully supported and recommended practice.

Workload resources such as Deployments, ReplicaSets, StatefulSets, and Jobs are designed to manage Pods declaratively. A Deployment, for example, defines a desired state---such as the number of replicas and the Pod template---and Kubernetes continuously works to maintain that state. If a Pod crashes, is deleted, or a node fails, the Deployment automatically creates a replacement Pod. This model provides self-healing, scalability, rolling updates, and rollback capabilities, which are not available when managing standalone Pods.

Option A is incorrect because static Pods are not managed through the API server. Static Pods are created and managed directly by the kubelet on a specific node using manifest files placed on disk. Although the API server becomes aware of static Pods, they cannot be created, modified, or deleted through it.

Option B is incorrect because Kubernetes does not guarantee that Pods will always remain on the same node. If a node becomes unhealthy or a Pod is evicted, the scheduler may place a replacement Pod on a different node. Only certain workload patterns, such as StatefulSets with persistent storage, attempt to preserve identity---not node placement.

Option C is also incorrect because container names within a Pod are immutable. Kubernetes does not allow renaming containers using kubectl patch or any other mechanism after the Pod has been created.

Therefore, the correct and verified answer is option D: creating Pods through workload resources like Deployments, which aligns with Kubernetes design principles and official documentation.

Answer : D

The defining capability of GitOps controllers such as Argo CD and Flux is continuous reconciliation: they compare the desired state stored in Git to the actual state in the cluster and then alert and/or correct drift, making D correct. In GitOps, Git becomes the single source of truth for declarative configuration (Kubernetes manifests, Helm charts, Kustomize overlays). The controller watches Git for changes and applies them, and it also watches the cluster for divergence.

This is more than ''auditing human changes'' (option A). GitOps does provide auditability because changes are made via commits and pull requests, but the core functionality is the reconciliation loop that keeps cluster state aligned with Git, including optional automated sync/remediation. Option B is not accurate because GitOps is not about tracking user Git commands; it's about reconciling desired state definitions. Option C (automatically creating pull requests for outdated dependencies) is a useful feature in some tooling ecosystems, but it is not the central defining behavior of GitOps controllers.

In Kubernetes delivery terms, this approach improves reliability: rollouts become repeatable, configuration drift is detected, and recovery is simpler (reapply known-good state from Git). It also supports separation of duties: platform teams can control policies and base layers, while app teams propose changes via PRs.

So the verified statement is: GitOps tools continuously reconcile Git desired state with cluster actual state---exactly option D.