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.

• ✗

  All capabilities except NET_BIND_SERVICE

  Why it's wrong here

  This option incorrectly suggests the container retains all default capabilities except NET_BIND_SERVICE. In Kubernetes, the `capabilities.drop: ["ALL"]` directive resets the capability bounding set to empty, removing every capability that a process could otherwise inherit, including all default capabilities granted by the container runtime. The subsequent `add: ["NET_BIND_SERVICE"]` then inserts exactly that single capability into the now-empty set. Consequently, the final capability set is exactly `NET_BIND_SERVICE`, not a full set minus one; the misconception is thinking of `drop` as removing a single capability when `ALL` is a wholesale reset.

• ✓

  Only NET_BIND_SERVICE

  Why this is correct

  This is the correct interpretation: the container runs with exactly one Linux capability, `NET_BIND_SERVICE`. When `capabilities.drop` contains `ALL`, the container runtime begins with a completely empty capability set for the process, stripping away all default capabilities such as `CHOWN`, `DAC_OVERRIDE`, and `FOWNER`. Then `capabilities.add` with `NET_BIND_SERVICE` adds back just that one capability, allowing the process to bind to privileged ports (below 1024) but nothing else. This is a common least-privilege pattern for services that need to serve traffic on port 80 or 443.

• ✗

  No capabilities

  Why it's wrong here

  This option mistakenly treats the `add` entry as irrelevant or assumes the container still has no capabilities because `drop: ["ALL"]` is present. However, the order of operations in Kubernetes capability handling is deterministic: drop first, then add. Even after dropping ALL, the explicit addition of `NET_BIND_SERVICE` means the final capability set is non-empty, and the process can bind to low-numbered ports. Thus, saying 'no capabilities' ignores the additive step and misreads the YAML semantics.

• ✗

  All default capabilities plus NET_BIND_SERVICE

  Why it's wrong here

  This option presupposes that the default capabilities (the ones the container runtime would normally provide) survive the `drop: ["ALL"]` directive, and that `NET_BIND_SERVICE` is simply appended to that default set. In reality, `drop: ["ALL"]` is an absolute removal of every capability from the bounding set, overriding the runtime's defaults entirely. The `add` list then repopulates the set from scratch, so since only `NET_BIND_SERVICE` is added, the container does not have any of the default capabilities. This configuration intentionally eliminates the default set and starts clean, so claiming 'all default capabilities plus NET_BIND_SERVICE' is the opposite of what the YAML accomplishes.

Go deeper

Related to this question