{"id":17220,"date":"2026-09-21T07:08:36","date_gmt":"2026-09-21T07:08:36","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17220"},"modified":"2026-09-21T07:08:36","modified_gmt":"2026-09-21T07:08:36","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part15-q281-300","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part15-q281-300\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part15 Q281-300"},"content":{"rendered":"<h2><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/kcna-exam-dumps\"><b>Linux Foundation KCNA Exam Dumps<\/b><\/a><b> and Practice Test Dumps.<\/b><\/h2>\n<p>&nbsp;<\/p>\n<h3><b>Question 281<\/b><\/h3>\n<p><b>Which Kubernetes object is used to ensure that a desired number of application replicas remain available?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Deployment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Secret<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Deployment manages a desired number of replicated Pods and is commonly used for stateless applications. It works with ReplicaSets to maintain the requested number of Pods and can automatically replace Pods that become unavailable. Deployments also support scaling, rolling updates, and revision history. Services provide networking, ConfigMaps store non-sensitive configuration, and Secrets store sensitive information. By declaring the desired replica count in a Deployment, administrators allow Kubernetes controllers to continuously reconcile the actual number of running Pods with the desired state.<\/span><\/p>\n<h3><b>Question 282<\/b><\/h3>\n<p><b>Which Kubernetes object provides a stable endpoint while the Pods behind it may be replaced or rescheduled?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Job<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Service provides a stable network endpoint for a group of Pods. Pod IP addresses can change when Pods are recreated, rescheduled, or replaced during a rolling update. A Service hides these changes from clients by providing a stable virtual IP and DNS name. Its selector identifies the Pods that should receive traffic. ReplicaSets maintain Pod counts, Jobs manage finite workloads, and ConfigMaps provide configuration. Services are therefore a key abstraction for reliable communication between Kubernetes applications and for exposing workloads to clients.<\/span><\/p>\n<h3><b>Question 283<\/b><\/h3>\n<p><b>Which Kubernetes object can be used to provide configuration data to containers without rebuilding their images?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A ConfigMap allows non-sensitive configuration data to be stored separately from a container image. Containers can consume ConfigMap values through environment variables, command-line arguments, or mounted files. This makes it possible to use the same application image with different configuration settings in different environments. For example, development and production deployments can use different endpoints while keeping the application image unchanged. PersistentVolumes provide storage, ReplicaSets maintain replicas, and Services provide networking. ConfigMaps therefore support flexible and reusable application configuration.<\/span><\/p>\n<h3><b>Question 284<\/b><\/h3>\n<p><b>Which Kubernetes object should be used to store credentials such as API tokens and passwords?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Secret<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Annotation<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Secret is the Kubernetes resource intended for sensitive information such as passwords, API tokens, certificates, and other credentials. Secrets can be provided to containers through environment variables or mounted files. Administrators should also use appropriate RBAC permissions and consider encryption at rest to improve security. ConfigMaps are intended for non-sensitive configuration, while Namespaces provide logical organization and annotations store metadata. Secrets therefore provide the standard Kubernetes mechanism for separating sensitive values from application code and ordinary configuration.<\/span><\/p>\n<h3><b>Question 285<\/b><\/h3>\n<p><b>Which Kubernetes feature allows a Pod to use storage that remains available beyond the lifetime of an individual Pod?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Persistent storage<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service discovery<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RBAC<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NetworkPolicy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Persistent storage allows application data to survive beyond the lifecycle of an individual Pod. Kubernetes commonly provides this through PersistentVolumes and PersistentVolumeClaims. When a Pod is deleted or recreated, the associated persistent storage can remain available according to the storage configuration and reclaim policy. This is particularly important for databases and other stateful applications. Services provide networking, RBAC controls access, and NetworkPolicies control traffic. Persistent storage therefore separates application data from the temporary lifecycle of individual Pods.<\/span><\/p>\n<h3><b>Question 286<\/b><\/h3>\n<p><b>Which access mode allows a persistent volume to be mounted as read-write by multiple nodes when supported by the storage system?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadOnlyMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteOnce<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteMany<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReadWriteSingle<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">ReadWriteMany, commonly abbreviated RWX, allows a volume to be mounted with read-write access by multiple nodes when the underlying storage implementation supports that capability. This can be useful for applications where several Pods on different nodes need to access the same shared data. ReadWriteOnce generally allows read-write mounting by a single node, while ReadOnlyMany allows multiple nodes to mount the volume as read-only. The actual supported access modes depend on the storage provider and CSI driver. RWX is therefore associated with shared read-write storage.<\/span><\/p>\n<h3><b>Question 287<\/b><\/h3>\n<p><b>Which Kubernetes storage component allows Kubernetes to integrate with external storage systems through a standard interface?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CNI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CSI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CRI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RBAC<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Container Storage Interface, or CSI, provides a standard mechanism for Kubernetes to integrate with external storage systems. CSI drivers can support operations such as provisioning, attaching, mounting, and managing persistent storage. This allows storage providers to integrate with Kubernetes without requiring provider-specific logic to be built directly into the Kubernetes core. CNI handles networking, CRI handles container runtime integration, and RBAC manages authorization. CSI is therefore the interface specifically designed for connecting Kubernetes workloads to supported storage technologies.<\/span><\/p>\n<h3><b>Question 288<\/b><\/h3>\n<p><b>Which Kubernetes interface is responsible for integrating Pod networking with networking plugins?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CSI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CRI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CNI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RBAC<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Container Network Interface, or CNI, provides a standard approach for configuring networking for containers and Pods. CNI plugins can assign Pod IP addresses, create network interfaces, configure routes, and provide additional networking capabilities. Kubernetes relies on the networking implementation to provide the expected Pod networking model. CSI is used for storage, CRI connects Kubernetes with container runtimes, and RBAC controls authorization. CNI is therefore the interface most directly associated with providing network connectivity for Kubernetes workloads.<\/span><\/p>\n<h3><b>Question 289<\/b><\/h3>\n<p><b>Which Kubernetes mechanism controls which users or workloads can perform actions on API resources?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RBAC<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CNI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CSI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">HPA<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Role-Based Access Control, or RBAC, controls authorization for Kubernetes API resources. RBAC permissions are defined through Roles or ClusterRoles and assigned to identities using RoleBindings or ClusterRoleBindings. This allows administrators to specify exactly which resources a user, group, or ServiceAccount can access and which operations they can perform. CNI handles networking, CSI handles storage, and HPA manages application replica scaling. RBAC is therefore a fundamental security mechanism for controlling access to Kubernetes resources and enforcing least-privilege permissions.<\/span><\/p>\n<h3><b>Question 290<\/b><\/h3>\n<p><b>Which Kubernetes resource is used to limit the total amount of CPU and memory requested by workloads in a Namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LimitRange<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PodDisruptionBudget<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A ResourceQuota can limit aggregate resource consumption within a Namespace. Administrators can configure quotas for CPU requests, CPU limits, memory requests, memory limits, object counts, and other supported resources. This prevents a single Namespace from consuming an unlimited share of cluster capacity. A LimitRange focuses on individual containers or Pods by defining resource defaults and minimum or maximum values. PodDisruptionBudget protects application availability during voluntary disruptions, while Services provide networking. ResourceQuota is therefore the appropriate mechanism for controlling total Namespace-level resource consumption.<\/span><\/p>\n<h3><b>Question 291<\/b><\/h3>\n<p><b>Which Kubernetes resource can provide default CPU and memory values when containers do not explicitly define them?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LimitRange<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NetworkPolicy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A LimitRange can define default CPU and memory requests or limits for containers within a Namespace. This helps ensure that workloads receive appropriate resource configuration even when developers do not explicitly specify every value. LimitRange can also enforce minimum and maximum resource constraints. ResourceQuota works differently by controlling aggregate consumption across a Namespace. Services provide networking and NetworkPolicies control network traffic. LimitRange is therefore useful for establishing consistent per-container resource defaults and preventing workloads from using values outside defined boundaries.<\/span><\/p>\n<h3><b>Question 292<\/b><\/h3>\n<p><b>Which Kubernetes feature can automatically increase the number of Pod replicas when resource utilization rises?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Vertical Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cluster Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Horizontal Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Horizontal Pod Autoscaler, or HPA, adjusts the number of replicas for a supported workload based on observed metrics and configured targets. For example, an HPA can increase replicas when CPU utilization remains above a configured target and reduce replicas when demand decreases. Vertical Pod Autoscaler focuses on adjusting resource requests and limits, while Cluster Autoscaler changes the number of nodes in the cluster. ResourceQuota limits aggregate consumption. HPA therefore provides application-level horizontal scaling by changing the number of running workload replicas.<\/span><\/p>\n<h3><b>Question 293<\/b><\/h3>\n<p><b>Which autoscaling mechanism focuses on changing CPU and memory resource requests for Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Horizontal Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Vertical Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cluster Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Vertical Pod Autoscaler, or VPA, focuses on adjusting CPU and memory resource requests and, depending on its configuration, limits for Pods. It uses observed workload behavior to recommend or apply more appropriate resource values. This differs from HPA, which changes the number of replicas, and Cluster Autoscaler, which changes the number of cluster nodes. ReplicaSets maintain a desired number of Pods but do not optimize their resource requirements. VPA is therefore useful when the primary scaling concern is how much CPU or memory each Pod requires.<\/span><\/p>\n<h3><b>Question 294<\/b><\/h3>\n<p><b>Which Kubernetes autoscaling mechanism can change the number of nodes available in a cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cluster Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Horizontal Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Vertical Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Deployment<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Cluster Autoscaler operates at the cluster infrastructure level and can adjust the number of nodes when supported by the underlying environment. It may add nodes when workloads cannot be scheduled because of insufficient capacity and remove nodes when they are no longer needed according to its configured behavior. HPA changes the number of application replicas, while VPA adjusts Pod resource requirements. Deployments manage application Pods rather than infrastructure nodes. Cluster Autoscaler therefore addresses cluster capacity rather than directly scaling application replicas.<\/span><\/p>\n<h3><b>Question 295<\/b><\/h3>\n<p><b>Which Kubernetes component is responsible for assigning an unscheduled Pod to an appropriate node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-proxy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-scheduler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">etcd<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kube-scheduler selects a suitable node for Pods that have not yet been assigned to a node. It evaluates scheduling constraints and available resources, including CPU and memory requests, node affinity, taints and tolerations, and other scheduling requirements. Once a node is selected, the assignment is recorded through the Kubernetes API. The kubelet on that node then manages the Pod&#8217;s execution. kube-proxy handles Service networking and etcd stores cluster state. The scheduler therefore plays the central role in making Pod placement decisions.<\/span><\/p>\n<h3><b>Question 296<\/b><\/h3>\n<p><b>Which Kubernetes component communicates with the container runtime on a node to ensure containers are running?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-apiserver<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-scheduler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CoreDNS<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubelet runs on each Kubernetes node and works with the container runtime to ensure that containers specified by assigned Pods are running. It monitors Pod and container status and reports relevant information back to the control plane. The kubelet can also perform health-related actions based on configured probes and Pod specifications. The API server handles cluster API requests, the scheduler assigns Pods to nodes, and CoreDNS provides DNS services. The kubelet therefore serves as the primary node-level agent responsible for managing Pod execution.<\/span><\/p>\n<h3><b>Question 297<\/b><\/h3>\n<p><b>Which Kubernetes component provides the central API endpoint through which clients and controllers interact with the cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">etcd<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-controller-manager<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-apiserver<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-proxy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kube-apiserver provides the central API endpoint for Kubernetes. Tools such as kubectl communicate with the cluster through the API server, and internal components such as controllers and the scheduler also use the API. The API server handles authentication, authorization, admission processing, and interaction with persistent cluster state. etcd stores the state, controller-manager runs controllers, and kube-proxy supports networking. Because many Kubernetes operations pass through the API server, it acts as the central communication layer of the control plane.<\/span><\/p>\n<h3><b>Question 298<\/b><\/h3>\n<p><b>Which Kubernetes component runs reconciliation controllers that work to maintain desired resource states?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-controller-manager<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-scheduler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">containerd<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kube-controller-manager runs several Kubernetes controllers responsible for continuously reconciling actual state with desired state. Controllers monitor resources through the Kubernetes API and take corrective actions when differences are detected. Examples include controllers associated with ReplicaSets, Jobs, Nodes, and other resources. The scheduler focuses on Pod placement, the kubelet manages workloads on individual nodes, and containerd provides container runtime functionality. The controller manager is therefore central to Kubernetes automation and self-healing because its controllers continuously work toward the declared desired state.<\/span><\/p>\n<h3><b>Question 299<\/b><\/h3>\n<p><b>Which Kubernetes storage object represents a request for a specific amount and type of persistent storage?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolumeClaim<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VolumeSnapshot<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A PersistentVolumeClaim, or PVC, represents an application&#8217;s request for persistent storage. It can specify requirements such as storage capacity, access mode, and StorageClass. Kubernetes can then bind the claim to an appropriate PersistentVolume or dynamically provision storage through the selected StorageClass when supported. A PersistentVolume represents the available storage resource itself, while a StorageClass describes storage provisioning characteristics. PVCs allow application developers to request storage without needing to manage the details of the underlying storage infrastructure directly.<\/span><\/p>\n<h3><b>Question 300<\/b><\/h3>\n<p><b>Which Kubernetes resource defines a class of storage and can be used for dynamic volume provisioning?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolumeClaim<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMap<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A StorageClass defines a category or class of storage and can specify the provisioner and parameters used for dynamic PersistentVolume provisioning. When an application creates a PersistentVolumeClaim referencing a StorageClass, Kubernetes can request storage from the configured storage provider when dynamic provisioning is supported. PersistentVolumes represent actual storage resources, while PersistentVolumeClaims represent application requests for storage. ConfigMaps store configuration data. StorageClasses therefore provide the abstraction that connects application storage requests with the characteristics and capabilities of an underlying storage system.<\/span><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full Linux Foundation KCNA Exam Dumps and Practice Test Dumps. &nbsp; Question 281 Which Kubernetes object is used to ensure that a desired number of application replicas remain available? ConfigMap Service Deployment Secret Correct Answer: 3 Explanation A Deployment manages a desired number of replicated Pods and is commonly used for stateless applications. It [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17220"}],"collection":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/comments?post=17220"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17220\/revisions"}],"predecessor-version":[{"id":17221,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17220\/revisions\/17221"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17220"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17220"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17220"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}