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.

• ✓

  Setting the annotation 'seccomp.security.alpha.kubernetes.io/pod' on the pod

  Why this is correct

  This is a valid, though deprecated, method for applying a seccomp profile at the pod level. The annotation's value can be 'localhost/<profile-name>' to reference a profile stored on the node, or 'runtime/default' for the runtime's default. Although superseded by the securityContext.seccompProfile field, this annotation is still honored by the kubelet, making it a legitimate (if legacy) way to configure a custom profile.

• ✗

  Using 'securityContext.seccompProfile.type: RuntimeDefault' with 'localhostProfile' set

  Why it's wrong here

  In the seccompProfile API, 'type' is a required enum and 'localhostProfile' is only used when type is 'Localhost'. Setting type: RuntimeDefault tells the runtime to use its built-in default profile; any value in localhostProfile is ignored, and in fact the API server validation rejects the combination because localhostProfile must be empty for non-Localhost types. Therefore this configuration is invalid and cannot be used to apply a custom profile.

• ✗

  Configuring the kubelet with --seccomp-default-profile flag

  Why it's wrong here

  The kubelet flag --seccomp-default-profile (which requires the SeccompDefault feature gate) only sets a cluster-wide default of 'runtime/default' for pods that do not specify any seccomp profile. It cannot reference a custom profile file, nor can it be used to apply a specific profile to an individual pod. It is a node-level default, not an application method, so it does not satisfy custom pod-level seccomp requirements.

• ✓

  Using 'securityContext.seccompProfile.type: Localhost' with 'localhostProfile' set

  Why this is correct

  This is the current, recommended mechanism to apply a custom seccomp profile. The profile JSON file must be placed in the kubelet's seccomp directory (usually /var/lib/kubelet/seccomp), and the pod references it by setting seccompProfile.type: Localhost with localhostProfile: <filename>. This is the non-deprecated alternative to the alpha annotation and is supported for both pod-level and container-level security contexts.

• ✗

  Adding a seccomp profile to the container image and referencing it in the pod spec

  Why it's wrong here

  Seccomp profiles are not part of the container image; they are host filesystem files that the container runtime loads from the node's local disk. There is no Kubernetes field that can reference a profile inside an image, and the runtime has no way to extract it. All custom profiles must be pre-placed on every node that will run the pod, typically under /var/lib/kubelet/seccomp, before the pod is scheduled.

Go deeper

Related to this question