Application Observability and Maintenance →hardMultiple ChoiceObjective-mapped

CKAD Application Observability and Maintenance Practice Question

A pod has a startup probe with failureThreshold: 30 and periodSeconds: 10. The application takes up to 5 minutes to start. What should be changed to ensure the startup probe does not kill the container prematurely?

⚠ Common exam trap

The trap is that candidates may consider setting initialDelaySeconds as a valid solution to extend the probe's grace period. However, for startup probes, the best practice is to adjust failureThreshold and periodSeconds to cover the expected startup time, rather than adding an initial delay which defeats the purpose of immediate probing.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Increase failureThreshold to 40

Increasing failureThreshold to 40 (from 30) with periodSeconds: 10 gives a total timeout of 40 × 10 = 400 seconds (6 minutes 40 seconds), which exceeds the 5-minute startup time. Setting initialDelaySeconds (Option D) would also delay the first probe execution, but best practices recommend adjusting the probe's failure threshold and interval instead of using an initial delay for startup probes, as the purpose of a startup probe is to start probing immediately and replace the need for an initial delay.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Increase failureThreshold to 40
Why this is correct
Increasing failureThreshold to 40 allows the startup probe to fail up to 40 consecutive times before the kubelet declares the container failed. Because the existing periodSeconds is 10, the new total grace period is 40 × 10 = 400 seconds (6m40s), which comfortably exceeds the application's 5-minute (300-second) startup requirement. This is the correct modification because it directly extends the cumulative time the kubelet tolerates an unready container without changing how frequently the probe runs or delaying the start of probing. The extra 100 seconds of tolerance eliminates the risk of premature termination while still allowing the probe to eventually catch a genuinely broken container.
✗
Change periodSeconds to 5
Why it's wrong here
Changing periodSeconds to 5 reduces the interval between individual probe executions from 10 seconds to 5 seconds. With a failureThreshold of 30, the cumulative number of failures that triggers a kill is reached after 30 × 5 = 150 seconds (2m30s), which is half the wall-clock time of the original 300-second window. Since the application requires approximately 5 minutes (300 seconds) to become ready, the container will be terminated far too early. This change is counterproductive because it shortens the total startup failure window rather than extending it.
✗
Change timeoutSeconds to 30
Why it's wrong here
Incorrect. timeoutSeconds controls the timeout for an individual probe check, not the overall failure window. The default timeout is 1 second, and increasing it does not extend the time before the probe decides the container has failed.
✗
Set initialDelaySeconds to 300
Why it's wrong here
Correct. Setting initialDelaySeconds to 300 seconds delays the probe start by 5 minutes, giving the application ample time to start. The subsequent probe failures (30 failureThreshold * 10 periodSeconds = 300 seconds) only start counting after the delay, so the container will not be killed prematurely.

Go deeper

CKAD Application Observability and Maintenance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question