CKS System Hardening Practice Test 5 — 15 Questions

Question 1

A pod with the following annotation is created: 'container.apparmor.security.beta.kubernetes.io/webserver: localhost/k8s-apparmor-profile'. However, the pod remains in 'Pending' state and the node logs show 'AppArmor not available'. What is the most likely cause?

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

Accepted Answer

AppArmor is not loaded or enabled on the node kernel. The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

Answer

The annotation should be on the pod's securityContext, not as an annotation

Answer

The AppArmor profile name is misspelled

Answer

The pod is using a privileged security context

Question 2

A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?

Accepted Answer

Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'. The 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Answer

Add a PodSecurityPolicy that sets seccomp to RuntimeDefault

Answer

Use a cronjob to audit and modify pods that do not have seccomp set

Answer

Add a seccomp profile to the kubelet configuration

Question 3

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/: localhost/my-custom-profile. The AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/` with the value `localhost/`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Answer

container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile

Answer

apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile

Answer

container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce

Question 4

Which Linux capability should be dropped to prevent a container from gaining new privileges via setuid binaries?

Accepted Answer

CAP_SETUID. CAP_SETUID (option C) is the Linux capability that controls whether a process can make arbitrary changes to process UIDs (setuid/setgid). Dropping this capability prevents a container from using setuid binaries (e.g., `su`, `sudo`) to escalate privileges, because the kernel will deny any attempt to change the effective UID. This directly addresses the requirement to prevent gaining new privileges via setuid binaries.

Answer

CAP_NET_RAW

Answer

CAP_DAC_OVERRIDE

Answer

CAP_SYS_ADMIN

Question 5

A pod is scheduled on a node that has AppArmor enabled, and the pod has the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write'. The profile 'deny-write' is loaded. However, the nginx container is able to write to the filesystem. What is the most likely issue?

Accepted Answer

The profile was loaded in complain mode using apparmor_parser with the -C flag. The most likely issue is that the AppArmor profile 'deny-write' was loaded in complain mode using the `apparmor_parser` with the `-C` flag. In complain mode, AppArmor logs policy violations but does not enforce them, allowing the container to write to the filesystem despite the profile being applied. The annotation is correctly formatted, and the profile is loaded, so enforcement depends on the mode.

Answer

The container is privileged

Answer

The pod's securityContext sets allowPrivilegeEscalation to true

Answer

The annotation is incorrectly formatted

Question 6

Which of the following is the correct way to drop all capabilities from a container in a pod specification?

Accepted Answer

securityContext:
  capabilities:
    drop: ALL. In Kubernetes, to drop all capabilities from a container, you must set `capabilities.drop` to `ALL` under the `securityContext`. The `capabilities` field is a standard part of the container's security context, and `drop` is the correct key to specify capabilities to remove. Using `ALL` (uppercase) ensures all capabilities defined by the Linux kernel (e.g., CAP_NET_RAW, CAP_SYS_ADMIN) are dropped, which is a best practice for minimizing privilege escalation risks.

Answer

securityContext:
  dropCapabilities: ALL

Answer

securityContext:
  capabilities:
    drop: ["all"]

Answer

securityContext:
  capabilities:
    remove: ALL

Question 7

A cluster has PodSecurity admission enabled. A developer creates a pod with the following security context: 'securityContext: { capabilities: { drop: ["ALL"], add: ["NET_ADMIN"] } }'. The namespace is labeled 'pod-security.kubernetes.io/enforce: baseline'. Will the pod be allowed?

Accepted Answer

Yes, because the baseline policy allows adding NET_ADMIN. The Pod Security Standards (PSS) baseline policy explicitly allows adding the NET_ADMIN capability. The baseline policy restricts certain capabilities but does not prohibit adding NET_ADMIN; it only restricts capabilities that could lead to host-level privilege escalation. Dropping ALL capabilities first and then adding NET_ADMIN is a valid pattern that satisfies the baseline policy's requirements.

Answer

No, because baseline requires dropping ALL first

Answer

Yes, because the pod drops all capabilities before adding specific ones

Answer

No, because dropping ALL capabilities is not allowed by baseline

Question 8

A security auditor wants to ensure that no container in the cluster has the CAP_SYS_ADMIN capability. Which of the following is the most effective way to enforce this cluster-wide?

Accepted Answer

Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods. A mutating admission webhook intercepts Pod creation requests and can automatically modify the pod spec to drop CAP_SYS_ADMIN before the pod is persisted. This approach works cluster-wide, is not deprecated like PodSecurityPolicy, and does not require modifying node-level components or relying on namespace-level enforcement that only warns or rejects but does not automatically drop capabilities.

Answer

Add a PodSecurityPolicy that drops CAP_SYS_ADMIN

Answer

Modify the kubelet to disallow CAP_SYS_ADMIN

Answer

Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'

Question 9

Which TWO of the following are valid methods to apply a custom seccomp profile to a pod in Kubernetes?

Accepted Answer

Setting the annotation 'seccomp.security.alpha.kubernetes.io/pod' on the pod. The annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to 1.19. This annotation is still valid in older clusters or when using the alpha API, and it directly specifies the seccomp profile path or type for the pod.

Answer

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

Answer

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

Answer

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

Question 10

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Accepted Answer

AppArmor profiles can be loaded in 'enforce' or 'complain' mode. AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Answer

The profile name in the annotation should be just the profile name without the 'localhost/' prefix

Answer

The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

Answer

AppArmor profiles are automatically loaded from a ConfigMap

Question 11

An administrator wants to enforce that all pods in a namespace use the restricted Pod Security Standard. Which of the following commands correctly enables this enforcement?

Accepted Answer

kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted. The Pod Security Standards are enforced via labels on the namespace, and the `pod-security.kubernetes.io/enforce` label with value `restricted` tells the Pod Security Admission controller to reject any pod that violates the restricted policy. This is the only way to actively block non-compliant pods from being created in the namespace.

Answer

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

Answer

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

Answer

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

Question 12

Which of the following is the correct annotation to apply an AppArmor profile named 'my-profile' to a container named 'app' in a pod?

Accepted Answer

container.apparmor.security.beta.kubernetes.io/app: localhost/my-profile. The AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/: localhost/`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Answer

security.alpha.kubernetes.io/apparmor/app: localhost/my-profile

Answer

pod.apparmor.security.beta.kubernetes.io/app: my-profile

Answer

container.apparmor.security.beta.kubernetes.io/app: my-profile

Question 13

A pod is running with a custom seccomp profile located at /var/lib/kubelet/seccomp/my-profile.json. Which securityContext configuration correctly applies this profile?

Accepted Answer

seccompProfile: { type: Localhost, localhostProfile: my-profile.json }. When using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` field must specify only the filename (not the full path). Kubernetes automatically prepends the default seccomp profile path `/var/lib/kubelet/seccomp/` to the `localhostProfile` value, so `my-profile.json` resolves to the correct location.

Answer

seccompProfile: { type: RuntimeDefault }

Answer

seccompProfile: { type: Localhost, localhostProfile: /var/lib/kubelet/seccomp/my-profile.json }

Answer

seccompProfile: { type: Unconfined }

Question 14

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

Accepted Answer

PSP support was removed from Kubernetes in 1.25. PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Answer

The PSP API version needs to be updated to v1

Answer

PSPs were replaced by NetworkPolicies in 1.25

Answer

The PSP was not applied to the correct namespace

Question 15

Which command is used to check whether AppArmor is enabled and which profiles are loaded on a Linux node?

Accepted Answer

aa-status. AppArmor is a Linux Security Module (LSM) enforced at the node level, not a Kubernetes resource. Kubernetes does not expose AppArmor status via kubectl. To check whether AppArmor is enabled and which profiles are loaded, you must execute `aa-status` directly on the node (e.g., via SSH). This command queries the AppArmor kernel module and lists all loaded profiles.

Answer

kubectl get seccomp

Answer

kubectl get apparmor

Answer

systemctl status apparmor