{"id":21081,"date":"2026-09-24T10:36:35","date_gmt":"2026-09-24T10:36:35","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21081"},"modified":"2026-09-24T10:36:35","modified_gmt":"2026-09-24T10:36:35","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part14-q261-280","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part14-q261-280\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part14 Q261-280"},"content":{"rendered":"

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

 <\/p>\n

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

Which object stores a Pod’s disruption budget?<\/b><\/p>\n

    \n
  1. ReplicaSet<\/span><\/li>\n
  2. LimitRange<\/span><\/li>\n
  3. ResourceQuota<\/span><\/li>\n
  4. PodDisruptionBudget<\/span><\/li>\n<\/ol>\n

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

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

    A PodDisruptionBudget defines how many replicas of an application can be voluntarily disrupted at the same time. It helps protect application availability during operations such as node maintenance or voluntary Pod eviction. A PDB can specify either a minimum number of available Pods or a maximum number of unavailable Pods. It does not prevent every possible Pod failure; involuntary disruptions such as hardware failures are different. ReplicaSets manage replica counts, LimitRanges define namespace-level resource defaults and constraints, and ResourceQuotas restrict aggregate resource consumption. PDBs are therefore primarily concerned with maintaining application availability during planned disruptions.<\/span><\/p>\n

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

    Which field specifies a Pod’s priority class?<\/b><\/p>\n

      \n
    1. priorityClassName<\/span><\/li>\n
    2. importanceLevel<\/span><\/li>\n
    3. schedulingPriority<\/span><\/li>\n
    4. podRank<\/span><\/li>\n<\/ol>\n

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

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

      The priorityClassName field associates a Pod with a PriorityClass. The resulting priority value influences scheduling order and can participate in preemption when cluster resources are insufficient. Higher-priority workloads can receive preferential scheduling treatment under appropriate conditions. The field references the name of an existing PriorityClass rather than directly containing a numeric priority value. Administrators should understand that priority does not guarantee immediate placement because other scheduling constraints still apply. Resource requests, taints, affinity rules, and available capacity can all affect whether a higher-priority Pod has a feasible node.<\/span><\/p>\n

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

      What does preemption allow the scheduler to do?<\/b><\/p>\n

        \n
      1. Increase node capacity<\/span><\/li>\n
      2. Modify resource requests<\/span><\/li>\n
      3. Remove lower-priority Pods<\/span><\/li>\n
      4. Disable scheduling constraints<\/span><\/li>\n<\/ol>\n

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

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

        Pod preemption allows the scheduler to consider removing lower-priority Pods when doing so can create a feasible placement for a higher-priority pending Pod. The scheduler evaluates whether preemption can satisfy the higher-priority workload’s requirements while respecting relevant constraints. Preemption does not increase physical node capacity or modify a Pod’s resource requests. It also does not simply disable scheduling rules. Because preemption can disrupt existing workloads, administrators should design priorities carefully and use appropriate disruption controls. Understanding priority and preemption is important when diagnosing why a high-priority Pod remains pending or causes other Pods to be evicted.<\/span><\/p>\n

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

        Which object defines reusable scheduling priority values?<\/b><\/p>\n

          \n
        1. SchedulingProfile<\/span><\/li>\n
        2. PriorityClass<\/span><\/li>\n
        3. PlacementPolicy<\/span><\/li>\n
        4. SchedulerRule<\/span><\/li>\n<\/ol>\n

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

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

          PriorityClass defines reusable priority values that Pods can reference through priorityClassName. It provides a named representation of scheduling importance and can influence scheduling order and preemption decisions. A PriorityClass is cluster-scoped, allowing multiple namespaces to use the same priority definition. Scheduling profiles configure scheduler behavior, while the other listed terms are not standard Kubernetes objects for defining Pod priority. When reviewing workload scheduling, administrators should inspect both the Pod’s selected PriorityClass and the actual numeric value associated with that class.<\/span><\/p>\n

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

          Which resource limits the combined object count in a namespace?<\/b><\/p>\n

            \n
          1. ResourceQuota<\/span><\/li>\n
          2. PriorityClass<\/span><\/li>\n
          3. LimitRange<\/span><\/li>\n
          4. PodDisruptionBudget<\/span><\/li>\n<\/ol>\n

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

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

            ResourceQuota can limit aggregate consumption within a namespace, including counts of selected Kubernetes objects. For example, a namespace can be restricted to a defined number of Pods, Services, or other supported resource types. This differs from LimitRange, which applies constraints or defaults to individual resources such as Pods or containers. PriorityClass affects scheduling importance, while PodDisruptionBudget concerns voluntary availability disruptions. When a new object is rejected even though the individual workload appears valid, checking the namespace’s ResourceQuota is a useful troubleshooting step.<\/span><\/p>\n

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

            Which feature supplies default resource requests for containers?<\/b><\/p>\n

              \n
            1. PriorityClass<\/span><\/li>\n
            2. PodSecurity<\/span><\/li>\n
            3. NetworkPolicy<\/span><\/li>\n
            4. LimitRange<\/span><\/li>\n<\/ol>\n

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

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

              A LimitRange can define default CPU or memory requests and limits for containers created within a namespace. This helps ensure that workloads receive defined resource settings even when the Pod specification does not explicitly provide them. LimitRange can also establish minimum and maximum resource boundaries. It applies to individual resources rather than the namespace-wide aggregate consumption controlled by ResourceQuota. When a newly created Pod unexpectedly receives resource values, administrators should inspect the namespace’s LimitRange objects to determine whether defaults were automatically applied.<\/span><\/p>\n

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

              Which QoS class applies when every container has equal CPU and memory requests and limits?<\/b><\/p>\n

                \n
              1. Burstable<\/span><\/li>\n
              2. Guaranteed<\/span><\/li>\n
              3. BestEffort<\/span><\/li>\n
              4. Flexible<\/span><\/li>\n<\/ol>\n

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

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

                A Pod receives the Guaranteed QoS class when its containers meet the required CPU and memory request-and-limit conditions, including matching values for those resources. Guaranteed workloads receive stronger resource guarantees compared with less constrained QoS classes. Burstable applies when at least some resource requests or limits are specified without meeting Guaranteed requirements. BestEffort applies when no CPU or memory requests or limits are configured. QoS classification can influence eviction behavior when a node experiences resource pressure, so understanding how Kubernetes categorizes workloads is important during resource-related troubleshooting.<\/span><\/p>\n

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

                What does emptyDir provide to containers in one Pod?<\/b><\/p>\n

                  \n
                1. Persistent cloud storage<\/span><\/li>\n
                2. Cluster-wide shared storage<\/span><\/li>\n
                3. Temporary shared filesystem<\/span><\/li>\n
                4. Remote database storage<\/span><\/li>\n<\/ol>\n

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

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

                  An emptyDir volume provides temporary storage associated with a Pod. The directory is created when the Pod is assigned to a node and can be shared among containers within that Pod. Its contents remain available while the Pod exists on that node but are removed when the Pod is deleted. emptyDir is useful for scratch files, temporary processing data, or communication between containers. It should not be treated as durable application storage. PersistentVolume-based storage is more appropriate when data must survive Pod replacement or rescheduling.<\/span><\/p>\n

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

                  Which volume type exposes a ConfigMap as files?<\/b><\/p>\n

                    \n
                  1. configMap<\/span><\/li>\n
                  2. settingsVolume<\/span><\/li>\n
                  3. configurationMount<\/span><\/li>\n
                  4. configFiles<\/span><\/li>\n<\/ol>\n

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

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

                    A ConfigMap can be mounted into a Pod using a volume whose source references the ConfigMap. Kubernetes presents selected ConfigMap keys as files within the mounted directory. This allows applications to consume configuration without embedding values directly into container images. Individual keys can be mapped to specific paths when more control is required. ConfigMaps are intended for non-sensitive configuration data; credentials should generally use Secrets instead. When a mounted configuration appears stale, administrators should also consider how the application reads files and whether it reloads changed configuration automatically.<\/span><\/p>\n

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

                    Which object stores non-sensitive application configuration?<\/b><\/p>\n

                      \n
                    1. ConfigMap<\/span><\/li>\n
                    2. Secret<\/span><\/li>\n
                    3. Lease<\/span><\/li>\n
                    4. Event<\/span><\/li>\n<\/ol>\n

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

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

                      A ConfigMap stores non-confidential configuration data that applications can consume through environment variables, command arguments, or mounted files. It is useful for separating configuration from container images so the same image can be deployed in different environments with different settings. Secrets are intended for sensitive information such as credentials, while Leases support coordination and Events record cluster-related occurrences. ConfigMaps do not provide encryption simply because they are configuration objects, so sensitive values should not be placed there merely for convenience.<\/span><\/p>\n

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

                      Which object is intended for sensitive configuration values?<\/b><\/p>\n

                        \n
                      1. ConfigMap<\/span><\/li>\n
                      2. Lease<\/span><\/li>\n
                      3. Secret<\/span><\/li>\n
                      4. EndpointSlice<\/span><\/li>\n<\/ol>\n

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

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

                        A Secret is Kubernetes’ resource for holding sensitive information such as passwords, tokens, or certificates. Pods can consume Secrets through environment variables or mounted volumes. Although Kubernetes provides mechanisms for protecting Secret data, administrators must still configure appropriate access controls and storage protections because authorization to read Secrets can expose their contents. ConfigMaps are intended for non-sensitive configuration, Leases support coordination, and EndpointSlices represent network endpoints. When designing workload access, Secret permissions should follow least-privilege principles so that applications receive only the credentials they actually require.<\/span><\/p>\n

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

                        Which API object coordinates leader ownership among components?<\/b><\/p>\n

                          \n
                        1. EndpointSlice<\/span><\/li>\n
                        2. Lease<\/span><\/li>\n
                        3. Secret<\/span><\/li>\n
                        4. ConfigMap<\/span><\/li>\n<\/ol>\n

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

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

                          The Lease object is commonly used for coordination mechanisms such as leader election. Components can update Lease information to indicate which participant currently holds leadership and to maintain a renewal timestamp. This allows distributed components to coordinate without relying on a custom external locking system. EndpointSlices describe Service endpoints, Secrets hold sensitive data, and ConfigMaps provide configuration. When investigating controller or scheduler coordination issues, examining Lease objects can reveal whether expected leadership records are being created and renewed.<\/span><\/p>\n

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

                          Which resource records notable cluster occurrences?<\/b><\/p>\n

                            \n
                          1. Lease<\/span><\/li>\n
                          2. ConfigMap<\/span><\/li>\n
                          3. Event<\/span><\/li>\n
                          4. Secret<\/span><\/li>\n<\/ol>\n

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

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

                            Kubernetes Events record notable occurrences associated with resources, such as scheduling failures, image-pull problems, mount errors, or successful lifecycle operations. They are particularly useful for troubleshooting because they often provide concise explanations of what Kubernetes attempted to do. Events are not intended to replace application logs or provide permanent audit history. Administrators commonly inspect Events when a Pod remains pending, fails to start, or repeatedly encounters infrastructure problems. Other resources such as ConfigMaps and Secrets serve configuration purposes rather than recording operational occurrences.<\/span><\/p>\n

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

                            Which object represents a lease used for coordination?<\/b><\/p>\n

                              \n
                            1. Event<\/span><\/li>\n
                            2. Secret<\/span><\/li>\n
                            3. Lease<\/span><\/li>\n
                            4. ConfigMap<\/span><\/li>\n<\/ol>\n

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

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

                              A Lease is a coordination object maintained through the Kubernetes API. It can record information such as the current holder identity and renewal timing, enabling distributed components to implement leader-election or other coordination patterns. Leases are lightweight compared with storing coordination state in larger configuration objects. Events record cluster occurrences, Secrets contain sensitive values, and ConfigMaps hold configuration. When a control-plane or application component uses leader election, Lease objects can help administrators understand which participant currently holds leadership.<\/span><\/p>\n

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

                              Which resource provides declarative validation for custom API objects?<\/b><\/p>\n

                                \n
                              1. CustomResourceDefinition<\/span><\/li>\n
                              2. ConfigMap<\/span><\/li>\n
                              3. Service<\/span><\/li>\n
                              4. PriorityClass<\/span><\/li>\n<\/ol>\n

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

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

                                A CustomResourceDefinition, or CRD, extends the Kubernetes API with a new custom resource type. Its schema can define the structure and validation rules for instances of that custom resource. This allows Kubernetes to store and validate domain-specific objects using the same API machinery used by built-in resources. ConfigMaps store configuration, Services provide networking abstractions, and PriorityClasses define scheduling priority values. When building or troubleshooting operators, understanding the CRD is essential because it establishes the API structure that the controller watches and manages.<\/span><\/p>\n

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

                                Which controller typically reconciles resources created from a CRD?<\/b><\/p>\n

                                  \n
                                1. kube-proxy<\/span><\/li>\n
                                2. Custom controller<\/span><\/li>\n
                                3. CoreDNS<\/span><\/li>\n
                                4. kubelet<\/span><\/li>\n<\/ol>\n

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

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

                                  A custom controller or operator commonly watches custom resources and reconciles their desired state with the actual cluster state. The CRD defines the API resource, while the controller supplies the behavior that gives that resource operational meaning. For example, a controller might create Deployments, Services, or other resources based on a custom object. kube-proxy manages Service networking, CoreDNS handles DNS, and kubelet manages workloads on individual nodes. If a custom resource exists but nothing happens after it is created, administrators should investigate whether the responsible controller is running and watching the correct resource.<\/span><\/p>\n

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

                                  Which field in a CRD defines its served API version?<\/b><\/p>\n

                                    \n
                                  1. storage<\/span><\/li>\n
                                  2. conversion<\/span><\/li>\n
                                  3. served<\/span><\/li>\n
                                  4. names<\/span><\/li>\n<\/ol>\n

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

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

                                    Within a CRD version definition, the served field indicates whether that version is served through the Kubernetes API. A CRD can contain multiple versions, allowing APIs to evolve while maintaining compatibility. The storage field identifies the version used for persisted representation, while conversion configuration can control how objects move between versions. The names section defines resource naming information. When a custom resource version unexpectedly returns a “not found” response, administrators should inspect the CRD’s version configuration and verify whether that version is currently served.<\/span><\/p>\n

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

                                    What does the CRD storage flag identify?<\/b><\/p>\n

                                      \n
                                    1. Preferred client version<\/span><\/li>\n
                                    2. External storage system<\/span><\/li>\n
                                    3. Network storage driver<\/span><\/li>\n
                                    4. Persisted API version<\/span><\/li>\n<\/ol>\n

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

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

                                      For a CRD with multiple versions, the storage flag identifies the version used to persist custom resource objects in the Kubernetes storage layer. Exactly one served version must be designated as the storage version. This is separate from deciding which API versions clients can access. Conversion mechanisms can translate objects between served versions and the storage representation. The storage flag does not identify a physical storage driver or an external storage system. Understanding this distinction becomes important when evolving custom APIs and troubleshooting version conversion or migration behavior.<\/span><\/p>\n

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

                                      Which API group contains Role and ClusterRole resources?<\/b><\/p>\n

                                        \n
                                      1. apps<\/span><\/li>\n
                                      2. rbac.authorization.k8s.io<\/span><\/li>\n
                                      3. scheduling.k8s.io<\/span><\/li>\n
                                      4. storage.k8s.io<\/span><\/li>\n<\/ol>\n

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

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

                                        Role and ClusterRole belong to the rbac.authorization.k8s.io API group. This group provides Kubernetes Role-Based Access Control resources used to define permissions. Role is namespace-scoped, while ClusterRole is cluster-scoped and can also describe permissions that are later granted within a namespace through an appropriate binding. The apps group contains workload resources such as Deployments, while scheduling and storage groups contain resources for their respective functions. Knowing the correct API group is useful when writing manifests, querying resources, or diagnosing authorization configuration.<\/span><\/p>\n

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

                                        Which binding grants a Role’s permissions to subjects?<\/b><\/p>\n

                                          \n
                                        1. RoleBinding<\/span><\/li>\n
                                        2. RoleGrant<\/span><\/li>\n
                                        3. PermissionLink<\/span><\/li>\n
                                        4. AccessBinding<\/span><\/li>\n<\/ol>\n

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

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

                                          A RoleBinding grants the permissions defined by a Role or, in some cases, a ClusterRole to specified subjects within a namespace. Subjects can include users, groups, or ServiceAccounts. The binding connects the identity to the permission set; creating a Role alone does not automatically grant anyone access. ClusterRoleBinding provides cluster-wide binding behavior for a ClusterRole. When troubleshooting an authorization failure, administrators should examine both the role rules and the relevant binding because either side can prevent the intended permission from being effective.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full CNCF CKA Exam Dumps and Practice Test Dumps   Question 261 Which object stores a Pod’s disruption budget? ReplicaSet LimitRange ResourceQuota PodDisruptionBudget Correct Answer: 4 Explanation: A PodDisruptionBudget defines how many replicas of an application can be voluntarily disrupted at the same time. It helps protect application availability during operations such as node […]<\/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\/21081"}],"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=21081"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21081\/revisions"}],"predecessor-version":[{"id":21082,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21081\/revisions\/21082"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}