{"id":17200,"date":"2026-09-21T07:03:36","date_gmt":"2026-09-21T07:03:36","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17200"},"modified":"2026-09-21T07:03:36","modified_gmt":"2026-09-21T07:03:36","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part5-q81-100","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part5-q81-100\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part5 Q81-100"},"content":{"rendered":"

View Full <\/b>Linux Foundation KCNA Exam Dumps<\/b><\/a> and Practice Test Dumps.<\/b><\/h2>\n

 <\/p>\n

Question 81<\/b><\/h3>\n

Which Kubernetes object is used to request storage from available PersistentVolumes?<\/b><\/p>\n

    \n
  1. PersistentVolumeClaim<\/span><\/li>\n
  2. ConfigMap<\/span><\/li>\n
  3. Service<\/span><\/li>\n
  4. ReplicaSet<\/span><\/li>\n<\/ol>\n

    Correct Answer: 1<\/b><\/p>\n

    Explanation<\/b><\/p>\n

    A PersistentVolumeClaim, or PVC, is a request for storage made by a user or workload in Kubernetes. Instead of directly managing the underlying storage resource, an application can request a specific amount of storage and access modes through a PVC. Kubernetes can then bind the claim to a suitable PersistentVolume. This abstraction separates application requirements from the actual storage implementation. ConfigMaps provide configuration data, Services provide networking, and ReplicaSets maintain Pod replicas. PVCs are commonly mounted into Pods when applications need persistent data that should survive Pod recreation.<\/span><\/p>\n

    Question 82<\/b><\/h3>\n

    Which access mode allows a PersistentVolume to be mounted as read-write by multiple nodes, when supported by the storage system?<\/b><\/p>\n

      \n
    1. ReadWriteOnce<\/span><\/li>\n
    2. ReadOnlyMany<\/span><\/li>\n
    3. ReadWriteMany<\/span><\/li>\n
    4. ReadWriteSingle<\/span><\/li>\n<\/ol>\n

      Correct Answer: 3<\/b><\/p>\n

      Explanation<\/b><\/p>\n

      ReadWriteMany, abbreviated RWX, allows a PersistentVolume to be mounted as read-write by multiple nodes when the underlying storage system supports this access mode. This can be useful for applications where multiple Pods running on different nodes need shared read and write access to the same data. ReadWriteOnce generally permits read-write mounting by a single node, while ReadOnlyMany permits read-only mounting by multiple nodes. The actual availability of each access mode depends on the storage implementation and its CSI driver capabilities.<\/span><\/p>\n

      Question 83<\/b><\/h3>\n

      Which Kubernetes resource defines a class of storage that can be dynamically provisioned?<\/b><\/p>\n

        \n
      1. StorageClass<\/span><\/li>\n
      2. ResourceQuota<\/span><\/li>\n
      3. Namespace<\/span><\/li>\n
      4. VolumeSnapshot<\/span><\/li>\n<\/ol>\n

        Correct Answer: 1<\/b><\/p>\n

        Explanation<\/b><\/p>\n

        A StorageClass defines different classes or types of storage available within a Kubernetes cluster. It can specify a provisioner and parameters that determine how storage should be dynamically created. When a PersistentVolumeClaim references a StorageClass, Kubernetes can request storage from the configured provisioner without requiring an administrator to manually create every PersistentVolume. StorageClasses are useful for offering different performance levels, replication options, or storage backends. ResourceQuota controls resource consumption, while Namespaces organize resources. StorageClass therefore plays an important role in Kubernetes dynamic storage provisioning.<\/span><\/p>\n

        Question 84<\/b><\/h3>\n

        Which Kubernetes component assigns newly created Pods to suitable nodes?<\/b><\/p>\n

          \n
        1. kubelet<\/span><\/li>\n
        2. kube-scheduler<\/span><\/li>\n
        3. kube-proxy<\/span><\/li>\n
        4. CoreDNS<\/span><\/li>\n<\/ol>\n

          Correct Answer: 2<\/b><\/p>\n

          Explanation<\/b><\/p>\n

          The kube-scheduler is responsible for selecting an appropriate node for Pods that have not yet been assigned to one. It evaluates factors such as resource availability, affinity rules, taints and tolerations, and other scheduling constraints. After the scheduler assigns a Pod to a node, the kubelet on that node is responsible for ensuring the Pod’s containers are running. kube-proxy handles service-related networking functions, while CoreDNS provides cluster DNS services. The scheduler is therefore a key control-plane component responsible for workload placement.<\/span><\/p>\n

          Question 85<\/b><\/h3>\n

          Which Kubernetes component runs on each node and ensures that containers described by Pod specifications are running?<\/b><\/p>\n

            \n
          1. kubelet<\/span><\/li>\n
          2. kube-scheduler<\/span><\/li>\n
          3. etcd<\/span><\/li>\n
          4. kube-controller-manager<\/span><\/li>\n<\/ol>\n

            Correct Answer: 1<\/b><\/p>\n

            Explanation<\/b><\/p>\n

            The kubelet is the primary Kubernetes agent running on each node. It receives Pod specifications from the Kubernetes control plane and works with the container runtime to ensure that the specified containers are running and healthy according to the Pod configuration. The kubelet also reports node and Pod status back to the API server. The scheduler determines where Pods should run, etcd stores cluster state, and the controller manager runs controllers. Understanding the kubelet’s node-level role is essential for understanding how Kubernetes turns desired workload definitions into running containers.<\/span><\/p>\n

            Question 86<\/b><\/h3>\n

            Which Kubernetes component stores the cluster’s persistent state?<\/b><\/p>\n

              \n
            1. CoreDNS<\/span><\/li>\n
            2. etcd<\/span><\/li>\n
            3. kube-proxy<\/span><\/li>\n
            4. kubelet<\/span><\/li>\n<\/ol>\n

              Correct Answer: 2<\/b><\/p>\n

              Explanation<\/b><\/p>\n

              etcd is a distributed key-value store used by Kubernetes to persist cluster state. Kubernetes stores important information such as resource definitions, configuration, and metadata in etcd. The Kubernetes API server communicates with etcd to read and write this state. Because etcd contains critical cluster information, it requires appropriate backup, security, and availability practices in production environments. CoreDNS provides DNS services, kube-proxy supports networking functions, and kubelet manages workloads on nodes. Protecting etcd is therefore an important part of maintaining a Kubernetes control plane.<\/span><\/p>\n

              Question 87<\/b><\/h3>\n

              Which component provides the primary API endpoint through which users and Kubernetes components interact with the cluster?<\/b><\/p>\n

                \n
              1. kube-apiserver<\/span><\/li>\n
              2. kubelet<\/span><\/li>\n
              3. kube-proxy<\/span><\/li>\n
              4. containerd<\/span><\/li>\n<\/ol>\n

                Correct Answer: 1<\/b><\/p>\n

                Explanation<\/b><\/p>\n

                The kube-apiserver provides the central API endpoint for Kubernetes. Users, kubectl, controllers, schedulers, and other components communicate with the cluster through the API server. It validates requests, performs authentication and authorization checks, and coordinates access to cluster state stored in etcd. The kubelet manages workloads on individual nodes, kube-proxy supports networking, and containerd is a container runtime. Because the API server is central to communication with the Kubernetes control plane, understanding its role is fundamental to understanding Kubernetes architecture.<\/span><\/p>\n

                Question 88<\/b><\/h3>\n

                Which Kubernetes networking component is responsible for implementing network rules that allow Services to route traffic to Pods?<\/b><\/p>\n

                  \n
                1. kube-proxy<\/span><\/li>\n
                2. kubelet<\/span><\/li>\n
                3. etcd<\/span><\/li>\n
                4. kube-scheduler<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 1<\/b><\/p>\n

                  Explanation<\/b><\/p>\n

                  kube-proxy is a node-level networking component traditionally responsible for implementing network rules that support Kubernetes Services. These rules help direct traffic addressed to a Service toward appropriate backend Pods. Depending on the cluster configuration and networking implementation, kube-proxy may use mechanisms such as iptables or IPVS. The kubelet manages Pods, etcd stores cluster state, and kube-scheduler handles Pod placement. Modern Kubernetes networking can vary significantly between environments, but kube-proxy remains an important component to understand when learning traditional Kubernetes Service networking.<\/span><\/p>\n

                  Question 89<\/b><\/h3>\n

                  Which Kubernetes resource organizes objects into logical groups and provides a scope for namespaced resources?<\/b><\/p>\n

                    \n
                  1. Namespace<\/span><\/li>\n
                  2. Node<\/span><\/li>\n
                  3. Service<\/span><\/li>\n
                  4. Ingress<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 1<\/b><\/p>\n

                    Explanation<\/b><\/p>\n

                    A Namespace provides a logical boundary for many Kubernetes resources. Namespaces are useful for separating environments, teams, applications, or projects within the same cluster. Resource names generally need to be unique within their namespace rather than across the entire cluster. Namespaces can also be used with RBAC policies and resource quotas to manage access and consumption. Nodes provide compute capacity, Services provide networking, and Ingress manages HTTP or HTTPS routing. Proper namespace organization can make large Kubernetes environments easier to manage and administer.<\/span><\/p>\n

                    Question 90<\/b><\/h3>\n

                    Which Kubernetes feature can limit the total amount of CPU and memory that resources in a namespace may consume?<\/b><\/p>\n

                      \n
                    1. NetworkPolicy<\/span><\/li>\n
                    2. ResourceQuota<\/span><\/li>\n
                    3. ServiceAccount<\/span><\/li>\n
                    4. StorageClass<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 2<\/b><\/p>\n

                      Explanation<\/b><\/p>\n

                      ResourceQuota allows administrators to limit aggregate resource consumption within a namespace. Quotas can restrict quantities such as CPU, memory, Pods, Services, PersistentVolumeClaims, and other supported resources. This helps prevent a single team or application from consuming an excessive share of cluster resources. Resource requests and limits control resources at the individual container level, while ResourceQuota applies restrictions across a namespace. NetworkPolicy controls traffic, ServiceAccounts provide identities, and StorageClasses define storage provisioning behavior. ResourceQuota is therefore useful for enforcing resource boundaries between teams and workloads.<\/span><\/p>\n

                      Question 91<\/b><\/h3>\n

                      Which Kubernetes feature can automatically adjust the number of Pod replicas based on observed resource utilization?<\/b><\/p>\n

                        \n
                      1. Horizontal Pod Autoscaler<\/span><\/li>\n
                      2. PersistentVolume<\/span><\/li>\n
                      3. NetworkPolicy<\/span><\/li>\n
                      4. ConfigMap<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1<\/b><\/p>\n

                        Explanation<\/b><\/p>\n

                        The Horizontal Pod Autoscaler, or HPA, automatically adjusts the number of replicas in a scalable workload based on observed metrics. A common configuration uses CPU or memory utilization, although other metrics can also be used when the necessary metrics infrastructure is available. The HPA increases replicas when demand rises and can reduce them when demand decreases, subject to configured limits. PersistentVolumes provide storage, NetworkPolicies control network traffic, and ConfigMaps store configuration. HPA is therefore an important Kubernetes mechanism for automatically scaling workloads horizontally.<\/span><\/p>\n

                        Question 92<\/b><\/h3>\n

                        Which Kubernetes autoscaling mechanism changes the resource requests and limits of Pods by creating or modifying workload configurations?<\/b><\/p>\n

                          \n
                        1. Horizontal Pod Autoscaler<\/span><\/li>\n
                        2. Vertical Pod Autoscaler<\/span><\/li>\n
                        3. Cluster Autoscaler<\/span><\/li>\n
                        4. Node Scheduler<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 2<\/b><\/p>\n

                          Explanation<\/b><\/p>\n

                          The Vertical Pod Autoscaler, or VPA, is designed to recommend or adjust CPU and memory resource requests for Pods. Instead of primarily changing the number of replicas, as the Horizontal Pod Autoscaler does, VPA focuses on the resources assigned to individual Pods. Depending on its configuration, VPA can operate in recommendation or update modes. Cluster Autoscaler works at the node level by adjusting cluster capacity. The scheduler places Pods onto nodes but does not itself provide autoscaling. Understanding these autoscaling approaches helps distinguish workload scaling from infrastructure scaling.<\/span><\/p>\n

                          Question 93<\/b><\/h3>\n

                          Which Kubernetes autoscaling mechanism can add or remove nodes from a cluster based on pending workloads and resource requirements?<\/b><\/p>\n

                            \n
                          1. Horizontal Pod Autoscaler<\/span><\/li>\n
                          2. Vertical Pod Autoscaler<\/span><\/li>\n
                          3. Cluster Autoscaler<\/span><\/li>\n
                          4. ReplicaSet<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 3<\/b><\/p>\n

                            Explanation<\/b><\/p>\n

                            The Cluster Autoscaler adjusts the number of nodes in a Kubernetes cluster based on workload scheduling requirements and configured limits. For example, when Pods cannot be scheduled because available nodes lack sufficient resources, the Cluster Autoscaler can request additional nodes from the underlying infrastructure provider. It can also remove underutilized nodes when doing so is safe and appropriate. HPA changes workload replica counts, VPA adjusts Pod resource recommendations or requests, and ReplicaSets maintain Pod replicas. Cluster Autoscaler therefore operates primarily at the infrastructure capacity level.<\/span><\/p>\n

                            Question 94<\/b><\/h3>\n

                            Which Kubernetes object provides an identity that a Pod can use when communicating with the Kubernetes API?<\/b><\/p>\n

                              \n
                            1. ServiceAccount<\/span><\/li>\n
                            2. ConfigMap<\/span><\/li>\n
                            3. StorageClass<\/span><\/li>\n
                            4. ReplicaSet<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 1<\/b><\/p>\n

                              Explanation<\/b><\/p>\n

                              A ServiceAccount provides an identity for processes running inside Pods when they need to interact with the Kubernetes API. Pods can be configured to use a particular ServiceAccount, and RBAC permissions can then determine which API operations that identity is allowed to perform. This provides a structured way to control application access to Kubernetes resources. ConfigMaps store configuration, StorageClasses define storage types, and ReplicaSets manage Pod replicas. Combining ServiceAccounts with RBAC is a common approach for implementing least-privilege access for applications running inside a cluster.<\/span><\/p>\n

                              Question 95<\/b><\/h3>\n

                              Which Kubernetes security mechanism determines whether a user or ServiceAccount is allowed to perform a specific API operation?<\/b><\/p>\n

                                \n
                              1. CNI<\/span><\/li>\n
                              2. RBAC<\/span><\/li>\n
                              3. CSI<\/span><\/li>\n
                              4. kube-proxy<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 2<\/b><\/p>\n

                                Explanation<\/b><\/p>\n

                                Role-Based Access Control, or RBAC, determines whether identities such as users, groups, and ServiceAccounts have permission to perform specific operations on Kubernetes resources. RBAC permissions are defined through objects such as Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. For example, an administrator can allow an application to read ConfigMaps in one namespace without granting permission to modify Deployments. CNI handles networking, CSI handles storage integration, and kube-proxy supports Service networking. RBAC is therefore a core Kubernetes security mechanism for controlling API access.<\/span><\/p>\n

                                Question 96<\/b><\/h3>\n

                                Which Kubernetes object is commonly used to expose an HTTP application to external clients using hostnames and URL paths?<\/b><\/p>\n

                                  \n
                                1. Ingress<\/span><\/li>\n
                                2. ConfigMap<\/span><\/li>\n
                                3. Job<\/span><\/li>\n
                                4. PersistentVolume<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 1<\/b><\/p>\n

                                  Explanation<\/b><\/p>\n

                                  An Ingress defines rules for routing HTTP and HTTPS traffic to Kubernetes Services. It can use hostnames and URL paths to direct incoming requests to different backend Services. For example, requests for different domains or paths can be routed to separate application components. An Ingress resource requires an Ingress controller or another implementation to actually process the defined rules. ConfigMaps provide configuration, Jobs run finite workloads, and PersistentVolumes provide storage. Ingress therefore provides a common abstraction for HTTP and HTTPS routing into Kubernetes applications.<\/span><\/p>\n

                                  Question 97<\/b><\/h3>\n

                                  Which Kubernetes Service type exposes a Service on each node’s IP address at a specified port?<\/b><\/p>\n

                                    \n
                                  1. ClusterIP<\/span><\/li>\n
                                  2. ExternalName<\/span><\/li>\n
                                  3. NodePort<\/span><\/li>\n
                                  4. Headless<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 3<\/b><\/p>\n

                                    Explanation<\/b><\/p>\n

                                    A NodePort Service exposes the Service on a port available on each node, allowing clients to access the Service through a node IP address and the assigned port. Kubernetes then routes the traffic toward the Service’s backend Pods according to the cluster’s networking behavior. ClusterIP provides internal cluster access, ExternalName maps a Service to an external DNS name, and a headless Service does not provide a conventional virtual cluster IP. NodePort is therefore useful when direct node-level access to a Kubernetes Service is required.<\/span><\/p>\n

                                    Question 98<\/b><\/h3>\n

                                    Which Kubernetes Service type is the default and provides an internal virtual IP for access within the cluster?<\/b><\/p>\n

                                      \n
                                    1. NodePort<\/span><\/li>\n
                                    2. LoadBalancer<\/span><\/li>\n
                                    3. ClusterIP<\/span><\/li>\n
                                    4. ExternalName<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 3<\/b><\/p>\n

                                      Explanation<\/b><\/p>\n

                                      ClusterIP is the default Kubernetes Service type. It provides a stable virtual IP address that can be used to access the Service from within the cluster. Traffic sent to the ClusterIP is distributed to the Service’s selected backend Pods according to the cluster networking implementation. NodePort additionally exposes a port on nodes, while LoadBalancer is commonly integrated with external load-balancing infrastructure. ExternalName maps a Service to an external DNS name rather than creating the usual virtual IP. ClusterIP is therefore the standard choice for internal Service communication.<\/span><\/p>\n

                                      Question 99<\/b><\/h3>\n

                                      Which Kubernetes object can provide a stable DNS name for individual Pods by omitting a cluster IP from the Service?<\/b><\/p>\n

                                        \n
                                      1. Headless Service<\/span><\/li>\n
                                      2. Deployment<\/span><\/li>\n
                                      3. DaemonSet<\/span><\/li>\n
                                      4. ResourceQuota<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 1<\/b><\/p>\n

                                        Explanation<\/b><\/p>\n

                                        A headless Service is created by setting its cluster IP behavior to <\/span>None<\/span>. Instead of providing a conventional virtual ClusterIP, DNS queries for the Service can return the IP addresses of the associated Pods. This behavior is particularly useful for applications that need to discover individual Pod endpoints, such as some stateful distributed systems. Deployments manage application replicas, DaemonSets maintain workloads on nodes, and ResourceQuota limits resource consumption. Headless Services therefore provide a useful service-discovery mechanism when direct Pod endpoint information is required.<\/span><\/p>\n

                                        Question 100<\/b><\/h3>\n

                                        Which Kubernetes principle describes the system continuously comparing actual state with desired state and taking action to reduce differences?<\/b><\/p>\n

                                          \n
                                        1. Imperative execution<\/span><\/li>\n
                                        2. Reconciliation<\/span><\/li>\n
                                        3. Image building<\/span><\/li>\n
                                        4. Port forwarding<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 2<\/b><\/p>\n

                                          Explanation<\/b><\/p>\n

                                          Reconciliation is a fundamental Kubernetes principle in which controllers continuously compare the desired state declared by users with the actual state of cluster resources. When a difference is detected, the relevant controller takes action to move the system toward the desired state. For example, if a Deployment requires three replicas and one Pod disappears, Kubernetes can create another Pod to restore the desired count. This model enables automation and self-healing. Imperative commands can still be used to interact with Kubernetes, but reconciliation is central to how Kubernetes controllers maintain workloads.<\/span><\/p>\n

                                           <\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Linux Foundation KCNA Exam Dumps and Practice Test Dumps.   Question 81 Which Kubernetes object is used to request storage from available PersistentVolumes? PersistentVolumeClaim ConfigMap Service ReplicaSet Correct Answer: 1 Explanation A PersistentVolumeClaim, or PVC, is a request for storage made by a user or workload in Kubernetes. Instead of directly managing the […]<\/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\/17200"}],"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=17200"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17200\/revisions"}],"predecessor-version":[{"id":17201,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17200\/revisions\/17201"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}