CKS System Hardening Practice Test 6 — 15 Questions

Question 1

A pod has the following security context: capabilities: { drop: ['ALL'] } and privileged: false. The pod fails to start because it requires the ability to run iptables commands. Which of the following should be added to the pod's security context?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

capabilities: { add: ['NET_ADMIN'] }. The pod needs to run iptables commands, which require the NET_ADMIN capability. Since the security context drops ALL capabilities, you must explicitly add NET_ADMIN back. Option D correctly adds NET_ADMIN, granting the necessary network administration privileges without making the container fully privileged.

Answer

privileged: true

Answer

capabilities: { add: ['SYS_ADMIN'] }

Answer

capabilities: { drop: ['NET_ADMIN'] }

Question 2

Which of the following fields in a PodSecurityPolicy (or Pod Security Standards) prevents a container from running as root?

Accepted Answer

runAsUser: MustRunAsNonRoot. `runAsUser: MustRunAsNonRoot` in a PodSecurityPolicy (or the equivalent Pod Security Standard `restricted` profile) enforces that the container's user ID (UID) must not be 0 (root). This directly prevents the container from running as root, as the security context will reject any pod that specifies `runAsUser: 0` or omits the field when the policy requires a non-root user.

Answer

runAsUser: RunAsAny

Answer

runAsGroup: MustRunAsNonRoot

Answer

seLinuxContext: MustRunAsNonRoot

Question 3

A security auditor wants to verify that the AppArmor profile 'my-profile' is in enforce mode on a running container. Which command should they run inside the node?

Accepted Answer

cat /proc//attr/current. The file `/proc//attr/current` contains the current AppArmor confinement status for a given process. Reading this file for a container's PID inside the node will show the profile name and mode (e.g., `my-profile (enforce)`), directly confirming that the profile is in enforce mode.

Answer

dmesg | grep apparmor

Answer

apparmor_parser -r my-profile

Answer

cat /proc/<pid>/environ

Question 4

A pod is in a Pending state with the event: 'failed to generate spec: failed to validate seccomp profile: seccomp profile not found'. The profile is stored at /var/lib/kubelet/seccomp/custom.json on the node. Which of the following is the MOST likely cause?

Accepted Answer

The localhostProfile field contains an absolute path instead of a relative one. The error 'seccomp profile not found' indicates the kubelet cannot locate the profile file. In Kubernetes, when using a seccomp profile stored on the node, the `localhostProfile` field must specify a relative path from the kubelet's seccomp root directory (default `/var/lib/kubelet/seccomp`). An absolute path like `/var/lib/kubelet/seccomp/custom.json` causes the kubelet to look for the file at that exact absolute path, but the seccomp validation logic expects a relative path and prepends the root, leading to a 'not found' error.

Answer

The profile name is misspelled in the pod specification

Answer

The node does not have seccomp enabled in the kubelet

Answer

The seccomp profile JSON is malformed

Question 5

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

Accepted Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }. The AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Answer

annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }

Answer

annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }

Question 6

A pod is configured with securityContext: { seccompProfile: { type: RuntimeDefault } }. Which of the following is true about this configuration?

Accepted Answer

The pod uses the default seccomp profile provided by the container runtime. Setting `seccompProfile.type: RuntimeDefault` in the pod's securityContext instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile, which is typically a restrictive profile that blocks a large set of syscalls. This is the recommended approach for enabling seccomp without needing to define a custom profile, and it is available in Kubernetes v1.19+.

Answer

The pod uses a custom seccomp profile

Answer

Seccomp is disabled for the pod

Answer

The pod must have CAP_SYS_ADMIN to use this setting

Question 7

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

Accepted Answer

apparmor_parser my-profile. The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Answer

apparmor_load my-profile

Answer

apparmor_parser -R my-profile

Answer

systemctl start apparmor my-profile

Question 8

A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?

Accepted Answer

Create a custom seccomp profile that allows the syscall and apply it via type: Localhost. The default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Answer

Use the RuntimeDefault profile and add capabilities

Answer

Change the seccomp profile to another runtime default

Answer

Set seccompProfile to Unconfined

Question 9

Which of the following securityContext settings prevents a container from using host network namespace?

Accepted Answer

hostNetwork: false. Setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.

Answer

hostIPC: false

Answer

hostNetwork: true

Answer

hostPID: false

Question 10

Which TWO of the following are valid Pod Security Standard levels? (Select 2)

Accepted Answer

privileged. The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Answer

medium

Answer

high

Answer

default

Question 11

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Accepted Answer

Seccomp can be configured using the securityContext.seccompProfile field. The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Answer

Seccomp profiles can only be applied to privileged containers

Answer

Seccomp can only restrict system calls, not allow them

Question 12

Which annotation is used to apply an AppArmor profile to a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/`, where `` is the name of the container. This annotation, which was introduced in Kubernetes v1.4 as a beta feature, tells the kubelet to apply the referenced AppArmor profile (e.g., `localhost/k8s-apparmor-example`) to the specified container during runtime.

Answer

apparmor.security.kubernetes.io/profile

Answer

security.kubernetes.io/apparmor

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 13

A security admin wants to drop all Linux capabilities for a container and then add only CAP_NET_BIND_SERVICE. Which YAML snippet correctly achieves this?

Accepted Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['NET_BIND_SERVICE']. It uses the standard Kubernetes `securityContext.capabilities` field with `drop: ['ALL']` to remove all Linux capabilities from the container, then `add: ['NET_BIND_SERVICE']` to grant only the `CAP_NET_BIND_SERVICE` capability. This is the proper YAML syntax for the desired capability set.

Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['NET_BIND_SERVICE']
  privileged: true

Answer

securityContext:
  capabilities:
    drop: ['NET_BIND_SERVICE']
    add: ['ALL']

Answer

securityContext:
  capDrop: ['ALL']
  capAdd: ['NET_BIND_SERVICE']

Question 14

An admin runs 'kubectl describe pod secure-pod' and sees 'seccompProfile: RuntimeDefault' under the container's security context. Which seccomp profile is being used?

Accepted Answer

The container runtime's default seccomp profile is applied. When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

Answer

A custom seccomp profile from '/var/lib/kubelet/seccomp/' is used

Answer

The container runtime's seccomp profile is set to 'Unconfined'

Answer

Seccomp is disabled for this container

Question 15

A cluster administrator wants to enforce the Pod Security Standard 'restricted' at the namespace level. Which command applies the PodSecurity admission label to the 'prod' namespace?

Accepted Answer

kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted. The `enforce` label is the only one that actively blocks pods that violate the specified Pod Security Standard (PSS) level. The command `kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted` applies the 'restricted' policy at the namespace level, causing the PodSecurity admission controller to reject any pod that does not comply with the restricted profile.

Answer

kubectl label namespace prod pod-security.kubernetes.io/warn=restricted

Answer

kubectl label namespace prod pod-security.kubernetes.io/audit=restricted

Answer

kubectl annotate namespace prod security.kubernetes.io/pod-security=restricted