Courseiva
← CKS
Full test
System Hardening →hardMultiple Choice

CKS System Hardening Practice Question

A custom seccomp profile is defined as follows:

{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["mkdir", "chmod"],
      "action": "SCMP_ACT_ERRNO"
    }
  ]
}

The profile is placed at /var/lib/kubelet/seccomp/deny-mkdir.json. Which pod securityContext configuration correctly applies this profile?

⚠ Common exam trap

CNCF often tests the case-sensitivity of `type: Localhost` (capital 'L') versus the incorrect lowercase `localhost`, and the distinction between the deprecated annotation-based approach and the current `seccompProfile` field in the security context.

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

✓

seccompProfile: type: Localhost localhostProfile: "deny-mkdir.json"

In Kubernetes, the `seccompProfile` field in the pod or container security context uses the `type: Localhost` (case-sensitive) and `localhostProfile` specifies the filename relative to the kubelet's seccomp root directory (`/var/lib/kubelet/seccomp/`). The profile file `deny-mkdir.json` is placed at that path, so `localhostProfile: "deny-mkdir.json"` correctly references it. This configuration blocks `mkdir` and `chmod` syscalls while allowing all others, as defined by the custom profile.

Answer analysis

Option-by-option breakdown

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

  • ✗

    annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/deny-mkdir"

    Why it's wrong here

    The annotation seccomp.security.alpha.kubernetes.io/pod is from the alpha era of Kubernetes seccomp support and has been deprecated for years. Modern Kubernetes (v1.19+) relies on the securityContext.seccompProfile field in the Pod or container spec, and annotations may even be ignored on newer API versions. Even if the annotation worked, it would only reference the profile on the node, but it does not leverage the explicit, strongly typed seccompProfile structure, making it fragile, legacy, and non-conformant with current API conventions.

  • ✓

    seccompProfile: type: Localhost localhostProfile: "deny-mkdir.json"

    Why this is correct

    This is the correct approach. The field seccompProfile is part of the Pod securityContext, and type: Localhost tells kubelet to load a custom profile file from the kubelet's seccomp localhost directory (typically /var/lib/kubelet/seccomp/). The localhostProfile field must contain the exact filename (e.g., deny-mkdir.json) that exists on the node, and the profile file must be valid JSON defining syscall rules, such as returning EPERM for mkdir and mkdirat. This configuration precisely applies the custom deny-mkdir profile to the pod's containers.

  • ✗

    seccompProfile: type: localhost localhostProfile: "deny-mkdir.json"

    Why it's wrong here

    The Kubernetes securityContext.seccompProfile.type field uses exact, case-sensitive enums: RuntimeDefault, Localhost, and Unconfined. Setting type: lowercase 'localhost' is invalid values and will be rejected by the API server, or at best treated as an unknown value and ignored, which would result in no seccomp profile being applied at all. This is a subtle but critical distinction—even though the YAML looks conceptually correct, a lowercase 'l' breaks the contract, and the pod may fail to start or silently run without the intended restriction.

  • ✗

    seccompProfile: type: RuntimeDefault

    Why it's wrong here

    Using type: RuntimeDefault applies the container runtime's built-in default seccomp profile, which is designed for general safety and compatibility but is not the same as the custom deny-mkdir.json profile. The custom profile has rules specifically to deny mkdir and mkdirat syscalls, while RuntimeDefault does not necessarily deny those syscalls and may allow them depending on the runtime (e.g., containerd's default profile blocks certain privileged syscalls but not mkdir). Therefore, this option defeats the explicit purpose of the question, which is to load a custom profile—RuntimeDefault provides a generic baseline, not the desired deny-mkdir behavior.

About these practice questions

This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.