{"id":21071,"date":"2026-09-24T10:35:03","date_gmt":"2026-09-24T10:35:03","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21071"},"modified":"2026-09-24T10:35:03","modified_gmt":"2026-09-24T10:35:03","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part9-q161-180","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part9-q161-180\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part9 Q161-180"},"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 161<\/b><\/h3>\n<p><b>Which command safely evicts eligible Pods from a node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl evacuate<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl drain<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl relocate<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl migrate<\/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 kubectl drain command prepares a node for maintenance by marking it unschedulable and attempting to evict eligible Pods. It is commonly used before rebooting, upgrading, or servicing a node. Pods managed by controllers can usually be recreated on other suitable nodes. Certain workloads, local storage, or unmanaged Pods may require additional flags or manual handling. Draining differs from cordoning because cordon only prevents new scheduling, while drain also attempts to remove existing workloads safely according to Kubernetes eviction rules.<\/span><\/p>\n<h3><b>Question 162<\/b><\/h3>\n<p><b>Which Kubernetes mechanism stores cluster state persistently?<\/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;\">kube-proxy<\/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: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">etcd is the distributed key-value store used by Kubernetes to persist cluster state. Kubernetes API objects and configuration information are stored through the API server in etcd. The API server provides controlled access to this data rather than allowing ordinary clients to communicate with etcd directly. Because etcd contains critical cluster information, its availability and data protection are important for control-plane reliability. Backup and recovery procedures for etcd are therefore significant administrative tasks when maintaining Kubernetes clusters.<\/span><\/p>\n<h3><b>Question 163<\/b><\/h3>\n<p><b>Which field identifies the desired number of Deployment replicas?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">spec.replicas<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">status.count<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">metadata.replicas<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">spec.instances<\/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 spec.replicas field defines the desired number of Pods for a Deployment. The Deployment controller works with its ReplicaSet to maintain that requested count. If Pods disappear or become unavailable for reasons that trigger replacement, the controllers attempt to restore the desired state. The status section instead reports observed information rather than defining the requested configuration. Administrators frequently modify spec.replicas when scaling workloads manually, while an autoscaler can also adjust this value according to its scaling logic.<\/span><\/p>\n<h3><b>Question 164<\/b><\/h3>\n<p><b>Which control-plane component exposes the Kubernetes API?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">etcd<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-apiserver<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kube-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;\">The kube-apiserver is the central component that exposes the Kubernetes API. Clients such as kubectl communicate with the API server to create, retrieve, modify, and delete Kubernetes resources. The API server also handles authentication, authorization, admission processing, and coordination with storage such as etcd. Other control-plane components communicate with the API server as well. Because it serves as the primary interface to cluster state, API server availability is essential for administrative operations and controller activity.<\/span><\/p>\n<h3><b>Question 165<\/b><\/h3>\n<p><b>Which resource enables automatic storage creation for a PVC?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VolumeTemplate<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StoragePolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ProvisioningConfig<\/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 StorageClass provides the information Kubernetes needs for dynamic storage provisioning. When a PersistentVolumeClaim requests a suitable StorageClass, the configured provisioner can create storage automatically instead of requiring an administrator to create a PersistentVolume beforehand. StorageClass parameters can describe backend-specific characteristics such as performance tiers or filesystem settings. This abstraction allows application manifests to request storage without embedding detailed infrastructure provisioning procedures directly into the workload definition.<\/span><\/p>\n<h3><b>Question 166<\/b><\/h3>\n<p><b>Which Linux service commonly manages kubelet startup on systemd nodes?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">containerd<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">systemd<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">crictl<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">journalctl<\/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;\">On Linux distributions using systemd, the kubelet is commonly managed as a systemd service. Administrators can use commands such as systemctl status kubelet, systemctl restart kubelet, and systemctl enable kubelet to inspect or manage its service state. The container runtime has a different responsibility because it runs containers rather than supervising the kubelet process. Understanding the service manager is useful during node troubleshooting, particularly when the kubelet fails to start or requires a configuration change followed by a restart.<\/span><\/p>\n<h3><b>Question 167<\/b><\/h3>\n<p><b>Which object can expose a custom application metric to HPA?<\/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;\">ServiceAccount<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Custom metrics API<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageClass<\/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 HorizontalPodAutoscaler can use custom metrics when the cluster provides an appropriate custom metrics API implementation. This allows scaling decisions to be based on application-specific measurements rather than only standard CPU or memory metrics. Examples might include request rates, queue depth, or another workload-specific measurement. The metrics infrastructure must expose the required metric in a form that HPA can query. This gives administrators greater flexibility when resource consumption alone does not accurately represent application demand.<\/span><\/p>\n<h3><b>Question 168<\/b><\/h3>\n<p><b>Which Service feature preserves client source IP in supported configurations?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">sessionAffinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">internalTrafficPolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">externalTrafficPolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">sourcePolicy<\/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 externalTrafficPolicy setting can influence how externally received Service traffic is handled and whether the original client source IP is preserved. With appropriate configuration, Local can preserve source addresses by routing traffic only to endpoints on the receiving node. This can be important for applications that rely on client IP information for logging, access control, or auditing. The behavior depends on the Service exposure method and networking implementation, so administrators should consider traffic routing and endpoint distribution when configuring it.<\/span><\/p>\n<h3><b>Question 169<\/b><\/h3>\n<p><b>Which command retrieves a resource definition in YAML format?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl show<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl export<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl dump<\/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 get command can display a resource in YAML format by using the -o yaml output option. For example, kubectl get pod example -o yaml returns the complete object representation available through the API. This is useful for inspecting fields, troubleshooting configuration, and preparing manifests based on existing objects. Administrators should distinguish the live object representation from a clean declarative manifest because generated metadata and runtime status may also appear in the YAML output.<\/span><\/p>\n<h3><b>Question 170<\/b><\/h3>\n<p><b>Which probe determines whether an application process is alive?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Readiness probe<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Startup probe<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Liveness probe<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Availability probe<\/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 liveness probe determines whether a container should be considered alive and functioning. If repeated liveness checks fail according to the configured thresholds, the kubelet can restart the affected container. This differs from readiness checks, which control whether the workload receives Service traffic. Startup probes provide additional protection for applications that need considerable initialization time. A correctly configured liveness probe should identify genuine application failure without causing unnecessary restarts during normal startup or temporary delays.<\/span><\/p>\n<h3><b>Question 171<\/b><\/h3>\n<p><b>Which command can create a temporary debugging Pod?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl debug<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl troubleshoot<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl inspect-pod<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl diagnose<\/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 debug command provides mechanisms for creating debugging containers or Pods to investigate runtime problems. It can be useful when an application image lacks troubleshooting utilities or when an administrator needs a temporary environment for diagnostics. Depending on the debugging scenario, the command can target a workload, node, or existing Pod. This makes it particularly valuable during practical Kubernetes administration tasks where direct inspection with the original application image is insufficient.<\/span><\/p>\n<h3><b>Question 172<\/b><\/h3>\n<p><b>Which object controls authentication credentials for workload API access?<\/b><\/p>\n<ol>\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;\">ServiceAccount<\/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;\">EndpointSlice<\/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 then be assigned to that ServiceAccount through RoleBindings or ClusterRoleBindings. This separates workload identity from human user identities and allows administrators to grant only the permissions an application requires. ServiceAccounts are therefore an important component of workload authentication and authorization within Kubernetes clusters.<\/span><\/p>\n<h3><b>Question 173<\/b><\/h3>\n<p><b>Which field specifies the container image registry path?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">containerImage<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">registryPath<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">image<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">imageSource<\/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 image field in a container specification identifies the container image that Kubernetes should run. It can include a registry address, repository, image name, and tag or digest. For example, an image reference can point to a private registry rather than a public default registry. The container runtime uses this reference when obtaining the image. Correct image naming is essential because an invalid repository, tag, registry address, or authentication configuration can prevent a container from starting.<\/span><\/p>\n<h3><b>Question 174<\/b><\/h3>\n<p><b>Which object represents a non-namespaced cluster node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Node<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">WorkerGroup<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterHost<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ComputeUnit<\/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 Node represents a machine that participates in a Kubernetes cluster and provides compute capacity for workloads. Nodes are cluster-scoped resources rather than namespaced objects. Each node typically runs components such as kubelet and a container runtime, with networking components also present depending on the cluster configuration. Administrators can inspect nodes for capacity, conditions, labels, taints, and other scheduling information. Because Nodes are not confined to namespaces, namespace-level resource boundaries do not directly scope the node object itself.<\/span><\/p>\n<h3><b>Question 175<\/b><\/h3>\n<p><b>Which scheduling rule expresses a preferred placement rather than a requirement?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Required node affinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Preferred node affinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Mandatory topology rule<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Hard node selector<\/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;\">Preferred node affinity expresses a scheduling preference rather than an absolute requirement. The scheduler attempts to place the Pod on nodes satisfying the preferred rule but can select another suitable node if the preference cannot be met. Required node affinity, in contrast, establishes a hard scheduling condition that must be satisfied. Preferred rules are useful when administrators want workloads distributed toward desirable node characteristics without risking indefinite Pending status when those characteristics are temporarily unavailable.<\/span><\/p>\n<h3><b>Question 176<\/b><\/h3>\n<p><b>Which command shows labels assigned to Kubernetes resources?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl metadata<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get &#8211;show-labels<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl display-labels<\/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 &#8211;show-labels option with kubectl get displays labels alongside resource information. Labels are key-value metadata used extensively for selecting and organizing Kubernetes objects. Services, Deployments, NetworkPolicies, and other resources can use selectors to identify matching Pods. Viewing labels is therefore a useful troubleshooting technique when a Service has unexpected endpoints or a controller is not managing the intended Pods. Accurate label and selector relationships are essential for many Kubernetes workloads.<\/span><\/p>\n<h3><b>Question 177<\/b><\/h3>\n<p><b>Which object defines a network rule controlling Pod traffic?<\/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;\">TrafficRule<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PodFirewall<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NetworkACL<\/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 governing network traffic to or from selected Pods. Policies can control ingress, egress, or both, depending on their configuration and the capabilities of the installed network plugin. A policy can select Pods using labels and then specify permitted traffic sources, destinations, ports, and protocols. NetworkPolicy behavior depends on a compatible networking implementation. Administrators should therefore verify that the cluster&#8217;s CNI implementation supports and enforces the desired policy rules.<\/span><\/p>\n<h3><b>Question 178<\/b><\/h3>\n<p><b>Which command prints the current resource definitions stored by kubectl?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config dump<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config view<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config inspect<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config show-all<\/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 kubectl config view command displays the contents of the kubeconfig configuration used by kubectl. It can show configured clusters, users, contexts, and related settings. Administrators can combine it with options such as &#8211;minify when they want information related to the currently selected context. This is useful when diagnosing authentication or cluster-targeting problems. Because kubeconfig can contain credential information, administrators should handle its output carefully and avoid unnecessarily exposing sensitive data.<\/span><\/p>\n<h3><b>Question 179<\/b><\/h3>\n<p><b>Which mechanism can automatically increase Pod replicas based on CPU usage?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cluster Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Vertical Pod Autoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">HorizontalPodAutoscaler<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Node Autoscaler<\/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 HorizontalPodAutoscaler can adjust the replica count of supported workloads based on observed metrics such as CPU utilization. When measured utilization moves above or below the configured target, the controller can increase or decrease the desired replica count within its configured boundaries. This differs from cluster-level autoscaling, which changes the number of nodes available for workloads. HPA therefore changes workload capacity rather than directly adding or removing worker machines.<\/span><\/p>\n<h3><b>Question 180<\/b><\/h3>\n<p><b>Which command shows the current API server and cluster services?<\/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 server-status<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl api-status<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl 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;\">The kubectl cluster-info command provides endpoint information for the Kubernetes control plane and available cluster services. It is a useful initial command when verifying that kubectl can communicate with the configured cluster. It does not replace deeper health checks, component logs, or node inspection, but it quickly confirms basic API connectivity and displays relevant service endpoints. Administrators can use it together with other diagnostic commands when investigating control-plane communication or cluster-access problems.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full CNCF CKA Exam Dumps and Practice Test Dumps &nbsp; Question 161 Which command safely evicts eligible Pods from a node? kubectl evacuate kubectl drain kubectl relocate kubectl migrate Correct Answer: 2 Explanation: The kubectl drain command prepares a node for maintenance by marking it unschedulable and attempting to evict eligible Pods. It is [&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\/21071"}],"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=21071"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21071\/revisions"}],"predecessor-version":[{"id":21072,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21071\/revisions\/21072"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21071"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21071"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21071"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}