CKS System Hardening Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  The pod is rejected by NodeRestriction admission

  Why it's wrong here

  NodeRestriction admission controller is an alpha/beta feature that constrains the kubelet's ability to modify Node and Pod objects, primarily by enforcing that the kubelet can only update its own Node and the pods bound to it. It applies only to kubelet API requests, not to normal user authentication when creating a pod, and it has no logic to inspect image names or registries. Therefore it cannot reject a user's pod creation.

• ✗

  The pod is rejected by PodSecurity admission

  Why it's wrong here

  PodSecurity admission (the successor to PodSecurityPolicy) evaluates the pod's security context against a policy level of privileged, baseline, or restricted, checking options like privileged containers, Linux capabilities, host namespaces, and allowed volume types. It does not parse the image reference, registry host, or digest, nor does it enforce any policy on which registries are allowed. A pod with an unusual registry would still pass PodSecurity because that is outside its scope.

• ✓

  The pod is created and the image is pulled

  Why this is correct

  The AlwaysPullImages admission controller mutates each new pod's containers, setting imagePullPolicy to Always, which forces the kubelet to pull the image from the registry at every pod start rather than using local cache. This mutation is a validation-type operation that does not reject the pod; the pod is admitted and scheduled. The kubelet then performs an image pull from the specified registry, and since no admission controller or runtime configuration in the default chain blocks untrusted registries, the pull succeeds and the pod runs.

• ✗

  The pod is created but the image is not pulled because it's untrusted

  Why it's wrong here

  There is no built-in mechanism in the standard Kubernetes admission chain that checks whether an image registry is 'trusted' or 'untrusted'. The kubelet simply attempts to pull the image based on the imagePullPolicy; if the registry is reachable and the image exists, it will be pulled. Blocking untrusted registries requires explicit supply-chain security layers, such as a validating admission policy, an image policy webhook, or container runtime signature verification like Container Image Signing, none of which are indicated in the exhibit.

Go deeper

Related to this question