{"id":21067,"date":"2026-09-24T10:34:28","date_gmt":"2026-09-24T10:34:28","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21067"},"modified":"2026-09-24T10:34:28","modified_gmt":"2026-09-24T10:34:28","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part7-q121-140","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part7-q121-140\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part7 Q121-140"},"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 121<\/b><\/h3>\n<p><b>Which field makes a container execute a custom startup command?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">args<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">entrypoint<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">startupCommand<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">command<\/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;\">The command field in a Kubernetes container specification overrides the image&#8217;s default executable. It is commonly used when a workload needs to start with a different process or command than the one defined by the container image. The args field supplies arguments to that command. Kubernetes separates these concepts so administrators can independently control the executable and its parameters. Understanding the distinction is useful when troubleshooting containers that start with unexpected processes or immediately terminate because their startup behavior differs from what the application requires.<\/span><\/p>\n<h3><b>Question 122<\/b><\/h3>\n<p><b>Which volume type combines data from multiple volume sources?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">hostPath<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">projected<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">emptyDir<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">downwardAPI<\/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 projected volume allows several existing volume sources to be presented together through a single directory inside a container. Supported sources can include ConfigMaps, Secrets, downward API information, and service account data. This is useful when an application expects related configuration or metadata under one filesystem location. Instead of mounting each source independently, administrators can combine them into a projected volume definition. The underlying data remains managed by its respective Kubernetes resources while the container receives a unified filesystem view.<\/span><\/p>\n<h3><b>Question 123<\/b><\/h3>\n<p><b>Which command creates a new Kubernetes namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl create namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl add namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl make namespace<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl init 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;\">The kubectl create namespace command creates a namespace directly from the command line. Namespaces provide logical separation for resources within a Kubernetes cluster and can be used to organize workloads, apply quotas, and manage access boundaries. For example, an administrator can create a dedicated namespace for a development workload before deploying its resources. After creation, resources can be targeted using the namespace option or by specifying namespace metadata in manifests. Namespaces are particularly useful in multi-team or multi-environment clusters.<\/span><\/p>\n<h3><b>Question 124<\/b><\/h3>\n<p><b>Which Pod field selects a specific node by its label?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">nodeAffinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">nodeName<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">nodeSelector<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">targetNode<\/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 nodeSelector field provides a straightforward way to constrain a Pod to nodes carrying specified labels. Kubernetes schedules the Pod only onto nodes whose labels satisfy the selector. This is useful for simple placement requirements such as choosing nodes with a particular hardware type or operating-system label. More complex placement rules can use node affinity. nodeSelector is therefore a convenient mechanism when the scheduling requirement is based on a direct label match rather than a more sophisticated expression.<\/span><\/p>\n<h3><b>Question 125<\/b><\/h3>\n<p><b>Which Service type exposes an application through each node&#8217;s IP and port?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterIP<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ExternalName<\/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;\">NodePort<\/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 NodePort Service exposes a Service on a static port across the nodes in the cluster. Clients can access the application using a node address together with the assigned NodePort. Kubernetes also maintains the Service abstraction and routes traffic toward suitable backend endpoints. NodePort is commonly used when external access is required without directly configuring a cloud load balancer. The actual port is allocated from the configured NodePort range unless an administrator explicitly specifies a valid value.<\/span><\/p>\n<h3><b>Question 126<\/b><\/h3>\n<p><b>Which resource stores information about a Kubernetes object&#8217;s creator and ownership relationships?<\/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;\">status<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">data<\/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 metadata section contains identifying and organizational information about Kubernetes objects. It can include names, namespaces, labels, annotations, owner references, and other metadata fields. Owner references are particularly important for controller-managed resources because they establish relationships between objects. Kubernetes can use these relationships during garbage collection when an owning object is removed. The spec describes the desired configuration, while status represents observed state. Understanding metadata is therefore essential when inspecting relationships and object identity.<\/span><\/p>\n<h3><b>Question 127<\/b><\/h3>\n<p><b>Which setting controls whether a failed container is restarted automatically?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">restartPolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">failurePolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">recoveryMode<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">restartStrategy<\/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 Pod restartPolicy controls how containers are restarted when they terminate. Common values include Always, OnFailure, and Never, with behavior depending on the workload type and Pod configuration. Deployments normally use the default Always behavior for their Pods, while Jobs commonly use OnFailure or Never. This setting concerns restarting containers within the Pod rather than recreating the entire Pod through a controller. Choosing the appropriate policy helps Kubernetes handle workloads according to their expected lifecycle.<\/span><\/p>\n<h3><b>Question 128<\/b><\/h3>\n<p><b>Which Kubernetes object assigns a numeric priority to Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PriorityPolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PriorityClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PodPriority<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">SchedulingClass<\/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 PriorityClass defines a priority value that can be associated with Pods. The scheduler can use Pod priority when making scheduling and preemption decisions. Higher-priority workloads may receive preferential treatment when cluster resources are constrained, including situations where lower-priority Pods can be preempted to make room. PriorityClass objects can also define whether the priority should be considered for preemption. Administrators should use meaningful priority levels because they influence scheduling behavior across workloads sharing the same cluster.<\/span><\/p>\n<h3><b>Question 129<\/b><\/h3>\n<p><b>Which command displays the API resources available in a cluster?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl api-list<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl resources<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl api-resources<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl show-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;\">The kubectl api-resources command lists the resource types available through the Kubernetes API server. Its output can show resource names, short names, API groups, whether resources are namespaced, and their associated kinds. This is useful when administrators need to discover the exact resource name accepted by kubectl commands. It can also help when working with unfamiliar custom resources installed through extensions. The command queries the API server rather than merely displaying locally remembered resource definitions.<\/span><\/p>\n<h3><b>Question 130<\/b><\/h3>\n<p><b>Which setting makes a Service reachable only inside the cluster by default?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterIP<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">InternalOnly<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PrivateIP<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LocalService<\/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;\">ClusterIP is the default Kubernetes Service type and provides a virtual IP reachable from within the cluster&#8217;s networking environment. It allows Pods and other internal clients to communicate with the selected backend Pods through a stable Service endpoint. ClusterIP does not normally expose the application directly to external clients. Other Service types, such as NodePort or LoadBalancer, provide additional exposure mechanisms. Internal Services are commonly used for communication between application tiers such as frontend, API, and database workloads.<\/span><\/p>\n<h3><b>Question 131<\/b><\/h3>\n<p><b>Which command removes a taint from a node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl taint nodes<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl untaint node<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl clear-taint<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl remove taint<\/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 taint nodes command can add or remove taints from Kubernetes nodes. To remove a specific taint, the taint key is followed by a trailing minus sign. This allows administrators to change node scheduling behavior without recreating the node. Removing a taint can make the node eligible for Pods that previously lacked the required toleration. Care should be taken because taints are often used deliberately to reserve nodes or protect specialized workloads from unsuitable scheduling.<\/span><\/p>\n<h3><b>Question 132<\/b><\/h3>\n<p><b>Which field defines environment variables from all keys in a ConfigMap?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">envConfig<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">envFrom<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">configEnv<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">mapEnvironment<\/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 envFrom field allows a container to import environment variables from an entire ConfigMap or Secret. Each eligible key becomes an environment variable inside the container, subject to Kubernetes naming requirements. This differs from the individual env configuration, where specific keys can be selected and assigned explicitly. Using envFrom can simplify manifests when an application needs many configuration values from the same source. Administrators should ensure that ConfigMap keys are suitable for use as environment variable names.<\/span><\/p>\n<h3><b>Question 133<\/b><\/h3>\n<p><b>Which storage resource requests capacity from a PersistentVolume system?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolumeClaim<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageRequest<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VolumeClaimSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentStorage<\/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 PersistentVolumeClaim, or PVC, represents a request for storage by a workload. It can specify requirements such as requested capacity, access modes, and a StorageClass. Kubernetes then attempts to bind the claim to a compatible PersistentVolume, either through an existing volume or dynamic provisioning. Applications normally reference the PVC rather than directly managing the underlying PersistentVolume. This separation allows storage administrators and application developers to work with storage through a consistent Kubernetes abstraction.<\/span><\/p>\n<h3><b>Question 134<\/b><\/h3>\n<p><b>Which admission feature can reject or modify API requests before persistence?<\/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;\">Admission controller<\/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;\">Admission controllers intercept requests after authentication and authorization but before the object is persisted by the API server. They can validate requests, apply policies, or modify objects depending on the configured controller. This provides an important control point for enforcing cluster-wide rules. Admission webhooks can also extend this behavior with custom validation or mutation logic. Admission control therefore operates at the API layer and is separate from node-level components such as kubelet or network components such as kube-proxy.<\/span><\/p>\n<h3><b>Question 135<\/b><\/h3>\n<p><b>Which Pod field requests a specific DNS resolution policy?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">dnsPolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">nameResolution<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">dnsMode<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">resolverPolicy<\/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 dnsPolicy field controls how DNS configuration is established for containers in a Pod. The default policy is typically ClusterFirst, which uses the cluster DNS service for Kubernetes service discovery while allowing other names to be resolved according to the configured environment. Other policies can be used for specialized networking scenarios. Correct DNS policy configuration matters when applications need to resolve internal Service names or when a Pod uses host networking and requires different DNS behavior.<\/span><\/p>\n<h3><b>Question 136<\/b><\/h3>\n<p><b>Which command shows all Pods across every namespace?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get pods &#8211;global<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get pods &#8211;all-namespaces<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl list pods &#8211;cluster<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl show pods &#8211;everywhere<\/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 get pods &#8211;all-namespaces command displays Pods from every namespace visible to the current Kubernetes credentials. This is useful when troubleshooting cluster-wide issues because a namespace-specific query may hide workloads running elsewhere. The commonly used short form is kubectl get pods -A. Administrators can use the output to identify unexpected workloads, compare Pod states across namespaces, or quickly determine whether an issue affects one namespace or a broader portion of the cluster.<\/span><\/p>\n<h3><b>Question 137<\/b><\/h3>\n<p><b>Which controller maintains one Pod on each eligible node?<\/b><\/p>\n<ol>\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;\">ReplicaSet<\/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;\">Deployment<\/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 Pod runs on each node matching its scheduling requirements. This makes DaemonSets useful for node-level services such as logging agents, monitoring collectors, and networking components. When a new eligible node joins the cluster, the DaemonSet controller can create the corresponding Pod there automatically. Conversely, when a node becomes ineligible or is removed, the associated DaemonSet workload is adjusted accordingly. Unlike a Deployment, its purpose is tied to node coverage rather than maintaining a general replica count.<\/span><\/p>\n<h3><b>Question 138<\/b><\/h3>\n<p><b>Which command validates the fields supported by a Kubernetes resource?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl inspect<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl schema<\/span><\/li>\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 fields<\/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 kubectl explain command displays documentation for Kubernetes resource fields and their structure. It is useful when creating or troubleshooting manifests because administrators can inspect which fields are available and understand their expected usage. For example, kubectl explain deployment.spec can provide information about the Deployment specification. This command queries the API schema available to kubectl and is especially valuable during CKA-style tasks where writing or modifying manifests quickly is required.<\/span><\/p>\n<h3><b>Question 139<\/b><\/h3>\n<p><b>Which scheduling mechanism can prevent two replicas sharing a node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Pod anti-affinity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">NodeSelector<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Pod priority<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/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;\">Pod anti-affinity allows administrators to express rules that discourage or prevent selected Pods from being scheduled near other Pods matching specified labels. A common use is distributing replicas across different nodes to reduce the impact of a single-node failure. Required anti-affinity can impose a hard placement restriction, while preferred rules express a scheduling preference. This differs from node selection, which targets node characteristics rather than relationships between workloads. Anti-affinity is therefore useful when workload distribution itself is part of the availability requirement.<\/span><\/p>\n<h3><b>Question 140<\/b><\/h3>\n<p><b>Which Kubernetes resource records events such as scheduling failures?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">EventLog<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterEvent<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Event<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ActivityRecord<\/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 Event resource records notable occurrences involving cluster objects. Events can describe scheduling failures, image-pull problems, container lifecycle changes, and other operational conditions. Administrators commonly inspect them while troubleshooting with commands such as kubectl get events or through object descriptions. Events are especially useful because they provide contextual information about what Kubernetes observed and attempted. They are not intended to replace comprehensive application or audit logging, but they provide valuable short-term diagnostic information about cluster activity.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full CNCF CKA Exam Dumps and Practice Test Dumps &nbsp; Question 121 Which field makes a container execute a custom startup command? args entrypoint startupCommand command Correct Answer: 4 Explanation: The command field in a Kubernetes container specification overrides the image&#8217;s default executable. It is commonly used when a workload needs to start with [&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\/21067"}],"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=21067"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21067\/revisions"}],"predecessor-version":[{"id":21068,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21067\/revisions\/21068"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}