{"id":17197,"date":"2026-09-21T07:01:25","date_gmt":"2026-09-21T07:01:25","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17197"},"modified":"2026-09-21T07:01:25","modified_gmt":"2026-09-21T07:01:25","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part4-q61-80","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part4-q61-80\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part4 Q61-80"},"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 61<\/b><\/h3>\n<p><b>Which Kubernetes component is responsible for maintaining the desired state of cluster resources?<\/b><\/p>\n<ol>\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;\">kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Controller Manager<\/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: 3<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Kubernetes Controller Manager runs various controllers that continuously monitor cluster resources and work to maintain their desired state. For example, the Deployment controller ensures that the required number of Pods exists, while the Node controller monitors node conditions. Controllers compare the desired state with the actual state and take corrective actions when differences are detected. kubelet manages workloads on individual nodes, kube-proxy handles networking functions, and CoreDNS provides DNS services. Understanding controllers is important because Kubernetes relies heavily on reconciliation to provide automation and self-healing behavior across the cluster.<\/span><\/p>\n<h3><b>Question 62<\/b><\/h3>\n<p><b>Which Kubernetes command displays information about the current cluster context?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl cluster-info<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get context<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl show cluster<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl cluster-status<\/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 <\/span><span style=\"font-weight: 400;\">kubectl cluster-info<\/span><span style=\"font-weight: 400;\"> command displays information about the Kubernetes cluster and its core services. It can provide URLs or endpoints associated with the Kubernetes control plane and other cluster services when available. This command is useful as an initial check to verify that kubectl can communicate with the cluster. Commands such as <\/span><span style=\"font-weight: 400;\">kubectl get nodes<\/span><span style=\"font-weight: 400;\"> provide information about individual nodes, while context-related commands manage which cluster and credentials kubectl uses. Understanding basic kubectl discovery commands helps administrators quickly verify connectivity and identify the cluster they are working with.<\/span><\/p>\n<h3><b>Question 63<\/b><\/h3>\n<p><b>Which Kubernetes object is used to expose a workload through a stable DNS name inside the cluster?<\/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;\">Secret<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/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 Kubernetes Service provides a stable network endpoint and DNS name for accessing a group of Pods. Kubernetes DNS automatically creates records for Services, allowing applications to communicate using service names rather than changing Pod IP addresses. This is particularly useful in dynamic environments where Pods may be recreated or rescheduled. Jobs are designed for finite tasks, Secrets store sensitive configuration, and PersistentVolumes provide storage. Services therefore provide an important abstraction between clients and the dynamic Pods running application workloads, making service discovery more reliable.<\/span><\/p>\n<h3><b>Question 64<\/b><\/h3>\n<p><b>Which Kubernetes resource is primarily used to provide configuration values to containers without embedding them in an image?<\/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;\">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;\">Node<\/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 Kubernetes administrators to store non-sensitive configuration values separately from container images. Containers can consume these values through environment variables, mounted files, or command-line arguments. This separation makes applications easier to configure across different environments because the same image can be reused with different configuration values. ConfigMaps should not normally be used for sensitive credentials; Kubernetes Secrets are intended for that purpose. Services provide networking, ReplicaSets manage Pod replicas, and Nodes provide compute resources. ConfigMaps therefore help implement flexible and reusable application configuration.<\/span><\/p>\n<h3><b>Question 65<\/b><\/h3>\n<p><b>Which Kubernetes object is used to store sensitive values such as passwords or tokens?<\/b><\/p>\n<ol>\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;\">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;\">Namespace<\/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 Kubernetes Secret is designed to store sensitive information such as passwords, authentication tokens, and other confidential values. Secrets can be exposed to containers through environment variables or mounted volumes. Although Secrets provide a Kubernetes resource specifically intended for sensitive data, administrators should still configure appropriate access controls and encryption practices. ConfigMaps are intended for non-sensitive configuration information. Services provide networking, while Namespaces organize resources. Understanding the difference between Secrets and ConfigMaps is important when designing secure Kubernetes applications and preparing for KCNA questions related to application configuration.<\/span><\/p>\n<h3><b>Question 66<\/b><\/h3>\n<p><b>Which Kubernetes scheduling feature prevents a Pod from being scheduled onto a node unless the Pod tolerates a matching taint?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Taints<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMaps<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Services<\/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;\">Taints allow administrators to mark nodes so that Pods without appropriate tolerations are prevented from being scheduled there. A taint can specify an effect such as <\/span><span style=\"font-weight: 400;\">NoSchedule<\/span><span style=\"font-weight: 400;\">, which instructs the scheduler not to place non-tolerating Pods on the node. Tolerations are configured on Pods to allow them to be scheduled onto appropriately tainted nodes. This mechanism is useful for dedicating nodes to specific workloads or preventing unsuitable workloads from running on certain nodes. Labels and selectors can influence scheduling and selection, but taints and tolerations specifically provide this scheduling restriction mechanism.<\/span><\/p>\n<h3><b>Question 67<\/b><\/h3>\n<p><b>Which Kubernetes scheduling feature allows Pods to express a preference or requirement for particular nodes based on labels?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Node affinity<\/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;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ingress<\/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;\">Node affinity allows Pods to express rules about which nodes they can or should run on based on node labels. Required node affinity can make a scheduling condition mandatory, while preferred node affinity expresses a preference that the scheduler attempts to satisfy. This capability is useful when workloads require specific hardware, geographic placement, operating systems, or other node characteristics. ResourceQuota controls resource consumption, Ingress manages HTTP or HTTPS routing, and Service discovery provides networking. Node affinity therefore provides a flexible mechanism for influencing workload placement based on node attributes.<\/span><\/p>\n<h3><b>Question 68<\/b><\/h3>\n<p><b>Which Kubernetes object is responsible for maintaining a desired number of Pod replicas but is commonly managed by a Deployment?<\/b><\/p>\n<ol>\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<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<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A ReplicaSet maintains a specified number of identical Pod replicas. If one of its managed Pods is deleted or becomes unavailable, the ReplicaSet attempts to create another Pod to restore the desired count. Deployments commonly manage ReplicaSets and add capabilities such as rolling updates and revision management. Services provide networking, Secrets store sensitive configuration, and Namespaces organize resources. Administrators generally create Deployments rather than managing ReplicaSets directly for typical stateless applications, but understanding ReplicaSets is important because they are an underlying mechanism used by Deployments.<\/span><\/p>\n<h3><b>Question 69<\/b><\/h3>\n<p><b>Which Kubernetes workload resource is designed to maintain stable network identities and persistent storage associations for Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DaemonSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StatefulSet<\/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<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A StatefulSet is designed for stateful applications that require stable identities, predictable Pod names, or persistent storage associations. Each StatefulSet Pod receives a stable ordinal identity, which can be important for distributed databases and other clustered applications. StatefulSets can also work with PersistentVolumeClaims to provide persistent storage to individual replicas. DaemonSets run workloads on eligible nodes, Jobs handle finite tasks, and ReplicaSets maintain interchangeable Pod replicas. StatefulSets therefore provide capabilities that are particularly useful when application instances cannot be treated as completely interchangeable.<\/span><\/p>\n<h3><b>Question 70<\/b><\/h3>\n<p><b>Which Kubernetes workload resource ensures that a Pod runs on every eligible node?<\/b><\/p>\n<ol>\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;\">Deployment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DaemonSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StatefulSet<\/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 DaemonSet ensures that a copy of a specified Pod runs on each node that meets its scheduling requirements. When a new eligible node is added to the cluster, the DaemonSet controller can create a corresponding Pod on that node. DaemonSets are commonly used for node-level agents such as monitoring, logging, and networking components. Deployments manage a desired number of application replicas, StatefulSets manage stateful workloads, and Jobs manage finite tasks. Therefore, DaemonSet is the appropriate Kubernetes workload resource when one Pod should run on each eligible node.<\/span><\/p>\n<h3><b>Question 71<\/b><\/h3>\n<p><b>Which Kubernetes object is commonly used to run a one-time database migration task?<\/b><\/p>\n<ol>\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;\">Service<\/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;\">DaemonSet<\/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 Kubernetes Job is appropriate for tasks that need to run to completion, such as database migrations, batch processing, or one-time maintenance operations. The Job controller creates Pods and tracks whether the required work completes successfully. Failed attempts can be retried according to the configured behavior. A Service provides networking, a ConfigMap stores configuration, and a DaemonSet is intended for workloads that should run on eligible nodes. Choosing a Job for a finite migration task follows Kubernetes&#8217; workload model and separates completion-oriented operations from continuously running application workloads.<\/span><\/p>\n<h3><b>Question 72<\/b><\/h3>\n<p><b>Which Kubernetes resource can create Jobs repeatedly according to a specified schedule?<\/b><\/p>\n<ol>\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;\">CronJob<\/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 CronJob creates Kubernetes Jobs according to a configured schedule. It is useful for recurring tasks such as backups, reports, cleanup processes, and periodic data processing. Each scheduled execution creates a Job, and the Job creates the required Pod to perform the task. Deployments are generally used for continuously running applications, ReplicaSets maintain Pod replicas, and Services provide network access. CronJobs use cron-style scheduling expressions to determine when Jobs should be created. They are therefore the Kubernetes resource specifically designed for recurring scheduled workloads.<\/span><\/p>\n<h3><b>Question 73<\/b><\/h3>\n<p><b>Which Kubernetes command is used to apply a resource definition from a YAML file?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl deploy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl apply<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl resource<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl install<\/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 <\/span><span style=\"font-weight: 400;\">kubectl apply<\/span><span style=\"font-weight: 400;\"> command is commonly used to create or update Kubernetes resources from declarative configuration files. For example, administrators can use <\/span><span style=\"font-weight: 400;\">kubectl apply -f manifest.yaml<\/span><span style=\"font-weight: 400;\"> to submit a YAML resource definition to the Kubernetes API. Kubernetes then attempts to make the actual cluster state match the configuration described by the manifest. This declarative approach is widely used for managing Kubernetes resources and supports repeatable configuration workflows. Other commands may perform specific operations, but <\/span><span style=\"font-weight: 400;\">kubectl apply<\/span><span style=\"font-weight: 400;\"> is the standard command for applying declarative resource manifests.<\/span><\/p>\n<h3><b>Question 74<\/b><\/h3>\n<p><b>Which Kubernetes command removes a resource from the cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl remove<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl destroy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl delete<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl erase<\/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 <\/span><span style=\"font-weight: 400;\">kubectl delete<\/span><span style=\"font-weight: 400;\"> command is used to remove Kubernetes resources from a cluster. Administrators can delete individual resources by specifying their type and name or remove resources defined in a manifest. For example, <\/span><span style=\"font-weight: 400;\">kubectl delete pod example<\/span><span style=\"font-weight: 400;\"> can delete a specific Pod. When a resource is controlled by another Kubernetes controller, deleting it may result in the controller creating a replacement to restore the desired state. Understanding this behavior is important when troubleshooting and managing workloads because deleting a managed resource does not necessarily permanently remove the workload.<\/span><\/p>\n<h3><b>Question 75<\/b><\/h3>\n<p><b>Which Kubernetes command can display the events associated with resources in a namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get events<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl show events<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl list alerts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl events show<\/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 <\/span><span style=\"font-weight: 400;\">kubectl get events<\/span><span style=\"font-weight: 400;\"> command displays Kubernetes events associated with resources in a namespace. Events can provide useful information about scheduling decisions, image-pulling failures, container startup problems, volume issues, and other cluster activities. They are particularly helpful when a Pod remains pending or fails to start. Events are generally intended as operational information rather than permanent application logs, so administrators should not rely on them as a long-term audit history. Combining event information with Pod descriptions and logs can provide a more complete view of workload problems.<\/span><\/p>\n<h3><b>Question 76<\/b><\/h3>\n<p><b>Which Kubernetes object is used to define a collection of permissions that can apply across the entire cluster?<\/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;\">ClusterRole<\/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;\">PersistentVolumeClaim<\/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 ClusterRole defines a set of permissions that can be used across a Kubernetes cluster. It can grant access to cluster-scoped resources and can also define permissions for namespaced resources when associated with the appropriate binding. A ClusterRole is used together with RoleBinding or ClusterRoleBinding depending on the desired scope. ConfigMaps store configuration, Services provide networking, and PersistentVolumeClaims request storage. Understanding ClusterRole is important when working with Kubernetes RBAC because it allows administrators to define reusable permission sets that can be assigned to users, groups, or ServiceAccounts.<\/span><\/p>\n<h3><b>Question 77<\/b><\/h3>\n<p><b>Which Kubernetes RBAC object grants a ClusterRole&#8217;s permissions across the cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RoleBinding<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterRoleBinding<\/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;\">ServiceAccount<\/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 ClusterRoleBinding associates a ClusterRole with a user, group, or ServiceAccount at the cluster level. This allows the specified identity to receive the permissions defined by the ClusterRole according to the binding. A RoleBinding can also reference a ClusterRole, but the resulting permissions are normally limited to the namespace where the RoleBinding exists. ConfigMaps store configuration and ServiceAccounts provide identities but do not themselves grant permissions. Understanding the difference between RoleBinding and ClusterRoleBinding is important for correctly implementing Kubernetes RBAC and avoiding unnecessarily broad access.<\/span><\/p>\n<h3><b>Question 78<\/b><\/h3>\n<p><b>Which Kubernetes networking resource can restrict ingress and egress traffic for selected Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NetworkPolicy<\/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;\">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: 1<\/b><\/p>\n<p><b>Explanation<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A NetworkPolicy defines rules controlling allowed network traffic to and from selected Pods. Policies can specify ingress and egress behavior using selectors and other supported criteria. For example, an administrator can restrict an application so that it accepts traffic only from Pods in a specific namespace or with particular labels. NetworkPolicy enforcement depends on the cluster&#8217;s networking implementation supporting the relevant capabilities. Deployments manage application replicas, ConfigMaps store configuration, and Secrets store sensitive information. NetworkPolicies therefore provide an important layer of network-level access control within Kubernetes environments.<\/span><\/p>\n<h3><b>Question 79<\/b><\/h3>\n<p><b>Which container runtime interface allows Kubernetes to communicate with supported container runtimes?<\/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;\">API<\/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;\">CRI stands for Container Runtime Interface and provides a standardized interface through which Kubernetes can communicate with container runtimes. It allows Kubernetes components to request operations such as creating, starting, stopping, and removing containers and Pods without being tightly coupled to one particular runtime implementation. CNI is associated with container networking, while CSI is associated with container storage. The Kubernetes API provides access to cluster resources but is not the interface used for container runtime operations. Understanding CRI, CNI, and CSI helps distinguish the major infrastructure interfaces used around Kubernetes.<\/span><\/p>\n<h3><b>Question 80<\/b><\/h3>\n<p><b>Which interface standard is used by Kubernetes to integrate with storage systems?<\/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;\">CRI<\/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;\">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;\">CSI stands for Container Storage Interface and provides a standardized way for container orchestration platforms such as Kubernetes to integrate with storage systems. CSI drivers allow Kubernetes to provision, attach, mount, and manage storage resources through supported storage backends. CNI handles container networking, while CRI provides the interface for container runtimes. RBAC controls authorization and permissions. Understanding CSI is important when studying Kubernetes storage because it separates Kubernetes storage management from the implementation details of individual storage vendors and platforms.<\/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 61 Which Kubernetes component is responsible for maintaining the desired state of cluster resources? kube-proxy kubelet Controller Manager CoreDNS Correct Answer: 3 Explanation The Kubernetes Controller Manager runs various controllers that continuously monitor cluster resources and work to maintain their desired state. [&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\/17197"}],"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=17197"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17197\/revisions"}],"predecessor-version":[{"id":17198,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17197\/revisions\/17198"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17197"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17197"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17197"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}