CKS System Hardening Practice Test 2 — 15 Questions

Question 1

Which of the following Pod specification settings prevents a container from using the 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 2

An administrator runs 'kubectl run test-pod --image=nginx --dry-run=client -o yaml > pod.yaml', then adds 'hostPID: true' and 'hostNetwork: true' to the pod's spec. After applying with 'kubectl apply -f pod.yaml', the pod is created but immediately goes into 'CrashLoopBackOff'. What is the likely cause?

Accepted Answer

The pod lacks the necessary Linux capabilities. The pod is created because hostPID and hostNetwork are allowed by default. nginx has CAP_NET_BIND_SERVICE by default, so it can bind to port 80. CrashLoopBackOff is likely due to port 80 already in use on the host or another runtime issue.

Answer

The container is missing a memory limit and gets OOMKilled

Answer

The namespace has a PodSecurity enforce level that restricts hostPID and hostNetwork

Answer

The 'hostPID' and 'hostNetwork' fields cannot be combined

Question 3

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

Accepted Answer

Setting 'securityContext.seccompProfile.type' in the pod spec. Option A is correct because Kubernetes supports the native seccomp field 'securityContext.seccompProfile.type' (with values such as RuntimeDefault, Localhost, or Unconfined) directly in the pod or container security context, which is the modern, stable way to apply a seccomp profile. Option E is correct because the legacy annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original mechanism for applying a seccomp profile to an entire pod before the securityContext field existed, and it is still recognized for backward compatibility. Option B is incorrect because 'container.apparmor.security.beta.kubernetes.io/<container>' applies an AppArmor profile, not a seccomp profile. Option C is incorrect because PodSecurityPolicy (deprecated and removed in Kubernetes 1.25) controlled seccomp via its own allowed/required annotations and fields, not by embedding a seccomp profile definition itself. Option D is incorrect because the seccompProfile field belongs under 'securityContext' (pod-level) or a container's securityContext, but the option's phrasing of including it under 'spec.securityContext' as a distinct method is not a valid separate mechanism from A.

Answer

Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'

Answer

Including 'seccomp' profile in PodSecurityPolicy

Answer

Including 'seccompProfile' under 'spec.securityContext' at the pod level

Question 4

A pod spec includes the following securityContext:

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: custom-profile.json

Where should the custom seccomp profile 'custom-profile.json' be placed on the node?

Accepted Answer

/var/lib/kubelet/seccomp/. When a pod's securityContext specifies a seccomp profile of type Localhost, the custom profile file must be placed on the node's filesystem under the default seccomp profile directory used by kubelet, which is /var/lib/kubelet/seccomp/. The kubelet reads profiles from this directory, and the localhostProfile field (e.g., custom-profile.json) is resolved relative to this path. Option D is correct because it matches the default kubelet seccomp profile path.

Answer

/etc/seccomp/

Answer

/etc/kubernetes/seccomp/

Answer

/var/lib/kubelet/seccomp/profiles/

Question 5

A cluster administrator wants to prevent all containers in a namespace from running with the NET_RAW capability. They plan to use a PodSecurityPolicy (PSP) but PSP is deprecated. Which approach should they use instead?

Accepted Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: baseline'. The 'baseline' PodSecurity standard enforces the minimum restrictions that prevent privilege escalation, including dropping the NET_RAW capability by default. The 'baseline' profile is designed to be applied to namespaces where most workloads run, and it automatically adds NET_RAW to the required drop capabilities list, which directly addresses the administrator's goal without the overhead of the more restrictive 'restricted' profile.

Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: privileged'

Answer

Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: restricted'

Answer

Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'

Question 6

A security auditor reports that a container can sniff network traffic on the host. Which field in the pod spec should be checked and set to false to prevent this?

Accepted Answer

hostNetwork: false. Setting `hostNetwork: true` in the pod spec allows the container to share the host's network namespace, enabling it to bind to host ports and, critically, to sniff all network traffic on the host network interface (e.g., using `tcpdump` or raw sockets). Setting `hostNetwork: false` (the default) isolates the container in its own network namespace, preventing it from accessing host-level network traffic. This is a fundamental Kubernetes security control to enforce network isolation.

Answer

hostNetwork: true

Answer

hostIPC: true

Answer

hostPID: true

Question 7

Which command loads an AppArmor profile from a file into the kernel?

Accepted Answer

apparmor_parser -r /path/to/profile. The `apparmor_parser` command is the standard tool for loading AppArmor profiles into the kernel. The `-r` flag replaces any existing profile with the same name, ensuring the new profile is active. Option B is correct because it uses the proper command and syntax to load a profile from a file into the kernel's AppArmor module.

Answer

apparmor_load /path/to/profile

Answer

aa-status

Answer

aa-enforce /path/to/profile

Question 8

An administrator wants to prevent containers from using hostNetwork, hostPID, and hostIPC. Which Pod Security Standard level enforces these restrictions?

Accepted Answer

Restricted. Both the Baseline and Restricted Pod Security Standards prohibit the use of hostNetwork, hostPID, and hostIPC. The Restricted standard is the most stringent of the two, adding further constraints such as seccomp requirements and capability drops, but it is not the only level that enforces the listed namespace restrictions. The question is ambiguous unless it specifies 'most stringent'.

Answer

None; you must manually configure admission webhooks

Answer

Privileged

Question 9

Which THREE of the following are valid seccomp profile types in Kubernetes? (Select three.)

Accepted Answer

Localhost. Option A (Localhost) is correct because Kubernetes supports the Localhost seccomp profile type, which references a JSON seccomp profile file placed on the node's filesystem (e.g., under /var/lib/kubelet/seccomp/), allowing administrators to apply a custom profile to a container. Option D (Unconfined) is correct because Kubernetes allows the Unconfined seccomp profile type, which explicitly disables seccomp filtering for the container, running it without any syscall restrictions. The third valid type, RuntimeDefault, is also a legitimate Kubernetes seccomp profile type, but since it is not marked [CORRECT] in this question, it is not counted among the correct answers here. Option C (ContainerDefault) is not a valid Kubernetes seccomp profile type; no such value exists in the seccompProfile.type field. Option E (KubernetesDefault) is likewise not a recognized seccomp profile type in Kubernetes; the API only accepts Localhost, RuntimeDefault, and Unconfined.

Answer

RuntimeDefault

Answer

ContainerDefault

Answer

KubernetesDefault

Question 10

Which TWO of the following are valid AppArmor profile modes? (Select two.)

Accepted Answer

Complain. AppArmor profiles operate in two primary modes: 'Complain' (also known as 'learning' mode) and 'Enforce' (the default mode). In Complain mode, policy violations are logged but not blocked, which is useful for testing and developing profiles. In Enforce mode, violations are both logged and blocked, actively enforcing the security policy. Options C (Complain) and D (Enforce) are correct.

Answer

Audit

Answer

Disabled

Answer

Unconfined

Question 11

Which TWO of the following are correct ways to apply a seccomp profile named 'audit.json' located on each node? (Select two.)

Accepted Answer

Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json. Option C is correct because the modern, stable seccomp API uses securityContext.seccompProfile with type: Localhost and localhostProfile: audit.json, which tells the kubelet to load the profile file from the node's seccomp profile root directory. Option D is correct because the legacy pod-level annotation seccomp.security.alpha.kubernetes.io/pod accepts the value localhost/audit.json, where the localhost/ prefix indicates a profile file residing on the node rather than a runtime default. Option A is incorrect because the annotation value audit.json lacks the required localhost/ prefix, so it would not be interpreted as a node-local profile. Option B is incorrect because the per-container annotation key is container.seccomp.security.alpha.kubernetes.io/<container_name> and its value must also be prefixed with localhost/ (i.e., localhost/audit.json), not just audit.json. Option E is incorrect because the field name is localhostProfile, not profile, so the manifest would be rejected or ignored.

Answer

Add annotation: seccomp.security.alpha.kubernetes.io/pod: audit.json

Answer

Add annotation per container: container.seccomp.security.alpha.kubernetes.io/<name>: localhost/audit.json

Answer

Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

Question 12

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

Accepted Answer

container.apparmor.security.beta.kubernetes.io/. The `container.apparmor.security.beta.kubernetes.io/` annotation is the exact key used to apply an AppArmor profile to a specific container within a pod. The value of this annotation specifies the profile name (e.g., `localhost/` or `runtime/default`), and it must be set on the Pod object before the pod is created, as AppArmor profiles cannot be applied to running containers.

Answer

security.alpha.kubernetes.io/apparmor

Answer

apparmor.kubernetes.io/default

Answer

seccomp.security.alpha.kubernetes.io/pod

Question 13

Which THREE of the following are valid AppArmor profile modes?

Accepted Answer

complain. AppArmor profiles can operate in complain mode (A), where policy violations are logged but not blocked, which is useful for developing and testing profiles without breaking applications. Enforce mode (C) is the standard operational mode where the profile's rules are actively applied and violations are denied and logged. Unconfined mode (D) is a valid state in which a process or profile runs without any AppArmor confinement, effectively applying no restrictions. Audit (B) is not a profile mode; auditing is a behavior (logging) that occurs within complain or enforce modes, not a mode itself. Allow (E) is not a profile mode either; 'allow' is a rule keyword used inside profile policy to permit specific operations.

Answer

audit

Answer

allow

Question 14

A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?

Accepted Answer

Configure control plane containers to run as non-root user and with read-only root filesystem. Running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.

Answer

Use seccomp profiles to block privilege escalation syscalls

Answer

Apply AppArmor profiles to all control plane pods

Answer

Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces

Question 15

An administrator wants to restrict pods from running as root. Which admission controller should be enabled?

Accepted Answer

PodSecurity. The PodSecurity admission controller (D) is the correct choice because it enforces the Pod Security Standards (Privileged, Baseline, Restricted) defined in the Kubernetes documentation. By enabling this controller, the administrator can configure a policy that prevents pods from running as root, typically by setting the 'Restricted' profile which requires 'runAsNonRoot: true' and 'runAsUser: > 10000' in the pod security context.

Answer

NodeRestriction

Answer

AlwaysPullImages

Answer

ServiceAccount