{"id":21093,"date":"2026-09-24T10:38:20","date_gmt":"2026-09-24T10:38:20","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21093"},"modified":"2026-09-24T10:38:20","modified_gmt":"2026-09-24T10:38:20","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part20-q381-400","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part20-q381-400\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part20 Q381-400"},"content":{"rendered":"

View Full <\/b>CNCF CKA Exam Dumps<\/b><\/a> and Practice Test Dumps<\/b><\/h2>\n

 <\/p>\n

Question 381<\/b><\/h3>\n

Which scheduling rule requires Pods to prefer certain nodes?<\/b><\/p>\n

    \n
  1. nodePreference<\/span><\/li>\n
  2. nodeSelector<\/span><\/li>\n
  3. nodeAffinity<\/span><\/li>\n
  4. nodeRule<\/span><\/li>\n<\/ol>\n

    Correct Answer: 3<\/b><\/p>\n

    Explanation:<\/b><\/p>\n

    nodeAffinity provides more expressive node-selection rules than a simple nodeSelector. It can define required placement conditions as well as preferred conditions that influence scheduling without making them mandatory. This allows administrators to express requirements based on node labels while supporting more flexible scheduling behavior. For example, a workload can prefer nodes in a particular zone while still allowing placement elsewhere when necessary. Node affinity is evaluated by the scheduler as part of its scheduling process and works with other placement constraints.<\/span><\/p>\n

    Question 382<\/b><\/h3>\n

    Which taint effect blocks new Pod scheduling without a toleration?<\/b><\/p>\n

      \n
    1. NoSchedule<\/span><\/li>\n
    2. PreferNoSchedule<\/span><\/li>\n
    3. NoExecute<\/span><\/li>\n
    4. BlockSchedule<\/span><\/li>\n<\/ol>\n

      Correct Answer: 1<\/b><\/p>\n

      Explanation:<\/b><\/p>\n

      NoSchedule prevents new Pods from being scheduled onto a tainted node unless those Pods have a matching toleration. Existing Pods that are already running on the node are not automatically removed solely because the taint is added. This makes NoSchedule useful when administrators want to reserve nodes for particular workloads or prevent additional placement. Other taint effects behave differently: NoExecute can affect already-running Pods, while PreferNoSchedule expresses a softer scheduling preference rather than a strict prohibition.<\/span><\/p>\n

      Question 383<\/b><\/h3>\n

      Which taint effect can evict existing non-tolerating Pods?<\/b><\/p>\n

        \n
      1. NoSchedule<\/span><\/li>\n
      2. NoExecute<\/span><\/li>\n
      3. PreferNoSchedule<\/span><\/li>\n
      4. EvictExisting<\/span><\/li>\n<\/ol>\n

        Correct Answer: 2<\/b><\/p>\n

        Explanation:<\/b><\/p>\n

        The NoExecute taint effect can cause existing Pods that do not tolerate the taint to be removed from the node, in addition to preventing incompatible Pods from being scheduled there. Tolerations can optionally include a time limit through tolerationSeconds, allowing a Pod to remain for a defined period after the taint is applied. This behavior is commonly relevant during node problems or special maintenance conditions. Administrators should distinguish NoExecute from NoSchedule, which primarily affects future scheduling decisions.<\/span><\/p>\n

        Question 384<\/b><\/h3>\n

        Which resource assigns a numeric priority to Pods?<\/b><\/p>\n

          \n
        1. PodPriority<\/span><\/li>\n
        2. PriorityRule<\/span><\/li>\n
        3. PriorityClass<\/span><\/li>\n
        4. SchedulingClass<\/span><\/li>\n<\/ol>\n

          Correct Answer: 3<\/b><\/p>\n

          Explanation:<\/b><\/p>\n

          A PriorityClass defines a priority value that can be assigned to Pods. Higher-priority Pods can receive preferential treatment during scheduling and may participate in preemption when cluster resources are insufficient. The Pod references the desired PriorityClass through its priorityClassName field. Priority is distinct from resource requests: a high-priority Pod still needs suitable resources on a node. Administrators can use PriorityClasses to distinguish critical workloads from less important workloads while carefully considering the effects of preemption.<\/span><\/p>\n

          Question 385<\/b><\/h3>\n

          Which scheduler phase filters unsuitable nodes?<\/b><\/p>\n

            \n
          1. scoring<\/span><\/li>\n
          2. binding<\/span><\/li>\n
          3. filtering<\/span><\/li>\n
          4. selection<\/span><\/li>\n<\/ol>\n

            Correct Answer: 4<\/b><\/p>\n

            Explanation:<\/b><\/p>\n

            The scheduler’s filtering stage removes nodes that cannot satisfy a Pod’s scheduling requirements. Conditions such as resource availability, taints, node affinity, volume constraints, and other rules can cause a node to be filtered out. After filtering, remaining feasible nodes can proceed to scoring, where the scheduler evaluates preferences and ranks candidates. Understanding this distinction helps when diagnosing Pending Pods: if every node is filtered out, the Pod cannot proceed to the later scoring and binding stages.<\/span><\/p>\n

            Question 386<\/b><\/h3>\n

            Which scheduler phase ranks feasible nodes?<\/b><\/p>\n

              \n
            1. scoring<\/span><\/li>\n
            2. filtering<\/span><\/li>\n
            3. reservation<\/span><\/li>\n
            4. validation<\/span><\/li>\n<\/ol>\n

              Correct Answer: 1<\/b><\/p>\n

              Explanation:<\/b><\/p>\n

              After unsuitable nodes have been filtered, the scheduler’s scoring stage evaluates the remaining feasible nodes and assigns scores according to configured scheduling plugins and preferences. The scheduler can then select a node based on the resulting scores. Scoring therefore expresses preferences rather than basic eligibility. A node may satisfy all mandatory requirements yet receive a lower score than another suitable node. When investigating unexpected placement, administrators should distinguish mandatory filtering constraints from preference-based scoring decisions.<\/span><\/p>\n

              Question 387<\/b><\/h3>\n

              Which storage resource requests dynamically provisioned storage?<\/b><\/p>\n

                \n
              1. PersistentVolume<\/span><\/li>\n
              2. StorageRequest<\/span><\/li>\n
              3. PersistentVolumeClaim<\/span><\/li>\n
              4. VolumeClaimSet<\/span><\/li>\n<\/ol>\n

                Correct Answer: 3<\/b><\/p>\n

                Explanation:<\/b><\/p>\n

                A PersistentVolumeClaim requests storage for a workload. When dynamic provisioning is configured, the claim can cause Kubernetes to provision an appropriate PersistentVolume through a StorageClass. The claim specifies requirements such as requested capacity and access modes. Pods then reference the claim rather than directly managing the underlying storage implementation. If a PVC remains Pending, administrators should inspect its requested capacity, access modes, StorageClass, provisioner, and related events to determine why suitable storage has not been made available.<\/span><\/p>\n

                Question 388<\/b><\/h3>\n

                Which storage resource represents provisioned persistent storage?<\/b><\/p>\n

                  \n
                1. PersistentVolume<\/span><\/li>\n
                2. StorageVolume<\/span><\/li>\n
                3. VolumeResource<\/span><\/li>\n
                4. PersistentDisk<\/span><\/li>\n<\/ol>\n

                  Correct Answer: 1<\/b><\/p>\n

                  Explanation:<\/b><\/p>\n

                  A PersistentVolume represents storage available to the Kubernetes cluster for persistent use. It can be statically created by an administrator or dynamically provisioned through a StorageClass and storage driver. A PersistentVolume has properties such as capacity, access modes, reclaim policy, and storage source. Pods normally consume PersistentVolumes indirectly through PersistentVolumeClaims. When storage binding fails, administrators should compare the PVC requirements with the available PersistentVolumes and inspect storage-related events.<\/span><\/p>\n

                  Question 389<\/b><\/h3>\n

                  Which resource defines dynamic volume provisioning behavior?<\/b><\/p>\n

                    \n
                  1. VolumeProfile<\/span><\/li>\n
                  2. StorageClass<\/span><\/li>\n
                  3. ProvisionPolicy<\/span><\/li>\n
                  4. StorageTemplate<\/span><\/li>\n<\/ol>\n

                    Correct Answer: 2<\/b><\/p>\n

                    Explanation:<\/b><\/p>\n

                    A StorageClass defines parameters and provisioning behavior for dynamically created PersistentVolumes. It can identify a provisioner and provide implementation-specific parameters, reclaim behavior, and other storage settings. A PVC can request a StorageClass to obtain dynamically provisioned storage. Different StorageClasses can represent different performance characteristics or storage backends. When a claim cannot be dynamically provisioned, administrators should inspect the selected StorageClass, its provisioner, events, and the associated CSI components.<\/span><\/p>\n

                    Question 390<\/b><\/h3>\n

                    Which reclaim policy deletes dynamically provisioned storage resources?<\/b><\/p>\n

                      \n
                    1. Preserve<\/span><\/li>\n
                    2. Retain<\/span><\/li>\n
                    3. Delete<\/span><\/li>\n
                    4. Archive<\/span><\/li>\n<\/ol>\n

                      Correct Answer: 3<\/b><\/p>\n

                      Explanation:<\/b><\/p>\n

                      The Delete reclaim policy allows Kubernetes and the associated storage provisioner to remove the underlying storage when the PersistentVolume is released, according to the provisioner’s behavior. This is commonly used for dynamically provisioned volumes where the storage should not remain after its claim is removed. Retain has a different purpose: it preserves the volume and its associated storage for manual recovery or reuse. Administrators should choose reclaim policies carefully because deletion can result in permanent data loss.<\/span><\/p>\n

                      Question 391<\/b><\/h3>\n

                      Which access mode permits multiple nodes to read and write a volume?<\/b><\/p>\n

                        \n
                      1. ReadWriteMany<\/span><\/li>\n
                      2. SharedReadWrite<\/span><\/li>\n
                      3. MultiNodeWrite<\/span><\/li>\n
                      4. ClusterWrite<\/span><\/li>\n<\/ol>\n

                        Correct Answer: 1<\/b><\/p>\n

                        Explanation:<\/b><\/p>\n

                        ReadWriteMany, or RWX, allows a volume to be mounted as read-write by multiple nodes when the underlying storage implementation supports that access mode. This is useful for workloads that need shared writable storage across Pods running on different nodes. Not every storage backend supports RWX, so the access mode requested by a PVC must be compatible with the provisioned storage. Administrators should check the CSI driver’s capabilities and the StorageClass when a claim requesting shared writable access cannot be fulfilled.<\/span><\/p>\n

                        Question 392<\/b><\/h3>\n

                        Which volume type shares a directory from the node filesystem?<\/b><\/p>\n

                          \n
                        1. nodePath<\/span><\/li>\n
                        2. hostPath<\/span><\/li>\n
                        3. localDirectory<\/span><\/li>\n
                        4. filesystemPath<\/span><\/li>\n<\/ol>\n

                          Correct Answer: 2<\/b><\/p>\n

                          Explanation:<\/b><\/p>\n

                          The hostPath volume type mounts a file or directory from the node’s filesystem into a Pod. It can be useful for specialized node-level workloads that need access to host files, but it reduces workload isolation and can create portability concerns because the referenced path exists on the node rather than in portable cluster storage. Administrators should use hostPath carefully and understand the security implications. A workload depending on hostPath may also behave differently when scheduled onto another node where the expected path or data does not exist.<\/span><\/p>\n

                          Question 393<\/b><\/h3>\n

                          Which volume type stores data temporarily with the Pod lifecycle?<\/b><\/p>\n

                            \n
                          1. emptyDir<\/span><\/li>\n
                          2. tempVolume<\/span><\/li>\n
                          3. podStorage<\/span><\/li>\n
                          4. transientDir<\/span><\/li>\n<\/ol>\n

                            Correct Answer: 1<\/b><\/p>\n

                            Explanation:<\/b><\/p>\n

                            An emptyDir volume is created when a Pod is assigned to a node and provides temporary storage shared by containers within that Pod. The directory exists for the lifetime of the Pod on that node and is removed when the Pod is removed. It is useful for scratch data, temporary files, caching, or communication between containers. Because it is not persistent across Pod replacement, it should not be used when application data must survive the Pod lifecycle. Administrators should distinguish emptyDir from persistent storage backed by a PersistentVolume.<\/span><\/p>\n

                            Question 394<\/b><\/h3>\n

                            Which resource limits namespace-wide object consumption?<\/b><\/p>\n

                              \n
                            1. NamespaceLimit<\/span><\/li>\n
                            2. ResourceQuota<\/span><\/li>\n
                            3. ObjectQuota<\/span><\/li>\n
                            4. ClusterQuota<\/span><\/li>\n<\/ol>\n

                              Correct Answer: 4<\/b><\/p>\n

                              Explanation:<\/b><\/p>\n

                              A ResourceQuota limits aggregate resource consumption within a namespace. It can restrict quantities such as CPU, memory, storage, and counts of selected Kubernetes objects. Resource quotas help prevent one namespace or team from consuming an uncontrolled share of cluster resources. When a resource creation request is rejected because of quota, administrators can inspect the namespace’s ResourceQuota objects and current usage. Quotas operate at the namespace level and complement other controls such as LimitRanges.<\/span><\/p>\n

                              Question 395<\/b><\/h3>\n

                              Which object defines default resource requests for containers?<\/b><\/p>\n

                                \n
                              1. ResourceDefaults<\/span><\/li>\n
                              2. LimitRange<\/span><\/li>\n
                              3. ContainerPolicy<\/span><\/li>\n
                              4. NamespaceResources<\/span><\/li>\n<\/ol>\n

                                Correct Answer: 2<\/b><\/p>\n

                                Explanation:<\/b><\/p>\n

                                A LimitRange can define default CPU and memory requests or limits for containers in a namespace. It can also impose minimum and maximum resource constraints. This helps establish consistent resource behavior when users create Pods without explicitly specifying every resource value. ResourceQuota and LimitRange serve different purposes: a quota controls aggregate namespace consumption, while a LimitRange governs individual resource settings and defaults. When a Pod receives unexpected resource values, administrators should inspect the namespace’s LimitRange configuration.<\/span><\/p>\n

                                Question 396<\/b><\/h3>\n

                                Which Kubernetes object stores sensitive application values?<\/b><\/p>\n

                                  \n
                                1. ConfigMap<\/span><\/li>\n
                                2. Secret<\/span><\/li>\n
                                3. SecureMap<\/span><\/li>\n
                                4. CredentialSet<\/span><\/li>\n<\/ol>\n

                                  Correct Answer: 2<\/b><\/p>\n

                                  Explanation:<\/b><\/p>\n

                                  A Kubernetes Secret is designed to hold sensitive data such as passwords, tokens, or keys that applications may need. Secrets can be exposed to containers through environment variables or mounted as files. Although Secrets provide Kubernetes mechanisms for handling sensitive values, administrators should also configure appropriate access control and encryption protections because Secret data requires careful security management. A ConfigMap is intended for non-confidential configuration. When a workload cannot access a Secret, administrators should inspect the referenced Secret, namespace, key names, and Pod permissions.<\/span><\/p>\n

                                  Question 397<\/b><\/h3>\n

                                  Which API object records Pod scheduling and lifecycle events?<\/b><\/p>\n

                                    \n
                                  1. Event<\/span><\/li>\n
                                  2. ActivityLog<\/span><\/li>\n
                                  3. PodHistory<\/span><\/li>\n
                                  4. AuditRecord<\/span><\/li>\n<\/ol>\n

                                    Correct Answer: 1<\/b><\/p>\n

                                    Explanation:<\/b><\/p>\n

                                    An Event records information about notable occurrences involving Kubernetes resources. Events can reveal scheduling failures, image-pull problems, mounting errors, probe failures, and other operational conditions. They are especially useful during troubleshooting because they often explain why a resource is Pending or failing. Administrators can inspect events with kubectl commands and correlate their timestamps with workload behavior. Events are not intended to replace persistent application logs or audit records, and their retention is generally limited compared with long-term logging systems.<\/span><\/p>\n

                                    Question 398<\/b><\/h3>\n

                                    Which command displays recent events across all namespaces?<\/b><\/p>\n

                                      \n
                                    1. kubectl get events –global<\/span><\/li>\n
                                    2. kubectl events –all<\/span><\/li>\n
                                    3. kubectl get events -A<\/span><\/li>\n
                                    4. kubectl list events –cluster<\/span><\/li>\n<\/ol>\n

                                      Correct Answer: 3<\/b><\/p>\n

                                      Explanation:<\/b><\/p>\n

                                      kubectl get events -A retrieves Event objects across all namespaces. The -A option is the shorthand for –all-namespaces. This is useful when troubleshooting cluster-wide issues where the affected namespace is not immediately known. Administrators can inspect event reasons, involved objects, timestamps, and messages to identify problems such as scheduling failures or image-pull errors. Filtering or sorting the results can make large event sets easier to analyze during active troubleshooting.<\/span><\/p>\n

                                      Question 399<\/b><\/h3>\n

                                      Which command shows detailed information about a node?<\/b><\/p>\n

                                        \n
                                      1. kubectl inspect node<\/span><\/li>\n
                                      2. kubectl describe node<\/span><\/li>\n
                                      3. kubectl node details<\/span><\/li>\n
                                      4. kubectl show node<\/span><\/li>\n<\/ol>\n

                                        Correct Answer: 2<\/b><\/p>\n

                                        Explanation:<\/b><\/p>\n

                                        kubectl describe node displays detailed information about a specific node, including labels, conditions, capacity, allocatable resources, taints, addresses, running Pods, and recent events. It is one of the most useful commands when diagnosing node-related problems. For example, a node showing NotReady may have conditions or events indicating kubelet, networking, storage, or resource-pressure issues. Administrators can combine the command with kubectl get nodes to first identify the node status and then investigate the affected node in detail.<\/span><\/p>\n

                                        Question 400<\/b><\/h3>\n

                                        Which node condition indicates insufficient available disk space?<\/b><\/p>\n

                                          \n
                                        1. MemoryPressure<\/span><\/li>\n
                                        2. PIDPressure<\/span><\/li>\n
                                        3. NetworkUnavailable<\/span><\/li>\n
                                        4. DiskPressure<\/span><\/li>\n<\/ol>\n

                                          Correct Answer: 4<\/b><\/p>\n

                                          Explanation:<\/b><\/p>\n

                                          DiskPressure indicates that a node is experiencing pressure related to available disk space or inode availability. Kubernetes can respond to node pressure through eviction mechanisms to protect node stability. Administrators investigating DiskPressure should examine filesystem usage, container images, writable container layers, logs, and ephemeral storage consumption. The condition differs from MemoryPressure, which concerns memory availability, and PIDPressure, which concerns process IDs. Reviewing node conditions and events with kubectl describe node can help identify the underlying resource problem.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full CNCF CKA Exam Dumps and Practice Test Dumps   Question 381 Which scheduling rule requires Pods to prefer certain nodes? nodePreference nodeSelector nodeAffinity nodeRule Correct Answer: 3 Explanation: nodeAffinity provides more expressive node-selection rules than a simple nodeSelector. It can define required placement conditions as well as preferred conditions that influence scheduling without […]<\/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\/21093"}],"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=21093"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21093\/revisions"}],"predecessor-version":[{"id":21094,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21093\/revisions\/21094"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21093"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21093"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21093"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}