View Full Linux Foundation KCNA Exam Dumps and Practice Test Dumps.

 

Question 181

Which Kubernetes probe determines whether a container is ready to receive network traffic?

1. Liveness probe
2. Startup probe
3. Readiness probe
4. Resource probe

Correct Answer: 3

Explanation

A readiness probe determines whether a container is ready to receive traffic from Kubernetes Services. When the readiness check fails, Kubernetes can remove the Pod from the endpoints used by a Service while keeping the container running. This is useful during application startup, temporary overload, or other situations where the application should remain running but should not receive requests. A liveness probe is used to determine whether a container should be restarted, while a startup probe helps accommodate slow-starting applications. Readiness is therefore primarily concerned with traffic availability.

Question 182

Which Kubernetes probe is primarily used to determine whether a container should be restarted?

1. Liveness probe
2. Readiness probe
3. Startup probe
4. Network probe

Correct Answer: 1

Explanation

A liveness probe checks whether an application inside a container is functioning properly. If the liveness probe repeatedly fails according to its configured thresholds, Kubernetes can restart the affected container. This can help recover applications that become stuck or otherwise unhealthy while the container process remains running. A readiness probe instead controls whether a Pod receives traffic, while a startup probe is designed to give slow-starting applications additional time to initialize. Properly configured liveness probes can improve application resilience without requiring manual intervention.

Question 183

Which Kubernetes probe is especially useful for applications that require a long time to start?

1. Readiness probe
2. Startup probe
3. Liveness probe
4. Service probe

Correct Answer: 2

Explanation

A startup probe is designed for applications that may take a significant amount of time to initialize. Kubernetes can use the startup probe to determine when the application has successfully started before applying liveness and readiness checks in the normal way. This prevents a slow-starting application from being incorrectly restarted because its liveness probe begins failing too early. Startup probes are especially useful for applications that perform lengthy initialization tasks, load large datasets, or require considerable startup processing before becoming operational.

Question 184

What is the primary purpose of an init container in a Kubernetes Pod?

1. To expose the Pod externally
2. To provide permanent storage
3. To perform initialization tasks before application containers start
4. To replace the kubelet

Correct Answer: 3

Explanation

An init container runs before the regular application containers in a Pod and is commonly used to perform initialization tasks. Examples include preparing files, waiting for a required dependency, performing setup operations, or generating initial configuration. Init containers must complete successfully before the next initialization stage or application containers can proceed. Unlike ordinary application containers, they are designed for setup rather than continuous application execution. This separation allows initialization logic to be handled independently from the main application image and can simplify application startup workflows.

Question 185

What happens when a Kubernetes Pod contains multiple containers?

1. Each container receives a separate Pod IP
2. The containers can share the Pod’s network and configured volumes
3. Every container must run on a different node
4. Each container belongs to a different Namespace

Correct Answer: 2

Explanation

Multiple containers in the same Kubernetes Pod share certain resources. In particular, they share the Pod’s network namespace, meaning they normally use the same Pod IP and can communicate through localhost. Containers can also share storage when the Pod defines and mounts common volumes. This model is useful for tightly coupled components, such as an application container working alongside a logging or proxy sidecar. Containers in one Pod are scheduled together and run on the same node. The Pod therefore provides a shared execution environment for closely related containers.

Question 186

Which Kubernetes QoS class is normally assigned when every container in a Pod has CPU and memory requests equal to their limits?

1. Guaranteed
2. BestEffort
3. Burstable
4. Standard

Correct Answer: 1

Explanation

A Pod can receive the Guaranteed Quality of Service class when its containers have CPU and memory requests configured and those requests are equal to their corresponding limits, subject to Kubernetes QoS classification rules. Guaranteed workloads generally receive stronger resource guarantees than lower QoS classes during resource pressure. BestEffort applies when containers have no CPU or memory requests or limits, while Burstable covers many configurations that fall between those two categories. QoS classification can influence how Kubernetes treats Pods when a node experiences resource pressure.

Question 187

Which Kubernetes QoS class generally applies to a Pod whose containers have no CPU or memory requests or limits?

1. Guaranteed
2. Burstable
3. BestEffort
4. Priority

Correct Answer: 3

Explanation

BestEffort is the Kubernetes QoS class generally assigned to a Pod when none of its containers have CPU or memory requests or limits configured. Such Pods do not have explicitly reserved compute resources. During node resource pressure, Kubernetes may treat BestEffort workloads differently from Pods with configured resource requirements. Burstable applies when some resource requests or limits are defined but the Pod does not meet the conditions for Guaranteed. Guaranteed requires stricter resource configuration. Understanding QoS classes helps explain how Kubernetes categorizes workloads and handles them during resource contention.

Question 188

Which field in a Kubernetes container specification defines the amount of CPU or memory the container is guaranteed for scheduling purposes?

1. Limits
2. Requests
3. Selectors
4. Replicas

Correct Answer: 2

Explanation

Resource requests specify the amount of CPU or memory that Kubernetes uses when determining whether a node has sufficient resources to schedule a Pod. For example, a container may request 500m CPU and 256Mi memory. The scheduler uses these requests when evaluating available node capacity. Resource limits, in contrast, define the maximum amount of a resource that a container can use according to Kubernetes resource enforcement behavior. Correctly setting requests helps Kubernetes make more appropriate scheduling decisions and reduces the risk of placing workloads on nodes without adequate capacity.

Question 189

What is the primary purpose of a container resource limit in Kubernetes?

1. To define the maximum resource consumption allowed for the container
2. To select the target node
3. To create a Service
4. To define the number of Pod replicas

Correct Answer: 1

Explanation

A resource limit defines an upper boundary for how much CPU or memory a container can consume. CPU limits can result in CPU throttling when the container attempts to use more CPU than its configured limit. Memory limits are enforced differently, and exceeding a memory limit can result in the container being terminated due to an out-of-memory condition. Requests are used primarily by the scheduler when making placement decisions. Limits therefore help establish resource consumption boundaries and can protect nodes from unrestricted use by individual containers.

Question 190

Which Deployment strategy gradually replaces old Pods with new Pods during an application update?

1. Recreate
2. RollingUpdate
3. StaticUpdate
4. ReplaceAll

Correct Answer: 2

Explanation

The RollingUpdate strategy gradually replaces old Pods with new Pods during a Deployment update. This approach can maintain application availability by avoiding the simultaneous removal of all existing Pods. Kubernetes controls the rollout according to settings such as maxUnavailable and maxSurge. The Recreate strategy instead terminates existing Pods before creating replacement Pods, which can cause downtime depending on the application. Rolling updates are widely used for stateless applications because they allow new versions to be introduced progressively while maintaining a desired level of service availability.

Question 191

Which kubectl command can be used to check the progress of a Deployment rollout?

1. kubectl rollout status
2. kubectl rollout check
3. kubectl deployment status
4. kubectl get rollout

Correct Answer: 1

Explanation

The kubectl rollout status command displays the progress of a Deployment rollout. It can be used to determine whether the updated ReplicaSet and its Pods have successfully reached the desired state. This is particularly useful during automated deployments because administrators or scripts can wait for the rollout to complete before continuing with subsequent operations. Other rollout-related commands can display revision history or undo changes. Monitoring rollout status helps identify updates that are still progressing or have encountered problems during deployment.

Question 192

Which kubectl command can be used to undo a previous Deployment rollout?

1. kubectl deployment rollback
2. kubectl rollout undo
3. kubectl rollback deployment
4. kubectl revert deployment

Correct Answer: 2

Explanation

The kubectl rollout undo command can be used to roll a Deployment back to a previous revision. This is useful when a newly deployed application version causes errors or unexpected behavior. Kubernetes maintains Deployment revision information that allows previous versions to be restored when available. Administrators can inspect rollout history using kubectl rollout history and then perform an undo operation. Rollbacks are an important part of controlled application deployment because they provide a mechanism for recovering from problematic updates without manually recreating the entire workload configuration.

Question 193

Which Kubernetes object can be used to prevent too many replicated application Pods from being voluntarily disrupted at the same time?

1. ResourceQuota
2. PodDisruptionBudget
3. NetworkPolicy
4. LimitRange

Correct Answer: 2

Explanation

A PodDisruptionBudget, or PDB, helps maintain application availability during voluntary disruptions such as node maintenance or cluster administration activities. It specifies availability requirements for a group of Pods, commonly using minimum available or maximum unavailable settings. A PDB does not prevent every possible form of Pod termination, particularly involuntary failures. ResourceQuota limits resource consumption, NetworkPolicy controls network traffic, and LimitRange establishes resource defaults or constraints within a Namespace. PodDisruptionBudget is therefore specifically associated with maintaining availability during supported voluntary disruption scenarios.

Question 194

Which Kubernetes object is used to define default or maximum resource constraints for containers within a Namespace?

1. LimitRange
2. Service
3. ConfigMap
4. StatefulSet

Correct Answer: 1

Explanation

A LimitRange allows administrators to define resource constraints within a Namespace. It can establish default CPU and memory requests or limits for containers and can also enforce minimum or maximum resource values. This helps ensure that workloads do not omit important resource settings and provides better control over resource usage. A ResourceQuota works at the aggregate Namespace level, limiting the total amount of selected resources that can be consumed. LimitRange instead focuses on individual Pods or containers and their resource configuration.

Question 195

Which Kubernetes object limits the aggregate amount of resources that can be consumed within a Namespace?

1. LimitRange
2. ResourceQuota
3. PodDisruptionBudget
4. ServiceAccount

Correct Answer: 2

Explanation

A ResourceQuota limits the total amount of selected resources that can be consumed by resources within a Namespace. Administrators can use quotas to control aggregate CPU, memory, object counts, and other supported resource types. This helps prevent a single Namespace or team from consuming an excessive share of cluster resources. LimitRange operates at the individual container or Pod level by defining defaults and constraints. ResourceQuota is therefore useful in multi-team clusters where administrators need to establish boundaries for overall Namespace consumption.

Question 196

Which Kubernetes object provides an identity that Pods can use when interacting with the Kubernetes API?

1. Service
2. ServiceAccount
3. ConfigMap
4. PersistentVolume

Correct Answer: 2

Explanation

A ServiceAccount provides an identity for processes running inside Pods when they need to interact with the Kubernetes API or other systems that recognize Kubernetes identities. Permissions for a ServiceAccount can be controlled using RBAC resources such as Roles and RoleBindings. Modern Kubernetes environments use projected or mounted credentials according to the cluster’s configuration and security practices. Services provide network endpoints, ConfigMaps store configuration, and PersistentVolumes provide storage. ServiceAccounts are therefore an important part of workload identity and authorization in Kubernetes.

Question 197

Which Kubernetes authorization mechanism determines what actions a user or ServiceAccount is allowed to perform?

1. RBAC
2. CNI
3. CSI
4. CRI

Correct Answer: 1

Explanation

Role-Based Access Control, or RBAC, controls which actions identities can perform against Kubernetes resources. RBAC uses resources such as Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings to associate permissions with users, groups, or ServiceAccounts. A Role usually defines permissions within a Namespace, while a ClusterRole can contain cluster-scoped or reusable permissions. CNI concerns container networking, CSI concerns storage integration, and CRI defines the container runtime interface. RBAC is therefore the primary Kubernetes authorization mechanism for controlling access to API resources.

Question 198

Which Kubernetes resource defines a set of permissions within a specific Namespace?

1. ClusterRole
2. Role
3. ServiceAccount
4. NamespaceQuota

Correct Answer: 2

Explanation

A Role defines a set of permissions for Kubernetes resources within a specific Namespace. It uses rules that specify allowed API groups, resources, and verbs such as get, list, create, update, or delete. The Role itself does not grant permissions to an identity until it is associated through a RoleBinding. A ClusterRole can define permissions at cluster scope and can also be used in some namespace-scoped bindings. Roles are therefore commonly used when access should be limited to resources within one particular Namespace.

Question 199

Which Kubernetes resource associates a Role with a user, group, or ServiceAccount within a Namespace?

1. ClusterRoleBinding
2. RoleBinding
3. NetworkPolicy
4. ResourceQuota

Correct Answer: 2

Explanation

A RoleBinding grants the permissions defined by a Role to specified subjects such as users, groups, or ServiceAccounts within a Namespace. The Role contains the permission rules, while the RoleBinding establishes who receives those permissions. A RoleBinding can also reference a ClusterRole, allowing cluster-level role definitions to be applied within a particular Namespace. ClusterRoleBinding is used when permissions should apply at the cluster level. This separation between defining permissions and assigning them is a fundamental concept in Kubernetes RBAC.

Question 200

Which Kubernetes resource controls allowed network traffic to and from selected Pods?

1. NetworkPolicy
2. ResourceQuota
3. ServiceAccount
4. ConfigMap

Correct Answer: 1

Explanation

A NetworkPolicy defines rules controlling network traffic to and from selected Pods. Policies can specify allowed ingress and egress traffic based on factors such as Pod selectors, Namespace selectors, IP blocks, and ports. NetworkPolicy enforcement depends on the networking implementation used by the cluster; a CNI plugin must support the relevant policy functionality. ResourceQuota manages aggregate resource consumption, ServiceAccounts provide workload identities, and ConfigMaps store configuration. NetworkPolicies are therefore an important Kubernetes mechanism for implementing network segmentation and restricting unnecessary communication between workloads.