{"id":21085,"date":"2026-09-24T10:37:10","date_gmt":"2026-09-24T10:37:10","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21085"},"modified":"2026-09-24T10:37:10","modified_gmt":"2026-09-24T10:37:10","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part16-q301-320","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part16-q301-320\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part16 Q301-320"},"content":{"rendered":"

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

 <\/p>\n

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

Which command checks node resource utilization?<\/b><\/p>\n

    \n
  1. kubectl top nodes<\/span><\/li>\n
  2. kubectl node usage<\/span><\/li>\n
  3. kubectl metrics nodes<\/span><\/li>\n
  4. kubectl resource nodes<\/span><\/li>\n<\/ol>\n

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

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

    kubectl top nodes displays resource usage information for cluster nodes when the Metrics API is available. It commonly reports CPU and memory consumption alongside capacity-related information. This command is useful when investigating resource pressure, identifying heavily utilized nodes, or determining whether workloads are consuming expected resources. It depends on a functioning metrics pipeline, such as Metrics Server. If the command returns an error indicating that metrics are unavailable, administrators should investigate the metrics components rather than assuming that node monitoring is functioning normally.<\/span><\/p>\n

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

    Which command displays resource consumption for containers?<\/b><\/p>\n

      \n
    1. kubectl usage pods<\/span><\/li>\n
    2. kubectl top pods<\/span><\/li>\n
    3. kubectl metrics pods<\/span><\/li>\n
    4. kubectl stats pods<\/span><\/li>\n<\/ol>\n

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

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

      kubectl top pods displays CPU and memory usage for Pods when the cluster’s resource metrics API is available. It can help administrators identify workloads consuming unusually large amounts of resources. The command can also be combined with namespace-related options to inspect workloads in a particular namespace. Metrics output represents observed usage rather than configured requests or limits. Therefore, when evaluating resource behavior, administrators should compare actual consumption with the workload specification and node capacity instead of relying on metrics alone.<\/span><\/p>\n

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

      Which status commonly indicates memory exhaustion killed a container?<\/b><\/p>\n

        \n
      1. OOMKilled<\/span><\/li>\n
      2. MemoryFailed<\/span><\/li>\n
      3. OutOfMemoryExit<\/span><\/li>\n
      4. ResourceKilled<\/span><\/li>\n<\/ol>\n

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

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

        OOMKilled indicates that a container was terminated because the operating system’s out-of-memory mechanism killed its process. This commonly occurs when memory consumption exceeds the available memory or a configured container limit. Administrators can inspect the container’s termination reason and exit information to confirm the condition. Repeated OOM kills may require adjusting memory limits, requests, or application behavior. Simply restarting the Pod does not resolve the underlying resource issue. Reviewing node memory pressure and the application’s actual consumption can help determine whether the problem is local to one workload or reflects broader capacity constraints.<\/span><\/p>\n

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

        Which container exit code usually represents successful completion?<\/b><\/p>\n

          \n
        1. 1<\/span><\/li>\n
        2. 2<\/span><\/li>\n
        3. 0<\/span><\/li>\n
        4. 137<\/span><\/li>\n<\/ol>\n

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

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

          An exit code of 0 conventionally indicates that a process completed successfully. Kubernetes records container termination information, including the exit code, which can help administrators determine whether a completed workload ended normally or failed. Nonzero values generally indicate some form of error, although their exact meaning depends on the application and runtime. Exit code 137, for example, commonly corresponds to a process terminated by SIGKILL. When troubleshooting Jobs or completed containers, checking both the exit code and termination reason provides more useful context than looking only at the container’s final state.<\/span><\/p>\n

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

          Which Pod phase represents completed execution successfully?<\/b><\/p>\n

            \n
          1. Failed<\/span><\/li>\n
          2. Succeeded<\/span><\/li>\n
          3. Running<\/span><\/li>\n
          4. Unknown<\/span><\/li>\n<\/ol>\n

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

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

            The Succeeded Pod phase indicates that all containers in the Pod terminated successfully and will not be restarted. This state is commonly seen with completed Jobs or other workloads designed for finite execution. Failed indicates that at least one container terminated unsuccessfully and the Pod will not continue running. Running means the Pod has been scheduled and at least one container is active or starting, while Unknown indicates that the Pod state could not be obtained reliably. Understanding Pod phases helps administrators quickly interpret workload lifecycle status.<\/span><\/p>\n

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

            Which command retrieves logs from a specific container?<\/b><\/p>\n

              \n
            1. kubectl logs pod -c container<\/span><\/li>\n
            2. kubectl output pod container<\/span><\/li>\n
            3. kubectl readlog pod container<\/span><\/li>\n
            4. kubectl container-log pod<\/span><\/li>\n<\/ol>\n

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

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

              The kubectl logs command can use the -c option to select a specific container when a Pod contains multiple containers. This is important because a multi-container Pod may have separate application, sidecar, or helper processes producing different logs. Without identifying the container when necessary, the command may not target the intended output. Administrators investigating application failures should inspect the relevant container’s logs rather than assuming all Pod logs represent the same process. For previously terminated instances, the appropriate previous-container option can provide additional diagnostic information.<\/span><\/p>\n

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

              Which option follows new log lines continuously?<\/b><\/p>\n

                \n
              1. –stream<\/span><\/li>\n
              2. –follow<\/span><\/li>\n
              3. –watch<\/span><\/li>\n
              4. –tail-live<\/span><\/li>\n<\/ol>\n

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

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

                The –follow option keeps a kubectl logs session open and streams new log output as it becomes available. This is useful when monitoring an application during startup, reproducing a failure, or observing behavior after a configuration change. Unlike –tail, which controls how many existing lines are displayed, –follow controls whether the command continues waiting for additional output. Administrators can combine it with container-selection and other logging options when troubleshooting multi-container workloads. Continuous log observation is particularly helpful when a failure happens shortly after a container starts.<\/span><\/p>\n

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

                Which field controls how many old ReplicaSets a Deployment retains?<\/b><\/p>\n

                  \n
                1. revisionLimit<\/span><\/li>\n
                2. historyLimit<\/span><\/li>\n
                3. revisionHistoryLimit<\/span><\/li>\n
                4. deploymentHistory<\/span><\/li>\n<\/ol>\n

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

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

                  revisionHistoryLimit specifies how many old ReplicaSets created by a Deployment are retained for rollback purposes. Keeping previous revisions allows administrators to inspect or restore earlier Deployment versions. When older revisions are no longer needed, Kubernetes can remove them according to this setting. A lower value reduces retained objects, while a higher value preserves more historical revisions. This field is specifically associated with Deployment revision history and should not be confused with Pod retention settings used by Jobs or other workload types.<\/span><\/p>\n

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

                  Which Deployment strategy replaces Pods gradually?<\/b><\/p>\n

                    \n
                  1. Recreate<\/span><\/li>\n
                  2. RollingUpdate<\/span><\/li>\n
                  3. ReplaceAll<\/span><\/li>\n
                  4. ProgressiveSwap<\/span><\/li>\n<\/ol>\n

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

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

                    The RollingUpdate Deployment strategy gradually replaces Pods from the previous ReplicaSet with Pods from the new revision. This allows an application to transition between versions while maintaining a controlled level of availability according to the configured update parameters. The Recreate strategy instead removes existing Pods before creating the replacement set. Rolling updates can be tuned with values such as maximum unavailable and maximum surge. When an update behaves unexpectedly, examining the Deployment strategy and rollout status can help determine whether the observed replacement behavior matches the intended configuration.<\/span><\/p>\n

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

                    Which Deployment field controls extra Pods during an update?<\/b><\/p>\n

                      \n
                    1. maxUnavailable<\/span><\/li>\n
                    2. maxSurge<\/span><\/li>\n
                    3. surgeLimit<\/span><\/li>\n
                    4. extraReplicas<\/span><\/li>\n<\/ol>\n

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

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

                      maxSurge controls the maximum number of Pods that can temporarily exist above the Deployment’s desired replica count during a rolling update. Allowing additional Pods can help maintain application availability while older replicas are being replaced. The value can be expressed as an absolute number or percentage. maxUnavailable controls how many replicas may be unavailable during the update and serves a different purpose. Administrators should consider both settings together because they determine how quickly and safely a rolling update can replace existing workload instances.<\/span><\/p>\n

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

                      Which field controls unavailable replicas during a rolling update?<\/b><\/p>\n

                        \n
                      1. maxUnavailable<\/span><\/li>\n
                      2. unavailableLimit<\/span><\/li>\n
                      3. minAvailable<\/span><\/li>\n
                      4. rolloutGap<\/span><\/li>\n<\/ol>\n

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

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

                        maxUnavailable defines how many replicas can be unavailable during a Deployment rolling update. It helps control the trade-off between rollout speed and application availability. A restrictive value keeps more replicas available while the update proceeds, whereas a larger value can allow faster replacement. This setting works together with maxSurge, which controls additional replicas temporarily created above the desired count. Administrators troubleshooting rollout behavior should inspect both values because an unexpectedly slow or disruptive update may result from either setting.<\/span><\/p>\n

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

                        Which command displays the rollout history of a Deployment?<\/b><\/p>\n

                          \n
                        1. kubectl deployment history<\/span><\/li>\n
                        2. kubectl rollout history<\/span><\/li>\n
                        3. kubectl history deployment<\/span><\/li>\n
                        4. kubectl revisions deployment<\/span><\/li>\n<\/ol>\n

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

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

                          kubectl rollout history displays revision information for supported workload resources such as Deployments. It can help administrators determine which revisions exist and inspect their associated changes. Rollout history is particularly useful before performing a rollback because it provides information about available previous versions. The command does not itself change the workload. When investigating an unsuccessful update, administrators can combine rollout history with rollout status and Deployment descriptions to understand which revision is currently active and which earlier revision may contain the desired configuration.<\/span><\/p>\n

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

                          Which command pauses a Deployment rollout?<\/b><\/p>\n

                            \n
                          1. kubectl deployment hold<\/span><\/li>\n
                          2. kubectl rollout pause<\/span><\/li>\n
                          3. kubectl pause deployment<\/span><\/li>\n
                          4. kubectl rollout stop<\/span><\/li>\n<\/ol>\n

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

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

                            kubectl rollout pause pauses a Deployment rollout so that subsequent modifications can be accumulated before the rollout resumes. This can be useful when several related changes should be applied together rather than triggering separate rollout operations. The command changes the Deployment’s rollout behavior but does not delete existing Pods. Administrators can later use the corresponding resume command to continue progression. Pausing is useful during controlled configuration changes or staged updates where intermediate revisions should not immediately become active.<\/span><\/p>\n

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

                            Which command resumes a paused Deployment?<\/b><\/p>\n

                              \n
                            1. kubectl rollout continue<\/span><\/li>\n
                            2. kubectl deployment resume<\/span><\/li>\n
                            3. kubectl rollout resume<\/span><\/li>\n
                            4. kubectl resume rollout<\/span><\/li>\n<\/ol>\n

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

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

                              kubectl rollout resume resumes a Deployment that was previously paused. Once resumed, Kubernetes can continue reconciling the Deployment toward its desired state and perform the pending rollout. This command is often used after multiple configuration changes have been applied while the Deployment was paused. If a Deployment remains unchanged after resuming, administrators should inspect its generation, rollout status, and controller events. Understanding the pause and resume workflow can be useful when managing controlled application updates.<\/span><\/p>\n

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

                              Which command removes a failed Deployment revision from active use?<\/b><\/p>\n

                                \n
                              1. kubectl rollout undo deployment<\/span><\/li>\n
                              2. kubectl deployment rollback<\/span><\/li>\n
                              3. kubectl revert deployment<\/span><\/li>\n
                              4. kubectl restore deployment<\/span><\/li>\n<\/ol>\n

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

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

                                kubectl rollout undo deployment rolls a Deployment back toward a previous revision. This is useful when a newly deployed application version causes failures or unexpected behavior. Kubernetes uses the Deployment’s retained revision history to identify earlier configurations. Administrators can also target a specific revision when necessary. Rollback changes the Deployment specification and allows its controller to reconcile the workload toward the selected version. Before performing a rollback, reviewing rollout history and application symptoms can help identify which revision should be restored.<\/span><\/p>\n

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

                                Which command waits for a Deployment to finish updating?<\/b><\/p>\n

                                  \n
                                1. kubectl rollout wait<\/span><\/li>\n
                                2. kubectl rollout status<\/span><\/li>\n
                                3. kubectl deployment monitor<\/span><\/li>\n
                                4. kubectl deployment wait<\/span><\/li>\n<\/ol>\n

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

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

                                  kubectl rollout status displays the progress of a Deployment rollout and can remain active while Kubernetes works toward the desired state. It is useful for confirming whether updated replicas have become available and whether the rollout has completed successfully. This differs from examining the Deployment specification alone because status reflects the controller’s current progression. Administrators can use rollout status during automated deployment workflows or manual troubleshooting. If the rollout stalls, additional inspection of ReplicaSets, Pods, events, and readiness conditions can identify the underlying issue.<\/span><\/p>\n

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

                                  Which workload controller maintains a desired number of identical Pods?<\/b><\/p>\n

                                    \n
                                  1. ReplicaSet<\/span><\/li>\n
                                  2. StatefulSet<\/span><\/li>\n
                                  3. DaemonSet<\/span><\/li>\n
                                  4. Job<\/span><\/li>\n<\/ol>\n

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

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

                                    A ReplicaSet maintains a specified number of matching Pods. If a managed Pod disappears, the ReplicaSet creates a replacement to restore the desired replica count. Deployments commonly manage ReplicaSets to provide higher-level rollout functionality. StatefulSets are intended for workloads requiring stable identities or ordered behavior, DaemonSets place Pods according to node-oriented requirements, and Jobs manage finite tasks. When troubleshooting a Deployment, understanding the underlying ReplicaSet can help explain why Pods are being created, removed, or replaced.<\/span><\/p>\n

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

                                    Which controller gives Pods stable ordinal identities?<\/b><\/p>\n

                                      \n
                                    1. ReplicaSet<\/span><\/li>\n
                                    2. StatefulSet<\/span><\/li>\n
                                    3. Job<\/span><\/li>\n
                                    4. CronJob<\/span><\/li>\n<\/ol>\n

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

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

                                      A StatefulSet provides Pods with stable ordinal identities and predictable naming. It is designed for workloads where individual replicas need persistent identity, stable network naming, or associated persistent storage. ReplicaSets provide interchangeable replicas without stable ordinal identities. Jobs manage finite execution, while CronJobs create Jobs according to a schedule. StatefulSet behavior can also include ordered creation and termination depending on its configuration. When administering stateful applications, these stable identities can simplify clustering, membership, and storage association.<\/span><\/p>\n

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

                                      Which controller ensures one Pod per eligible node?<\/b><\/p>\n

                                        \n
                                      1. ReplicaSet<\/span><\/li>\n
                                      2. StatefulSet<\/span><\/li>\n
                                      3. DaemonSet<\/span><\/li>\n
                                      4. Deployment<\/span><\/li>\n<\/ol>\n

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

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

                                        A DaemonSet ensures that a Pod is scheduled on each node that matches its placement requirements. This makes DaemonSets useful for node-level agents such as log collectors, monitoring agents, and networking components. The number of Pods changes as eligible nodes enter or leave the cluster. ReplicaSets and Deployments focus on maintaining replica counts independent of individual node coverage, while StatefulSets provide stable identities. When a DaemonSet Pod is missing from a particular node, administrators should inspect node eligibility, taints, tolerations, and DaemonSet scheduling conditions.<\/span><\/p>\n

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

                                        Which workload controller creates Pods for finite tasks?<\/b><\/p>\n

                                          \n
                                        1. Deployment<\/span><\/li>\n
                                        2. DaemonSet<\/span><\/li>\n
                                        3. ReplicaSet<\/span><\/li>\n
                                        4. Job<\/span><\/li>\n<\/ol>\n

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

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

                                          A Job creates Pods intended to run a task to completion rather than remain continuously available. The Job controller tracks successful completions and can create additional Pods when failures occur according to its configuration. This makes Jobs suitable for batch processing, database maintenance, migrations, and other finite operations. Deployments and ReplicaSets maintain ongoing application replicas, while DaemonSets target node-based workloads. When troubleshooting a Job, administrators should inspect completion counts, Pod status, retry behavior, and termination information to determine whether the task completed successfully.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full CNCF CKA Exam Dumps and Practice Test Dumps   Question 301 Which command checks node resource utilization? kubectl top nodes kubectl node usage kubectl metrics nodes kubectl resource nodes Correct Answer: 1 Explanation: kubectl top nodes displays resource usage information for cluster nodes when the Metrics API is available. It commonly reports CPU […]<\/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\/21085"}],"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=21085"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21085\/revisions"}],"predecessor-version":[{"id":21086,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21085\/revisions\/21086"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21085"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21085"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21085"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}