{"id":21091,"date":"2026-09-24T10:38:06","date_gmt":"2026-09-24T10:38:06","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21091"},"modified":"2026-09-24T10:38:06","modified_gmt":"2026-09-24T10:38:06","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part19-q361-380","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part19-q361-380\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part19 Q361-380"},"content":{"rendered":"<h2><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/cka-exam-dumps\"><b>CNCF CKA Exam Dumps<\/b><\/a><b> and Practice Test Dumps<\/b><\/h2>\n<p>&nbsp;<\/p>\n<h3><b>Question 361<\/b><\/h3>\n<p><b>Which CoreDNS file defines its plugin configuration?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Corefile<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DNSConfig<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResolverFile<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ServerConfig<\/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 CoreDNS Corefile defines how the DNS server operates through its configured plugins and directives. In Kubernetes, the Corefile is commonly stored in a ConfigMap named coredns within the kube-system namespace. It can specify Kubernetes service discovery, forwarding, caching, health checks, metrics, and other DNS behavior. When cluster DNS stops resolving names correctly, inspecting the CoreDNS ConfigMap and its Corefile is an important troubleshooting step. Configuration changes may require the CoreDNS Pods to reload or restart depending on the modification and deployment setup.<\/span><\/p>\n<h3><b>Question 362<\/b><\/h3>\n<p><b>Which CoreDNS plugin provides Kubernetes service discovery?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">forward<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubernetes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">resolver<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">serviceDNS<\/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 kubernetes CoreDNS plugin provides DNS responses based on Kubernetes Services and Pods. It watches Kubernetes API information and creates DNS records that allow workloads to resolve internal service names. This plugin is central to normal cluster DNS functionality. If Services cannot be resolved from Pods, administrators should inspect CoreDNS health, its configuration, and connectivity to the Kubernetes API. The forward plugin serves a different purpose by sending queries outside the Kubernetes domain to configured upstream resolvers.<\/span><\/p>\n<h3><b>Question 363<\/b><\/h3>\n<p><b>Which CoreDNS plugin forwards external DNS queries?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">external<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">proxy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">forward<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">upstreamDNS<\/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 forward plugin sends DNS queries to specified upstream resolvers. In a typical Kubernetes Corefile, queries outside the cluster&#8217;s configured DNS zones can be forwarded using the node&#8217;s resolver configuration or explicitly defined nameservers. This allows Pods to resolve external domains while CoreDNS continues handling Kubernetes service discovery internally. When external names fail but internal Service names work, administrators can inspect the forwarding configuration and upstream DNS connectivity. This helps separate cluster DNS problems from external resolver issues.<\/span><\/p>\n<h3><b>Question 364<\/b><\/h3>\n<p><b>Which Kubernetes object exposes a stable network endpoint?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">EndpointSlice<\/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;\">NetworkAttachment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RouteMap<\/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 Kubernetes Service provides a stable network endpoint for a group of backend Pods. Pods can be replaced, recreated, or moved between nodes while the Service maintains a consistent virtual endpoint. The Service selects backend Pods using labels and works with Kubernetes networking components to route traffic toward available endpoints. EndpointSlice objects provide the backend endpoint information used by the Service system, but they are not normally the client-facing abstraction. When a Service fails, administrators should inspect selectors, EndpointSlices, ports, and network connectivity.<\/span><\/p>\n<h3><b>Question 365<\/b><\/h3>\n<p><b>Which object stores current Service backend endpoints?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">EndpointSlice<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">BackendSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ServiceTargets<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PodRoutes<\/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;\">EndpointSlice objects contain information about the network endpoints associated with a Service. Kubernetes automatically manages EndpointSlices as backend Pods become available or unavailable. They provide a scalable replacement for the older Endpoints representation and can efficiently represent large numbers of backend endpoints. When a Service has no working backends, examining its EndpointSlices can reveal whether the selector is finding the expected Pods. Administrators should also verify that backend Pods are Ready and that their ports correspond to the Service configuration.<\/span><\/p>\n<h3><b>Question 366<\/b><\/h3>\n<p><b>Which Service type exposes an application using an external load balancer?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PublicEndpoint<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NodePort<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LoadBalancer<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ExternalService<\/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 LoadBalancer Service type requests an externally accessible load-balancing mechanism from an environment that supports it. In cloud environments, the platform&#8217;s integration commonly provisions or configures an external load balancer and assigns an externally reachable address. The Service still provides the Kubernetes abstraction for routing traffic to backend Pods. Availability and behavior depend on the cluster environment and its load-balancer implementation. Administrators troubleshooting a LoadBalancer Service should inspect its status, events, assigned address, backend endpoints, and cloud-provider integration.<\/span><\/p>\n<h3><b>Question 367<\/b><\/h3>\n<p><b>Which Service type exposes a port on every node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterPort<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NodePort<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">HostService<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NodeExpose<\/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 NodePort Service exposes the selected application through a designated port on each node&#8217;s network address. Incoming traffic directed to that node port can be forwarded toward the Service&#8217;s backend Pods. NodePort is useful when external infrastructure needs to reach a Kubernetes Service through node addresses, although it does not itself provide a cloud load balancer. When troubleshooting NodePort access, administrators should verify the assigned port, node reachability, Service endpoints, firewall rules, and the application&#8217;s target port.<\/span><\/p>\n<h3><b>Question 368<\/b><\/h3>\n<p><b>Which Gateway API resource identifies the controller implementation?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">GatewayClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">GatewayController<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">TrafficClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RouteClass<\/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;\">GatewayClass identifies a class of Gateway infrastructure and specifies the controller responsible for managing Gateways of that class. A Gateway references a GatewayClass to indicate which implementation should manage it. This separates infrastructure configuration from individual traffic-routing resources. If a Gateway remains unprogrammed or does not receive the expected status, administrators should verify that its GatewayClass exists and that the referenced controller implementation is installed and functioning. GatewayClass is therefore an important part of the Gateway API resource hierarchy.<\/span><\/p>\n<h3><b>Question 369<\/b><\/h3>\n<p><b>Which Gateway API resource defines an HTTP routing rule?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">WebRoute<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">HTTPRoute<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">HTTPMapping<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RouteRule<\/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;\">HTTPRoute defines HTTP-specific routing rules within the Gateway API. It can describe how HTTP requests are matched and directed toward backend Services. Rules can support characteristics such as hostnames, paths, headers, and traffic behavior depending on the supported API features. An HTTPRoute is associated with a Gateway rather than directly replacing the role of a Service. When HTTP traffic is not reaching an application, administrators should inspect the Gateway, its listeners, HTTPRoute status, parent references, and backend Service configuration.<\/span><\/p>\n<h3><b>Question 370<\/b><\/h3>\n<p><b>Which Gateway API resource represents the traffic-handling infrastructure?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">TrafficGateway<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gateway<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NetworkGatewaySpec<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RouteGateway<\/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 Gateway resource represents an instance of traffic-handling infrastructure in the Gateway API. It defines listeners and provides the entry point through which configured routes can direct traffic toward backend Services. A Gateway references a GatewayClass that determines which controller manages it. Routes such as HTTPRoute can then attach to the Gateway according to its listener and attachment rules. This separation allows infrastructure responsibilities and application routing responsibilities to be represented by different Kubernetes resources.<\/span><\/p>\n<h3><b>Question 371<\/b><\/h3>\n<p><b>Which NetworkPolicy field identifies selected Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">podSelector<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">targetPods<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">workloadSelector<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">endpointSelector<\/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 podSelector field identifies Pods to which a NetworkPolicy applies. Selectors can use labels to define the target group within the policy&#8217;s namespace. A NetworkPolicy can then control permitted ingress, egress, or both depending on its configuration. An empty Pod selector has special meaning and can select all Pods in the relevant namespace. When a policy unexpectedly blocks traffic, administrators should examine the selected Pods, policy types, allowed peers, and ports rather than assuming the policy affects every workload in the cluster.<\/span><\/p>\n<h3><b>Question 372<\/b><\/h3>\n<p><b>Which NetworkPolicy section defines permitted inbound traffic?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ingressRules<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">inbound<\/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;\">allowIngress<\/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 ingress section of a NetworkPolicy defines allowed inbound traffic for the selected Pods. Rules can specify permitted sources and destination ports. Once a Pod becomes isolated for ingress through NetworkPolicy, traffic must satisfy the applicable ingress rules to be accepted. Administrators troubleshooting blocked connections should examine both the policy selecting the destination Pod and the source restrictions specified in its ingress rules. NetworkPolicy enforcement depends on the cluster&#8217;s network implementation supporting the required policy functionality.<\/span><\/p>\n<h3><b>Question 373<\/b><\/h3>\n<p><b>Which NetworkPolicy section controls outbound traffic?<\/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;\">outboundRules<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">exitTraffic<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">networkExit<\/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 egress section defines permitted outbound traffic from Pods selected by a NetworkPolicy. Rules can restrict destinations and ports, allowing administrators to limit which external or internal services a workload can contact. If a Pod suddenly cannot reach another Service or external address, an egress policy may be responsible. Troubleshooting should include identifying all policies selecting the source Pod and checking whether the destination and port satisfy the configured rules. NetworkPolicy behavior also depends on the capabilities of the installed network plugin.<\/span><\/p>\n<h3><b>Question 374<\/b><\/h3>\n<p><b>Which DNS name resolves a Service within its namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">service.cluster<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">service.localhost<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">service.namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">service.namespace.svc<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Kubernetes Service can be addressed using a DNS name containing its Service name, namespace, and svc DNS domain component. The resulting name follows the Kubernetes service-discovery structure and can be resolved by CoreDNS. Fully qualified names can include the cluster domain suffix as well. Using the namespace component allows workloads to distinguish Services with identical names that exist in different namespaces. When DNS resolution fails, administrators should verify the Service, namespace, CoreDNS configuration, and the Pod&#8217;s DNS settings.<\/span><\/p>\n<h3><b>Question 375<\/b><\/h3>\n<p><b>Which DNS record type is commonly used for Service port discovery?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PTR<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">SRV<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">MX<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">TXT<\/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;\">SRV records provide information about services and their associated ports. Kubernetes DNS can create SRV records for named Service ports, allowing applications to discover both service targets and port information through DNS. This is particularly useful for protocols or applications that need more than a simple address lookup. By comparison, A and AAAA records provide address information, while PTR records support reverse lookups. When an application expects service discovery through SRV records, administrators should verify that the relevant Service port is named correctly.<\/span><\/p>\n<h3><b>Question 376<\/b><\/h3>\n<p><b>Which command queries DNS from inside a temporary Pod?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl dns-test<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl resolve<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl run<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl dnscheck<\/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;\">kubectl run can create a temporary Pod that is useful for performing network and DNS troubleshooting from inside the cluster. Administrators commonly start a small diagnostic container and use commands such as nslookup or dig inside it to test DNS resolution. This approach is valuable because it tests DNS from the same network environment experienced by normal workloads. If a lookup fails inside the diagnostic Pod, administrators can then investigate CoreDNS, the Pod&#8217;s resolver configuration, Services, and network connectivity.<\/span><\/p>\n<h3><b>Question 377<\/b><\/h3>\n<p><b>Which kubeadm directory contains static control-plane manifests?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\/etc\/kubernetes\/manifests<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\/var\/kube\/static<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\/opt\/kubernetes\/control<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\/etc\/kube\/control-plane<\/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;\">On kubeadm-managed control-plane nodes, static Pod manifests for components such as the API server, scheduler, controller manager, and etcd are stored under \/etc\/kubernetes\/manifests. The kubelet monitors this directory and manages the corresponding static Pods. Changing an appropriate manifest can therefore affect the associated control-plane component. Administrators troubleshooting control-plane startup should inspect these files along with kubelet logs and Pod status. Careful editing is essential because invalid manifests can prevent critical control-plane components from starting.<\/span><\/p>\n<h3><b>Question 378<\/b><\/h3>\n<p><b>Which kubeadm command upgrades a control-plane node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm update<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm upgrade node<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm upgrade apply<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm cluster-upgrade<\/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;\">kubeadm upgrade apply performs a control-plane upgrade to the specified Kubernetes version on the node where the command is executed. It handles kubeadm&#8217;s upgrade workflow and updates control-plane-related configuration as required. In a multi-node cluster, worker-node upgrade procedures are handled separately. Administrators should verify version compatibility and follow the appropriate upgrade sequence rather than changing component versions independently. During troubleshooting, kubeadm configuration and control-plane manifest changes should also be reviewed if an upgrade does not produce the expected component versions.<\/span><\/p>\n<h3><b>Question 379<\/b><\/h3>\n<p><b>Which kubeadm command removes cluster configuration from a node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm purge<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm reset<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm clear<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubeadm remove-cluster<\/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;\">kubeadm reset reverses changes made by kubeadm on a node as part of cluster initialization or joining. It is commonly used when a node needs to be cleaned before being reused or reconfigured. The command should not be confused with deleting an individual Kubernetes workload. Administrators should understand that resetting a node is a significant operation and may require additional cleanup depending on the networking, storage, and runtime configuration present on that machine. It is normally performed deliberately rather than as a routine troubleshooting command.<\/span><\/p>\n<h3><b>Question 380<\/b><\/h3>\n<p><b>Which Kubernetes component assigns Pods to suitable nodes?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-controller<\/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;\">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-scheduler selects suitable nodes for Pods that have not yet been assigned to a node. It evaluates scheduling requirements such as resource availability, affinity rules, taints and tolerations, topology constraints, and other scheduling conditions. Once a suitable placement is determined, the scheduler records the assignment, after which kubelet on the selected node handles Pod execution. If Pods remain Pending, administrators should inspect Pod events and scheduling messages to identify constraints that prevent placement.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full CNCF CKA Exam Dumps and Practice Test Dumps &nbsp; Question 361 Which CoreDNS file defines its plugin configuration? Corefile DNSConfig ResolverFile ServerConfig Correct Answer: 1 Explanation: The CoreDNS Corefile defines how the DNS server operates through its configured plugins and directives. In Kubernetes, the Corefile is commonly stored in a ConfigMap named coredns [&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\/21091"}],"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=21091"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21091\/revisions"}],"predecessor-version":[{"id":21092,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21091\/revisions\/21092"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21091"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21091"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21091"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}