Linux Foundation Kubernetes and Cloud Native Associate (KCNA)

✅ **runC **

Reasoning: runC is the reference implementation of the Open Container Initiative (OCI) Runtime Specification. It is a lightweight, portable container runtime that directly creates and runs containers using native Linux kernel features (namespaces, cgroups), making it inherently OCI compliant and a primary "native" runtime. ❌ Why the other choices are incorrect:

• Option B is incorrect: runV is a low-level runtime that runs OCI images inside lightweight virtual machines, thus providing virtualization-based isolation rather than purely native Linux containerization.
• Option C is incorrect: Kata Containers provides OCI compliance by using lightweight virtual machines for each container. This offers enhanced isolation but is a VM-based runtime, not a native host kernel container runtime.
• Option D is incorrect: gVisor is a user-space kernel that intercepts system calls, providing a secure sandbox environment for containers. While OCI compliant, it operates as an application kernel rather than a native Linux container runtime.

✅

Reasoning: Deployments are the recommended controller for managing scalable, stateless applications. They provide declarative updates, rolling rollbacks, and horizontal scaling capabilities. Deployments create and manage ReplicaSets, ensuring a specified number of Pod replicas are running, thus offering robust management for stateless services. ❌ Why the other choices are incorrect:

• Option A is incorrect: ReplicaSets ensure a stable number of Pod replicas but lack advanced update strategies like rolling updates. Deployments manage ReplicaSets, providing a higher-level, more robust way to manage application lifecycle.
• Option C is incorrect: DaemonSets ensure a Pod runs on every (or specific) node. They are used for node-specific background tasks, not for general scalable, stateless applications that don't require deployment on every single node.
• Option D is incorrect: A Pod is the smallest deployable unit and represents a single instance. It provides no inherent scaling, update management, or self-healing capabilities on its own, requiring a controller for such features.

✅

Reasoning: The CronJob controller is responsible for creating a Job object at the scheduled time. Subsequently, the Job controller detects this new Job and proceeds to create the necessary Pods to execute the workload, monitoring their completion. ❌ Why the other choices are incorrect:

• Option A is incorrect: Kubelet runs Pods on a node; it does not watch for CronJob objects, nor does it create Pods directly from them. That's a controller's role.
• Option B is incorrect: The kube-scheduler assigns newly created Pods to nodes. It does not watch CronJob objects or create Jobs/Pods.
• Option C is incorrect: The CronJob controller creates a Job resource, not a Pod directly. The Job controller then creates the Pods.

✅

Reasoning: The kubelet is the primary "node agent" that runs on each worker node. Its core responsibility is to take PodSpecs (definitions of pods) and ensure that the containers defined within those pods are running and healthy on its node. ❌ Why the other choices are incorrect:

• Option A is incorrect: This describes the Kubernetes Dashboard, an optional web-based UI for managing clusters, not the kubelet.
• Option B is incorrect: This describes kube-proxy, which handles network proxying for Services, directing traffic to Pods across nodes.
• Option C is incorrect: This describes the kube-scheduler, a control plane component responsible for assigning new Pods to available nodes.

✅

Reasoning: The kube-apiserver command-line flag --authorization-mode defaults to AlwaysAllow if no other modes are specified. When active, this mode authorizes all API requests without any further permission checks. While production clusters use stronger modes, AlwaysAllow is the technical default for the flag. ❌ Why the other choices are incorrect:

• Option A is incorrect: RBAC (Role-Based Access Control) is the recommended and most common authorization mode, but it is not the API server's default if the flag is unspecified. It requires explicit configuration.
• Option C is incorrect: AlwaysDeny is not a default. This mode would deny all requests from being authorized, effectively making the cluster unusable without explicit configuration.
• Option D is incorrect: ABAC (Attribute-Based Access Control) is an older, configurable authorization mechanism for Kubernetes. It is not the default value for the --authorization-mode flag.

✅

Reasoning: The Cluster Autoscaler dynamically adds nodes when batch jobs create pending pods and removes them when nodes become idle. This perfectly matches the bursty workload, ensuring compute resources are only consumed when actively needed, making it the most cost-effective approach for cloud-based clusters. ❌ Why the other choices are incorrect:

• Option A is incorrect: Running a fixed group of nodes for the peak load means paying for idle resources most of the week, which is not cost-effective for bursty workloads. Taints/tolerations only manage placement, not cost.
• Option C is incorrect: Reserved instances are for predictable, steady-state loads, not bursty usage. Committing to a reservation for the peak burst would mean paying for idle capacity for the majority of the time, negating cost savings.
• Option D is incorrect: PriorityClasses manage scheduling order on existing nodes. They do not provision new nodes or reduce costs for bursty workloads. If nodes are insufficient, priority alone won't ensure timely completion or cost-effectiveness.

✅ **Headless Service **

Reasoning: A Headless Service in Kubernetes is explicitly defined by setting its clusterIP to None. This means the Service does not get an internal cluster IP address, and DNS queries for it return the IP addresses of the backing Pods directly, enabling client-to-pod communication without kube-proxy. ❌ Why the other choices are incorrect:

• Option B: Nodeless Service is incorrect: This is not a standard or recognized term within Kubernetes networking. Services abstract access to Pods, not necessarily tied to nodes in this manner.
• Option C: IPLess Service is incorrect: While descriptive, "IPLess Service" is not the official Kubernetes term for a service without a cluster IP address. The correct term is "Headless Service."
• Option D: Specless Service is incorrect: All Kubernetes resources, including Services, must have a specification (spec) to be valid. A "Specless Service" is not a valid concept.

✅ **Continuous Integration / Continuous Deployment **

Reasoning: CI/CD commonly stands for Continuous Integration and Continuous Deployment. Continuous Integration involves frequently merging code changes, while Continuous Deployment fully automates software releases to production environments. This option accurately reflects the industry-standard definition. ❌ Why the other choices are incorrect:

• Option A is incorrect: "Continuous Information" is not part of the standard CI/CD acronym.
• Option B is incorrect: While "Continuous Integration" is correct, "Continuous Development" for the second CD is not the standard interpretation; it's either Delivery or Deployment.
• Option C is incorrect: "Cloud Integration" and "Cloud Development" are unrelated to the standard CI/CD acronym.

✅

Reasoning: Kubernetes Secrets store their data values in a base64 encoded format within the API. This is an encoding scheme, not encryption, meaning the data is easily reversible to its original plaintext. It represents the default presentation of secret values. ❌ Why the other choices are incorrect:

• Option A is incorrect: Kubernetes Secrets are not encrypted by default in the API or when stored in the underlying etcd data store. Encryption at rest for etcd is an optional, configurable feature, not a default for the values themselves.
• Option B is incorrect: While Secrets are stored unencrypted in etcd, the values within the Secret object exposed via the API are base64 encoded, not presented as raw plain text. They must be decoded to reveal the original value.
• Option C is incorrect: SHA256 is a cryptographic hashing algorithm, used for integrity verification or one-way storage (like passwords). It is not used for encoding reversible data like Secret values.

✅

Reasoning: kube-proxy implements the Kubernetes Service concept. It watches the Kubernetes API for changes to Services and Endpoints, then maintains network rules (e.g., iptables or IPVS) on each node to direct traffic to the correct backend pods for those Services, providing load balancing. ❌ Why the other choices are incorrect:

• Option A is incorrect: Ingress controllers (e.g., NGINX, Traefik) are responsible for implementing the Ingress resource type, not kube-proxy.
• Option C is incorrect: Managing general data egress from nodes is primarily handled by the node's network configuration or CNI plugin, not kube-proxy's core function.
• Option D is incorrect: The kube-apiserver component is responsible for managing access to the Kubernetes API, including authentication and authorization.