View Full CNCF CKA Exam Dumps and Practice Test Dumps

 

Question 321

Which CronJob field defines its execution schedule?

1. triggerExpression
2. runPattern
3. executionPlan
4. schedule

Correct Answer: 4

Explanation:

The schedule field defines when a CronJob should create Jobs. Kubernetes uses cron-style scheduling syntax for this field, allowing administrators to specify recurring execution patterns such as hourly, daily, or weekly tasks. The CronJob controller evaluates the schedule and creates Job objects according to the configured timing. This makes CronJobs suitable for recurring backups, reports, maintenance operations, and other periodic tasks. The schedule controls when executions begin but does not determine the behavior of the generated Job itself. That behavior is described separately through the CronJob’s jobTemplate.

Question 322

Which CronJob policy prevents overlapping executions?

1. Forbid
2. Allow
3. Replace
4. ConcurrentBlock

Correct Answer: 1

Explanation:

The Forbid concurrency policy prevents a CronJob from starting a new Job when a previous Job created by that same CronJob is still running. The scheduled occurrence is skipped instead. This is useful when overlapping executions could corrupt data, duplicate work, or consume excessive resources. Allow permits concurrent executions, while Replace terminates the currently running Job and starts the newer one. Concurrency policy applies to Jobs created by the same CronJob and does not automatically coordinate executions originating from separate CronJob objects.

Question 323

Which CronJob setting temporarily stops future Job creation?

1. pauseExecution
2. suspend
3. disableSchedule
4. holdRuns

Correct Answer: 2

Explanation:

The CronJob suspend field can temporarily stop the controller from creating subsequent Jobs. Setting it to true suspends future executions while leaving the CronJob itself present. Jobs that have already started are not stopped simply because the CronJob becomes suspended. When suspension is removed, missed executions may be handled according to the CronJob’s scheduling rules and deadline configuration. This feature is useful when administrators need to temporarily pause recurring maintenance or batch processing without deleting the CronJob definition.

Question 324

Which CronJob field limits how late a missed Job may start?

1. delayLimitSeconds
2. missedRunWindow
3. startingDeadlineSeconds
4. lateStartTimeout

Correct Answer: 3

Explanation:

startingDeadlineSeconds defines how long after its scheduled time a missed CronJob execution may still be started. If the delay exceeds the configured deadline, Kubernetes skips that particular execution. This is useful for tasks where running an old missed operation later would no longer be useful. For example, a periodic data collection task may need to run close to its intended time rather than several hours afterward. The field applies to delayed Job creation and does not determine the normal recurring schedule itself.

Question 325

Which CronJob field controls retained successful Job history?

1. completedRunLimit
2. successHistoryLimit
3. finishedJobCount
4. successfulJobsHistoryLimit

Correct Answer: 4

Explanation:

successfulJobsHistoryLimit controls how many successfully completed Jobs created by a CronJob are retained. Keeping a limited history prevents completed Job objects from accumulating indefinitely. The default behavior retains several successful Jobs, while setting the value to zero prevents successful finished Jobs from being retained through this history mechanism. A separate field controls failed Job history. These settings are useful for managing clusters where recurring tasks create many completed Job objects. They affect retained Job history rather than changing the CronJob’s execution frequency or success criteria.

Question 326

Which Job field specifies required successful completions?

1. completions
2. successTarget
3. completionGoal
4. requiredRuns

Correct Answer: 1

Explanation:

The Job completions field specifies how many successful Pod completions are required for the Job to be considered complete. This allows a Job to represent workloads that require multiple successful executions rather than just one. The Job controller tracks successful completions and continues creating or managing Pods until the configured target is reached. This differs from parallelism, which controls how many Pods may run concurrently. Understanding these two fields is important when designing batch workloads because a Job can require many total completions while limiting the number of simultaneous workers.

Question 327

Which Job field controls simultaneous Pod execution?

1. workerLimit
2. parallelism
3. concurrencyCount
4. activeWorkers

Correct Answer: 2

Explanation:

The parallelism field controls the maximum number of Pods that a Job attempts to run concurrently. It is useful for batch workloads that can divide work among multiple workers. A Job can have a larger completion target while restricting the number of active Pods through parallelism. This distinction allows administrators to control cluster resource consumption while still completing a large amount of work. Increasing parallelism may improve throughput when sufficient resources are available, but it can also increase CPU, memory, storage, and network demand.

Question 328

Which Job setting removes finished Jobs after a delay?

1. cleanupAfterFinish
2. expirationSeconds
3. ttlSecondsAfterFinished
4. completedObjectTimeout

Correct Answer: 3

Explanation:

ttlSecondsAfterFinished allows Kubernetes to automatically clean up a finished Job after the configured number of seconds. The mechanism can apply after the Job reaches a completed or failed terminal state. It is useful when administrators want historical Job objects to remain available temporarily for inspection but do not want them retained indefinitely. Automatic cleanup also helps prevent large numbers of completed Jobs from accumulating in a busy cluster. The setting controls the lifetime after completion rather than the Job’s execution duration or retry behavior.

Question 329

Which Job field limits retry attempts after Pod failures?

1. retryCeiling
2. failureRetryCount
3. podRetryMaximum
4. backoffLimit

Correct Answer: 4

Explanation:

backoffLimit specifies how many retries are permitted for a Job after failed Pod executions before Kubernetes considers the Job failed. This allows administrators to control how aggressively a failed batch workload should be retried. A low value prevents endless repeated attempts when an application has a persistent problem, while a higher value provides more opportunities for transient failures to recover. The setting concerns retry behavior rather than the number of successful completions or simultaneous Pods. When a Job repeatedly fails, checking its retry count and Pod termination reasons can clarify the cause.

Question 330

Which Job policy stops creating Pods after a deadline?

1. activeDeadlineSeconds
2. executionTimeout
3. jobLifetimeLimit
4. runtimeDeadline

Correct Answer: 1

Explanation:

activeDeadlineSeconds specifies the maximum amount of time a Job is allowed to remain active. When the deadline is exceeded, Kubernetes terminates the Job rather than allowing it to continue indefinitely. This is useful for workloads that should complete within a known operational window. The deadline applies to the Job’s active lifetime rather than merely limiting an individual container execution. Administrators can use it to prevent stalled batch workloads from consuming resources indefinitely. When investigating a Job that stops unexpectedly, its deadline configuration should be checked alongside Pod termination information.

Question 331

Which Pod field controls automatic container restart behavior?

1. retryPolicy
2. restartPolicy
3. recoveryMode
4. restartStrategy

Correct Answer: 2

Explanation:

The Pod restartPolicy determines how kubelet handles terminated containers within the Pod. Common values include Always, OnFailure, and Never, although the allowed behavior depends on the workload type. Deployments normally use the default behavior that keeps containers running, while Jobs commonly use Never or OnFailure. Choosing the correct policy is important because it determines whether a terminated process is restarted automatically. It does not determine how many replicas a workload should have or how often a CronJob creates new Jobs.

Question 332

Which restart policy is commonly used for a one-shot successful task?

1. Always
2. Retry
3. Never
4. Persistent

Correct Answer: 3

Explanation:

The Never restart policy tells Kubernetes not to restart containers after they terminate. It is suitable for Pods designed to perform a finite task where the Pod’s completion state should remain available for inspection. Jobs commonly use this behavior or OnFailure, depending on the desired retry model. Always is associated with continuously running workloads, while the other listed values are not standard Kubernetes restart-policy values. Selecting the appropriate restart behavior is especially important for batch processing because repeated restarts can alter how task failures are handled.

Question 333

Which Pod-level setting enables host networking?

1. hostNetwork
2. nodeNetwork
3. useHostNet
4. hostInterface

Correct Answer: 1

Explanation:

The hostNetwork setting allows a Pod to use the network namespace of the node on which it runs. Containers configured this way can access the node’s network interfaces directly rather than receiving the normal isolated Pod network namespace. This behavior can be required by specialized node-level applications but reduces some network isolation. Administrators should use host networking deliberately because it can create port conflicts and expose workloads more directly to node networking. When troubleshooting a Pod with unexpected network addresses, checking whether hostNetwork is enabled can explain the behavior.

Question 334

Which Pod setting exposes the node’s process namespace?

1. hostProcessNamespace
2. nodePID
3. hostPID
4. shareNodeProcesses

Correct Answer: 3

Explanation:

hostPID allows containers in a Pod to use the host’s process ID namespace. This can make processes running on the node visible from inside the Pod, depending on permissions and configuration. Such access is generally reserved for specialized infrastructure or diagnostic workloads because it reduces process isolation between the workload and the host. It is different from sharing a process namespace only among containers within the same Pod. Administrators should carefully evaluate security implications before enabling host-level namespace access.

Question 335

Which Pod setting enables access to the host IPC namespace?

1. hostIPC
2. nodeIPC
3. sharedIPC
4. hostInterprocess

Correct Answer: 1

Explanation:

The hostIPC field allows a Pod to use the host’s IPC namespace. IPC mechanisms such as shared memory can therefore be accessible across the host and the Pod, depending on the workload and permissions involved. This configuration can be required by specialized applications but reduces the normal namespace isolation provided to Pods. Host-level namespace options should be enabled only when necessary because they can increase the security impact of a compromised workload. Administrators troubleshooting applications that depend on host IPC should inspect the Pod’s security and namespace settings.

Question 336

Which Pod setting allows sharing process IDs only among its containers?

1. podProcessSharing
2. shareProcessNamespace
3. containerPIDMode
4. internalProcessShare

Correct Answer: 2

Explanation:

shareProcessNamespace allows containers belonging to the same Pod to share a process namespace. This permits processes in one container to be visible to another container within that Pod. It can be useful for tightly coupled sidecars or diagnostic scenarios where one container needs awareness of processes running in another. Unlike hostPID, it does not expose the entire node’s process namespace. Because process visibility changes the normal isolation boundary between containers, administrators should enable it only when the application architecture requires this behavior.

Question 337

Which Pod field controls the maximum graceful shutdown interval?

1. shutdownTimeout
2. terminationGracePeriodSeconds
3. gracefulStopLimit
4. podExitWindow

Correct Answer: 2

Explanation:

terminationGracePeriodSeconds specifies how long Kubernetes normally allows a Pod’s containers to terminate gracefully after termination begins. During this period, applications can perform cleanup before the runtime eventually forces termination if processes remain active. This setting is important for workloads that need time to flush data, close connections, or finish in-flight operations. A very short period can interrupt cleanup, while an unnecessarily long period can delay replacement or shutdown operations. Administrators should choose a value appropriate to the application’s actual shutdown behavior.

Question 338

Which lifecycle hook runs immediately before container termination?

1. preStop
2. beforeExit
3. shutdownHook
4. terminationStart

Correct Answer: 1

Explanation:

The preStop lifecycle hook is executed before a container is terminated. It can be used to perform application-specific shutdown actions, such as notifying another component or initiating graceful cleanup. The hook operates within the container lifecycle and is separate from the application’s own signal-handling logic. Administrators should ensure that the hook completes within the available termination grace period. If a workload depends on cleanup commands but they appear not to execute correctly, checking the lifecycle configuration and container termination timing can help identify the problem.

Question 339

Which lifecycle hook runs after a container starts?

1. startupHook
2. postStart
3. afterLaunch
4. initializationHook

Correct Answer: 2

Explanation:

The postStart lifecycle hook is invoked after a container is created, although its execution is not necessarily guaranteed to occur before the container’s main process begins. It can be used for initialization-related actions that need to occur as part of the container lifecycle. Administrators should not treat it as a strict replacement for application startup logic because timing can overlap with the main process. When a workload relies on initialization ordering, the container command itself or an appropriate initialization mechanism may provide more predictable behavior.

Question 340

Which probe type prevents readiness and liveness checks until startup succeeds?

1. healthGate
2. initializationProbe
3. startupProbe
4. bootCheck

Correct Answer: 3

Explanation:

A startupProbe is designed for applications that require significant initialization time. When configured, Kubernetes waits for the startup probe to succeed before beginning liveness or readiness probing for that container. This prevents a slow-starting application from being restarted or considered unready prematurely while it is still initializing. Once startup succeeds, the other configured probes can take over their respective responsibilities. This makes startup probes particularly useful for applications with long initialization phases, while readiness and liveness probes address traffic eligibility and ongoing health.