{"id":21069,"date":"2026-09-24T10:34:46","date_gmt":"2026-09-24T10:34:46","guid":{"rendered":"https:\/\/www.examlabs.com\/certification\/?p=21069"},"modified":"2026-09-24T10:34:46","modified_gmt":"2026-09-24T10:34:46","slug":"cncf-cka-practice-test-questions-and-exam-dumps-part8-q141-160","status":"publish","type":"post","link":"https:\/\/www.examlabs.com\/certification\/cncf-cka-practice-test-questions-and-exam-dumps-part8-q141-160\/","title":{"rendered":"CNCF CKA Practice Test Questions and Exam Dumps Part8 Q141-160"},"content":{"rendered":"<h2><b>View Full <\/b><a href=\"https:\/\/www.examlabs.com\/cka-exam-dumps\"><b>CNCF CKA Exam Dumps<\/b><\/a><b> and Practice Test Dumps<\/b><\/h2>\n<p>&nbsp;<\/p>\n<h3><b>Question 141<\/b><\/h3>\n<p><b>Which command opens an interactive shell inside a running container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl shell<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl exec -it<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl enter<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl connect<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl exec -it command allows an administrator to start an interactive process inside a running container. The -i option keeps standard input available, while -t allocates a terminal. This is commonly used for troubleshooting applications, checking files, testing connectivity, or examining processes from inside the container environment. When a Pod contains multiple containers, the -c option can identify the intended container. This technique is especially useful when logs alone do not provide enough information to diagnose a running workload.<\/span><\/p>\n<h3><b>Question 142<\/b><\/h3>\n<p><b>Which object provides a stable identity for StatefulSet Pods?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Deployment<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ReplicaSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DaemonSet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StatefulSet<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A StatefulSet manages applications that require stable identities for their Pods. Its Pods receive predictable names based on ordinal positions, such as web-0 and web-1. These identities remain associated with the corresponding StatefulSet replicas even when individual Pods are recreated. StatefulSets are useful for workloads that need stable network identities, persistent storage associations, or ordered deployment and termination behavior. This differs from ordinary replicated workloads where Pod names can change when replacement Pods are created.<\/span><\/p>\n<h3><b>Question 143<\/b><\/h3>\n<p><b>Which field specifies a container&#8217;s memory request?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">resources.requests.memory<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">resources.memory.request<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">memory.resources.request<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">requests.resources.ram<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A container&#8217;s memory request is defined under resources.requests.memory. The request represents the amount of memory Kubernetes uses when making scheduling decisions for the Pod. It does not necessarily represent the maximum memory the process can consume. That behavior is controlled by the memory limit. Resource requests help the scheduler determine whether a node has sufficient allocatable capacity for the workload. Correctly defining them is important because overly large requests can prevent scheduling, while unrealistically small values can produce inaccurate resource planning.<\/span><\/p>\n<h3><b>Question 144<\/b><\/h3>\n<p><b>Which command displays the kubelet service status on a systemd node?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">systemctl show kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">service kubelet list<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">systemctl status kubelet<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl status kubelet<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">On a systemd-based Linux node, systemctl status kubelet displays the current status of the kubelet service. It can reveal whether the service is active, stopped, failed, or repeatedly restarting. The output also provides recent service messages that can help identify configuration or startup problems. This is useful during node troubleshooting because the kubelet is responsible for managing Pods assigned to that node. If the kubelet is unhealthy, workloads may stop being managed correctly even though the node itself remains reachable.<\/span><\/p>\n<h3><b>Question 145<\/b><\/h3>\n<p><b>Which field determines how many Pods a Job may run simultaneously?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">activeDeadlineSeconds<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">completionMode<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">parallelism<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">successLimit<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The parallelism field controls how many Pods belonging to a Job may run concurrently. Increasing this value allows multiple instances of the batch task to execute at the same time, potentially reducing overall completion time. It differs from completions, which specifies how many successful executions are required for the Job to finish. The appropriate value depends on the workload and available cluster resources. Excessive parallelism can create unnecessary resource pressure, while a very low value may make batch processing slower.<\/span><\/p>\n<h3><b>Question 146<\/b><\/h3>\n<p><b>Which object controls voluntary disruption for a replicated workload?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PodDisruptionBudget<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LimitRange<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PriorityClass<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A PodDisruptionBudget helps maintain application availability during voluntary disruptions. It can specify either a minimum number of available Pods or a maximum number of unavailable Pods for a selected workload. This is particularly relevant during operations such as node maintenance or controlled Pod eviction. A PodDisruptionBudget does not prevent involuntary failures such as hardware crashes or severe resource pressure. Instead, it gives Kubernetes and administrators guidance about how much voluntary disruption the application can tolerate while remaining operational.<\/span><\/p>\n<h3><b>Question 147<\/b><\/h3>\n<p><b>Which command lists the contexts configured in kubeconfig?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config get-contexts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl config list<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl contexts show<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl get contexts<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl config get-contexts command lists the contexts available in the current kubeconfig. Each context can identify a cluster, user, and namespace combination. The output also indicates which context is currently active. This command is useful when administrators manage several Kubernetes environments and need to select the correct target before running commands. Unlike current-context, which reports only the active context, get-contexts provides the broader set of configured context choices.<\/span><\/p>\n<h3><b>Question 148<\/b><\/h3>\n<p><b>Which volume type exposes Pod metadata to a container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">configMap<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">secret<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">downwardAPI<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">metadataVolume<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The downwardAPI volume allows selected Pod and container metadata to be made available to a container as files. Information such as Pod labels, annotations, and certain resource-related values can be exposed this way. This allows applications to discover information about their own execution environment without requiring direct access to the Kubernetes API. The approach is useful for applications that need contextual metadata while maintaining a clean separation from cluster administration credentials.<\/span><\/p>\n<h3><b>Question 149<\/b><\/h3>\n<p><b>Which command applies a manifest while creating or updating its objects?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl sync<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl apply<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl merge<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl publish<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl apply command creates or updates Kubernetes resources based on a manifest. It is commonly used for declarative resource management because the manifest represents the desired configuration. When the configuration changes, applying the updated manifest allows Kubernetes to reconcile the object toward that desired state. This differs from commands designed for imperative creation of individual resources. Declarative management through manifests is especially useful when configurations need to be maintained consistently and reapplied across environments.<\/span><\/p>\n<h3><b>Question 150<\/b><\/h3>\n<p><b>Which storage mode presents a volume as a filesystem inside a container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">block<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">raw<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">device<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Filesystem<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 4<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The Filesystem value for a volume&#8217;s volumeMode makes the storage available to the container as a mounted filesystem. The alternative Block mode exposes the storage as a raw block device, allowing applications that require direct block-level access to use it. The choice depends on the workload&#8217;s storage requirements and the capabilities of the underlying storage provider. Filesystem mode is the common choice for applications that expect ordinary directories and files rather than a raw device.<\/span><\/p>\n<h3><b>Question 151<\/b><\/h3>\n<p><b>Which command displays the current Kubernetes cluster endpoint information?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl cluster-info<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl cluster-url<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl endpoint-info<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl server-info<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl cluster-info command displays information about the Kubernetes control plane and other registered cluster services. It is useful as a quick connectivity check when beginning cluster troubleshooting. If the command cannot communicate with the API server, the administrator can investigate kubeconfig settings, network connectivity, authentication, or control-plane availability. The command does not provide complete cluster health diagnostics, but it offers a convenient first indication that kubectl can reach the configured Kubernetes environment.<\/span><\/p>\n<h3><b>Question 152<\/b><\/h3>\n<p><b>Which resource lets administrators define storage provisioning behavior?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">PersistentVolume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VolumePolicy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">StorageClass<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ProvisioningRule<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A StorageClass describes a class of storage and defines parameters used for dynamic volume provisioning. It can identify a provisioner and include settings that influence how storage is created. PersistentVolumeClaims can request a StorageClass when they need dynamically provisioned storage. This abstraction allows different storage types to be offered to workloads without requiring application manifests to contain provider-specific provisioning details. Administrators can create multiple StorageClasses for different performance, replication, or storage-backend requirements.<\/span><\/p>\n<h3><b>Question 153<\/b><\/h3>\n<p><b>Which container hook runs immediately before termination?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">startup<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">shutdown<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">preStop<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">beforeExit<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The preStop lifecycle hook executes immediately before a container is terminated, allowing the application to perform shutdown-related actions. It can be useful for tasks such as notifying another system, completing cleanup, or allowing an application to stop accepting new work. The hook runs as part of the Pod termination process and should complete within the available termination grace period. Administrators should design the hook carefully because a long-running or failed cleanup operation can affect how gracefully the container shuts down.<\/span><\/p>\n<h3><b>Question 154<\/b><\/h3>\n<p><b>Which RBAC object contains a reusable set of permissions?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ClusterRole<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RoleBinding<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ServiceAccount<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">SubjectAccessReview<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A ClusterRole defines a set of RBAC permissions that can be reused by bindings. Despite its name, a ClusterRole can describe permissions for both cluster-scoped resources and namespaced resources. A Role is another permission definition that exists within a namespace. Bindings then associate these permission definitions with users, groups, or ServiceAccounts. Keeping permission rules separate from their assignments makes RBAC configuration easier to reuse and manage across different subjects or namespaces.<\/span><\/p>\n<h3><b>Question 155<\/b><\/h3>\n<p><b>Which command removes a Kubernetes resource immediately by name?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl erase<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl delete<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl remove<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl destroy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl delete command removes Kubernetes resources such as Pods, Deployments, Services, and other objects. Administrators can specify the resource type and object name, or use a manifest to identify resources for deletion. Deletion behavior can be influenced by object ownership and finalizers, so an object may remain temporarily while required cleanup occurs. This command should be used carefully because removing a controller-managed resource can trigger significant changes to the workloads it manages.<\/span><\/p>\n<h3><b>Question 156<\/b><\/h3>\n<p><b>Which mechanism can expose a Secret as files inside a container?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">secretRef<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">secretEnv<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Secret volume<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">credentialMount<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">A Secret can be mounted as a volume so that its keys become files within a container filesystem. This allows applications to consume credentials or other sensitive configuration without embedding those values directly into container images. Kubernetes manages the Secret object separately from the Pod specification, while the volume provides the container with access to the selected data. Administrators should still apply appropriate RBAC permissions because access to the Secret object determines who can retrieve its underlying values.<\/span><\/p>\n<h3><b>Question 157<\/b><\/h3>\n<p><b>Which node condition indicates insufficient available memory?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">MemoryPressure<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">MemoryShortage<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LowMemory<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RAMPressure<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 1<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The MemoryPressure node condition indicates that a node is experiencing memory pressure. Kubernetes can respond to resource pressure through eviction mechanisms when available resources become critically constrained. Administrators can inspect node conditions to determine whether memory availability is contributing to workload problems. Memory pressure may result from workloads consuming substantial memory or from insufficient node capacity. Investigating resource requests, limits, actual consumption, and node capacity can help identify the cause before changing workloads or adding capacity.<\/span><\/p>\n<h3><b>Question 158<\/b><\/h3>\n<p><b>Which scheduling stage removes nodes that cannot satisfy Pod requirements?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Binding<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Scoring<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Filtering<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reservation<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">During scheduling, the filtering stage removes nodes that cannot satisfy the Pod&#8217;s requirements. Factors can include resource requests, taints, affinity rules, and other scheduling constraints. The remaining feasible nodes then proceed to scoring, where Kubernetes determines which suitable node is preferable. If no nodes survive filtering, the Pod remains unscheduled until conditions change. Understanding filtering helps explain why a Pod can remain Pending even when nodes appear available, because available capacity alone does not guarantee that every scheduling constraint is satisfied.<\/span><\/p>\n<h3><b>Question 159<\/b><\/h3>\n<p><b>Which resource defines the maximum number of stored object versions for a ConfigMap?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ResourceQuota<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">LimitRange<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RevisionHistoryLimit<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ConfigMapDataPolicy<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 3<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">revisionHistoryLimit is associated with workload controllers such as Deployments and controls how many old ReplicaSet revisions are retained for rollback purposes. It does not define versions for ConfigMaps themselves. Retaining historical workload revisions can make rollback possible while limiting unnecessary object accumulation. Administrators should choose a value that provides sufficient recovery history without retaining excessive obsolete revisions. This setting is particularly relevant when applications undergo frequent Deployment updates and rollback capability needs to remain available.<\/span><\/p>\n<h3><b>Question 160<\/b><\/h3>\n<p><b>Which command checks authorization for a specific Kubernetes action?<\/b><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl auth check<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl auth can-i<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl permission-test<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">kubectl access verify<\/span><\/li>\n<\/ol>\n<p><b>Correct Answer: 2<\/b><\/p>\n<p><b>Explanation:<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The kubectl auth can-i command checks whether the current identity is authorized to perform a specified Kubernetes action. For example, it can determine whether a user or ServiceAccount may create Pods, read Secrets, or delete Deployments. Administrators can also evaluate permissions in the context of another identity when appropriate authorization exists. This makes the command valuable for diagnosing RBAC problems because it tests authorization directly rather than requiring administrators to infer permissions from multiple Role and RoleBinding objects.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>View Full CNCF CKA Exam Dumps and Practice Test Dumps &nbsp; Question 141 Which command opens an interactive shell inside a running container? kubectl shell kubectl exec -it kubectl enter kubectl connect Correct Answer: 2 Explanation: The kubectl exec -it command allows an administrator to start an interactive process inside a running container. The -i [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1648,1647],"tags":[],"_links":{"self":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21069"}],"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=21069"}],"version-history":[{"count":1,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21069\/revisions"}],"predecessor-version":[{"id":21070,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/posts\/21069\/revisions\/21070"}],"wp:attachment":[{"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/media?parent=21069"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/categories?post=21069"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.examlabs.com\/certification\/wp-json\/wp\/v2\/tags?post=21069"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}