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

A Deployment’s replica count is controlled by spec.replicas. You can scale a Deployment by changing that field—either directly editing the object or using kubectl’s scaling helper. ThereforeCis correct: you can scale usingkubectl scaleand also viakubectl edit.

kubectl scale deployment --replicas= is the purpose-built command for scaling. It updates the Deployment’s desired replica count and lets the Deployment controller and ReplicaSet reconcile the change by creating or deleting Pods. This is the cleanest and most explicit operational approach, and it’s easy to automate in scripts and pipelines.

kubectl edit deployment opens the live object in an editor, allowing you to modify fields such as spec.replicas manually. When you save and exit, kubectl submits the updated object back to the API server. This method is useful for quick interactive adjustments or when you’re already making other spec edits, but it’s less structured and more error-prone than kubectl scale for simple replica changes.

Option B is invalid because kubectl scale-up deployment is not a standard kubectl command. Option A is incorrect because kubectl edit is not theonlymethod; scaling is commonly done with kubectl scale. Option D is also incorrect because while kubectl scale is a primary method, kubectl edit is also a valid method to change replicas.

In production, you often scale with autoscalers (HPA/VPA), but the question is asking about kubectl methods. The key Kubernetes concept is that scaling is achieved by updating desired state (spec.replicas), and controllers reconcile Pods to match.

=========

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.

=========

Kubernetes commonly authenticates users usingOpenID Connect (OIDC)when JSON Web Tokens (JWTs) are involved, soAis correct. OIDC is an identity layer on top of OAuth 2.0 that standardizes how clients obtain identity information and how JWTs are issued and validated.

In Kubernetes, authentication happens at theAPI server. When OIDC is configured, the API server validates incoming bearer tokens (JWTs) by checking token signature and claims against the configured OIDC issuer and client settings. Kubernetes can use OIDC claims (such as sub, email, groups) to map the authenticated identity to Kubernetes RBAC subjects. This is how enterprises integrate clusters with identity providers such as Okta, Dex, Azure AD, or other OIDC-compliant IdPs.

Options B, C, and D are fabricated phrases and not real frameworks. Kubernetes documentation explicitly references OIDC as a supported method for token-based user authentication (alongside client certificates, bearer tokens, static token files, and webhook authentication). The key point is that Kubernetes does not “invent” JWT auth; it integrates with standard identity providers through OIDC so clusters can participate in centralized SSO and group-based authorization.

Operationally, OIDC authentication is typically paired with:

RBACfor authorization (“what you can do”)

Audit logging for traceability

Short-lived tokens and rotation practices for security

Group claim mapping to simplify permission management

So, the verified framework Kubernetes uses with JWTs for user authentication isOpenID Connect.

=========

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.

=========

A Kubernetes node must have acontainer runtimeto run Pods, soDis correct. Kubernetes schedules Pods to nodes, but the actual execution of containers is performed by a runtime such ascontainerdorCRI-O. The kubelet communicates with that runtime via theContainer Runtime Interface (CRI)to pull images, create sandboxes, and start/stop containers. Without a runtime, the node cannot launch container processes, so Pods cannot transition into running state.

Options A and B confuse networking kernel settings with runtime requirements. iptables bridged traffic visibility and IPv4 forwarding can be relevant for node networking, but they do not replace the need for a container runtime. Networking and container execution are separate layers: you need networking for connectivity, and you need a runtime for running containers.

Option C is also incorrect and muddled. Container runtimes are not deprecated; rather, Kubernetes removed the built-in Docker shim integration from kubelet in favor of CRI-native runtimes. CRI is an interface, not “something you install instead of a runtime.” In practice you install a CRI-compatible runtime (containerd/CRI-O), which implements CRI endpoints that kubelet talks to.

Operationally, the runtime choice affects node behavior: image management, logging integration, performance characteristics, and compatibility. Kubernetes installation guides explicitly list installing a container runtime as a prerequisite for worker nodes. If a cluster has nodes without a properly configured runtime, workloads scheduled there will fail to start (often stuck in ContainerCreating/ImagePullBackOff/Runtime errors).

Therefore, the only fully correct statement isD: each node needs a container runtime to run Pods.

=========

Kubernetes supports two primary built-in modes of Service discovery for workloads:environment variablesandDNS, makingAcorrect.

Environment variables: When a Pod is created, kubelet can inject environment variables for Services that exist in the same namespace at the time the Pod starts. These variables include the Service host and port (for example, MY_SERVICE_HOST and MY_SERVICE_PORT). This approach is simple but has limitations: values are captured at Pod creation time and don’t automatically update if Services change, and it can become cluttered in namespaces with many Services.

DNS-based discovery: This is the most common and flexible method. Kubernetes cluster DNS (usually CoreDNS) provides names like service-name.namespace.svc.cluster.local. Clients resolve the name and connect to the Service, which then routes to backend Pods. DNS scales better, is dynamic with endpoint updates, supports headless Services for per-Pod discovery, and is the default pattern for microservice communication.

The other options are not Kubernetes service discovery modes. Labels and selectors are used internally to relate Services to Pods, but they are not what application code uses for discovery (apps typically don’t query selectors; they call DNS names). LDAP and RADIUS are identity/authentication protocols, not service discovery. DHCP is for IP assignment on networks, not for Kubernetes Service discovery.

Operationally, DNS is central: many applications assume name-based connectivity. If CoreDNS is misconfigured or overloaded, service-to-service calls may fail even if Pods and Services are otherwise healthy. Environment-variable discovery can still work for some legacy apps, but modern cloud-native practice strongly prefers DNS (and sometimes service meshes on top of it). The key exam concept is:Kubernetes provides service discovery via env vars and DNS.

=========

The runtimes most associated withsandboxed isolationaregVisor’s runscandKata Containers, makingCcorrect. Standard container runtimes (like containerd with runc) rely primarily on Linux namespaces and cgroups for isolation. That isolation is strong for many use cases, but it shares the host kernel, which can be a concern for multi-tenant or high-risk workloads.

gVisor (runsc)provides a user-space kernel-like layer that intercepts and mediates system calls, reducing the container’s direct interaction with the host kernel.Kata Containerstakes a different approach: it runs containers inside lightweight virtual machines, providing hardware-virtualization boundaries (or VM-like isolation) while still integrating into container workflows. Both are used to increase isolation compared to traditional containers, and both can be integrated with Kubernetes through compatible CRI/runtime configurations.

The other options are incorrect for the question’s intent. “rune, cgroups” is not a meaningful pairing here (cgroups is a Linux resource mechanism, not a runtime). “docker, containerd” are commonly used container platforms/runtimes but are not specifically the “sandboxed isolation” category (containerd typically uses runc for standard isolation). “crun, cri-o” represents a low-level OCI runtime (crun) and a CRI implementation (CRI-O), again not specifically a sandboxed-isolation grouping.

So, when the question asks for the group that providesadditional sandboxingandelevated security, the correct, well-established answer isrunsc + Kata.

The role most commonly responsible for defining, testing, and running anincident managementprocess isSite Reliability Engineers (SREs), soAis correct. SRE is an operational engineering discipline focused on ensuring reliability, availability, and performance of services in production. Incident management is a core part of that mission: when outages or severe degradations occur, someone must coordinate response, restore service quickly, and then drive follow-up improvements to prevent recurrence.

In cloud native environments (including Kubernetes), incident response involves both technical and process elements. On the technical side, SREs ensure observability is in place—metrics, logs, traces, dashboards, and actionable alerts—so incidents can be detected and diagnosed quickly. They also validate operational readiness: runbooks, escalation paths, on-call rotations, and post-incident review practices. On the process side, SREs often establish severity classifications, response roles (incident commander, communications lead, subject matter experts), and “game day” exercises or simulated incidents to test preparedness.

Project managers may help coordinate schedules and communication for projects, but they are not typically the owners of operational incident response mechanics. Application developers are crucial participants during incidents, especially for debugging application-level failures, but they are not usually the primary maintainers of the incident management framework. Quality engineers focus on testing and quality assurance, and while they contribute to preventing defects, they are not usually the owners of real-time incident operations.

In Kubernetes specifically, incidents often span multiple layers: workload behavior, cluster resources, networking, storage, and platform dependencies. SREs are positioned to manage the cross-cutting operational view and to continuously improve reliability through error budgets, SLOs/SLIs, and iterative hardening. That’s why the correct persona isSite Reliability Engineers.

=========

The verified correct answer isD (the container runtime). On a Kubernetes node, thecontainer runtime(such as containerd or CRI-O) is the component that actuallyexecutes containers—it creates container processes, manages their lifecycle, pulls images, and interacts with the underlying OS primitives (namespaces, cgroups) through an OCI runtime like runc. In that direct sense, the runtime is what “runs workloads.”

It’s important to distinguish responsibilities. Thekubelet(A) is the node agent thatorchestrateswhat should run on the node: it watches the API server for Pods assigned to the node and then asks the runtime to start/stop containers accordingly. Kubelet is essential for node management, but it does not itself execute containers; it delegates execution to the runtime via CRI.kube-proxy(B) handles Service traffic routing rules (or is replaced by other dataplanes) and does not run containers.kube-apiserver(C) is a control plane component that stores and serves cluster state; it is not a node workload runner.

So, in the execution chain: scheduler assigns Pod → kubelet sees Pod assigned → kubelet calls runtime via CRI → runtime launches containers. When troubleshooting “containers won’t start,” you often inspect kubelet logs and runtime logs because the runtime is the component that can fail image pulls, sandbox creation, or container start operations.

Therefore, the best answer to “which node component is responsible to run workloads” isthe container runtime, optionD.

=========

Kubernetes supports multiple autoscaling mechanisms, but they operate at different layers. The question asks specifically about automatically managing thenumber of nodesin the cluster, which is the role of theCluster Autoscaler—thereforeBis correct.

Cluster Autoscaler monitors the scheduling state of the cluster. When Pods are pending because there are not enough resources (CPU/memory) available on existing nodes—meaning the scheduler cannot place them—Cluster Autoscaler can request that the underlying infrastructure (typically a cloud provider node group / autoscaling group) add nodes. Conversely, when nodes are underutilized and Pods can be rescheduled elsewhere, Cluster Autoscaler can drain those nodes (respecting disruption constraints like PodDisruptionBudgets) and then remove them to reduce cost. This aligns with cloud-native elasticity: scale infrastructure up and down automatically based on workload needs.

The other options are different:Horizontal Pod Autoscaler (HPA)changes the number of Pod replicas for a workload (like a Deployment) based on metrics (CPU utilization, memory, or custom metrics). It scales the application layer, not the node layer.Vertical Pod Autoscaler (VPA)changes resource requests/limits (CPU/memory) for Pods, effectively “scaling up/down” the size of individual Pods. It also does not directly change node count, though its adjustments can influence scheduling pressure. “Node Autoscaler” is not the canonical Kubernetes component name used in standard terminology; the widely referenced upstream component for node count is Cluster Autoscaler.

In real systems, these autoscalers often work together: HPA increases replicas when traffic rises; that may cause Pods to go Pending if nodes are full; Cluster Autoscaler then adds nodes; scheduling proceeds; later, traffic drops, HPA reduces replicas and Cluster Autoscaler removes nodes. This layered approach provides both performance and cost efficiency.

=========