CCNA System Hardening Questions

Multi-Selectmedium

Which TWO AppArmor modes are available? (Select 2)

Select 2 answers

A.enforce

B.complain

C.audit

D.allow

E.unconfined

AnswersA, B

Enforce mode actively denies actions not allowed by the profile.

Why this answer

AppArmor has two operational modes: 'enforce' and 'complain'. In 'enforce' mode, AppArmor actively enforces the security policy, blocking actions that violate the profile and logging the denial. In 'complain' mode, AppArmor logs policy violations but does not block them, allowing administrators to test profiles before enforcing them.

Exam trap

The CNCF CKS exam often tests the distinction between AppArmor modes and profile rule keywords, leading candidates to confuse 'audit' (a rule keyword) or 'unconfined' (a process state) with actual operational modes.

Practice this question →

MCQhard

You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?

A.Restrict SSH access to the node using firewall rules

B.Disable unnecessary system services (e.g., telnet, rsh) on the node

C.Drop the NET_RAW capability from all containers running on the node

D.Apply the latest security patches to the host kernel

AnswerC

This is a container-level hardening measure. While beneficial, it does not directly harden the node itself.

Why this answer

The least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.

Exam trap

The trap here is that candidates confuse container-level security controls (like dropping capabilities) with node-level hardening, assuming any security measure applied to containers also hardens the underlying node, when in fact node hardening requires direct OS and infrastructure changes.

How to eliminate wrong answers

Option A is wrong because restricting SSH access via firewall rules directly reduces the node's network attack surface by limiting administrative access, which is a fundamental node hardening practice. Option B is wrong because disabling unnecessary services like telnet and rsh eliminates legacy, unencrypted protocols that could be exploited to compromise the node, making it a critical hardening step. Option D is wrong because applying the latest security patches to the host kernel addresses known vulnerabilities in the node's core operating system, which is essential for node-level security.

Practice this question →

MCQmedium

A pod is running with AppArmor enabled using a profile named 'k8s-apparmor-profile'. You want to verify that the profile is loaded and set to enforce mode. Which command should you run on the node?

A.aa-status

B.aa-profile --status

C.aa-enabled

D.cat /sys/kernel/security/apparmor/profiles

AnswerA

'aa-status' lists all loaded AppArmor profiles and their modes (enforce/complain).

Why this answer

`aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

Exam trap

The trap here is that candidates may confuse `aa-enabled` (which only checks if AppArmor is enabled) with `aa-status` (which shows loaded profiles and their modes), or they may think the raw kernel interface file is the correct answer, but the CKS exam expects knowledge of the standard user-space tool `aa-status` for verification.

How to eliminate wrong answers

Option B is wrong because `aa-profile --status` is not a valid AppArmor command; the correct command to check profile status is `aa-status` or `apparmor_status`. Option C is wrong because `aa-enabled` only checks if AppArmor is enabled on the system (returns 0 if enabled, 1 if not), but it does not list loaded profiles or their enforcement mode. Option D is wrong because while `cat /sys/kernel/security/apparmor/profiles` does list loaded profiles and their modes, it is a raw kernel interface that may not be available in all environments (e.g., containers or systems without securityfs mounted) and is less user-friendly than `aa-status`; the question asks for a command to run, and `aa-status` is the standard, reliable tool.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Audit

B.Disabled

C.Complain

D.Enforce

E.Unconfined

AnswersC, D

Complain mode is a valid AppArmor profile mode in which policy violations are logged but not blocked. When a profile runs in complain mode (sometimes called learning mode), the kernel records every action that would have been denied under enforce mode to the audit log, while still allowing the operation to proceed. This is typically used during profile development or debugging to see what a profile would catch before enforcing it. A profile can be set to complain mode by appending 'complain' to the profile declaration or by using the aa-complain command.

Why this answer

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.

Exam trap

In the CNCF-CKS exam, candidates often confuse profile modes with process states. The trap here is mistaking 'Unconfined' (a process state with no profile) for a valid profile mode, or thinking 'Audit' is a mode when it is actually a profile flag.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Setting 'securityContext.seccompProfile.type' in the pod spec

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

C.Including 'seccomp' profile in PodSecurityPolicy

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

E.Adding annotation 'seccomp.security.alpha.kubernetes.io/pod'

AnswersA, E

This is the current recommended way.

Why this answer

The `securityContext.seccompProfile.type` field in the pod spec is the current, stable method to apply a seccomp profile to a pod in Kubernetes (since v1.19). This field directly specifies the seccomp profile type (e.g., `RuntimeDefault`, `Localhost`, or `Unconfined`) at the container or pod level, and is the recommended approach in modern clusters.

Exam trap

CNCF often tests the distinction between deprecated/removed features (like PodSecurityPolicy) and current stable APIs, and the trap here is that candidates confuse the old annotation-based approach (`seccomp.security.alpha.kubernetes.io/pod`) with the modern `securityContext.seccompProfile.type` field, or mistake AppArmor annotations for seccomp annotations.

Practice this question →

MCQmedium

An administrator wants to enforce a custom AppArmor profile named 'k8s-apparmor-example' on a pod. The profile has been loaded on the node. Which annotation should be added to the pod's metadata to apply this profile?

A.container.apparmor.security.beta.kubernetes.io/nginx: localhost/k8s-apparmor-example

B.container.apparmor.security.beta.kubernetes.io/pod: localhost/k8s-apparmor-example

C.apparmor.security.beta.kubernetes.io/pod: k8s-apparmor-example

D.container.apparmor.security.beta.kubernetes.io/nginx: k8s-apparmor-example

AnswerA

This is correct. The annotation key uses the required 'container.' prefix followed by the exact container name 'nginx', and the value provides the 'localhost/' prefix to reference a preloaded AppArmor profile on the node. The kubelet reads this annotation and enforces the profile 'k8s-apparmor-example' on the nginx container, failing to start the container if the profile is not loaded on the node.

Why this answer

The annotation format for applying an AppArmor profile to a container in a pod is `container.apparmor.security.beta.kubernetes.io/<container_name>`. The value `localhost/k8s-apparmor-example` specifies that the profile named `k8s-apparmor-example` is loaded locally on the node. This annotation enforces the profile on the container named 'nginx'.

Exam trap

CNCF often tests the exact annotation syntax, specifically that the key must include `container.` and the container name, and the value must include `localhost/` for a custom profile, leading candidates to confuse the pod-level annotation with the container-level one.

How to eliminate wrong answers

Option B is wrong because the annotation key uses `pod` instead of the actual container name (`nginx`); the annotation must target a specific container, not the pod. Option C is wrong because the annotation key is missing the `container.` prefix and uses `pod` instead of the container name, and the value lacks the `localhost/` prefix required for a locally loaded profile. Option D is wrong because it is identical to Option A and is listed as correct, but the question expects only one correct answer; however, in the provided options, Option A is marked as correct and Option D is a duplicate, so Option D is considered wrong in the context of the answer set because it is not the designated correct choice.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid AppArmor profile modes?

Select 2 answers

A.Complain

B.Enforce

C.Audit

D.Disable

E.Permissive

AnswersA, B

In complain mode, violations are logged but not blocked.

Why this answer

AppArmor has two primary operational modes: 'Complain' (also known as 'learning' mode) and 'Enforce'. In Complain mode, policy violations are logged but not blocked, allowing administrators to test profiles. In Enforce mode, violations are both logged and blocked, actively enforcing the security policy.

Exam trap

The CKS exam often tests the distinction between AppArmor and SELinux modes; the trap here is that candidates confuse 'Permissive' (SELinux) with 'Complain' (AppArmor), or assume 'Audit' is a valid AppArmor mode because of the Linux audit subsystem.

Practice this question →

Multi-Selectmedium

Which TWO of the following are valid ways to reduce the attack surface of a Kubernetes node? (Select 2)

Select 2 answers

A.Load all kernel modules to support any workload

B.Restrict hostNetwork, hostPID, and hostIPC access from containers

C.Enable SSH access for all users for troubleshooting

D.Disable unnecessary system services on the node

E.Allow containers to run as root

AnswersB, D

These settings reduce a container's ability to access host resources.

Why this answer

Restricting hostNetwork, hostPID, and hostIPC access from containers is a valid way to reduce the attack surface of a Kubernetes node because it prevents containers from breaking out of their namespace isolation. When a container uses hostNetwork, it shares the node's network stack, potentially allowing it to sniff traffic or bind to privileged ports. Similarly, hostPID and hostIPC grant access to the host's process table and inter-process communication mechanisms, which can be leveraged for privilege escalation or information disclosure.

By default, these should be disabled unless absolutely necessary, as they directly expose host-level resources to the container.

Exam trap

CNCF often tests the misconception that loading all kernel modules is beneficial for compatibility, when in fact it violates the principle of minimizing the attack surface by only loading required modules.

Practice this question →

MCQmedium

A security team wants to ensure that all containers in a pod run with only the minimum required Linux capabilities. Which of the following approaches is BEST?

A.Set securityContext.capabilities.drop: ['ALL'] with no add

B.Leave capabilities unset to use the default set

C.Add only the necessary capabilities without dropping

D.Set securityContext.capabilities.drop: ['ALL'] and add only necessary capabilities

AnswerD

Setting securityContext.capabilities.drop to ALL and then adding only the required capabilities is the correct hardening approach because it starts with zero capabilities, eliminating every default privilege that could be exploited. By explicitly adding back only the specific capabilities needed for the application to function—such as NET_BIND_SERVICE or SYS_TIME—the container runs with the absolute minimum privilege necessary. This reduces the potential impact of a container breakout and adheres to the security principle of least privilege.

Why this answer

It implements the principle of least privilege by first dropping all capabilities with `drop: ['ALL']` and then explicitly adding back only those capabilities that are strictly necessary for the container to function. This ensures that the container runs with the absolute minimum set of Linux capabilities, reducing the attack surface and adhering to Kubernetes security best practices for system hardening.

Exam trap

CNCF often tests the misconception that simply dropping all capabilities is sufficient, but the trap here is that dropping all without adding necessary ones can break the application, while adding capabilities without dropping all leaves unnecessary capabilities enabled, both of which fail the 'minimum required' requirement.

How to eliminate wrong answers

Option A is wrong because dropping all capabilities without adding any back may cause the container to fail if it requires any capabilities to operate (e.g., `NET_BIND_SERVICE` for binding to privileged ports), leading to runtime errors. Option B is wrong because leaving capabilities unset uses the default set, which includes many capabilities (e.g., `CHOWN`, `DAC_OVERRIDE`, `FOWNER`, `FSETID`, `KILL`, `SETGID`, `SETUID`, `SETPCAP`, `NET_BIND_SERVICE`, `NET_RAW`, `SYS_CHROOT`, `MKNOD`, `AUDIT_WRITE`, `SETFCAP`) that are often unnecessary and increase the risk of privilege escalation. Option C is wrong because adding only necessary capabilities without first dropping all capabilities leaves the default capabilities intact, which still includes potentially dangerous capabilities that are not required, violating the principle of least privilege.

Practice this question →

MCQeasy

Which of the following host access settings should be disabled to reduce the attack surface of a container?

A.hostNetwork: true

B.hostPID: true

C.hostIPC: true

D.hostPID: false

AnswerD

The secure configuration is hostPID: false, which isolates the container's PID namespace so it can only see its own processes. This minimizes the attack surface by preventing a compromised container from inspecting or manipulating host-level processes, thereby maintaining strong isolation and reducing the potential for privilege escalation or information disclosure.

Why this answer

Setting `hostPID: false` explicitly disables the container's access to the host's process ID namespace, which reduces the attack surface by preventing the container from seeing or interacting with host processes. In Kubernetes, when `hostPID` is set to `true`, the container shares the host's PID namespace, allowing it to potentially escalate privileges or interfere with other workloads. Disabling this setting (i.e., `false`) is a recommended security best practice to enforce process isolation.

Exam trap

The trap here is that candidates often confuse the boolean value that should be set to disable the feature (i.e., `false`) with the dangerous setting itself (i.e., `true`), so they might incorrectly select `hostPID: true` as the answer to disable, when the question explicitly asks for the disabled setting.

How to eliminate wrong answers

Option A is wrong because `hostNetwork: true` enables the container to use the host's network stack directly, bypassing network isolation and exposing the container to host network attacks, but the question asks for a setting that should be disabled to reduce the attack surface, and `hostNetwork: true` is a dangerous setting that should be disabled (set to false), not enabled. Option B is wrong because `hostPID: true` is the dangerous setting that should be disabled; the question asks for the disabled setting, and `hostPID: true` is the enabled state, not the disabled one. Option C is wrong because `hostIPC: true` allows the container to use the host's inter-process communication (IPC) namespace, which can lead to shared memory attacks or information leakage, but again, the question asks for the disabled setting, and `hostIPC: true` is the enabled state that should be disabled.

Practice this question →

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

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 →