Simulado Certified Kubernetes Application Developer (CKAD)

A StatefulSet runs a primary-replica database where pod ordinal 0 must always be fully Ready before ordinal 1 starts, because replicas bootstrap by streaming from the primary. After switching the StatefulSet's podManagementPolicy to Parallel to speed up rollouts, the replicas now intermittently fail to bootstrap. What is the correct understanding?

1. Parallel guarantees ordinal 0 starts first but skips its readiness gate; add an initContainer to ordinal 0 to slow it down
2. Parallel only affects scale-down ordering, so the bootstrap failures must be caused by a misconfigured readiness probe
3. podManagementPolicy controls volume attachment order, not pod startup order; the issue is a PVC binding race
4. Parallel podManagementPolicy launches all pods at once without waiting for predecessors to become Ready; revert to OrderedReady to preserve the ordinal startup dependency ✓ (correta)

A liveness probe uses `exec` with the command `["cat", "/tmp/healthy"]`, periodSeconds: 5, timeoutSeconds: 1, failureThreshold: 3. The app deletes /tmp/healthy when it deadlocks. Operators report that even with periodSeconds 5 and failureThreshold 3, the container sometimes takes much longer than ~15 seconds to restart after the file disappears. Which factor BEST explains the extra delay?

1. An exec probe runs a process inside the container each period; under heavy CPU contention the probe command itself can be slow to schedule or exceed timeoutSeconds, stretching the time to accumulate three consecutive failures. ✓ (correta)
2. Liveness exec probes are evaluated by the API server, which batches them on a 60-second control loop, so restarts are always delayed.
3. failureThreshold only counts failures that occur on even-numbered periods, doubling the effective time.
4. The probe waits for the readinessProbe to fail first before it is allowed to count any failures.

A Pod in namespace `team-a` has no `serviceAccountName` set. The application inside needs to list Pods in its own namespace via the Kubernetes API. An admin has created a Role granting `list` on `pods` and a RoleBinding referencing the ServiceAccount `pod-reader` in `team-a`. The application still receives a 403 Forbidden. Assuming the token is correctly mounted and valid, what is the most likely cause?

1. A Role can only bind to users and groups, never to ServiceAccounts, so the binding silently has no effect.
2. The token mounted in the Pod is for the node's kubelet identity, which RBAC always denies for namespaced API calls.
3. RoleBindings cannot grant `list` on Pods; a ClusterRoleBinding is required for any verb on the `pods` resource.
4. The Pod is running under the namespace's `default` ServiceAccount, not `pod-reader`, so the RoleBinding's permissions do not apply to it. ✓ (correta)