{"id":17224,"date":"2026-09-21T07:09:16","date_gmt":"2026-09-21T07:09:16","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17224"},"modified":"2026-09-21T07:09:16","modified_gmt":"2026-09-21T07:09:16","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part17-q321-340","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part17-q321-340\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part17 Q321-340"},"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 321<\/b><\/h3>\n<p><b>Which Kubernetes object is used to store non-sensitive configuration data separately from application container images?<\/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;\">PersistentVolume<\/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 ConfigMap stores non-sensitive configuration data separately from application container images. It can contain values such as application settings, environment variables, command-line parameters, or configuration files. Pods can consume ConfigMap data through environment variables, command arguments, or mounted volumes. Secrets are intended for sensitive information, while PersistentVolumes provide persistent storage and ServiceAccounts provide identities for workloads. Separating configuration from container images makes applications easier to configure across different environments without rebuilding the image whenever a configuration value changes.<\/span><\/p>\n<h3><b>Question 322<\/b><\/h3>\n<p><b>Which Kubernetes resource is specifically intended for storing sensitive information 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;\">Namespace<\/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;\">A Secret is designed to hold sensitive information such as passwords, authentication tokens, or certificates. Pods can consume Secret data through environment variables or mounted volumes. Although Kubernetes Secrets provide mechanisms for handling sensitive values, administrators should also configure appropriate access controls and encryption protections because simply storing a value in a Secret does not automatically make it inaccessible to authorized users. ConfigMaps are intended for non-sensitive configuration. Using Secrets helps keep sensitive configuration separate from application images and ordinary configuration data.<\/span><\/p>\n<h3><b>Question 323<\/b><\/h3>\n<p><b>Which Kubernetes API field identifies the type of object being defined in a YAML manifest?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">metadata<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">spec<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kind<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">status<\/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 kind field identifies the type of Kubernetes object represented by a manifest. Examples include Pod, Deployment, Service, ConfigMap, and Namespace. The apiVersion field specifies the API group and version used for the resource. metadata contains information such as the object&#8217;s name and labels, while spec describes the desired configuration for resources that support it. The status section generally represents the current observed state maintained by Kubernetes. Understanding these common manifest fields is essential when creating declarative Kubernetes configurations.<\/span><\/p>\n<h3><b>Question 324<\/b><\/h3>\n<p><b>What is the primary purpose of the metadata section in a Kubernetes resource manifest?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To define container CPU limits<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To store identifying information such as names and labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To define the container image registry<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To configure the cluster&#8217;s DNS server<\/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 metadata section contains identifying and organizational information about a Kubernetes object. Common metadata fields include name, namespace, labels, and annotations. Labels can be used for selection and grouping, while annotations can store additional descriptive information that is not normally used for selection. The metadata section does not directly define container CPU limits or cluster DNS configuration. Resource-specific configuration is generally found in the spec section. Proper metadata is important because Kubernetes and its supporting tools use names, labels, and other metadata to identify and organize resources.<\/span><\/p>\n<h3><b>Question 325<\/b><\/h3>\n<p><b>Which kubectl command provides documentation about Kubernetes resource fields and their structure?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl explain<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl expose<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl scale<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl proxy<\/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 kubectl explain command provides documentation about Kubernetes API resources and their fields. For example, administrators can use kubectl explain pod or kubectl explain deployment.spec to inspect available fields and understand their purpose. This is useful when writing YAML manifests because it provides information directly through the Kubernetes API machinery. The expose command creates a Service from a resource, scale changes replica counts, and proxy provides access through a local proxy. kubectl explain is therefore a practical reference tool for working with Kubernetes resource definitions.<\/span><\/p>\n<h3><b>Question 326<\/b><\/h3>\n<p><b>Which Kubernetes concept allows controllers to continuously compare the desired state with the current state and make corrective changes?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Container runtime<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reconciliation<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Port forwarding<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Service discovery<\/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;\">Reconciliation is the process through which Kubernetes controllers compare the desired state of resources with their current observed state and take actions to reduce any difference. For example, if a Deployment specifies three replicas but only two are running, its controllers work to create another Pod. This continuous control-loop approach is a fundamental part of Kubernetes architecture. Container runtimes execute containers, port forwarding provides temporary network access, and service discovery helps workloads locate Services. Reconciliation enables Kubernetes to maintain the state declared by users.<\/span><\/p>\n<h3><b>Question 327<\/b><\/h3>\n<p><b>Which Kubernetes component is responsible for authenticating requests, authorizing access, and serving the Kubernetes API?<\/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-apiserver<\/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 kube-apiserver is the central API component of the Kubernetes control plane. It receives API requests from kubectl, controllers, administrators, and other clients. Requests can pass through authentication and authorization mechanisms before being processed. The API server also coordinates access to cluster state and communicates with other control-plane components. The kubelet manages workloads on individual nodes, kube-proxy handles Service-related networking functions, and CoreDNS provides DNS-based service discovery. The kube-apiserver therefore acts as the primary interface for interacting with the Kubernetes cluster.<\/span><\/p>\n<h3><b>Question 328<\/b><\/h3>\n<p><b>Which Kubernetes control-plane component makes scheduling decisions for Pods that do not yet have a node assigned?<\/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;\">etcd<\/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 kube-scheduler selects suitable nodes for Pods that have not yet been assigned to a node. It evaluates factors such as resource requirements, node constraints, affinity rules, taints and tolerations, and other scheduling conditions. After selecting a suitable node, the scheduler records the assignment through the Kubernetes API. The kube-controller-manager runs various controllers, kubelet manages Pods on a node, and etcd stores cluster state. Scheduling is therefore a distinct control-plane responsibility handled by the kube-scheduler.<\/span><\/p>\n<h3><b>Question 329<\/b><\/h3>\n<p><b>What is the primary purpose of etcd in a Kubernetes cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To execute containers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To provide external DNS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To store Kubernetes cluster state<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To route Service traffic<\/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;\">etcd is a distributed key-value store used by Kubernetes to persist important cluster state. Kubernetes control-plane components rely on this stored information to maintain objects and configuration required to operate the cluster. etcd does not execute application containers or directly provide Service networking. The kubelet works with the container runtime on nodes, CoreDNS provides DNS functionality, and networking components handle Service traffic. Because etcd contains critical cluster information, production deployments commonly consider its availability, backup, security, and recovery when designing the control plane.<\/span><\/p>\n<h3><b>Question 330<\/b><\/h3>\n<p><b>Which component runs on each Kubernetes node and communicates with the control plane to manage Pods?<\/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-scheduler<\/span><\/li>\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;\">CoreDNS<\/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 kubelet is the primary node agent in Kubernetes. It runs on each node and is responsible for ensuring that the containers described by assigned Pods are running and healthy according to the desired configuration. The kubelet communicates with the Kubernetes API and works with the container runtime to manage containers. The scheduler makes placement decisions, etcd stores cluster state, and CoreDNS provides DNS services. The kubelet therefore plays a key role in connecting control-plane decisions with actual workload execution on individual nodes.<\/span><\/p>\n<h3><b>Question 331<\/b><\/h3>\n<p><b>Which Kubernetes security mechanism determines whether an authenticated identity is allowed to perform an action on a resource?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Scheduling<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Authorization<\/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;\">Reconciliation<\/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;\">Authorization determines whether an authenticated identity has permission to perform a requested action on a Kubernetes resource. Kubernetes commonly uses role-based access control, or RBAC, to define permissions for users, groups, and ServiceAccounts. Authentication establishes who or what is making a request, while authorization evaluates whether that identity has sufficient permissions. Reconciliation and scheduling serve different purposes within cluster operation. Proper authorization helps restrict access to sensitive resources and prevents workloads or users from performing actions beyond their assigned permissions.<\/span><\/p>\n<h3><b>Question 332<\/b><\/h3>\n<p><b>Which RBAC object defines permissions within a specific Namespace?<\/b><\/p>\n<ol>\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;\">Role<\/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;\">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 Role defines permissions within a specific Namespace. It can specify allowed API operations such as get, list, create, update, or delete for particular resources. A Role does not by itself grant permissions; a RoleBinding is commonly used to associate the Role with a user, group, or ServiceAccount. ClusterRole can define permissions that are not restricted to a single Namespace, while ClusterRoleBinding associates ClusterRole permissions with subjects at the cluster level. Namespace-scoped Roles are useful for limiting application access to only the resources required within a particular Namespace.<\/span><\/p>\n<h3><b>Question 333<\/b><\/h3>\n<p><b>Which RBAC object can define permissions that apply across the cluster rather than being limited to one Namespace?<\/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;\">RoleBinding<\/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;\">PersistentVolumeClaim<\/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 ClusterRole defines a set of RBAC permissions at the cluster scope. It can be used for resources that are cluster-scoped and can also be associated with access to namespaced resources depending on how the permissions are bound. A ClusterRoleBinding can grant those permissions to users, groups, or ServiceAccounts across the cluster. Role is restricted to a particular Namespace, while ConfigMaps and PersistentVolumeClaims serve configuration and storage purposes. ClusterRole is therefore an important component for defining broader Kubernetes access permissions.<\/span><\/p>\n<h3><b>Question 334<\/b><\/h3>\n<p><b>What is the primary purpose of a RoleBinding in Kubernetes RBAC?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To connect a Role or ClusterRole to subjects such as users or ServiceAccounts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To create a new Kubernetes node<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To allocate persistent storage<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To expose a Deployment externally<\/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 RoleBinding grants the permissions defined by a Role or ClusterRole to specified subjects such as users, groups, or ServiceAccounts within the RoleBinding&#8217;s Namespace scope. This separation between defining permissions and assigning permissions makes RBAC flexible. A Role describes what actions are permitted, while the RoleBinding identifies who receives those permissions. RoleBindings do not create nodes, allocate persistent storage, or expose applications. They are a key part of implementing least-privilege access within Kubernetes environments.<\/span><\/p>\n<h3><b>Question 335<\/b><\/h3>\n<p><b>Which Kubernetes object provides an identity that Pods can use when interacting with the Kubernetes API?<\/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;\">ServiceAccount<\/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;\">PersistentVolume<\/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 ServiceAccount provides an identity for processes running inside Pods when they need to interact with the Kubernetes API. RBAC permissions can be associated with the ServiceAccount to control what actions the workload is allowed to perform. This allows administrators to give applications only the permissions they require instead of relying on broad access. Services provide network access to Pods, ConfigMaps store non-sensitive configuration, and PersistentVolumes provide storage. ServiceAccounts therefore play an important role in workload identity and Kubernetes API access control.<\/span><\/p>\n<h3><b>Question 336<\/b><\/h3>\n<p><b>What does a default-deny ingress NetworkPolicy generally accomplish?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Allows all incoming traffic<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Blocks selected DNS queries only<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Denies incoming traffic unless another policy permits it<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Deletes incoming Pods<\/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 default-deny ingress NetworkPolicy can restrict incoming traffic to Pods so that traffic is not permitted unless another applicable NetworkPolicy allows it. This approach can provide a strong baseline for network isolation. Administrators can then explicitly define the required communication paths between workloads. NetworkPolicies depend on a compatible networking implementation that supports policy enforcement. A default-deny policy does not delete Pods or affect Kubernetes object existence. It controls network traffic according to the policy rules applied to selected Pods.<\/span><\/p>\n<h3><b>Question 337<\/b><\/h3>\n<p><b>Which NetworkPolicy direction controls traffic leaving selected Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Egress<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ingress<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Scheduling<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Admission<\/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;\">Egress refers to network traffic leaving Pods. A NetworkPolicy can specify egress rules to control which destinations selected Pods are allowed to communicate with. Ingress refers to traffic entering selected Pods. Egress policies can be useful when applications should only connect to approved databases, APIs, DNS services, or other destinations. NetworkPolicy enforcement depends on the cluster&#8217;s network plugin supporting the required policy functionality. Scheduling and admission are separate Kubernetes mechanisms and do not describe the direction of Pod network traffic.<\/span><\/p>\n<h3><b>Question 338<\/b><\/h3>\n<p><b>Which Kubernetes component commonly provides DNS-based service discovery inside a cluster?<\/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;\">etcd<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">CoreDNS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-scheduler<\/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;\">CoreDNS commonly provides DNS-based service discovery within Kubernetes clusters. It allows workloads to resolve Kubernetes Service names into addresses that can be used for communication. This means applications can generally communicate using stable DNS names rather than depending on individual Pod IP addresses, which can change when Pods are recreated. The kubelet manages node workloads, etcd stores cluster state, and kube-scheduler assigns Pods to nodes. CoreDNS therefore provides an important networking service that helps applications discover Kubernetes Services.<\/span><\/p>\n<h3><b>Question 339<\/b><\/h3>\n<p><b>Which Kubernetes concept allows a custom API resource to be introduced into the cluster without modifying the Kubernetes core source code?<\/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;\">CustomResourceDefinition<\/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;\">LimitRange<\/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 CustomResourceDefinition, commonly called a CRD, allows Kubernetes administrators and developers to define new API resource types. Once a CRD is installed, users can create custom resources using the new kind. CRDs are widely used to extend Kubernetes APIs and are often combined with controllers or operators that implement behavior for those resources. ReplicaSets manage Pod replicas, ResourceQuotas control aggregate resource consumption, and LimitRanges define default or maximum resource constraints within a Namespace. CRDs therefore provide an extensibility mechanism for Kubernetes-based platforms.<\/span><\/p>\n<h3><b>Question 340<\/b><\/h3>\n<p><b>What is the primary role of an operator in a Kubernetes environment?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To replace the Kubernetes API server<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To provide only container image storage<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To implement domain-specific operational logic through controllers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">To act as a physical network switch<\/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;\">An operator extends Kubernetes with domain-specific operational knowledge, typically through custom resources and controllers. It can automate tasks such as deploying applications, managing configuration, performing backups, handling upgrades, or responding to application-specific events. Operators commonly use the Kubernetes reconciliation pattern to compare desired and actual states and take corrective actions. They do not replace the API server or act as physical network devices. By combining Kubernetes extensibility mechanisms with controller logic, operators can automate complex operational workflows within the cluster.<\/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 321 Which Kubernetes object is used to store non-sensitive configuration data separately from application container images? Secret ConfigMap PersistentVolume ServiceAccount Correct Answer: 2 Explanation A ConfigMap stores non-sensitive configuration data separately from application container images. It can contain values such as application [&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\/17224"}],"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=17224"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17224\/revisions"}],"predecessor-version":[{"id":17225,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17224\/revisions\/17225"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17224"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17224"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17224"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}