{"id":17222,"date":"2026-09-21T07:08:55","date_gmt":"2026-09-21T07:08:55","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=17222"},"modified":"2026-09-21T07:08:55","modified_gmt":"2026-09-21T07:08:55","slug":"linux-foundation-kcna-practice-test-questions-and-exam-dumps-part16-q301-320","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/linux-foundation-kcna-practice-test-questions-and-exam-dumps-part16-q301-320\/","title":{"rendered":"Linux Foundation KCNA Practice Test Questions and Exam Dumps Part16 Q301-320"},"content":{"rendered":"

View Full <\/b>Linux Foundation KCNA Exam Dumps<\/b><\/a> and Practice Test Dumps.<\/b><\/h2>\n

 <\/p>\n

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

Which taint effect prevents new Pods from being scheduled onto a node unless they tolerate the taint?<\/b><\/p>\n

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

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

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

    The NoSchedule taint effect prevents Kubernetes from scheduling new Pods onto a node unless those Pods have a matching toleration. This mechanism is useful when administrators want to reserve nodes for particular workloads or keep general workloads away from specialized infrastructure. PreferNoSchedule is a softer preference that tells the scheduler to avoid placing Pods on the node when possible, but it does not strictly prevent scheduling. NoExecute has an additional effect on existing Pods. Taints and tolerations therefore provide an important mechanism for controlling workload placement across cluster nodes.<\/span><\/p>\n

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

    Which taint effect can cause existing Pods without a matching toleration to be removed from a node?<\/b><\/p>\n

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

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

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

      The NoExecute taint effect affects both scheduling and existing Pods. When a node has a NoExecute taint, Pods that do not have a matching toleration can be evicted from that node. Pods with an appropriate toleration may remain for the duration specified by tolerationSeconds, if configured. NoSchedule primarily prevents new scheduling, while PreferNoSchedule expresses a preference rather than a strict restriction. NoExecute is therefore useful when workloads must be actively removed from a node unless they explicitly tolerate the node condition.<\/span><\/p>\n

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

      What does a Pod toleration allow a Pod to do when a matching taint exists on a node?<\/b><\/p>\n

        \n
      1. Ignore all resource limits<\/span><\/li>\n
      2. Access every Namespace<\/span><\/li>\n
      3. Bypass container image requirements<\/span><\/li>\n
      4. Be considered for scheduling onto the tainted node<\/span><\/li>\n<\/ol>\n

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

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

        A toleration allows a Pod to tolerate a matching taint on a node. This means the taint does not automatically prevent the Pod from being considered for scheduling there, depending on the taint effect and other scheduling requirements. A toleration does not force the scheduler to place the Pod on that node. It simply removes the particular taint as a blocking condition. Resource limits, Namespace permissions, and image requirements are controlled by other Kubernetes mechanisms. Tolerations are commonly used with specialized nodes that are reserved for particular workloads.<\/span><\/p>\n

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

        Which scheduling mechanism directly specifies that a Pod should run on nodes having a particular label?<\/b><\/p>\n

          \n
        1. nodeSelector<\/span><\/li>\n
        2. Service selector<\/span><\/li>\n
        3. ResourceQuota<\/span><\/li>\n
        4. ConfigMap<\/span><\/li>\n<\/ol>\n

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

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

          nodeSelector provides a simple way to constrain a Pod to nodes containing specific labels. For example, a Pod can specify a nodeSelector requiring a label such as disktype=ssd. The scheduler then considers only nodes matching that requirement. Service selectors perform a different function by selecting Pods for network traffic. ResourceQuota limits aggregate resource consumption, while ConfigMap stores configuration. nodeSelector is therefore appropriate when a straightforward label-based node placement requirement is sufficient and more advanced affinity rules are not necessary.<\/span><\/p>\n

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

          Which Kubernetes feature provides more expressive rules for selecting nodes than a simple nodeSelector?<\/b><\/p>\n

            \n
          1. Service discovery<\/span><\/li>\n
          2. Node affinity<\/span><\/li>\n
          3. ConfigMap<\/span><\/li>\n
          4. ReplicaSet<\/span><\/li>\n<\/ol>\n

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

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

            Node affinity provides more expressive scheduling rules than nodeSelector. It allows administrators to define required or preferred relationships between Pods and node labels. Required affinity can make a condition mandatory, while preferred affinity expresses a scheduling preference. This flexibility is useful when workloads need to target specific hardware, geographic zones, operating systems, or other node characteristics. Services use selectors to identify Pods for networking, ConfigMaps store configuration, and ReplicaSets maintain Pod replicas. Node affinity is therefore a flexible mechanism for controlling workload placement.<\/span><\/p>\n

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

            Which scheduling feature helps distribute Pods across failure domains such as zones or nodes?<\/b><\/p>\n

              \n
            1. Pod topology spread constraints<\/span><\/li>\n
            2. ConfigMap<\/span><\/li>\n
            3. ServiceAccount<\/span><\/li>\n
            4. ResourceQuota<\/span><\/li>\n<\/ol>\n

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

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

              Pod topology spread constraints help distribute Pods across defined topology domains such as nodes, availability zones, or other labeled failure domains. This can improve application availability by avoiding excessive concentration of replicas in one location. Administrators can define constraints that describe how evenly workloads should be distributed. ConfigMaps provide configuration, ServiceAccounts provide workload identities, and ResourceQuotas control aggregate resource consumption. Topology spread constraints are particularly useful for highly available applications where replicas should not all depend on the same node or failure domain.<\/span><\/p>\n

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

              Which Kubernetes scheduling concept is commonly used to keep certain Pods apart from each other?<\/b><\/p>\n

                \n
              1. ResourceQuota<\/span><\/li>\n
              2. Pod anti-affinity<\/span><\/li>\n
              3. ConfigMap<\/span><\/li>\n
              4. Service<\/span><\/li>\n<\/ol>\n

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

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

                Pod anti-affinity allows administrators to express rules that discourage or prevent certain Pods from being scheduled close to other Pods matching specified label selectors. This can be useful for spreading replicas across nodes or zones to reduce the impact of node failures. For example, replicas of a highly available application can be configured so that multiple replicas do not share the same node. ResourceQuota manages aggregate resource consumption, ConfigMap stores configuration, and Service provides networking. Pod anti-affinity therefore focuses specifically on relationships between Pod placement locations.<\/span><\/p>\n

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

                Which resource unit is commonly used to represent a fraction of a CPU in Kubernetes?<\/b><\/p>\n

                  \n
                1. Gi<\/span><\/li>\n
                2. Mi<\/span><\/li>\n
                3. m<\/span><\/li>\n
                4. Ki<\/span><\/li>\n<\/ol>\n

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

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

                  The letter m represents millicpu units in Kubernetes. One CPU is equivalent to 1000m, so a request of 500m represents approximately half of one CPU. CPU resources can be specified using whole CPU values or millicpu quantities. Units such as Mi and Gi are commonly associated with memory quantities, while Ki represents kibibytes. Understanding resource units is important when defining container requests and limits because Kubernetes uses these values for scheduling and resource management decisions.<\/span><\/p>\n

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

                  What can happen when a container exceeds its configured memory limit?<\/b><\/p>\n

                    \n
                  1. The container may be terminated due to an out-of-memory condition<\/span><\/li>\n
                  2. Kubernetes automatically increases the memory limit<\/span><\/li>\n
                  3. The container becomes a privileged container<\/span><\/li>\n
                  4. The Pod is automatically moved to another Namespace<\/span><\/li>\n<\/ol>\n

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

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

                    If a container exceeds its configured memory limit, it can be terminated by the system because of an out-of-memory condition. Kubernetes does not automatically increase the configured memory limit simply because the application requires more memory. The exact behavior can depend on node conditions and workload configuration, but memory limits are enforced differently from CPU limits. CPU usage above a limit is generally throttled, while excessive memory consumption can result in termination. Appropriate resource requests and limits should therefore be selected based on realistic application requirements.<\/span><\/p>\n

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

                    Which Kubernetes QoS class is typically assigned when every container in a Pod has CPU and memory requests and limits set, with requests equal to limits?<\/b><\/p>\n

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

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

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

                      A Pod can receive the Guaranteed Quality of Service class when its containers have both CPU and memory requests and limits configured appropriately, with each request equal to its corresponding limit. Guaranteed workloads generally receive stronger resource guarantees compared with lower QoS classes during resource pressure. BestEffort applies when no requests or limits are specified, while Burstable applies to many configurations that fall between these conditions. QoS classification helps Kubernetes make decisions about workload behavior during resource pressure on a node.<\/span><\/p>\n

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

                      Which Kubernetes QoS class generally applies to a Pod that has no CPU or memory requests and limits configured?<\/b><\/p>\n

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

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

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

                        A Pod generally receives the BestEffort QoS class when none of its containers specify CPU or memory requests or limits. Such workloads have fewer resource guarantees than Pods in the Guaranteed or Burstable classes. During severe node resource pressure, BestEffort workloads can be more vulnerable to eviction. This classification does not mean the Pod cannot run; it describes how Kubernetes categorizes its resource configuration. Administrators should understand QoS classes when designing workloads because resource requests and limits influence scheduling and behavior during resource contention.<\/span><\/p>\n

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

                        Which QoS class commonly applies when a Pod has some resource requests or limits configured but does not meet the requirements for Guaranteed?<\/b><\/p>\n

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

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

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

                          The Burstable QoS class commonly applies when a Pod has CPU or memory requests and limits configured but does not satisfy the conditions required for Guaranteed. For example, a Pod might specify a memory request without setting an equal memory limit. Burstable workloads receive more resource information than BestEffort workloads but do not have the same classification as Guaranteed Pods. Kubernetes uses QoS classifications when managing resources and responding to resource pressure. Properly configured requests and limits can therefore help workloads receive more predictable resource management.<\/span><\/p>\n

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

                          Which probe determines whether a container is ready to receive network traffic?<\/b><\/p>\n

                            \n
                          1. Startup probe<\/span><\/li>\n
                          2. Readiness probe<\/span><\/li>\n
                          3. Liveness probe<\/span><\/li>\n
                          4. Resource probe<\/span><\/li>\n<\/ol>\n

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

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

                            A readiness probe determines whether a container is ready to receive traffic. When a readiness check fails, Kubernetes can remove the Pod from the endpoints used by Services, preventing traffic from being sent to an application that is not currently ready. A readiness probe does not normally restart the container. A liveness probe is used to determine whether a container should be restarted, while a startup probe helps handle slow-starting applications. Readiness checks are therefore important for reliable traffic management during application startup and temporary unavailability.<\/span><\/p>\n

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

                            Which probe is designed to determine whether a container should be restarted because it is considered unhealthy?<\/b><\/p>\n

                              \n
                            1. Readiness probe<\/span><\/li>\n
                            2. Startup probe<\/span><\/li>\n
                            3. Liveness probe<\/span><\/li>\n
                            4. NetworkPolicy<\/span><\/li>\n<\/ol>\n

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

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

                              A liveness probe is used to determine whether a running container is still healthy enough to continue operating. If the configured liveness check repeatedly fails according to the probe thresholds, Kubernetes can restart the container. This is useful for applications that may become stuck or otherwise unable to recover without a restart. Readiness probes control whether traffic should be sent to a Pod, while startup probes help protect slow-starting applications from premature liveness failures. Liveness probes therefore focus primarily on detecting conditions that require container recovery.<\/span><\/p>\n

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

                              Which probe is particularly useful for an application that requires significant time to start before liveness checking should begin?<\/b><\/p>\n

                                \n
                              1. Startup probe<\/span><\/li>\n
                              2. Readiness probe<\/span><\/li>\n
                              3. ResourceQuota<\/span><\/li>\n
                              4. Service probe<\/span><\/li>\n<\/ol>\n

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

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

                                A startup probe is designed for applications that may require substantial time to initialize. Kubernetes can use the startup probe to determine when the application has successfully started before allowing other probe behavior, such as liveness checking, to take effect. This prevents a slow-starting application from being incorrectly restarted because its liveness endpoint was not ready quickly enough. Readiness probes address traffic availability, while ResourceQuota controls Namespace-level resource consumption. Startup probes are therefore especially useful for applications with long or unpredictable initialization processes.<\/span><\/p>\n

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

                                Which container type runs before the main application containers and must complete successfully before they start?<\/b><\/p>\n

                                  \n
                                1. Sidecar container<\/span><\/li>\n
                                2. Init container<\/span><\/li>\n
                                3. Ephemeral container<\/span><\/li>\n
                                4. Registry container<\/span><\/li>\n<\/ol>\n

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

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

                                  An init container runs before the main application containers in a Pod. Init containers can perform setup tasks such as preparing files, waiting for dependencies, or initializing configuration. Kubernetes runs init containers in order, and each must complete successfully before the next one starts and before the main containers are launched. This makes them useful for initialization logic that should happen only before the application begins normal execution. Regular application containers are designed for ongoing workloads, while init containers have a distinct startup-oriented lifecycle.<\/span><\/p>\n

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

                                  What happens to an emptyDir volume when the Pod that uses it is removed?<\/b><\/p>\n

                                    \n
                                  1. It becomes a PersistentVolume automatically<\/span><\/li>\n
                                  2. Its data is normally deleted<\/span><\/li>\n
                                  3. Its contents are moved to etcd<\/span><\/li>\n
                                  4. It remains permanently available to all Pods<\/span><\/li>\n<\/ol>\n

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

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

                                    An emptyDir volume is created when a Pod is assigned to a node and provides temporary storage that can be shared among containers within that Pod. Its contents normally exist for the lifetime of the Pod. When the Pod is removed from the node, the emptyDir data is deleted. It is therefore suitable for temporary files, caching, and sharing data between containers in the same Pod, but it should not be used when data must survive Pod deletion. PersistentVolumes and PersistentVolumeClaims are designed for longer-lived persistent storage.<\/span><\/p>\n

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

                                    Which Kubernetes object can expose a Service using an external load balancer when supported by the environment?<\/b><\/p>\n

                                      \n
                                    1. ClusterIP Service<\/span><\/li>\n
                                    2. NodePort Service<\/span><\/li>\n
                                    3. LoadBalancer Service<\/span><\/li>\n
                                    4. Headless Service<\/span><\/li>\n<\/ol>\n

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

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

                                      A Service of type LoadBalancer can request an external load balancer from an infrastructure provider when the Kubernetes environment supports that capability. This provides an externally reachable endpoint for the Service and can be useful for applications that need to accept traffic from outside the cluster. ClusterIP provides internal cluster access, NodePort exposes a port on nodes, and a headless Service does not provide a conventional cluster virtual IP. LoadBalancer is therefore the Service type commonly associated with external load-balancing functionality.<\/span><\/p>\n

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

                                      Which Kubernetes Service type exposes a service on a port that is allocated from a range on each node?<\/b><\/p>\n

                                        \n
                                      1. ClusterIP<\/span><\/li>\n
                                      2. ExternalName<\/span><\/li>\n
                                      3. LoadBalancer<\/span><\/li>\n
                                      4. NodePort<\/span><\/li>\n<\/ol>\n

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

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

                                        A NodePort Service exposes the Service on a specific port across the nodes in the cluster. External clients can reach the service using a node address and the assigned NodePort, subject to network configuration and firewall rules. NodePort also typically creates the underlying ClusterIP behavior. ClusterIP is primarily for internal access, LoadBalancer can integrate with an external load-balancing system, and ExternalName maps a Service to an external DNS name. NodePort is therefore useful when access through node-level ports is required.<\/span><\/p>\n

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

                                        Which Kubernetes Service type is normally used for internal cluster communication and receives a stable virtual IP?<\/b><\/p>\n

                                          \n
                                        1. ClusterIP<\/span><\/li>\n
                                        2. NodePort<\/span><\/li>\n
                                        3. LoadBalancer<\/span><\/li>\n
                                        4. ExternalName<\/span><\/li>\n<\/ol>\n

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

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

                                          ClusterIP is the default Kubernetes Service type and provides a stable virtual IP for internal communication within the cluster. Other workloads can access the Service without needing to know the changing IP addresses of individual Pods. Kubernetes uses the Service selector to identify the appropriate backend Pods and route traffic to them. NodePort additionally exposes a port on cluster nodes, while LoadBalancer can provide external load-balancing functionality. ExternalName instead maps a Service to an external DNS name. ClusterIP is therefore the standard choice for internal Service-to-Service communication.<\/span><\/p>\n

                                           <\/p>\n","protected":false},"excerpt":{"rendered":"

                                          View Full Linux Foundation KCNA Exam Dumps and Practice Test Dumps.   Question 301 Which taint effect prevents new Pods from being scheduled onto a node unless they tolerate the taint? NoExecute NoSchedule PreferNoSchedule AllowSchedule Correct Answer: 2 Explanation The NoSchedule taint effect prevents Kubernetes from scheduling new Pods onto a node unless those Pods […]<\/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\/17222"}],"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=17222"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17222\/revisions"}],"predecessor-version":[{"id":17223,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/17222\/revisions\/17223"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=17222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=17222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=17222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}