CCNA Cks System Hardening Questions — Page 3 of 3

151

MCQmedium

Which of the following is the correct way to disable swap on a Kubernetes node to improve security?

A.Run 'swapoff -a' and remove swap entry from /etc/fstab

B.Set kernel parameter 'vm.swappiness=0'

C.Run 'systemctl stop swap'

D.Run 'kubelet --disable-swap'

AnswerA

This disables swap immediately and permanently.

Why this answer

Disabling swap is a prerequisite for Kubernetes nodes to ensure kubelet works correctly with memory management and resource isolation. Running 'swapoff -a' disables all active swap devices immediately, and removing the swap entry from /etc/fstab prevents swap from being re-enabled after a reboot. This is the standard and complete method recommended by Kubernetes documentation for system hardening.

Exam trap

The trap here is that candidates may think 'vm.swappiness=0' is sufficient to disable swap, but it only minimizes swap usage without actually turning it off, which still violates Kubernetes node requirements.

How to eliminate wrong answers

Option B is wrong because setting 'vm.swappiness=0' only reduces the kernel's tendency to use swap but does not disable it; swap remains active and can still be used, which can cause kubelet instability. Option C is wrong because 'systemctl stop swap' is not a valid systemd command; swap is managed via 'swapoff' or systemd swap units (e.g., 'systemctl stop dev-sda1.swap'), but the generic 'swap' service does not exist. Option D is wrong because 'kubelet --disable-swap' is not a valid kubelet flag; kubelet does not have a built-in option to disable swap, and swap must be disabled at the OS level before starting kubelet.

Practice this question →

152

MCQeasy

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

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

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

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

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

AnswerB

Correct. The annotation key targets the container, and the value includes the profile name with 'localhost/' prefix.

Why this answer

Option B is correct because the AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. 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.

Exam trap

CNCF often tests the exact annotation format, specifically the `localhost/` prefix and the `security.beta.kubernetes.io` API group, to catch candidates who confuse AppArmor with Seccomp (which uses `security.alpha.kubernetes.io/seccomp`) or who forget the per-container targeting.

How to eliminate wrong answers

Option A is wrong because it uses the `security.alpha.kubernetes.io` prefix, which is an older, deprecated API group for AppArmor; the correct group is `security.beta.kubernetes.io`. Option C is wrong because it uses `pod.apparmor.security.beta.kubernetes.io`, which is not a valid annotation key; AppArmor annotations are per-container, not per-pod. Option D is wrong because it omits the required `localhost/` prefix in the value; the profile name must be specified as `localhost/my-profile` to reference a locally loaded profile, not just `my-profile`.

Practice this question →

153

MCQmedium

A cluster administrator wants to enforce Pod Security Standards at the namespace level using the built-in PodSecurity admission controller. The namespace 'test' should reject any pod that violates the 'baseline' level. Which command applies this correctly?

A.kubectl annotate ns test pod-security.kubernetes.io/enforce-version=baseline

B.kubectl label ns test pod-security.kubernetes.io/enforce=baseline

C.kubectl label ns test pod-security.kubernetes.io/warn=baseline

D.kubectl label ns test pod-security.kubernetes.io/audit=baseline

AnswerB

This label enforces the baseline Pod Security Standard on the namespace.

Why this answer

Option B is correct because the PodSecurity admission controller uses the label `pod-security.kubernetes.io/enforce` to enforce the specified Pod Security Standard (e.g., `baseline`) at the namespace level. Pods that violate the enforced level are rejected by the admission controller. The `enforce` label triggers the admission webhook to block non-compliant pods, which matches the requirement to reject violations.

Exam trap

CNCF often tests the distinction between the three Pod Security Standard modes (`enforce`, `warn`, `audit`) and the fact that only `enforce` actually blocks pods, while `warn` and `audit` are non-blocking; candidates frequently confuse `warn` or `audit` with enforcement.

How to eliminate wrong answers

Option A is wrong because it uses `kubectl annotate` with the key `pod-security.kubernetes.io/enforce-version`, which is not a valid label for enforcement; the correct key is `pod-security.kubernetes.io/enforce`, and it must be set as a label, not an annotation. Option C is wrong because `pod-security.kubernetes.io/warn=baseline` only generates a warning for violations but does not reject the pod, so it does not meet the requirement to reject violations. Option D is wrong because `pod-security.kubernetes.io/audit=baseline` only logs violations in the audit log without rejecting or warning, which also fails to enforce rejection.

Practice this question →

154

MCQmedium

Refer to the exhibit. The pod fails to start with the error 'container has runAsNonRoot but image will run as root'. Which change would fix the issue?

A.Set runAsNonRoot: false

B.Change runAsUser to 0

C.Use a different image that runs as non-root

D.Add NET_ADMIN capability

AnswerA

Removes the non-root requirement, allowing the image to run as root.

Why this answer

The error 'container has runAsNonRoot but image will run as root' occurs because the Pod's security context sets `runAsNonRoot: true`, but the container image is configured to run as root (UID 0). Setting `runAsNonRoot: false` removes the enforcement, allowing the container to run as root as the image expects. This directly resolves the conflict between the security context constraint and the image's default user.

Exam trap

CNCF often tests the misconception that you must change the image or add capabilities to fix a `runAsNonRoot` violation, when in fact the simplest fix is to adjust the security context setting to match the image's behavior.

How to eliminate wrong answers

Option B is wrong because changing `runAsUser` to 0 explicitly sets the container to run as root, which still violates the `runAsNonRoot: true` constraint and would produce the same error. Option C is wrong because while using a different image that runs as non-root would technically fix the issue, it is not the only or most direct change; the question asks which change would fix the issue, and modifying the security context is a simpler, valid approach. Option D is wrong because adding `NET_ADMIN` capability does not affect the user ID the container runs as; it only grants network administration privileges and does not address the root/non-root mismatch.

Practice this question →

155

MCQeasy

Which of the following seccomp profile types should be used to apply the container runtime's default seccomp profile?

A.Unconfined

B.RuntimeDefault

C.Default

D.Localhost

AnswerB

RuntimeDefault applies the container runtime's default seccomp profile.

Why this answer

The 'RuntimeDefault' type tells the runtime to use its default seccomp profile.

Practice this question →

156

Multi-Selectmedium

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes?

Select 3 answers

A.Minimize host access from containers (e.g., disable hostPID, hostNetwork)

B.Use minimal base container images

C.Disable unnecessary system services on nodes

D.Expose the host network to containers for better performance

E.Run containers as root to simplify permissions

AnswersA, B, C

Reduces the container's ability to affect the host.

Why this answer

Option A is correct because disabling hostPID and hostNetwork prevents containers from accessing the host's process namespace and network stack, which would otherwise allow privilege escalation or network sniffing. This aligns with the principle of least privilege and reduces the node's attack surface by isolating container workloads from the host OS.

Exam trap

CNCF often tests the misconception that hostNetwork improves performance without security trade-offs, or that running as root is acceptable for legacy apps, but the CKS exam expects strict adherence to least privilege and namespace isolation.

Practice this question →

157

MCQeasy

An administrator wants to prevent a container from accessing the host's network. Which pod security context field should be set to false?

A.hostIPC

B.privileged

C.hostPID

D.hostNetwork

AnswerD

Setting hostNetwork: false prevents the container from using the host's network.

Why this answer

The `hostNetwork` field in the Pod Security Context, when set to `true`, allows the container to use the host's network namespace directly, bypassing the pod's own network stack. Setting it to `false` (the default) ensures the container uses an isolated network namespace, preventing direct access to host network interfaces, iptables rules, and network services. This is the correct field to disable to meet the requirement of preventing container access to the host's network.

Exam trap

CNCF often tests the distinction between `hostNetwork` and `privileged` — candidates mistakenly think that disabling `privileged` alone prevents host network access, but `privileged` controls capabilities and device access, not namespace isolation, so `hostNetwork` must be explicitly set to `false`.

How to eliminate wrong answers

Option A is wrong because `hostIPC` controls access to the host's Inter-Process Communication (IPC) namespace (e.g., shared memory segments), not network access. Option B is wrong because `privileged` grants the container all capabilities and removes most kernel-level restrictions, but it does not specifically control network namespace sharing; a privileged container can still have `hostNetwork: false` and be isolated from the host network. Option C is wrong because `hostPID` allows the container to see all host processes via the PID namespace, which is unrelated to network access.

Practice this question →

158

MCQhard

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

A.The pod must run as privileged to use AppArmor

B.The annotation is missing the 'localhost/' prefix

C.The profile is in complain mode, not enforce mode

D.The profile is not loaded on the node

AnswerC

In complain mode, AppArmor allows all actions and only logs violations; it does not enforce restrictions.

Why this answer

Option C is correct because AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Exam trap

CNCF often tests the distinction between 'complain' and 'enforce' modes, where candidates mistakenly assume that a loaded profile always enforces restrictions, ignoring that complain mode only logs violations without blocking them.

How to eliminate wrong answers

Option A is wrong because AppArmor does not require the pod to run as privileged; it works with standard containers and enforces profiles at the kernel level via LSM hooks. Option B is wrong because the annotation 'localhost/my-profile' already includes the 'localhost/' prefix, which is the correct format for referencing a locally loaded profile. Option D is wrong because the question explicitly states the profile 'my-profile' is loaded on the node in complain mode, so it is present and not missing.

Practice this question →

159

MCQhard

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?

A.The PSP API version needs to be updated to v1

B.PSPs were replaced by NetworkPolicies in 1.25

C.PSP support was removed from Kubernetes in 1.25

D.The PSP was not applied to the correct namespace

AnswerC

Correct. PodSecurityPolicy was removed in Kubernetes 1.25.

Why this answer

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.

Exam trap

The trap here is that candidates may think PSPs are merely deprecated or need a version update, but the CKS exam tests the specific knowledge that PSP was removed entirely in 1.25, and that NetworkPolicies serve a completely different purpose.

How to eliminate wrong answers

Option A is wrong because PSP API version updates are irrelevant; the entire PSP API was removed in 1.25, not just deprecated or requiring a version bump. Option B is wrong because NetworkPolicies control network traffic between pods, not pod security constraints like privileged containers; they are not a replacement for PSPs. Option D is wrong because namespace scoping is not the issue; PSPs were cluster-level resources that applied globally via admission controllers, and their removal affects all namespaces equally.

Practice this question →

160

MCQeasy

Which command loads an AppArmor profile into the kernel?

A.apparmor_load /path/to/profile

B.aa-load /path/to/profile

C.aa-status /path/to/profile

D.apparmor_parser -r /path/to/profile

AnswerD

apparmor_parser loads the profile into the kernel.

Why this answer

The `apparmor_parser` command is the standard tool for loading AppArmor profiles into the Linux kernel. The `-r` flag (replace) loads or reloads the specified profile file, merging it into the kernel's security policy. This is the correct method because AppArmor profiles are text files that must be parsed and loaded by the kernel's LSM (Linux Security Module) subsystem via this utility.

Exam trap

The trap here is that candidates may confuse the command with similar-sounding names like `aa-load` or `apparmor_load`, or mistake `aa-status` (a status-checking tool) for a loading command, because the CKS exam often tests precise command names and their specific functions.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; AppArmor does not provide a command with that name. Option B is wrong because `aa-load` is not a standard AppArmor command; the correct command is `apparmor_parser`. Option C is wrong because `aa-status` is used to check the status of loaded AppArmor profiles (e.g., which profiles are enforced or complain mode), not to load a profile into the kernel.

Practice this question →