Courseiva

CCNA Cks System Hardening Questions

75 of 137 questions · Page 1/2 · Cks System Hardening topic · Answers revealed

Practice these questionsExam hubAll questions
1
MCQmedium

A security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

A.Privileged
B.Custom
C.Baseline
D.Restricted
AnswerD

The restricted level is the Pod Security Standard that directly fulfills the requirement: it mandates that every container set securityContext.capabilities.drop to ALL and permits adding back only the NET_BIND_SERVICE capability when required, such as for binding to low-numbered ports. It also enforces runAsNonRoot, a non-zero runAsUser, allowPrivilegeEscalation: false, and the RuntimeDefault seccomp profile. This capability-denylist-plus-allowlist approach matches the security engineer's intent to eliminate all non-essential capabilities.

Why this answer

The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

Exam trap

CNCF often tests the misconception that 'Baseline' is sufficient for strict capability control, but Baseline only blocks known dangerous capabilities (e.g., `CAP_SYS_ADMIN`) and does not require dropping all capabilities, so candidates must recognize that only Restricted enforces a full drop-all policy.

How to eliminate wrong answers

Option A is wrong because the Privileged profile allows unrestricted capabilities and does not enforce dropping any, which is the opposite of the requirement. Option B is wrong because 'Custom' is not a valid Pod Security Standard; the three built-in standards are Privileged, Baseline, and Restricted. Option C is wrong because the Baseline profile only prevents known privilege escalations but does not require dropping all capabilities by default, so it does not enforce the strict capability policy needed.

Practice this question →
2
Multi-Selecthard

A security auditor recommends limiting the use of host namespaces in pods. Which THREE of the following fields, if set to true, expose the host namespace to a container?

Select 3 answers
A.hostPID
B.hostIPC
C.hostFS
D.hostUsers
E.hostNetwork
AnswersA, B, E

Setting hostPID: true mounts the host's PID namespace into the container, allowing it to see all processes running on the node, including those of other pods and system daemons. This breaks namespace isolation and creates a severe privilege escalation risk because the container could discover secrets in process arguments or signal critical system processes. It should only be used in highly trusted, admin-controlled pods.

Why this answer

Setting `hostPID: true` in a Pod spec allows the container to share the host's process ID namespace. This means the container can see and interact with all processes running on the host node, which breaks process isolation and can lead to privilege escalation or information leakage.

Exam trap

CNCF often tests the distinction between actual Pod spec fields (`hostPID`, `hostIPC`, `hostNetwork`) and non-existent or runtime-specific fields like `hostFS` or `hostUsers`, which candidates might confuse with host namespace options.

Practice this question →
3
MCQmedium

You are managing a Kubernetes cluster that hosts multiple microservices. The cluster uses Kubernetes v1.25. Recently, a security audit identified that containers are running with the default seccomp profile (unconfined). The security team has requested that all containers use a seccomp profile that blocks unnecessary syscalls. You need to implement this cluster-wide without breaking existing applications. The audit also found that the kubelet's anonymous authentication is enabled, which should be disabled. Additionally, you need to ensure that the kubelet's NodeRestriction admission controller is enabled to limit what nodes can do. Which of the following is the most appropriate sequence of actions?

A.Disable anonymous authentication immediately, then enable NodeRestriction, and finally apply the restrictive seccomp profile
B.Apply the 'runtime/default' seccomp profile cluster-wide immediately, then disable anonymous auth, and finally enable NodeRestriction
C.Enable NodeRestriction first, then apply a restrictive seccomp profile, and last disable anonymous authentication
D.First, configure the kubelet to use a seccomp profile that logs violations (e.g., 'runtime/default' with log), then after verifying no breakage, switch to 'runtime/default'. Then disable anonymous authentication and enable NodeRestriction admission controller
AnswerD

This order works because it first configures the kubelet to use a seccomp profile that logs violations, such as a Localhost profile that maps default-blocked syscalls to SCMP_ACT_LOG instead of SCMP_ACT_ERRNO. After observing logs for a period and confirming that no application-required syscall is being denied, you can switch to enforcing 'runtime/default' with low risk. Then, disabling anonymous authentication closes unauthenticated access to the kubelet/API, and enabling NodeRestriction constrains what a compromised kubelet can change, completing the hardening. This phased approach, validate-then-enforce, prevents downtime and gives you evidence for every security decision.

Why this answer

It follows the principle of least disruption: first, it applies the 'runtime/default' seccomp profile in logging mode to detect any blocked syscalls without breaking applications. After verifying no breakage, it switches to enforcing mode. Then, it disables anonymous authentication and enables the NodeRestriction admission controller, both of which are non-disruptive configuration changes.

This sequence minimizes risk to existing workloads while meeting all audit requirements.

Exam trap

The trap here is that candidates rush to apply the restrictive seccomp profile immediately (options A, B, C) without considering the need for a gradual rollout via logging mode to avoid breaking existing applications, which is a key CKS focus on safe system hardening.

How to eliminate wrong answers

Option A is wrong because disabling anonymous authentication immediately could break cluster components that rely on it (e.g., kubelet health checks) before verifying dependencies, and applying a restrictive seccomp profile without testing could crash applications. Option B is wrong because applying 'runtime/default' immediately without logging mode first risks breaking existing applications that depend on blocked syscalls. Option C is wrong because enabling NodeRestriction first is safe but applying a restrictive seccomp profile without prior logging validation could cause application failures, and disabling anonymous authentication last leaves a security gap during the process.

Practice this question →
4
MCQmedium

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?

A.Use seccomp profiles to block privilege escalation syscalls
B.Apply AppArmor profiles to all control plane pods
C.Configure control plane containers to run as non-root user and with read-only root filesystem
D.Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces
AnswerC

Setting runAsNonRoot: true and an explicit runAsUser (for example, 1000) in the pod security context, along with readOnlyRootFilesystem: true, directly removes root privileges and makes the container's immutable root filesystem fail-closed on any write attempt. This is the most effective hardening for control plane components because it attacks both privilege escalation and tampering of the container's filesystem at the source, rather than filtering specific kernel or program actions.

Why this answer

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.

Exam trap

CNCF often tests the distinction between runtime security mechanisms (seccomp, AppArmor) and container-level privilege controls (user ID, read-only filesystem), leading candidates to choose a syscall or MAC profile instead of the direct least-privilege configuration.

How to eliminate wrong answers

Option A is wrong because seccomp profiles restrict system calls (syscalls) but do not control the user identity under which a container runs or prevent privilege escalation via user namespace manipulation; they are a complementary measure, not a primary least-privilege approach. Option B is wrong because AppArmor profiles enforce mandatory access control on a per-program basis but do not change the user context of the container process; they also require a profile to be loaded on the node, which may not be available for all control plane components. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, and even when available, it only enforces policies at the pod admission level, not directly on the container runtime configuration; moreover, control plane components are often managed as static pods or systemd services, not through the Kubernetes API, making PSP inapplicable.

Practice this question →
5
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 applies the loaded profile's rules and actively blocks any operation they deny, logging violations. This satisfies the question's requirement for a valid AppArmor mode, alongside complain mode, which permits actions but records them.

Why this answer

AppArmor provides exactly two operational modes for a profile: enforce (option A) and complain (option B). In enforce mode, the profile's rules are actively applied and any access that violates the policy is denied and logged, which is the default mode for loaded profiles. In complain mode, violations are not blocked but are instead logged as complaints, allowing administrators to test and refine a profile before enforcing it.

The other options are not AppArmor modes: audit (C) is not a mode but rather a logging facility/flag, allow (D) is not an AppArmor mode (it resembles SELinux terminology or a policy rule action), and unconfined (E) describes a process with no profile attached, not a selectable profile mode.

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 →
6
MCQhard

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?

A.kubectl label namespace prod pod-security.kubernetes.io/warn=restricted
B.kubectl label namespace prod pod-security.kubernetes.io/audit=restricted
C.kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted
D.kubectl annotate namespace prod security.kubernetes.io/pod-security=restricted
AnswerC

This command correctly applies the `pod-security.kubernetes.io/enforce` label with the value `restricted`, which makes the Pod Security Admission controller reject any Pod that fails the restricted Pod Security Standard. The enforcement is mandatory: the Pod admission request is denied and the API server returns an error. This is the standard, documented mechanism for enforcing a Pod Security Standard at the namespace level.

Why this answer

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.

Exam trap

The trap here is that candidates confuse the three modes (enforce, audit, warn) and often pick `warn` or `audit` thinking they provide enforcement, or they mistakenly use an annotation instead of a label, which is not recognized by the PodSecurity admission controller.

How to eliminate wrong answers

Option A is wrong because the `warn` label only generates a warning message when a non-compliant pod is created, but does not block the pod. Option B is wrong because the `audit` label adds an audit event to the audit log for non-compliant pods, but does not enforce or block them. Option D is wrong because it uses an incorrect annotation key (`security.kubernetes.io/pod-security`) and the `annotate` command instead of `label`; the correct mechanism uses labels with the `pod-security.kubernetes.io/enforce` key.

Practice this question →
7
MCQeasy

A DevOps team wants to ensure that all container images are pulled from a trusted registry only. Which cluster-level configuration should be applied?

A.Configure kubelet with --pod-manifest-path pointing to a whitelist
B.Enable PodSecurity with restricted profile
C.Use NetworkPolicy to block traffic to untrusted registries
D.Enable ImagePolicyWebhook admission controller
AnswerD

ImagePolicyWebhook is an admission controller that intercepts Pod create and update operations and sends an ImageReview payload containing each container's image name to an external HTTP/HTTPS service. The webhook responds with an admission decision, allowing an administrator to reject any image that doesn't come from a trusted registry, tag, or digest. This is the standard built-in mechanism for applying a centralized, registry-aware image policy to every Pod submitted through the API server.

Why this answer

The ImagePolicyWebhook admission controller allows you to configure a cluster-level admission plugin that intercepts all Pod creation requests and validates the container images against an external webhook backend. This backend can enforce policies such as allowing only images from a trusted registry (e.g., `mytrustedregistry.io/*`), rejecting any image that does not match the whitelist. It operates at the API server level, ensuring that no Pod with an untrusted image can be created in the cluster.

Exam trap

CNCF often tests the distinction between admission controllers that validate image sources (ImagePolicyWebhook) versus those that enforce Pod security contexts (PodSecurity), leading candidates to mistakenly choose PodSecurity when the question is about registry trust.

How to eliminate wrong answers

Option A is wrong because `--pod-manifest-path` is used by the kubelet to load static Pods from a local directory, not to enforce registry whitelisting; it has no mechanism to validate image sources. Option B is wrong because PodSecurity (formerly PodSecurityPolicy) restricts Pod security contexts (e.g., privileged containers, host namespaces), not the registry from which images are pulled. Option C is wrong because NetworkPolicy controls network traffic at the IP/port level (Layer 3/4) and cannot inspect or block the source registry of container images; it cannot prevent a Pod from pulling an image from an untrusted registry.

Practice this question →
8
MCQmedium

A container is running with the following securityContext: securityContext: capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] Which capabilities will the container have?

A.All capabilities except NET_BIND_SERVICE
B.Only NET_BIND_SERVICE
C.No capabilities
D.All default capabilities plus NET_BIND_SERVICE
AnswerB

This is the correct interpretation: the container runs with exactly one Linux capability, `NET_BIND_SERVICE`. When `capabilities.drop` contains `ALL`, the container runtime begins with a completely empty capability set for the process, stripping away all default capabilities such as `CHOWN`, `DAC_OVERRIDE`, and `FOWNER`. Then `capabilities.add` with `NET_BIND_SERVICE` adds back just that one capability, allowing the process to bind to privileged ports (below 1024) but nothing else. This is a common least-privilege pattern for services that need to serve traffic on port 80 or 443.

Why this answer

The securityContext first drops all capabilities with `drop: ["ALL"]`, which removes every capability from the container's bounding set. Then `add: ["NET_BIND_SERVICE"]` adds back only that single capability. Therefore, the final effective set is exactly `NET_BIND_SERVICE`, making option B correct.

Exam trap

Kubernetes often tests the misconception that `drop: ["ALL"]` only removes non-default capabilities, or that adding a capability after dropping all restores the default set; the trap is that the order of operations is sequential and additive, so the final set is exactly what is added, not a union of defaults and additions.

How to eliminate wrong answers

Option A is wrong because dropping ALL and then adding NET_BIND_SERVICE does not leave all capabilities except NET_BIND_SERVICE; the drop operation removes everything, and the add operation only restores the specified capability, so the container ends up with only NET_BIND_SERVICE. Option C is wrong because the add directive explicitly grants NET_BIND_SERVICE, so the container does have that capability, not none. Option D is wrong because the default capabilities are not present; the `drop: ["ALL"]` overrides any defaults, leaving only the explicitly added capability.

Practice this question →
9
MCQmedium

Which of the following is correct about dropping the 'NET_RAW' capability?

A.It prevents the container from binding to a privileged port (<1024)
B.It prevents the container from using the 'ping' command
C.It prevents the container from creating raw sockets, which can be used for packet crafting attacks
D.It prevents the container from making any network connections
AnswerC

CAP_NET_RAW governs the ability to create raw sockets via socket(AF_INET, SOCK_RAW, protocol), which allows a process to craft arbitrary IP packets, spoof addresses, and forge protocol headers. Dropping this capability prevents such packet crafting attacks and also stops raw-socket packet sniffing on the host network, substantially reducing attack surface. Because normal applications use SOCK_STREAM or SOCK_DGRAM, their TCP/UDP traffic is unaffected, making this a precise least-privilege control.

Why this answer

The `NET_RAW` capability controls access to raw and packet sockets (AF_PACKET, SOCK_RAW). Dropping it prevents the container from creating raw sockets, which are often used for crafting custom packets, performing ARP spoofing, or launching other network-layer attacks. This is a key hardening measure to reduce the container's ability to manipulate network traffic at the low level.

Exam trap

CNCF often tests the misconception that 'ping' requires `NET_RAW`, but in modern Linux, ping can use a privileged datagram socket (ICMP_ECHO via SOCK_DGRAM) or setuid, so dropping `NET_RAW` does not always break ping.

How to eliminate wrong answers

Option A is wrong because binding to a privileged port (<1024) is controlled by the `CAP_NET_BIND_SERVICE` capability, not `NET_RAW`. Option B is wrong because the `ping` command typically uses ICMP echo requests, which can be sent via a datagram socket (SOCK_DGRAM) or raw socket; on many systems, ping falls back to a privileged datagram socket, so dropping `NET_RAW` does not necessarily prevent ping from working. Option D is wrong because dropping `NET_RAW` does not affect standard TCP/UDP connections; those use socket types (SOCK_STREAM, SOCK_DGRAM) that are governed by other capabilities like `CAP_NET_ADMIN` or `CAP_NET_RAW` only for raw sockets.

Practice this question →
10
MCQhard

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?

A.container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile
B.apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile
C.container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/my-custom-profile
D.container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce
AnswerC

This is the correct format for per-container AppArmor confinement. The key `container.apparmor.security.beta.kubernetes.io/<container_name>` tells the kubelet to apply the specified profile to the container identified by `<container_name>`. The value `localhost/my-custom-profile` instructs the kubelet to load a profile named `my-custom-profile` from the node's AppArmor profile directory (typically `/etc/apparmor.d`). The kubelet verifies that the profile is loaded before starting the container; if it isn't, the pod is rejected.

Why this answer

The AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>` with the value `localhost/<profile_name>`. 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.

Exam trap

CNCF often tests the exact annotation key format and the necessity of the `localhost/` prefix, leading candidates to omit the `container.` prefix or the `localhost/` value, or to confuse the annotation structure with other security contexts like seccomp or SELinux.

How to eliminate wrong answers

Option A is wrong because the annotation prefix is `container.apparmor.security.beta.kubernetes.io/`, not `container.apparmor.kubernetes.io/` — the latter is not a valid Kubernetes annotation key for AppArmor. Option B is wrong because the annotation key is missing the `container.` prefix and the value is missing the `localhost/` prefix; the correct value must be `localhost/my-custom-profile`, not just `my-custom-profile`. Option D is wrong because the annotation key incorrectly places the profile name in the key itself and uses `enforce` as the value; the correct format uses the container name in the key and `localhost/<profile_name>` as the value.

Practice this question →
11
MCQeasy

What is the purpose of the 'seccomp' feature in Kubernetes?

A.To restrict file system access for a container
B.To restrict the system calls a container can make
C.To restrict the Linux capabilities a container can use
D.To restrict network access for a container
AnswerB

Seccomp (secure computing mode) is a Linux kernel feature that constrains a containerized process to a specific set of allowed system calls. In Kubernetes, you define a profile via seccompProfile (Unconfined, RuntimeDefault, or Localhost) and the container runtime loads the BPF filter to intercept syscalls; any call not in the allowlist is rejected or triggers a default action. This shrinks the kernel attack surface by blocking dangerous syscalls such as mount, ptrace, or kexec_load, which is the core purpose of seccomp.

Why this answer

Seccomp (secure computing mode) is a Linux kernel feature that allows a process to specify a filter for the system calls it can make. In Kubernetes, seccomp profiles can be applied to pods or containers to restrict the allowed syscalls, reducing the kernel attack surface. This is a key mechanism for container runtime security, distinct from filesystem, capability, or network controls.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and Linux capabilities (privilege granularity), so candidates may confuse restricting capabilities with restricting syscalls.

How to eliminate wrong answers

Option A is wrong because restricting file system access is achieved via read-only root filesystems, securityContext with readOnlyRootFilesystem, or AppArmor/SELinux profiles, not seccomp. Option C is wrong because restricting Linux capabilities is done via the 'capabilities' field in securityContext (e.g., drop: ALL), while seccomp filters syscalls at a lower level. Option D is wrong because restricting network access is managed by NetworkPolicies, not seccomp.

Practice this question →
12
MCQmedium

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?

A.The container is privileged
B.The profile was loaded in complain mode using apparmor_parser with the -C flag
C.The pod's securityContext sets allowPrivilegeEscalation to true
D.The annotation is incorrectly formatted
AnswerB

AppArmor profiles have two modes: enforce and complain. The `apparmor_parser` with `-C` (or `--complain`) loads the profile into complain mode, where violations are logged via audit but not blocked. If a pod's profile was loaded in complain mode, the kernel allows the denied operations while recording them, so the pod appears to run without AppArmor enforcement even though the profile is actively attached. This precisely matches the symptom: the profile is loaded but not enforcing.

Why this answer

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.

Exam trap

CNCF often tests the distinction between enforce and complain modes in AppArmor, where candidates assume a loaded profile is always enforced, but the `-C` flag changes behavior to logging-only.

How to eliminate wrong answers

Option A is wrong because a privileged container would bypass AppArmor entirely, but the question states the profile is loaded and the annotation is set, so the issue is about enforcement mode, not privilege. Option C is wrong because `allowPrivilegeEscalation` controls whether processes can gain more privileges than their parent, but it does not affect AppArmor profile enforcement; AppArmor enforces regardless of privilege escalation settings. Option D is wrong because the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write' is correctly formatted per Kubernetes conventions, using the profile name prefixed with 'localhost/'.

Practice this question →
13
MCQmedium

A node in your cluster is running unnecessary services that increase the attack surface. Which of the following is the BEST approach to reduce the attack surface on the node?

A.Use a firewall to block all ports except those required
B.Apply a NetworkPolicy to block traffic to the node
C.Identify and disable unnecessary system services using systemctl or similar tools
D.Use AppArmor to confine the services
AnswerC

Disabling and removing unnecessary services with systemctl --now disable and optionally masking their unit files stops the running process and prevents it from starting at boot, eliminating the attack vector at the source. This follows the least functionality principle, which is the correct remediation for unnecessary services. It also frees system resources and reduces the surface available to an attacker who has achieved code execution on the node. For a Kubernetes node, keep only required services such as containerd, kubelet, kube-proxy, and necessary system utilities.

Why this answer

The most direct way to reduce the attack surface on a node is to disable unnecessary services that are actively listening or running. Tools like `systemctl disable` or `systemctl stop` permanently turn off services such as `telnet`, `rpcbind`, or `cups`, which are common vectors for exploitation. Simply blocking ports with a firewall (A) leaves the service running and potentially exploitable via localhost or if the firewall is misconfigured, while AppArmor (D) confines but does not remove the service.

NetworkPolicies (B) operate at the Kubernetes network layer and cannot control host-level services.

Exam trap

A common mistake in the CKS exam is to focus on network-level controls (firewall, NetworkPolicy) or confinement (AppArmor) rather than disabling the unnecessary service directly. The key is that disabling the service removes the attack surface entirely, whereas blocking or confining still leaves the service running and potentially exploitable through other means.

How to eliminate wrong answers

Option A is wrong because a firewall only blocks network access to ports but does not stop the underlying service from running; the service remains active and could be exploited locally or if the firewall rule is bypassed. Option B is wrong because a NetworkPolicy is a Kubernetes resource that controls pod-to-pod traffic within the cluster and has no effect on host-level services running directly on the node. Option D is wrong because AppArmor provides mandatory access control to confine a service's capabilities, but it does not disable or remove the service, so the attack surface from the service's existence and potential vulnerabilities remains.

Practice this question →
14
Matchingmedium

Match each etcd security configuration to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Encrypts communication between etcd clients and the etcd server

Encrypts communication between etcd cluster members

Requires clients to present a valid certificate to access etcd

Encrypts etcd data stored on disk (requires manual configuration)

Limits which users or clients can perform operations on etcd keys

Why these pairings

In this matching exercise, each etcd security configuration should be paired with its correct description. Common confusions arise between client-to-server TLS and peer-to-peer TLS due to similar wording. Client-to-server TLS secures communication between clients and the cluster, while peer-to-peer TLS secures inter-member communication.

Client certificate authentication and RBAC are distinct security features.

Practice this question →
15
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

Dropping NET_RAW restricts container capabilities, which is a pod-level control, not node hardening. Node hardening targets the host itself: kubelet flags, file permissions, kernel parameters and package updates. Capability removal leaves the underlying node configuration untouched, making it least effective here.

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 →
16
MCQmedium

A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?

A.capabilities.drop: ["ALL"] capabilities.add: ["NET_BIND_SERVICE"]
B.cap_drop: ["NET_RAW"]
C.cap_add: ["ALL"]
D.cap_add: ["NET_BIND_SERVICE"]
AnswerA

This configuration correctly satisfies the policy by first using capabilities.drop: ["ALL"] to clear the container's entire capability bounding set, effectively denying every privilege by default. It then explicitly re-adds only NET_BIND_SERVICE, which is the specific capability required to bind to privileged ports (those below 1024). This follows the principle of least privilege: the container starts with nothing and receives only the single capability necessary for its intended function, making it compliant and secure.

Why this answer

It drops all Linux capabilities using `capabilities.drop: ["ALL"]` and then explicitly adds only the necessary `NET_BIND_SERVICE` capability via `capabilities.add: ["NET_BIND_SERVICE"]`. This adheres to the principle of least privilege by starting from a clean slate and granting only the required capability. In Kubernetes security contexts, the correct keys are `capabilities.drop` and `capabilities.add` under the `securityContext` field.

Options B and D partially meet the requirement but do not drop all capabilities; Option C adds all capabilities, violating the policy.

Exam trap

CNCF often tests the misconception that simply adding a capability is sufficient, without realizing that the default capability set 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`) and that dropping all first is mandatory to enforce least privilege.

How to eliminate wrong answers

Option B is wrong because `cap_drop: ["NET_RAW"]` only drops the `CAP_NET_RAW` capability, leaving all other capabilities intact, which violates the requirement to drop all capabilities first. Option C is wrong because `cap_add: ["ALL"]` adds every capability, which is the opposite of dropping all capabilities and contradicts the security policy. Option D is wrong because `cap_add: ["NET_BIND_SERVICE"]` without a preceding `cap_drop: ["ALL"]` only adds the capability on top of the default set, which still includes many unnecessary capabilities, failing to meet the 'drop all' requirement.

Practice this question →
17
Multi-Selectmedium

Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?

Select 3 answers
A.Scan images for vulnerabilities before deployment
B.Store sensitive configuration data directly in the image
C.Use imagePullSecrets to authenticate to private container registries
D.Use minimal base images like distroless or scratch
E.Run containers as root to avoid permission issues
AnswersA, C, D

Scanning images for known vulnerabilities before deployment is a foundational security gate because containers inherit the package inventory of their base image and layers. Tools like Trivy or Grype compare installed packages against vulnerability databases in CI/CD, failing builds on critical flaws. Without this check, vulnerable images can run indefinitely, giving attackers a known path to exploit in production.

Why this answer

Scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide.

Option C is correct because using imagePullSecrets is a recommended practice to authenticate to private container registries. While imagePullSecrets do not enforce access control policies on which images can be pulled, they securely store credentials and enable pods to pull images from private registries, which is essential for using images that are not publicly accessible. This prevents unauthorized access to private images and reduces the risk of using compromised public images.

Option D is correct because using minimal base images such as distroless or scratch reduces the attack surface by eliminating unnecessary packages, libraries, and utilities. This aligns with the principle of least functionality and minimizes the number of potential vulnerabilities that could be exploited.

Exam trap

CNCF often tests the misconception that imagePullSecrets (Option C) are used to restrict which images can be pulled from registries, but in reality, imagePullSecrets only authenticate to private registries and do not enforce any access control or policy on which images are allowed to be pulled; for restriction, you need an admission controller like OPA/Gatekeeper or a registry firewall.

Practice this question →
18
MCQhard

A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?

A.seccompProfile: type: Unconfined localhostProfile: "custom-profile.json"
B.seccompProfile: type: RuntimeDefault localhostProfile: "custom-profile.json"
C.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/custom-profile.json"
D.seccompProfile: type: Localhost localhostProfile: "custom-profile.json"
AnswerD

This is the correct configuration: type Localhost tells the kubelet to load a custom seccomp profile from a file on the node, and localhostProfile gives the filename relative to the kubelet's seccomp directory. The kubelet then constructs the full path /var/lib/kubelet/seccomp/custom-profile.json and passes it to the container runtime, which enforces the syscall restrictions defined in that JSON file.

Why this answer

When using a custom seccomp profile stored in the default kubelet seccomp directory (`/var/lib/kubelet/seccomp/`), the `type` must be `Localhost` and the `localhostProfile` must be a relative path (just the filename). Kubernetes automatically prepends the default seccomp root path, so `custom-profile.json` resolves to `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the misconception that `localhostProfile` requires an absolute path, but the correct syntax is a relative path (just the filename) when the profile resides in the default kubelet seccomp directory.

How to eliminate wrong answers

Option A is wrong because `type: Unconfined` disables seccomp entirely and ignores any `localhostProfile` value. Option B is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile, not a custom one, and `localhostProfile` is ignored when type is not `Localhost`. Option C is wrong because `localhostProfile` must be a relative path (just the filename) when the profile is in the default kubelet seccomp directory; an absolute path like `/var/lib/kubelet/seccomp/custom-profile.json` is not valid in this context.

Practice this question →
19
MCQeasy

An admin wants to check which AppArmor profiles are loaded. Which command should they run?

A.apparmor list
B.aa-status
C.seccomp-status
D.ls /sys/kernel/security/apparmor/profiles
AnswerB

aa-status is the canonical utility from the apparmor-utils package that reads the kernel's loaded AppArmor profiles via the securityfs interface and presents them in a human-readable format. It shows each profile's mode (enforce or complain), lists profiles that are loaded, and can optionally display the processes currently confined by each profile. For an admin checking loaded profiles, aa-status is the correct, supported command.

Why this answer

The `aa-status` command is the standard tool for displaying the status of AppArmor, including which profiles are loaded, their enforcement mode (enforce/complain), and process confinement. It queries the AppArmor security module directly via the kernel interface, making it the correct and most comprehensive command for this task.

Exam trap

A common trap is that candidates may think the profiles are listed via a filesystem path or confuse AppArmor with seccomp, which is another Linux security module used in Kubernetes for restricting syscalls. However, `aa-status` is the proper command for AppArmor profile status, and it is often used on Kubernetes nodes to verify profile loading.

How to eliminate wrong answers

Option A is wrong because `apparmor list` is not a valid command; AppArmor does not provide a `list` subcommand. Option C is wrong because `seccomp-status` is not a real command; seccomp (secure computing mode) is a separate Linux kernel feature for syscall filtering, and its status is checked via `/proc/sys/kernel/seccomp/` or `seccomp-tools`, not this command. Option D is wrong because while `ls /sys/kernel/security/apparmor/profiles` does list the profile names as files, it only shows the names and not the full status (e.g., mode, process association), and is not the standard admin command; `aa-status` is the intended tool.

Practice this question →
20
MCQhard

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

A.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest"
B.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: warn: "restricted" warn-version: "latest"
C.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "privileged" enforce-version: "latest"
D.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest"
AnswerA

The `restricted` enforce level applies the most restrictive Pod Security Standard, which is exactly what the security team requires. It rejects any pod that does not meet strict criteria: privileged containers are forbidden, all Linux capabilities are dropped except `NET_BIND_SERVICE`, and settings like `runAsNonRoot` and `seccompProfile` become mandatory. With `enforce-version: latest`, the policy tracks the current standard as Kubernetes evolves, ensuring ongoing compliance without manual updates.

Why this answer

The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Exam trap

The trap here is that candidates often confuse the 'baseline' profile with 'restricted', thinking baseline is sufficient to block added capabilities, but baseline explicitly allows a set of capabilities (e.g., CHOWN, DAC_OVERRIDE) that are not permitted under the restricted standard.

How to eliminate wrong answers

Option B is wrong because it uses 'warn' mode, which only generates a warning but does not block non-compliant pods; the question requires enforcement (blocking) of the restricted profile. Option C is wrong because it uses the 'privileged' profile, which allows all capabilities and is the opposite of the required restriction. Option D is wrong because it uses the 'baseline' profile, which allows a minimal set of capabilities beyond the default (e.g., NET_RAW, CHOWN) and does not enforce the stricter 'restricted' standard that drops all non-default capabilities.

Practice this question →
21
Multi-Selecthard

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

Select 3 answers
A.Seccomp can be configured using the securityContext.seccompProfile field
B.Seccomp profiles can only be applied to privileged containers
C.The RuntimeDefault seccomp profile uses the container runtime's default profile
D.Seccomp can only restrict system calls, not allow them
E.Custom seccomp profiles must be placed in /var/lib/kubelet/seccomp/ on the node
AnswersA, C, E

In the Kubernetes API, seccomp is configured declaratively through the securityContext.seccompProfile field, available at both pod and container scope. This field accepts a type (Unconfined, RuntimeDefault, or Localhost) and optionally a localhostProfile name. Since v1.19 it is GA, superseding the older alpha annotations, and is the only supported way to attach a seccomp profile to workloads.

Why this answer

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.

Exam trap

CNCF often tests the misconception that seccomp only applies to privileged containers or that it can only deny syscalls, when in fact it is a general-purpose syscall filter for all containers and supports both allow and deny actions.

Practice this question →
22
MCQmedium

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?

A.kubectl label namespace myns pod-security.kubernetes.io/audit=restricted
B.kubectl annotate namespace myns pod-security.kubernetes.io/enforce=restricted
C.kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted
D.kubectl label namespace myns pod-security.kubernetes.io/warn=restricted
AnswerC

The enforce level of Pod Security Admission blocks pod creation if it violates the restricted policy, which is the strictest standard. By adding this label to the namespace, the PSA controller applies the policy at admission time, rejecting any non-compliant pod. This matches the administrator's requirement to enforce the policy.

Why this answer

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.

Exam trap

CNCF often tests the distinction between labels and annotations, and the trap here is that candidates confuse `kubectl annotate` with `kubectl label` for setting Pod Security Standard enforcement, or they pick `audit` or `warn` thinking they enforce the policy.

How to eliminate wrong answers

Option A is wrong because `pod-security.kubernetes.io/audit` only logs violations without blocking them, so it does not enforce the policy. Option B is wrong because Pod Security Standards use labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be applied as a label for the admission controller to recognize it. Option D is wrong because `pod-security.kubernetes.io/warn` only generates a warning message for the user but still allows the pod to be created, so it does not enforce the restricted standard.

Practice this question →
23
Multi-Selectmedium

Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)

Select 2 answers
A.Setting securityContext.seLinuxOptions.type
B.Using the seccomp.security.alpha.kubernetes.io/pod annotation
C.Using the container.apparmor.security.beta.kubernetes.io annotation
D.Using the seccomp.security.beta.kubernetes.io/pod annotation
E.Setting securityContext.seccompProfile.type
AnswersB, E

The seccomp.security.alpha.kubernetes.io/pod annotation was the original way to request seccomp enforcement, allowing values like localhost/profile.json or runtime/default. It is alpha-qualified and deprecated; since Kubernetes 1.19 the preferred expression is the seccompProfile field. The annotation still functions in many legacy clusters, but it has no beta counterpart and will be removed as the alpha API is abandoned.

Why this answer

The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.

Exam trap

Kubernetes often tests the distinction between alpha (`seccomp.security.alpha.kubernetes.io/pod`) and beta (`seccomp.security.beta.kubernetes.io/pod`) annotations, where the beta version never existed for seccomp, causing candidates to confuse it with the AppArmor beta annotation pattern.

Practice this question →
24
MCQhard

A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?

A.securityContext: seccompProfile: type: Localhost localhostProfile: custom-profile.json
B.securityContext: seccompProfile: type: Unconfined
C.securityContext: seccompProfile: type: RuntimeDefault localhostProfile: custom-profile.json
D.securityContext: seccomp: profile: custom-profile.json
AnswerA

The correct structure uses seccompProfile.type: Localhost to indicate that a profile file is stored on the node, and localhostProfile: custom-profile.json to reference that specific file. The kubelet looks for the file in the node's seccomp profile directory (typically /var/lib/kubelet/seccomp) and loads it to restrict syscalls for the container. This is the only syntax in the current Kubernetes API that directly applies a custom local seccomp profile.

Why this answer

When using a custom seccomp profile stored on the node, the `type: Localhost` field must be set, and the `localhostProfile` field specifies the filename (relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`). This configuration tells the container runtime to load the profile from the node's filesystem at the path `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the distinction between the `seccompProfile` field (correct in Kubernetes 1.19+) and the older `seccomp` annotation-based syntax, and candidates mistakenly choose option D because they remember the old annotation format or confuse `profile` with `localhostProfile`.

How to eliminate wrong answers

Option B is wrong because `type: Unconfined` disables seccomp entirely, which does not apply any custom profile and is the opposite of what the question asks. Option C is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile, and specifying `localhostProfile` alongside `RuntimeDefault` is invalid; the `localhostProfile` field is only used when `type: Localhost` is set. Option D is wrong because the correct API field is `seccompProfile` (not `seccomp`), and the subfield for the profile name is `localhostProfile` (not `profile`); this syntax is from an older, deprecated API version.

Practice this question →
25
MCQhard

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

A.The pod uses a custom seccomp profile
B.Seccomp is disabled for the pod
C.The pod must have CAP_SYS_ADMIN to use this setting
D.The pod uses the default seccomp profile provided by the container runtime
AnswerD

RuntimeDefault instructs the kubelet to apply the container runtime's own preconfigured seccomp profile, such as containerd's or CRI-O's default, rather than a custom or unconfined policy. This restricts syscalls without requiring a profile file on the node.

Why this answer

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+.

Exam trap

The CKS exam often tests the distinction between `RuntimeDefault`, `Localhost`, and `Unconfined` — the trap here is confusing `RuntimeDefault` with a custom profile or thinking it requires special capabilities, when in fact it is a simple, runtime-provided default that requires no extra privileges.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` explicitly uses the runtime's built-in default profile, not a custom one; a custom profile would be specified with `type: Localhost` and a `localhostProfile` path. Option B is wrong because `RuntimeDefault` enables seccomp enforcement using the runtime's default profile, it does not disable seccomp; disabling seccomp would be `type: Unconfined`. Option C is wrong because no special capability like `CAP_SYS_ADMIN` is required to use `RuntimeDefault`; the seccomp profile is applied by the runtime without requiring additional privileges in the pod's security context.

Practice this question →
26
MCQmedium

A pod is created with the following security context: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json Where must the 'audit.json' file be placed on the node?

A./etc/kubernetes/seccomp/profiles/audit.json
B./var/lib/kubelet/audit.json
C./var/lib/kubelet/seccomp/profiles/audit.json
D./var/lib/containerd/seccomp/audit.json
AnswerC

This is the correct location because the kubelet's default `--seccomp-profile-root` is `/var/lib/kubelet/seccomp`, and the standard practice is to place profile JSON files in a `profiles` subdirectory beneath that root. When a pod references `seccompProfile.type: Localhost` with `localhostProfile: profiles/audit.json`, the kubelet resolves the path to exactly `/var/lib/kubelet/seccomp/profiles/audit.json` and passes the file to the container runtime via CRI. This aligns with Kubernetes documentation and distribution defaults, making it the only viable path for the kubelet to find the profile.

Why this answer

When a pod uses a `seccompProfile` of type `Localhost` with `localhostProfile: profiles/audit.json`, the file path is relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`. Therefore, the complete path on the node must be `/var/lib/kubelet/seccomp/profiles/audit.json`. This is the only location where the kubelet will look for the seccomp profile when `type: Localhost` is specified.

Exam trap

The CNCF CKS exam often tests the default seccomp profile root path (`/var/lib/kubelet/seccomp`) and the fact that `localhostProfile` is relative to that root, not an absolute path or a path under `/etc/kubernetes` or containerd directories.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/seccomp/profiles/audit.json` is not the default root for seccomp profiles; the kubelet uses `/var/lib/kubelet/seccomp` as its base directory. Option B is wrong because `/var/lib/kubelet/audit.json` places the file directly under the kubelet directory, but the seccomp profile must be inside the `seccomp/profiles/` subdirectory relative to the kubelet's seccomp root. Option D is wrong because `/var/lib/containerd/seccomp/audit.json` is a containerd-specific path, not the kubelet's seccomp profile directory; the kubelet does not look for seccomp profiles in containerd's data directory.

Practice this question →
27
Drag & Dropmedium

Order the steps to configure and use Falco for runtime security in a Kubernetes cluster.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Falco installation, configuration, deployment as DaemonSet, monitoring alerts, and tuning are the key steps.

Practice this question →
28
MCQeasy

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

A.apparmor_load my-profile
B.apparmor_parser my-profile
C.apparmor_parser -R my-profile
D.systemctl start apparmor my-profile
AnswerB

apparmor_parser my-profile is the correct way to load an AppArmor profile: it reads the profile file, validates its syntax, compiles it into binary policy, and writes it to the kernel's AppArmor securityfs interface. Once loaded, the kernel enforces the profile's rules against the target process. This command is the standard tool for both loading and replacing profiles (the -a flag explicitly adds a profile).

Why this answer

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.

Exam trap

The trap here is that candidates confuse `apparmor_parser` with a hypothetical `apparmor_load` command or misuse the `-R` flag, thinking it stands for 'run' or 'reload' instead of 'remove'.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; the correct tool is `apparmor_parser`. Option C is wrong because `apparmor_parser -R my-profile` removes (unloads) the profile from the kernel, not loads it. Option D is wrong because `systemctl start apparmor my-profile` is invalid syntax; `systemctl` manages the AppArmor service itself (e.g., `systemctl start apparmor`), not individual profiles, and passing a profile name as an argument is not supported.

Practice this question →
29
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 enumerates every loaded AppArmor profile and reports whether each is in enforce or complain mode. Running it on the node confirms both that k8s-apparmor-profile is loaded into the kernel and that it is actively enforcing, satisfying the verification requirement.

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 →
30
MCQmedium

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?

A.The annotation should be on the pod's securityContext, not as an annotation
B.AppArmor is not loaded or enabled on the node kernel
C.The AppArmor profile name is misspelled
D.The pod is using a privileged security context
AnswerB

This error is raised by the container runtime (or kubelet) when the node's kernel was not booted with AppArmor support (missing CONFIG_SECURITY_APPARMOR) or the apparmor kernel module is not loaded. Even if profiles are correctly referenced, the kernel must have AppArmor enabled, and profiles must be loaded with apparmor_parser before enforcement can occur. The specific 'AppArmor is not available' error indicates the runtime cannot find the AppArmor subsystem at all, so no profile can be applied.

Why this answer

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.

Exam trap

CNCF often tests the distinction between a profile being misconfigured (e.g., wrong name) versus the underlying kernel module not being available; the trap here is that candidates may assume a spelling error (Option C) when the node logs clearly point to a missing kernel feature.

How to eliminate wrong answers

Option A is wrong because the AppArmor profile is correctly specified as a pod annotation per the Kubernetes beta API (container.apparmor.security.beta.kubernetes.io/<container_name>), not in the securityContext. Option C is wrong because the node logs do not indicate a profile name mismatch; they explicitly state 'AppArmor not available', which is a kernel-level issue, not a name misspelling. Option D is wrong because a privileged security context does not prevent AppArmor from being available; it may bypass AppArmor enforcement, but the error here is about the kernel module not being present, not about privilege escalation.

Practice this question →
31
MCQmedium

A pod is running with securityContext.seccompProfile.type: Unconfined. Which statement is true?

A.The container is limited to a set of allowed syscalls as defined by the runtime.
B.The container can make any system call.
C.Seccomp is not supported on this node.
D.The container is running with the host's seccomp profile.
AnswerB

This is the correct interpretation. When seccompProfile is set to Unconfined, Kubernetes explicitly configures the container to run without a seccomp profile, effectively disabling kernel seccomp filtering for that container. All system calls the container makes are passed through to the kernel without being checked against a seccomp allowlist or denylist. Other security mechanisms like Linux capabilities or AppArmor may still apply, but seccomp imposes no restrictions.

Why this answer

When `securityContext.seccompProfile.type` is set to `Unconfined`, the container is allowed to make any system call without restriction. Seccomp (secure computing mode) is a Linux kernel feature that filters syscalls; `Unconfined` explicitly disables this filter, granting the container full syscall access. This is the most permissive seccomp profile and is the default if no profile is specified in older Kubernetes versions.

Exam trap

Candidates often mistake Unconfined for using the node's seccomp profile or think it means seccomp is unsupported, when in fact it explicitly disables syscall filtering.

How to eliminate wrong answers

Option A is wrong because `Unconfined` means no syscall restrictions are applied, whereas a limited set of allowed syscalls corresponds to a `RuntimeDefault` or a custom profile. Option C is wrong because seccomp support is a kernel feature; if the node does not support seccomp, the pod would fail to start or fall back to `Unconfined`, but the statement 'Seccomp is not supported on this node' is not implied by the profile type. Option D is wrong because `Unconfined` does not use the host's seccomp profile; it disables seccomp entirely, while using the host's profile would require `Localhost` with a path to the host's profile file.

Practice this question →
32
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 →
33
MCQeasy

Which of the following commands shows all loaded AppArmor profiles?

A.apparmor_parser
B.aa-status
C.aa-disable
D.aa-enforce
AnswerB

aa-status is the canonical command for displaying all loaded AppArmor profiles and their operational modes, such as enforce or complain. It queries the kernel's AppArmor subsystem through /sys/kernel/security/apparmor/profiles and also lists the processes currently confined by each profile. This makes it the correct tool when you need to see which profiles are active on the system.

Why this answer

The `aa-status` command displays the current status of AppArmor, including all loaded profiles, their enforcement mode (enforce/complain), and which processes are confined by them. This is the standard tool for listing active AppArmor profiles on a system.

Exam trap

The trap here is that candidates confuse `apparmor_parser` (which loads profiles) with `aa-status` (which lists them), or assume that `aa-enforce` or `aa-disable` somehow show profile status, when they are actually mode-changing commands.

How to eliminate wrong answers

Option A is wrong because `apparmor_parser` is used to load or compile AppArmor profiles from text files into the kernel, not to list currently loaded profiles. Option C is wrong because `aa-disable` is used to disable an AppArmor profile by removing its symbolic link from `/etc/apparmor.d/`, not to display profiles. Option D is wrong because `aa-enforce` is used to set a profile to enforce mode (actively blocking violations), not to list loaded profiles.

Practice this question →
34
Multi-Selecthard

Which THREE of the following are best practices for minimizing host access from containers to reduce the attack surface? (Select three.)

Select 3 answers
A.Avoid setting hostPID to true
B.Avoid setting hostNetwork to true
C.Avoid setting hostIPC to true
D.Disable swap on nodes
E.Avoid using hostPort in container port mappings
AnswersA, B, C

Setting hostPID to true places the container directly in the host's process ID namespace, letting it list and signal every process running on the node. An attacker who compromises such a container can inspect /proc entries for sensitive host processes, inject signals, or potentially escalate privileges. Therefore, avoiding hostPID is a fundamental pod security practice to preserve process isolation.

Why this answer

Setting hostPID to true allows a container to share the host's process ID namespace, enabling it to see all host processes and potentially access sensitive information or perform privilege escalation. Avoiding this setting reduces the attack surface by preventing containers from interacting with host-level processes, which is a key principle of namespace isolation in Kubernetes.

Exam trap

CNCF often tests the distinction between host access (namespace sharing) and host exposure (port mapping or resource limits), so candidates may mistakenly select options like hostPort or swap disabling as host access controls when they are actually about network exposure or system performance.

Practice this question →
35
Multi-Selecthard

Which TWO of the following are effective methods to harden the kubelet against unauthorized access?

Select 2 answers
A.Set --read-only-port=10255
B.Enable --authentication-token-webhook
C.Enable the NodeRestriction admission controller
D.Configure --client-ca-file and --tls-cert-file to require client certificates
E.Set --anonymous-auth=true
AnswersB, D

Enabling --authentication-token-webhook makes the kubelet validate bearer tokens against the API server's TokenReview endpoint, so only authenticated, authorised identities can reach the kubelet API. This closes anonymous or unauthenticated access to the kubelet's HTTPS endpoint.

Why this answer

To harden the kubelet's own HTTPS endpoint, enable --authentication-token-webhook to validate bearer tokens via the Kubernetes TokenReview API, and configure --client-ca-file with --tls-cert-file to require and validate client certificates. NodeRestriction is an admission controller that limits what the kubelet can modify in the API server; it does not protect the kubelet endpoint from unauthorized access.

Exam trap

The kubelet's own API endpoint is protected by authentication and authorization settings such as --anonymous-auth=false, --authentication-token-webhook, --client-ca-file, and --authorization-mode=Webhook. NodeRestriction limits a compromised kubelet's API-server access but does not harden the kubelet itself against incoming unauthorized requests.

Practice this question →
36
MCQhard

A cluster has enabled the NodeRestriction admission controller. A developer is trying to create a pod with hostNetwork: true but is getting an error. What is the most likely reason?

A.The error is unrelated to NodeRestriction; the issue is likely a missing PodSecurityPolicy or Pod Security Admission that denies hostNetwork
B.The NodeRestriction admission controller blocks pods with hostNetwork
C.The nodeSelector on the pod conflicts with NodeRestriction
D.The developer lacks RBAC permissions to create pods
AnswerA

The NodeRestriction admission controller only constrains kubelet-authorized requests that modify Node or status Pod objects; it never evaluates pod specs for fields like hostNetwork. A denial mentioning hostNetwork is instead characteristic of either a deprecated PodSecurityPolicy admission plugin or the newer Pod Security Admission (baseline/restricted) which explicitly rejects hostNetwork: true. Therefore the error is not caused by NodeRestriction but by a cluster security policy.

Why this answer

The NodeRestriction admission controller only limits node self-updates to kubelet nodes, preventing them from modifying their own labels, taints, or other node objects. It does not block pods with `hostNetwork: true`. The error is most likely caused by a missing PodSecurityPolicy or Pod Security Admission (PSA) that denies pods with `hostNetwork: true`, as these are the mechanisms that enforce host namespace restrictions.

Exam trap

The trap here is that candidates confuse NodeRestriction (which restricts kubelet node updates) with PodSecurityPolicy or Pod Security Admission (which restrict pod security contexts like hostNetwork), leading them to incorrectly attribute the error to NodeRestriction.

How to eliminate wrong answers

Option B is wrong because NodeRestriction does not block pods with `hostNetwork`; it restricts kubelet modifications to node objects. Option C is wrong because `nodeSelector` is not affected by NodeRestriction; NodeRestriction only applies to node updates by the kubelet, not pod scheduling. Option D is wrong because the error is about admission control, not RBAC; if the developer lacked RBAC permissions to create pods, they would get a Forbidden error, not an admission-related error.

Practice this question →
37
Multi-Selecthard

Which THREE of the following are best practices for reducing the attack surface of Kubernetes nodes? (Select three.)

Select 3 answers
A.Use read-only root filesystems for containers where possible
B.Allow privileged containers for debugging
C.Disable unnecessary system services on nodes
D.Run containers as root to simplify management
E.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)
AnswersA, C, E

Setting the container's root filesystem to read-only via securityContext or readOnlyRootFilesystem forces any write to use ephemeral volumes like emptyDir or a writable tmpfs, so malware cannot persist by modifying binaries, configuration, or libraries. It also prevents container processes from dropping malicious files onto the underlying image layers, significantly limiting post-exploitation activity. Where a container genuinely needs temporary writes, mount a dedicated emptyDir volume rather than loosening the root filesystem.

Why this answer

Using a read-only root filesystem for containers (e.g., setting `readOnlyRootFilesystem: true` in the container's security context) prevents attackers from writing malicious binaries or modifying system files inside the container, even if they gain code execution. This reduces the attack surface by limiting the container's ability to persist changes or escalate privileges through file system manipulation.

Exam trap

CNCF often tests the misconception that privileged containers are acceptable for debugging in production, but the CKS exam emphasizes that privileged mode should never be used in production environments because it disables all security controls and grants host-level capabilities.

Practice this question →
38
MCQmedium

A container needs to run with the NET_ADMIN capability to modify network settings. The cluster enforces the baseline Pod Security Standard. Which securityContext configurations are valid? (Select all that apply.)

A.capabilities: add: ["NET_ADMIN"]
B.linuxCapabilities: add: ["NET_ADMIN"]
C.capabilities: drop: ["ALL"] add: ["NET_ADMIN"]
D.capabilities: drop: ["NET_ADMIN"]
AnswerA, C

Correct. Adding NET_ADMIN directly is allowed under the baseline PSS.

Why this answer

Under the baseline Pod Security Standard (PSS), both options A and C are valid because the baseline profile permits adding specific capabilities like NET_ADMIN. Option A directly adds NET_ADMIN to the container's capabilities. Option C drops all capabilities first and then adds NET_ADMIN, which is also compliant because dropping all is allowed under baseline, and then adding NET_ADMIN is permitted.

Option B uses an invalid field name (linuxCapabilities should be capabilities). Option D drops NET_ADMIN, which would remove the required capability.

Exam trap

Candidates often assume that dropping all capabilities is required (as in the restricted profile) even when the baseline profile is in effect. Both option A and C are valid under baseline; the trap is thinking only one is correct.

How to eliminate wrong answers

Option B is wrong because `linuxCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities`. Option C is wrong because dropping all capabilities (`drop: ["ALL"]`) is unnecessary under the baseline PSS, which does not require dropping all capabilities, and it would remove capabilities that the container might need for normal operation, potentially breaking functionality. Option D is wrong because dropping NET_ADMIN would remove the very capability required to modify network settings, making the container unable to perform its intended task.

Practice this question →
39
MCQeasy

What is the default seccomp profile applied when a pod's security context has 'seccompProfile.type: RuntimeDefault'?

A.The profile defined in /var/lib/kubelet/seccomp/default.json
B.Unconfined (no seccomp)
C.The Docker default profile, which blocks around 300 syscalls
D.The container runtime's default seccomp profile, which blocks around 40 syscalls
AnswerD

With seccompProfile.type set to RuntimeDefault, the kubelet asks the container runtime (e.g., containerd) to apply its built-in default seccomp filter. This runtime-owned profile blocks roughly 40 syscalls that are considered dangerous or unnecessary in a container, such as mounting filesystems or kernel module loading, while allowing normal application syscalls. It is the correct answer because it accurately names both the source (the runtime) and the approximate number of blocked syscalls.

Why this answer

When `seccompProfile.type: RuntimeDefault` is set in a pod's security context, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp profile. This runtime default profile is a curated allowlist that blocks approximately 40 syscalls known to be dangerous or unnecessary for containers, providing a balance between security and compatibility. It is not the Docker default (which blocks ~300 syscalls) but a more permissive profile tailored to the runtime's container model.

Exam trap

CNCF often tests the misconception that `RuntimeDefault` refers to Docker's legacy default profile (which blocks ~300 syscalls), when in fact it refers to the container runtime's own default (which blocks ~40 syscalls), and candidates may confuse it with `Unconfined` or a custom localhost path.

How to eliminate wrong answers

Option A is wrong because `/var/lib/kubelet/seccomp/default.json` is a custom seccomp profile path that can be specified via `seccompProfile.type: Localhost`, not the default applied by `RuntimeDefault`. Option B is wrong because `Unconfined` is a separate seccomp profile type (`seccompProfile.type: Unconfined`) that disables seccomp entirely, whereas `RuntimeDefault` explicitly enables the runtime's default restrictions. Option C is wrong because the Docker default profile blocks around 300 syscalls and is not the profile applied by `RuntimeDefault`; the runtime default (e.g., containerd's) is more permissive, blocking only about 40 syscalls, and is independent of Docker's profile.

Practice this question →
40
MCQhard

A cluster uses PodSecurity admission. A namespace has the label 'pod-security.kubernetes.io/enforce: baseline'. A user creates a pod that runs a container with 'privileged: true'. What happens?

A.The pod is rejected by the admission controller.
B.The pod is created but flagged with a warning.
C.The pod is created successfully because privileged is allowed at baseline.
D.The pod is created but the privileged setting is ignored.
AnswerA

Correct. Pod Security Admission operates at admission time: when the enforce label is set on a namespace, any pod manifest that violates the policy is rejected by the API server before it is persisted. A pod requesting privileged access (e.g., via `securityContext.privileged: true`) clearly fails the baseline profile, which forbids privileged containers. Consequently, the API server returns a validation error and the pod is never created within the namespace.

Why this answer

The PodSecurity admission controller enforces the configured security level based on the namespace label. The 'baseline' level prohibits privileged containers, so a pod with 'privileged: true' violates the policy. The admission controller rejects the pod immediately, preventing its creation.

Exam trap

The trap here is that candidates may confuse the 'baseline' profile with the 'privileged' profile, or assume that the enforce mode only warns, when in fact it blocks the pod creation entirely.

How to eliminate wrong answers

Option B is wrong because when the enforce mode is set to 'baseline', the admission controller does not just warn; it actively rejects pods that violate the policy. Option C is wrong because the 'baseline' profile explicitly disallows privileged containers; only the 'privileged' profile allows them. Option D is wrong because the PodSecurity admission controller does not silently ignore violations; it either rejects the pod or, in warn mode, logs a warning, but enforce mode means rejection.

Practice this question →
41
Multi-Selecthard

Which TWO of the following are valid AppArmor profile modes? (Select 2 correct answers)

Select 2 answers
A.enforce
B.disabled
C.audit
D.unconfined
E.complain
AnswersA, E

Enforce is the default and primary AppArmor profile mode: when a profile is loaded in enforce mode, the kernel actively blocks any operation that violates the profile's rules and logs the denial to the audit log. This is the mode used in production to actually restrict a container's capabilities, because it rejects unauthorized syscalls, file accesses, or network operations rather than merely reporting them.

Why this answer

AppArmor profile modes determine how the Mandatory Access Control (MAC) policy is applied. 'Enforce' (option A) actively enforces the profile's rules, blocking any actions that violate the policy and logging the denial. 'Complain' (option E) logs policy violations without blocking them, allowing for testing and debugging of profiles before switching to enforce mode.

Exam trap

The CNCF-CKS exam often tests the distinction between profile modes and module states; the trap here is that 'disabled' and 'audit' sound plausible but are not actual AppArmor profile modes—'disabled' refers to the AppArmor kernel module being off, and 'audit' is a rule-level flag, not a profile mode.

Practice this question →
42
Multi-Selectmedium

Which TWO of the following are valid methods to apply a seccomp profile to a Kubernetes pod? (Select two.)

Select 2 answers
A.Using the field: spec.seccompProfile
B.Using the pod annotation: seccomp.security.alpha.kubernetes.io/pod
C.Using the field: securityContext.seccompProfile.type
D.Using the command line flag: --seccomp-profile when running kubectl run
E.Using the pod annotation: container.seccomp.security.alpha.kubernetes.io
AnswersB, C

The annotation seccomp.security.alpha.kubernetes.io/pod is a legacy but still functional method to apply a seccomp profile to the entire pod. It predates the seccompProfile field in securityContext and is deprecated in favor of the structured API, yet many existing workloads still rely on it. Placing this key on the Pod object tells the runtime to use the referenced profile, making it a valid approach.

Why this answer

The seccomp.security.alpha.kubernetes.io/pod annotation was the original method to apply a seccomp profile to an entire pod in Kubernetes versions prior to v1.19. This annotation specifies the seccomp profile path or type (e.g., 'runtime/default' or 'localhost/<profile>') for the pod's containers, and it remains valid in older clusters or when using legacy configurations.

Exam trap

CNCF often tests the distinction between the GA field (securityContext.seccompProfile) and the deprecated annotation method, and candidates may confuse the incomplete annotation format (e.g., missing container name) with a valid option.

Practice this question →
43
Multi-Selectmedium

Which THREE of the following are restrictions enforced by the 'baseline' Pod Security Standard? (Select three.)

Select 3 answers
A.Host network access (hostNetwork) is not allowed
B.Capabilities must be limited to a minimal set (drop: ["ALL"] is not required but must not add dangerous capabilities)
C.Seccomp profile must be set to RuntimeDefault or Localhost
D.Privilege escalation must be disabled (AllowPrivilegeEscalation: false)
E.Containers must run as non-root (runAsNonRoot: true)
AnswersA, B, D

The baseline profile explicitly forbids setting hostNetwork: true, which would place the pod in the host's network namespace and expose all physical network interfaces. This isolation ensures that processes in containers cannot bind to host ports or sniff/monitor host traffic, providing a hard boundary between the pod and the underlying host. Enabling hostPID or hostIPC is also forbidden, but hostNetwork is specifically called out in the option.

Why this answer

The 'baseline' Pod Security Standard (PSS) enforces several restrictions to provide a reasonable level of security without breaking most workloads. The three correct restrictions are:

A: Host network access (hostNetwork) is not allowed. The baseline profile prohibits sharing host namespaces, including hostNetwork, to isolate pods from the host network.

B: Capabilities must be limited to a minimal set. While the baseline profile does not require dropping all capabilities (drop: ["ALL"]), it prohibits adding dangerous capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, or CAP_SYS_PTRACE. This prevents escalation of privileges through capability misuse.

D: Privilege escalation must be disabled (AllowPrivilegeEscalation: false). This is a baseline requirement to prevent processes from gaining more privileges than their parent.

Option C (seccomp profile must be set to RuntimeDefault or Localhost) and Option E (containers must run as non‑root) are both requirements of the 'restricted' profile, not the baseline. Therefore, they are incorrect selections.

Exam trap

The CKS exam often tests the distinction between baseline and restricted profiles, and the trap here is that candidates confuse the baseline's capability restriction (which only blocks dangerous capabilities, not all) with the restricted profile's stricter requirement to drop all capabilities.

Practice this question →
44
MCQmedium

A cluster uses a custom mutating admission webhook that adds a sidecar container to all pods. After an upgrade, the webhook crashes and pods cannot be created. What is the best way to prevent this scenario in future?

A.Run multiple replicas of the webhook
B.Set the webhook's failurePolicy to Ignore
C.Disable admission webhooks in the cluster
D.Create a validating webhook as a backup
AnswerB

Setting failurePolicy: Ignore tells the API server to bypass the webhook if it cannot be reached or returns an error, allowing pod creation to proceed without the mutation. This guarantees availability but at the cost of correctness, as the pod may miss required mutations. It is a standard mitigator for webhook outages, but should be used only when the mutation is non-critical or the mutation can be enforced elsewhere.

Why this answer

Setting the webhook's failurePolicy to Ignore ensures that if the webhook fails (e.g., crashes or times out), the API server will bypass the webhook and allow the pod creation to proceed. This prevents a single point of failure from blocking all pod creation, which is critical for cluster availability. The default failurePolicy is Fail, which would cause the entire admission request to fail if the webhook is unreachable.

Exam trap

The trap here is that candidates often think high availability (multiple replicas) is sufficient, but the CKS exam tests the understanding that failurePolicy is the direct mechanism to prevent a single webhook failure from blocking all pod creation, regardless of replica count.

How to eliminate wrong answers

Option A is wrong because running multiple replicas of the webhook improves availability but does not prevent the scenario where all replicas crash or the webhook service becomes unreachable; the failurePolicy must be set to Ignore to handle such cases. Option C is wrong because disabling admission webhooks entirely removes the sidecar injection capability and is an overreaction that breaks the intended functionality, not a best practice for resilience. Option D is wrong because a validating webhook cannot serve as a backup for a mutating webhook; it operates on a different phase and cannot perform mutations, and it would also suffer from the same failurePolicy issue if not configured correctly.

Practice this question →
45
Multi-Selecthard

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

Select 2 answers
A.AppArmor profiles can be loaded in 'enforce' or 'complain' mode
B.The profile name in the annotation should be just the profile name without the 'localhost/' prefix
C.If the profile is not loaded on the node, the pod will be rejected
D.The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'
E.AppArmor profiles are automatically loaded from a ConfigMap
AnswersA, C

AppArmor profiles support two execution modes: enforce and complain. In enforce mode, any operation that violates the profile is blocked and the process is denied permission, while in complain mode the same violation is logged to the system log but allowed to proceed. The mode is set inside the profile file (e.g., 'flags=(enforce)') or specified during loading via apparmor_parser, and Kubernetes does not alter it once the profile is loaded on the node.

Why this answer

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.

Exam trap

The trap here is that candidates often confuse the annotation key format (thinking it uses the profile name instead of the container name) or forget that the 'localhost/' prefix is mandatory when referencing a node-local profile.

Practice this question →
46
MCQhard

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?

A.Add a PodSecurityPolicy that drops CAP_SYS_ADMIN
B.Modify the kubelet to disallow CAP_SYS_ADMIN
C.Implement a mutating admission webhook that automatically drops CAP_SYS_ADMIN from all pods
D.Configure each namespace with 'pod-security.kubernetes.io/enforce: restricted'
AnswerC

A mutating admission webhook intercepts every Pod creation or update request before the object is persisted, allowing it to patch the container's securityContext.capabilities.drop to include CAP_SYS_ADMIN (and often other dangerous capabilities as well). This is cluster-wide by default because webhooks apply to all namespaces unless you configure namespace selectors, and the mutation is recorded in the final Pod spec before any kubelet or container runtime sees it. Additionally, the webhook can log or annotate which pods were mutated, providing central auditability.

Why this answer

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.

Exam trap

The trap here is that candidates confuse Pod Security Standards (PSS) with automatic capability dropping, but the 'restricted' profile only enforces a deny-list on explicit capability requests, not a mutation to drop inherited capabilities.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is deprecated since Kubernetes 1.21 and removed in 1.25, so it is not a viable cluster-wide enforcement mechanism for current clusters. Option B is wrong because the kubelet does not have a configuration to disallow specific Linux capabilities; capability enforcement is a pod-level security context concern, not a kubelet-level setting. Option D is wrong because the 'restricted' Pod Security Standard (PSS) profile does not automatically drop CAP_SYS_ADMIN; it only rejects pods that explicitly request it, but pods that do not explicitly set capabilities may still inherit it from the container runtime default.

Practice this question →
47
MCQhard

A pod runs with 'hostNetwork: true' and 'hostPID: true'. Which security concern is MOST directly increased?

A.The container can access host processes and potentially escape
B.The container can modify iptables rules
C.The container can sniff network traffic of other pods
D.The container can mount the host filesystem
AnswerA

With hostPID: true, the container shares the host's PID namespace, so it can enumerate and interact with every host process through /proc. If the container runs as root or has CAP_SYS_PTRACE, it can ptrace host processes, read their memory, inject signals, or extract credentials. This visibility drastically lowers the barrier to a container escape because a single kernel exploit or misconfiguration that gives code execution inside the container can be leveraged against host-level processes directly, rather than being confined to the container's own PID namespace.

Why this answer

Setting `hostNetwork: true` and `hostPID: true` in a pod grants the container direct access to the host's network namespace and process namespace. With `hostPID: true`, the container can see all host processes (e.g., via `ps aux`) and potentially interact with them using system calls like `ptrace`, which could allow escaping the container by injecting code into a host process. This combination directly increases the risk of container breakout, making A the most significant security concern.

Exam trap

The trap here is that candidates focus on the network-related concern (sniffing traffic) because `hostNetwork` is more obvious, but they overlook that `hostPID` enables direct process manipulation, which is a more severe security risk for container escape.

How to eliminate wrong answers

Option B is wrong because modifying iptables rules requires `NET_ADMIN` capability, which is not granted by `hostNetwork: true` alone; `hostNetwork` only shares the network namespace, not the ability to alter firewall rules. Option C is wrong because sniffing network traffic of other pods is already possible with `hostNetwork: true` (since the container shares the host's network stack), but this is a lesser concern compared to process-level escape; the question asks for the 'MOST directly increased' concern. Option D is wrong because mounting the host filesystem requires a `hostPath` volume mount or privileged access, which is not automatically provided by `hostNetwork` or `hostPID`; these settings do not grant filesystem access.

Practice this question →
48
MCQeasy

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

A.apparmor.security.kubernetes.io/profile
B.security.kubernetes.io/apparmor
C.container.apparmor.security.beta.kubernetes.io/<container_name>
D.seccomp.security.alpha.kubernetes.io/pod
AnswerC

This is the correct annotation format. The key 'container.apparmor.security.beta.kubernetes.io/<container_name>' targets a specific container by name, and its value specifies the AppArmor profile to enforce, such as 'runtime/default' or 'localhost/<custom-profile>'. Although it is a beta annotation that has been superseded by the AppArmor field in the container's securityContext, it remains a valid and functional way to apply profiles on older or legacy Kubernetes versions.

Why this answer

The AppArmor profile for a container in a pod is specified using the annotation `container.apparmor.security.beta.kubernetes.io/<container_name>`, where `<container_name>` 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.

Exam trap

The trap here is that candidates confuse the AppArmor annotation with the seccomp annotation (option D) or invent a non-existent annotation (options A and B), because the exam often tests the exact syntax of these security annotations, which are easy to mix up due to similar naming patterns.

How to eliminate wrong answers

Option A is wrong because `apparmor.security.kubernetes.io/profile` is not a valid Kubernetes annotation; the correct prefix is `container.apparmor.security.beta.kubernetes.io/`. Option B is wrong because `security.kubernetes.io/apparmor` is not a recognized annotation for AppArmor; it resembles a generic security context key but does not exist in the Kubernetes API. Option D is wrong because `seccomp.security.alpha.kubernetes.io/pod` is the annotation used to apply a seccomp profile to a pod, not an AppArmor profile.

Practice this question →
49
MCQeasy

Which Pod Security Standard level allows the use of hostNetwork, hostPID, and hostIPC?

A.None of the above
B.Baseline
C.Privileged
D.Restricted
AnswerC

The Privileged level is intentionally the most permissive Pod Security Standard, imposing no restrictions on the pod's security context or namespace usage. It explicitly permits access to host namespaces, so setting hostNetwork to true is allowed without any policy interference. This is why Privileged is the only standard among the three that satisfies the requirement in the question.

Why this answer

The Privileged Pod Security Standard (PSS) level is the most permissive, allowing unrestricted access to host-level resources, including hostNetwork, hostPID, and hostIPC. These settings grant the pod direct access to the host's network namespace, process table, and inter-process communication mechanisms, which are explicitly prohibited in the Baseline and Restricted levels. The Privileged level is designed for system-level workloads that require such elevated permissions, such as CNI plugins or monitoring agents.

Exam trap

CNCF often tests the misconception that Baseline allows host-level namespace sharing, when in fact Baseline only permits a limited set of non-host-level privileges, while hostNetwork, hostPID, and hostIPC are exclusive to the Privileged level.

How to eliminate wrong answers

Option A is wrong because 'None of the above' is incorrect; the Privileged level explicitly allows hostNetwork, hostPID, and hostIPC. Option B is wrong because the Baseline level prohibits hostNetwork, hostPID, and hostIPC by default, as defined in the Kubernetes Pod Security Standards documentation. Option D is wrong because the Restricted level is the most restrictive, enforcing the strongest security controls and disallowing all host namespace sharing, including hostNetwork, hostPID, and hostIPC.

Practice this question →
50
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

Complain mode logs AppArmor policy violations but still permits the action, unlike enforce which blocks it. It is a valid profile mode used to test policy before enforcing, satisfying the question's requirement for a genuine AppArmor mode.

Why this answer

Option A, Complain mode, is correct because AppArmor profiles can be set to complain (also called learning) mode, in which policy violations are logged but not blocked, allowing administrators to test and refine profiles. Option B, Enforce mode, is correct because it is the standard operational mode where the profile's rules are actively applied and violations are denied and logged. The unmarked options do not belong: Audit is not a profile mode (auditing is a logging behavior that occurs within complain or enforce modes), Disable is not a mode but rather the state of having no profile loaded or the profile removed, and Permissive is not an AppArmor term — it is the terminology used by SELinux, while AppArmor's equivalent is Complain.

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 →
51
MCQmedium

What is the default seccomp profile for Kubernetes containers when no seccompProfile is specified?

A.Localhost
B.No profile is applied
C.RuntimeDefault
D.Unconfined
AnswerC

The effective default seccomp profile for containers in Kubernetes is `RuntimeDefault`, which instructs the container runtime to apply its own built-in seccomp policy. This policy allows common application syscalls while blocking privileged or rarely needed ones such as `mount`, `reboot`, and `kexec_load`, providing a secure baseline. Even though a pod's `securityContext` may omit `seccompProfile`, the runtime enforces this profile automatically; in v1.29+ this is the expected behavior unless explicitly overridden.

Why this answer

When no `seccompProfile` is specified in the Pod or container security context, Kubernetes applies the `RuntimeDefault` seccomp profile by default. This profile is defined by the container runtime (e.g., containerd or CRI-O) and blocks a specific set of syscalls that are considered dangerous or unnecessary for containers, while allowing normal application operations. This default behavior was introduced in Kubernetes 1.19 and became the default for all pods in Kubernetes 1.22, enhancing security without requiring explicit configuration.

Exam trap

A common trap is the misconception that no seccomp profile means 'no restrictions' (Unconfined), but the correct default is `RuntimeDefault`, which applies a secure baseline profile automatically.

How to eliminate wrong answers

Option A is wrong because `Localhost` refers to a custom seccomp profile loaded from a file on the node's filesystem, which is not the default; it must be explicitly specified via `localhostProfile`. Option B is wrong because Kubernetes does apply a default seccomp profile (`RuntimeDefault`) when none is specified, so no profile is not the default behavior. Option D is wrong because `Unconfined` disables seccomp entirely, allowing all syscalls, which is the opposite of the secure default and must be explicitly set.

Practice this question →
52
MCQmedium

Which of the following correctly adds the NET_ADMIN capability to a container in a Kubernetes pod?

A.securityContext: capabilities: cap_add: - ALL
B.securityContext: capabilities: add: - NET_ADMIN
C.securityContext: capabilities: cap_add: - NET_ADMIN (but placed at pod spec level)
D.securityContext: capabilities: cap_add: - NET_ADMIN
AnswerB

This is the correct Kubernetes syntax: the container-level securityContext contains a `capabilities` field with an `add` list. The key `add` is part of the Kubernetes API and instructs the container runtime to grant the specified Linux capabilities to the container's processes. Here, `NET_ADMIN` enables administrative operations on network devices and settings, which is a common requirement for networking containers. Placing this securityContext at the container level is also required for it to take effect.

Why this answer

In Kubernetes, the correct field to add a Linux capability to a container is `capabilities.add` in the container's `securityContext`. Option B uses `add: - NET_ADMIN` at the container level, which is the proper syntax. Option D uses `cap_add`, which is Docker Compose syntax and invalid in Kubernetes.

Option A uses `cap_add` with `ALL`, which adds all capabilities and is not specific. Option C places the `securityContext` at the pod spec level, but the pod-level `securityContext` does not support a `capabilities` field; capabilities must be set in each container's `securityContext`. Therefore, C is invalid, not just less precise.

Exam trap

The correct Kubernetes syntax for adding capabilities is `add` in the container's `securityContext`. A common pitfall is using `cap_add` (Docker Compose syntax) or attempting to place `capabilities` under the pod-level `securityContext`, which is not supported.

How to eliminate wrong answers

Option A is wrong because it uses `cap_add` (a Docker Compose key) instead of the Kubernetes `add` field, and it adds `ALL` capabilities, which violates the principle of least privilege and is not a targeted addition of `NET_ADMIN`. Option B is wrong because although it uses the correct `add` field, it is placed at the pod spec level (`securityContext` at the pod level) rather than at the container level, where `capabilities` must be defined; pod-level `securityContext` does not support a `capabilities` field. Option C is wrong because it uses `cap_add` (a Docker Compose key) instead of the Kubernetes `add` field, even though it is placed at the pod spec level, which is also incorrect.

Practice this question →
53
MCQhard

You are a security engineer at a company running a Kubernetes cluster in production. The cluster uses containerd as the container runtime and has been configured with Node Authorizer and NodeRestriction admission controller. Recently, a security audit revealed that several pods running as root have been compromised via container escape vulnerabilities. The audit report recommends hardening the nodes to reduce the attack surface. Specifically, you need to ensure that even if an attacker gains root access inside a container, they cannot execute privileged operations on the host node, such as loading kernel modules, modifying host network settings, or accessing host devices. The cluster runs on Ubuntu 20.04 nodes with Linux kernel 5.4. You have access to modify node-level configurations but must minimize performance impact and avoid breaking existing workloads that rely on standard Linux capabilities. Which of the following actions would most effectively mitigate these risks?

A.Configure containerd to use a default seccomp profile that blocks unprivileged user namespaces and restricts kernel modules loading, and apply it to all pods via a mutating admission webhook.
B.Enable user namespaces for all containers by setting the 'hostUsers: false' option in the pod spec, which maps container root to a non-root user on the host.
C.Remove the CAP_SYS_ADMIN and CAP_NET_ADMIN capabilities from all containers by setting a default PodSecurityPolicy that drops these capabilities.
D.Enable AppArmor on all nodes and apply a custom profile that denies all mount and network-related system calls.
AnswerA

A default seccomp profile that blocks risky syscalls (e.g., those used for kernel module loading, user namespace creation) effectively prevents many container escapes without breaking most workloads. Applying it via a webhook ensures all pods use it.

Why this answer

Seccomp (secure computing mode) can filter system calls at the kernel level, and by configuring containerd to use a default seccomp profile that blocks syscalls related to unprivileged user namespaces (e.g., `clone` with `CLONE_NEWUSER`) and kernel module loading (e.g., `init_module`, `finit_module`), you prevent container escapes from performing privileged host operations. This approach is runtime-level, applies globally without modifying pod specs, and minimizes performance impact since seccomp uses a BPF-based filter that adds negligible overhead.

Exam trap

CNCF often tests the misconception that dropping capabilities alone is sufficient for host-level hardening, but the trap here is that capabilities only restrict privileged operations that require them, while seccomp provides syscall-level filtering that can block escape vectors even when the container runs as root.

How to eliminate wrong answers

Option B is wrong because setting `hostUsers: false` in the pod spec enables user namespace remapping, which maps the container's root user to a non-root user on the host, but this feature is not supported by containerd in Kubernetes versions prior to 1.27 and requires specific runtime support; it also does not block kernel module loading or host network modifications if the container retains capabilities like CAP_SYS_MODULE. Option C is wrong because dropping CAP_SYS_ADMIN and CAP_NET_ADMIN reduces the attack surface but does not prevent an attacker from using other capabilities (e.g., CAP_SYS_MODULE to load kernel modules) or exploiting syscalls that do not require capabilities, such as `mount` with `MS_BIND` if the container runs as root. Option D is wrong because AppArmor profiles deny system calls at the LSM level, but applying a custom profile that denies all mount and network-related syscalls would break standard container operations (e.g., creating network interfaces, mounting tmpfs) and is not a default or easily maintainable solution; additionally, AppArmor is not enabled by default on all Ubuntu 20.04 nodes and requires kernel configuration.

Practice this question →
54
Multi-Selectmedium

Which THREE of the following actions help reduce the attack surface of containers? (Select 3 correct answers)

Select 3 answers
A.Set hostNetwork: true for better network performance
B.Set securityContext.runAsNonRoot: true
C.Drop all capabilities and add only required ones
D.Enable audit logging for all API requests
E.Run containers with read-only root filesystem
AnswersB, C, E

Setting securityContext.runAsNonRoot: true enforces that the container's primary process runs as a non-root UID, failing to start otherwise. This prevents an attacker who exploits a container vulnerability from gaining root privileges on the host via trivial container escape paths, because the process lacks UID 0. Combined with an explicit runAsUser and a non-root user in the image, this hardens the workload against privilege escalation.

Why this answer

Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID that is not 0 (root). This prevents an attacker who gains code execution inside the container from having root privileges, which would otherwise allow them to escape the container, modify system binaries, or perform privileged operations. It is a fundamental principle of least privilege and directly reduces the attack surface by limiting the damage a compromised container can do.

Exam trap

A common pitfall in this exam is confusing security controls that directly reduce the attack surface (e.g., dropping capabilities, read-only filesystem, non-root user) with controls that provide visibility or performance improvements (e.g., audit logging, hostNetwork). Candidates often incorrectly select options that enhance monitoring or speed rather than those that harden the container.

Practice this question →
55
MCQeasy

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

A.apparmor_parser -r /path/to/profile
B.aa-enforce /path/to/profile
C.aa-status
D.modprobe apparmor
AnswerA

apparmor_parser is the userspace utility specifically designed to compile and load AppArmor profiles into the kernel's AppArmor LSM. The -r flag stands for 'replace', which is essential when re-loading an already loaded profile (e.g., after editing the policy file) because it overwrites the prior version atomically. Without -r, the command would fail with 'profile already loaded' if a profile with the same name exists. Thus, this is the only option that actually performs the load from a file.

Why this answer

The `apparmor_parser` command loads AppArmor profiles into the kernel. The `-r` flag replaces an existing profile with the one from the specified file, ensuring the kernel enforces the updated rules. This is the standard method to load or reload AppArmor profiles from a profile file.

Exam trap

CNCF often tests the distinction between loading a profile (`apparmor_parser`) and changing its mode (`aa-enforce` or `aa-complain`), causing candidates to confuse the command that loads the profile with the one that sets its enforcement state.

How to eliminate wrong answers

Option B is wrong because `aa-enforce` sets an already-loaded profile to enforce mode, but does not load a profile from a file into the kernel. Option C is wrong because `aa-status` only displays the current status of loaded AppArmor profiles and does not load any profiles. Option D is wrong because `modprobe apparmor` loads the AppArmor kernel module, not a specific profile; the module must already be loaded for profiles to be used.

Practice this question →
56
MCQmedium

A pod spec includes 'hostPID: true' and 'hostNetwork: true'. What security concern does this raise?

A.The container can use the host's GPU and other devices
B.The container can see all host processes and access the host network namespace, increasing the risk of privilege escalation
C.The container can read and write to the host filesystem
D.The container cannot use a securityContext
AnswerB

When hostPID is true, the container shares the host's PID namespace, allowing it to list and signal every process on the node; with hostNetwork true, it attaches to the host network namespace, so it can bind to host ports and observe host network traffic. This combination weakens isolation substantially: a compromised container could use ptrace (if permitted) or sniff network packets, increasing the chance of privilege escalation to the host. It also bypasses typical container network policies and process-level sandboxing.

Why this answer

Setting `hostPID: true` allows the container to see all processes running on the host, which can leak sensitive information and enable process injection. Setting `hostNetwork: true` gives the container direct access to the host's network namespace, bypassing network policies and potentially allowing the container to bind to privileged ports or sniff traffic. Together, these settings significantly increase the attack surface and risk of privilege escalation or host compromise.

Exam trap

CNCF often tests the distinction between namespace sharing (`hostPID`, `hostNetwork`, `hostIPC`) and volume mounts or device access; the trap here is that candidates confuse `hostNetwork` with host filesystem access or assume `hostPID` implies device access.

How to eliminate wrong answers

Option A is wrong because GPU and device access is controlled by `hostDevice` or resource limits, not by `hostPID` or `hostNetwork`. Option C is wrong because read/write access to the host filesystem requires a `hostPath` volume mount or `hostFilesystem` capability, not `hostPID` or `hostNetwork`. Option D is wrong because a pod with `hostPID: true` and `hostNetwork: true` can still use a `securityContext`; these settings are independent of the `securityContext` field.

Practice this question →
57
MCQeasy

A Pod is being deployed with a securityContext that sets runAsUser: 1000 and runAsGroup: 3000. The container image's files are owned by root:root with permissions 755. The application needs to write to a directory /data that is mounted as an emptyDir volume. What will happen when the container attempts to write to /data?

A.The write will fail because emptyDir volumes are read-only by default.
B.The write will fail with a permission denied error because the emptyDir volume is owned by root and the container runs as user 1000.
C.The write will succeed because runAsUser and runAsGroup automatically change the ownership of mounted volumes.
D.The write will succeed because emptyDir volumes are always writable by any user.
AnswerB

By default, an emptyDir volume is created with ownership root:root and permissions 0755. Since the container process runs as user 1000 and group 3000, it lacks write permission on the volume root. Without a fsGroup setting to change ownership or permissions, the write will fail with a permission denied error.

Why this answer

An emptyDir volume is created with root:root ownership and 0755 permissions by default. The container runs as user 1000 and group 3000, which are not the owner and do not have write permission on the volume root. Unless a fsGroup is specified to change the group ownership and permissions, the write will fail with a permission denied error.

The other options incorrectly assume automatic writability or misattribute the cause.

Exam trap

The trap here is assuming that setting runAsUser and runAsGroup automatically adjusts volume permissions, when actually fsGroup is needed to change volume ownership.

Practice this question →
58
MCQhard

A cluster has been compromised due to a container running with privileged escalation. The team wants to prevent any container from gaining new privileges. Which configuration should be applied?

A.Set securityContext.runAsUser: 1000
B.Set securityContext.readOnlyRootFilesystem: true
C.Drop all capabilities with securityContext.capabilities.drop: ["ALL"]
D.Set securityContext.allowPrivilegeEscalation: false
AnswerD

Setting allowPrivilegeEscalation: false directly applies the Linux 'no_new_privs' flag to the container process, which prevents the process and its children from ever gaining more privileges than their original execution context, even if a later exec of a setuid-root or capability-enabled binary occurs. This is a kernel-level mechanism that blocks the common privilege-escalation vectors such as SUID binaries, file capabilities, and certain ioctl-based operations. It is the most direct security control among the options because it explicitly targets the privilege-escalation mechanism itself, rather than only constraining the user ID, filesystem, or capabilities. For this compromised container, this setting is necessary to contain the breach and prevent further elevation.

Why this answer

Setting `securityContext.allowPrivilegeEscalation: false` directly prevents a container from gaining new privileges beyond those it was initially granted, such as through setuid binaries or the `NO_NEW_PRIVS` flag. This is the exact control needed to block privilege escalation attacks, as it forces the kernel to deny any request for elevated privileges, even if the binary has the setuid bit set.

Exam trap

CNCF often tests the misconception that dropping all capabilities is sufficient to prevent privilege escalation, but the trap is that capabilities and privilege escalation are separate controls—`allowPrivilegeEscalation: false` is the specific setting to block setuid-based escalation.

How to eliminate wrong answers

Option A is wrong because setting `runAsUser: 1000` only specifies the user ID under which the container runs, but it does not prevent the container from escalating privileges (e.g., via a setuid binary owned by root). Option B is wrong because `readOnlyRootFilesystem: true` only makes the container's root filesystem read-only, which protects against writes but has no effect on privilege escalation mechanisms. Option C is wrong because dropping all capabilities with `capabilities.drop: ["ALL"]` removes Linux capabilities but does not disable the ability to gain new privileges through setuid binaries or other mechanisms; `allowPrivilegeEscalation: false` is required to block that path.

Practice this question →
59
Multi-Selecthard

A security engineer is hardening a cluster and wants to reduce the attack surface of Pods by restricting their access to host resources. The engineer is reviewing a Pod specification and plans to remove or disable settings that grant host-level access. Which two settings should the engineer remove or set to false to reduce the attack surface? (Choose two.)

Select 2 answers
A.allowPrivilegeEscalation: true
B.readOnlyRootFilesystem: false
C.hostPID: true
D.hostNetwork: true
E.privileged: false
AnswersC, D

Setting hostPID to true places the Pod in the host's PID namespace, allowing it to see and potentially signal all processes on the node. Removing this setting or setting it to false isolates the Pod's process namespace, preventing it from viewing or interacting with host processes. This significantly reduces the attack surface.

Why this answer

The hostNetwork and hostPID fields, when set to true, place the Pod in the host's network and PID namespaces respectively, giving it direct access to host resources and significantly increasing the attack surface. Removing or setting these to false isolates the Pod. The other options either represent secure settings that are already in place or address different security concerns not directly related to host resource access.

Exam trap

The trap here is focusing on privilege escalation or filesystem writability instead of the host namespace flags that actually grant host resource access.

Practice this question →
60
MCQhard

Given the exhibit, what will happen when a user creates a pod with an image from an untrusted registry?

A.The pod is rejected by NodeRestriction admission
B.The pod is rejected by PodSecurity admission
C.The pod is created and the image is pulled
D.The pod is created but the image is not pulled because it's untrusted
AnswerC

The AlwaysPullImages admission controller mutates each new pod's containers, setting imagePullPolicy to Always, which forces the kubelet to pull the image from the registry at every pod start rather than using local cache. This mutation is a validation-type operation that does not reject the pod; the pod is admitted and scheduled. The kubelet then performs an image pull from the specified registry, and since no admission controller or runtime configuration in the default chain blocks untrusted registries, the pull succeeds and the pod runs.

Why this answer

By default, Kubernetes does not enforce any restrictions on image registries. The kubelet will attempt to pull the image from any registry, including untrusted ones, unless an admission controller like ImagePolicyWebhook or a runtime-specific policy (e.g., containerd's `untrusted_workload` mode) is explicitly configured. In this scenario, no such policy is mentioned, so the pod is created and the image is pulled.

Exam trap

CNCF often tests the misconception that Kubernetes has a built-in 'untrusted registry' blocker, when in reality it requires explicit admission control or runtime configuration to enforce such policies.

How to eliminate wrong answers

Option A is wrong because NodeRestriction admission only limits the Node API access (e.g., prevents nodes from modifying pods bound to other nodes), not image registry validation. Option B is wrong because PodSecurity admission (formerly PSP) enforces security contexts and capabilities, not registry trustworthiness. Option D is wrong because Kubernetes does not have a built-in mechanism to block image pulls based on registry trust; the image will be pulled unless a custom admission webhook or runtime policy is configured.

Practice this question →
61
MCQeasy

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

A.kubectl get seccomp
B.kubectl get apparmor
C.aa-status
D.systemctl status apparmor
AnswerC

aa-status is a command from the AppArmor userspace tools that reads /sys/kernel/security/apparmor and displays whether AppArmor is enabled, lists loaded profiles, and shows processes confined by each profile. It is the standard way to inspect AppArmor's state on a node. This is why it correctly answers the question.

Why this answer

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.

Exam trap

The trap here is that candidates assume AppArmor can be managed like a Kubernetes resource using kubectl, but it is a node-level security module that must be checked with Linux-native commands, not Kubernetes API objects.

How to eliminate wrong answers

Option A is wrong because `kubectl get seccomp` is not a valid kubectl command; seccomp profiles are managed via pod security contexts or runtime classes, not through a dedicated kubectl subcommand. Option B is wrong because `kubectl get apparmor` is also invalid; AppArmor profiles are not Kubernetes API resources and cannot be retrieved with kubectl. Option D is wrong because `systemctl status apparmor` only checks the systemd service status, not whether AppArmor is enabled in the kernel or which profiles are loaded; the service may be running but AppArmor could be in complain mode or have no profiles loaded.

Practice this question →
62
MCQeasy

Which tool is used to load AppArmor profiles on a node?

A.apparmor_parser
B.aa-enforce
C.aa-status
D.kubectl apply
AnswerA

apparmor_parser is the standard userspace tool that reads AppArmor policy text files, compiles them into the kernel's binary policy format, and sends them to the AppArmor LSM via the securityfs interface (typically mounted at /sys/kernel/security/apparmor). Flags such as -r (replace) and -a (add) control whether an existing profile is overwritten or a new one is inserted, making this the definitive tool for loading or updating profiles on a node. Without a successful apparmor_parser invocation, no AppArmor profile is active in the kernel, regardless of any other tools.

Why this answer

The `apparmor_parser` tool is the standard utility for loading AppArmor profiles into the kernel's security module. It reads profile definitions from text files, compiles them into binary form, and loads them into the kernel's LSM (Linux Security Module) subsystem. Without this tool, AppArmor profiles cannot be activated on a node.

Exam trap

Candidates may confuse `aa-enforce` (which changes the mode of an already-loaded profile) with the actual profile loading tool, or mistakenly think `kubectl apply` can load kernel-level security profiles. In the CKS exam, understanding the correct tool for loading AppArmor profiles is important for node hardening.

How to eliminate wrong answers

Option B is wrong because `aa-enforce` is used to switch an already-loaded AppArmor profile from complain mode to enforce mode, not to load a profile from scratch. Option C is wrong because `aa-status` only displays the current status of loaded AppArmor profiles and does not perform any loading operations. Option D is wrong because `kubectl apply` is a Kubernetes command for managing cluster resources (e.g., pods, deployments) and has no capability to interact with the node-level AppArmor subsystem.

Practice this question →
63
MCQmedium

An administrator wants to drop all capabilities for a container and then add back only NET_BIND_SERVICE. Which securityContext configuration is correct?

A.capabilities: add: ["NET_BIND_SERVICE"]
B.capabilities: drop: ["ALL"]
C.capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"]
D.capabilities: drop: ["NET_BIND_SERVICE"] add: ["ALL"]
AnswerC

Dropping "ALL" first strips every Linux capability, including defaults, then adding NET_BIND_SERVICE back grants only the ability to bind ports below 1024. This satisfies the stem's constraint of a single re-added capability, since Kubernetes applies drops before adds within the same securityContext.

Why this answer

It first drops all capabilities using `drop: ["ALL"]`, which removes every Linux capability from the container, and then explicitly adds back only `NET_BIND_SERVICE`. This follows the principle of least privilege: start with no capabilities and grant only what is needed. The `securityContext` in Kubernetes applies these settings at the container level, ensuring the container can bind to privileged ports (below 1024) without any other elevated permissions.

Exam trap

Kubernetes often tests the order of operations in capability management — candidates mistakenly think that adding a capability after dropping all is unnecessary or that dropping all alone is sufficient, but the correct sequence must explicitly include both `drop: ["ALL"]` and `add: ["NET_BIND_SERVICE"]` to achieve the intended least-privilege state.

How to eliminate wrong answers

Option A is wrong because it only adds `NET_BIND_SERVICE` without dropping any existing capabilities, leaving the container with its default set of capabilities (which may include many unnecessary and potentially dangerous ones). Option B is wrong because it drops all capabilities but never adds back `NET_BIND_SERVICE`, so the container would lack the ability to bind to privileged ports, causing failures for services that need to listen on ports like 80 or 443. Option D is wrong because it drops `NET_BIND_SERVICE` and adds `ALL`, which is the opposite of the desired configuration — it removes the needed capability and grants all capabilities, violating the principle of least privilege.

Practice this question →
64
MCQmedium

What is the effect of setting 'hostPID: true' in a pod's spec?

A.The container runs with the host's IPC namespace.
B.The container can access the host's network interfaces.
C.The container can mount the host's filesystem.
D.The container runs in the host's PID namespace.
AnswerD

The container runs in the host's PID namespace. This is correct because when hostPID: true is set, the container sees the exact same process list and process IDs as processes on the host, and processes inside the container are visible to all host processes. This removes process isolation, letting the container inspect or send signals (if permitted) to any host process. It effectively makes the container's own PID 1 correspond to the host's init process, so there is no separate PID namespace.

Why this answer

Setting 'hostPID: true' in a pod's spec allows the container to share the host node's PID namespace, meaning the container can see and interact with all processes running on the host, not just those within its own PID namespace. This is a privileged-level setting that bypasses the default process isolation provided by Kubernetes and Linux namespaces.

Exam trap

CNCF often tests the distinction between the three host namespace settings (hostPID, hostIPC, hostNetwork) and candidates frequently confuse 'hostPID' with 'hostNetwork' or 'hostIPC' due to similar naming patterns.

How to eliminate wrong answers

Option A is wrong because 'hostPID: true' controls the PID namespace, not the IPC namespace; to share the host's IPC namespace, you would set 'hostIPC: true'. Option B is wrong because accessing the host's network interfaces is achieved by setting 'hostNetwork: true', not 'hostPID: true'. Option C is wrong because mounting the host's filesystem is not directly controlled by 'hostPID'; that requires a hostPath volume mount or privileged container settings.

Practice this question →
65
MCQhard

A pod is configured with a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. The pod manifest uses securityContext.seccompProfile with type: Localhost and localhostProfile: "custom-profile.json". The pod fails to start with an error 'seccomp profile not found'. What is the most likely cause?

A.The securityContext.seccompProfile.defaultRuntimeProfile field must be set to 'custom-profile.json'.
B.The seccomp profile should be defined in the pod's annotations, not securityContext.
C.The custom-profile.json file is not present on the node filesystem.
D.The localhostProfile field must be an absolute path.
AnswerC

A missing localhost profile file prevents the container runtime from initializing the container. When `type: Localhost` is used, the kubelet resolves `localhostProfile` against the node's seccomp profile root and sends the path to the runtime; if the file is not present, the container creation fails with a file-not-found error and the pod never reaches Running. Always verify that the profile file exists on every worker node that may schedule the pod.

Why this answer

The error 'seccomp profile not found' indicates that the Kubernetes kubelet cannot locate the specified profile file on the node's filesystem. When using `type: Localhost`, the `localhostProfile` value is resolved relative to the kubelet's seccomp profile root directory (default `/var/lib/kubelet/seccomp`). If the file `custom-profile.json` does not exist at that path on the node, the pod will fail to start.

Exam trap

CNCF often tests the misconception that `localhostProfile` requires an absolute path, but in reality it is a relative path from the kubelet's seccomp directory, and the error 'not found' points to a missing file, not a path format issue.

How to eliminate wrong answers

Option A is wrong because `defaultRuntimeProfile` is not a valid field in `securityContext.seccompProfile`; the correct field is `type`, and `defaultRuntimeProfile` is a separate concept used in the kubelet's configuration or in the `RuntimeDefault` type. Option B is wrong because seccomp profiles can be defined either via pod annotations (deprecated in Kubernetes 1.19) or via `securityContext.seccompProfile` (the current stable API); the error is not due to using `securityContext` instead of annotations. Option D is wrong because `localhostProfile` does not require an absolute path; it is interpreted as a filename relative to the kubelet's seccomp profile directory (`/var/lib/kubelet/seccomp`), and an absolute path would be incorrect unless it points to a file outside that directory, which is not supported.

Practice this question →
66
MCQeasy

Refer to the exhibit. A security engineer sees that podPidsLimit is set to -1. What security concern does this raise?

A.It sets a hard limit of 1 PID per pod, which may break workloads
B.It limits each container to 1000 PIDs
C.It disables PID limiting, allowing a single pod to consume all PIDs on the node, risking a fork bomb
D.It enforces a default PID limit of 100 per pod
AnswerC

A podPidsLimit of -1 removes the cgroup pids.max cap entirely, so the container can spawn unlimited processes. A fork bomb inside that pod would exhaust the node's PID table, starving kubelet and other workloads of process IDs.

Why this answer

Setting `podPidsLimit` to `-1` in Kubernetes disables PID limiting for pods, meaning a single pod can create an unlimited number of processes. This poses a security risk because a compromised or malicious pod could launch a fork bomb, exhausting all available PIDs on the node and causing a denial of service (DoS) for other workloads. The correct answer is C.

Exam trap

The trap here is that candidates often assume `-1` means 'no limit' is safe or that it enforces a default, but the CKS exam tests the specific security implication of disabling PID limiting, which is the risk of a fork bomb and node-wide DoS.

How to eliminate wrong answers

Option A is wrong because `-1` does not set a hard limit of 1 PID; it disables the limit entirely, and a value of 1 would be impractical and not the default behavior. Option B is wrong because `-1` does not limit each container to 1000 PIDs; that would correspond to a positive integer value, not `-1`. Option D is wrong because `-1` does not enforce a default PID limit of 100 per pod; it explicitly removes any limit, and the default in Kubernetes is typically 100 (set via `--pod-max-pids` in kubelet), but `-1` overrides that.

Practice this question →
67
MCQeasy

Which of the following is a valid way to check the status of AppArmor profiles on a node?

A.Use 'apparmor_parser --status'
B.Run 'kubectl get apparmorprofiles'
C.Read the file /sys/kernel/security/apparmor/profiles
D.Run 'aa-status' on the node
AnswerD

aa-status is the canonical utility from the apparmor-utils package for checking AppArmor status on a node. It reads the AppArmor security filesystem under /sys/kernel/security/apparmor/ to display loaded profiles, their enforcement mode (enforce or complain), and which processes are confined. Running aa-status on the node gives an administrator the exact, current state of the AppArmor subsystem, making it the correct and most direct verification method.

Why this answer

`aa-status` is the standard command-line tool for checking the status of AppArmor profiles on a Linux node. It displays which profiles are loaded, which processes are confined, and the enforcement mode (enforce/complain). This is the direct, node-level utility for AppArmor status verification.

Exam trap

The trap here is that candidates may confuse Kubernetes-native resources (like `kubectl get`) with node-level security tools, or assume that reading a kernel file is equivalent to using the dedicated status command, but the exam expects familiarity with the standard Linux administration command `aa-status` for AppArmor.

How to eliminate wrong answers

Option A is wrong because `apparmor_parser` is used to load or unload AppArmor profiles into the kernel, not to check their status; the `--status` flag does not exist for this command. Option B is wrong because `kubectl get apparmorprofiles` is not a valid Kubernetes API resource; AppArmor profiles are managed at the node level, not via Kubernetes objects. Option C is wrong because while `/sys/kernel/security/apparmor/profiles` lists loaded profiles, it is a raw kernel interface that requires parsing and does not provide a human-readable status summary like `aa-status` does.

Practice this question →
68
MCQmedium

An administrator wants to enforce that no container in a specific namespace runs with the privileged security context. They decide to use Pod Security Standards. Which Pod Security Standard level should be applied to the namespace?

A.baseline
B.custom
C.restricted
D.privileged
AnswerC

Restricted is the most restrictive level and prohibits privileged containers.

Why this answer

The restricted Pod Security Standard (PSS) level is the correct choice because it enforces the most stringent set of security controls, including the prohibition of privileged containers. This level denies any pod that requests `privileged: true` or uses other privileged capabilities, ensuring that no container in the namespace can run with elevated host access. The baseline level is less restrictive and allows some privileged configurations, while the privileged level imposes no restrictions at all.

Exam trap

The trap here is that candidates often confuse the 'baseline' level as being sufficient to block privileged containers, but baseline only prevents known privilege escalations and does not explicitly deny the `privileged: true` setting, which is only enforced by the restricted level.

How to eliminate wrong answers

Option A is wrong because the baseline level only blocks known privilege escalations but still allows some privileged settings (e.g., `privileged: true` is not explicitly denied by baseline). Option B is wrong because 'custom' is not a standard Pod Security Standard level; PSS defines only three built-in levels: privileged, baseline, and restricted. Option D is wrong because the privileged level explicitly permits all containers to run with privileged security contexts, which is the opposite of the enforcement goal.

Practice this question →
69
MCQhard

A container runs as non-root and needs to perform operations that require CAP_SYS_PTRACE. Which YAML snippet correctly adds only this capability while following the principle of least privilege?

A.securityContext: capabilities: add: ['SYS_PTRACE']
B.securityContext: capabilities: drop: ['ALL'] add: ['SYS_PTRACE']
C.securityContext: capabilities: drop: ['ALL']
D.securityContext: privileged: true
AnswerB

This explicitly drops every capability first, then adds only SYS_PTRACE, resulting in a minimal capability set scoped to the required operation. This follows the least-privilege principle: the container receives exactly one Linux capability, reducing the kernel attack surface to the narrowest possible for the task.

Why this answer

It first drops all capabilities with `drop: ['ALL']` and then explicitly adds only `SYS_PTRACE`, ensuring the container runs with the minimum privileges required. This follows the principle of least privilege by removing any inherited or default capabilities before granting only the needed one. In Kubernetes, capabilities are Linux kernel capabilities; dropping all and adding only what is necessary is the recommended security practice.

Exam trap

CNCF often tests the misconception that simply adding a capability is sufficient, but the trap is that candidates forget to drop all other capabilities first, leaving the container with more privileges than intended.

How to eliminate wrong answers

Option A is wrong because it only adds `SYS_PTRACE` without dropping existing capabilities, meaning the container retains all default capabilities (e.g., CHOWN, DAC_OVERRIDE, FOWNER, etc.), violating the principle of least privilege. Option C is wrong because it drops all capabilities but does not add `SYS_PTRACE`, so the container would lack the required capability to perform ptrace operations. Option D is wrong because setting `privileged: true` grants all capabilities (including SYS_PTRACE) and disables most security constraints, which is excessive and violates least privilege.

Practice this question →
70
MCQmedium

Which of the following is NOT a valid seccomp profile type in Kubernetes?

A.SeccompDefault
B.Unconfined
C.RuntimeDefault
D.Localhost
AnswerA

SeccompDefault is not a valid seccomp profile type in Kubernetes. The valid values for the `type` field under `securityContext.seccompProfile` are `RuntimeDefault`, `Localhost`, and `Unconfined`. While the `SeccompDefault` feature gate enables the runtime default profile for pods, it does not appear as a profile type value. The attempt to set `type: SeccompDefault` will be rejected by the API server.

Why this answer

SeccompDefault is not a valid seccomp profile type in Kubernetes. The valid profile types are Unconfined, RuntimeDefault, and Localhost. SeccompDefault is a feature gate (introduced in Kubernetes 1.22) that, when enabled, tells the kubelet to use the RuntimeDefault seccomp profile by default for pods, but it is not itself a profile type.

Exam trap

The trap here is that candidates confuse the SeccompDefault feature gate with a valid seccomp profile type, especially since the feature gate name sounds like a profile type and is often mentioned in the context of default seccomp enforcement.

How to eliminate wrong answers

Option A is wrong because SeccompDefault is a feature gate, not a seccomp profile type. Option B is wrong because Unconfined is a valid seccomp profile type that disables seccomp filtering for a container. Option C is wrong because RuntimeDefault is a valid seccomp profile type that uses the container runtime's default seccomp profile (typically a restrictive profile that blocks syscalls like unshare, mount, etc.).

Option D is wrong because Localhost is a valid seccomp profile type that allows you to specify a custom seccomp profile file on the node's filesystem.

Practice this question →
71
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

Restricting hostNetwork, hostPID and hostIPC prevents pods sharing the node's network stack, process table and IPC namespace, blocking host snooping and privilege escalation. This directly reduces the node attack surface by severing container-to-host namespace sharing.

Why this answer

Option B is correct because restricting hostNetwork, hostPID, and hostIPC prevents containers from sharing the node's network, process, and IPC namespaces, which blocks container escapes and privilege escalation that would otherwise expose the host directly. Option D is correct because disabling unnecessary system services on the node removes unused daemons and listening ports, shrinking the exploitable attack surface in line with CIS Kubernetes Benchmark node hardening guidance. Option A is wrong because loading all kernel modules increases the attack surface by exposing additional kernel code and potential vulnerabilities rather than reducing it.

Option C is wrong because enabling SSH for all users broadens remote access and credential exposure instead of limiting it. Option E is wrong because allowing containers to run as root grants unnecessary privileges that can be leveraged to compromise the node.

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 →
72
MCQeasy

You are a platform engineer for a financial services company. Your Kubernetes cluster runs on bare-metal nodes with Ubuntu 20.04 and uses containerd as the container runtime. The cluster is in production with 50 worker nodes. A recent security scan shows that all nodes have the 'overlayfs' kernel module loaded, which is not required. The security policy requires minimal kernel modules. You need to disable the module without disrupting running containers. What should you do?

A.Restart containerd on each node to unload the module
B.Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining
C.Use 'rmmod overlayfs' after stopping all containers
D.Use 'modprobe -r overlayfs' on each node immediately
AnswerB

Adding 'blacklist overlayfs' to /etc/modprobe.d/ prevents the kernel's module autoload mechanism from loading the module during normal boot, but because overlayfs is often pulled in by the initramfs or as a dependency of another module, 'update-initramfs -u' is required to rebuild the initial RAM disk without it. Draining each node before reboot ensures that all pods are gracefully rescheduled to other nodes, so the reboot itself does not interrupt workloads. This is the only persistent and non-disruptive method to disable the module across reboots.

Why this answer

It permanently disables the overlayfs kernel module by adding it to the modprobe blacklist and updating the initramfs, ensuring the module is not loaded on subsequent boots. Draining and rebooting nodes one by one avoids disrupting running containers, as pods are rescheduled to other nodes before the node is taken offline. This approach aligns with the security policy of minimizing kernel modules while maintaining production uptime.

Exam trap

CNCF often tests the misconception that unloading a kernel module with 'rmmod' or 'modprobe -r' is safe while containers are running, but in reality, overlayfs is actively used by the container runtime and cannot be removed without causing filesystem errors or container crashes.

How to eliminate wrong answers

Option A is wrong because restarting containerd does not unload kernel modules; containerd is a user-space runtime that uses overlayfs, but unloading the module requires kernel-level operations, not a service restart. Option C is wrong because 'rmmod overlayfs' will fail if the module is in use by any container or filesystem, and stopping all containers on a node would disrupt running workloads, violating the requirement to avoid disruption. Option D is wrong because 'modprobe -r overlayfs' immediately unloads the module, which will fail if any process (including containerd or running containers) is using overlayfs, and even if it succeeds, it could cause container failures or filesystem errors without proper draining.

Practice this question →
73
MCQeasy

Which Pod Security Standard level allows the most relaxed security controls?

A.restricted
B.default
C.baseline
D.privileged
AnswerD

Privileged is the most relaxed Pod Security Standard level, imposing virtually no security restrictions on pods. It allows privileged containers, all Linux capabilities, host namespaces (network, PID, IPC), arbitrary seccomp or AppArmor overrides, and ephemeral containers, making it suitable only for system-level or trusted workloads. This design intentionally matches the behavior of running with no Pod Security admission restrictions, hence it is the correct answer.

Why this answer

The privileged Pod Security Standard (PSS) level imposes no restrictions on pod behavior, allowing unrestricted access to host resources, capabilities, and security contexts. This makes it the most relaxed level, as it does not enforce any of the constraints found in baseline or restricted profiles.

Exam trap

The trap here is that candidates may confuse 'default' with a valid PSS level, or assume 'baseline' is the most relaxed because it sounds less restrictive than 'restricted', but privileged explicitly allows all controls without limitation.

How to eliminate wrong answers

Option A is wrong because restricted is the most restrictive PSS level, enforcing strict security contexts, read-only root filesystems, and dropping all capabilities. Option B is wrong because 'default' is not a valid Pod Security Standard level; the three defined levels are privileged, baseline, and restricted. Option C is wrong because baseline applies a moderate set of restrictions (e.g., preventing hostPID, hostNetwork, and privileged containers) but is less relaxed than privileged.

Practice this question →
74
MCQmedium

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?

A.Use the RuntimeDefault profile and add capabilities
B.Change the seccomp profile to another runtime default
C.Set seccompProfile to Unconfined
D.Create a custom seccomp profile that allows the syscall and apply it via type: Localhost
AnswerD

The correct approach is to create a custom seccomp profile, a JSON file with a syscall allowlist that explicitly permits the missing syscall while retaining the default deny/safe list for all other syscalls. Place the profile on the node under the kubelet seccomp root, normally /var/lib/kubelet/seccomp, then reference it in the pod spec as securityContext.seccompProfile.type: Localhost with localhostProfile set to the filename. This gives fine-grained control and keeps the container secure, only widening the filter exactly where needed. It is the recommended way to handle seccomp exceptions.

Why this answer

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.

Exam trap

CNCF often tests the misconception that capabilities can override seccomp restrictions, but in reality, seccomp and capabilities are independent security mechanisms; a blocked syscall cannot be unblocked by adding capabilities.

How to eliminate wrong answers

Option A is wrong because capabilities control privileged operations (e.g., CAP_SYS_ADMIN), not syscall filtering; adding capabilities does not unblock a syscall blocked by seccomp. Option B is wrong because there is only one runtime default profile (RuntimeDefault) in containerd/Docker; changing to another runtime default is not possible as it is the same profile. Option C is wrong because setting seccompProfile to Unconfined disables all seccomp filtering, which is overly permissive and violates the principle of least privilege; it should only be used when absolutely necessary and after careful consideration.

Practice this question →
75
MCQmedium

An administrator wants to run a container that requires the SYS_TIME capability. Which field should be used in the securityContext to add this capability?

A.capabilities.add
B.privileged: true
C.allowPrivilegeEscalation: true
D.capabilities.drop
AnswerA

The `capabilities.add` field in a container's securityContext is the precise mechanism for granting individual Linux capabilities, such as NET_ADMIN or SYS_TIME, to a specific container without affecting the host or other containers. By explicitly adding only the required capabilities, the container runs with the least privilege necessary, adhering to the principle of least privilege. This field accepts a list of capability names, which are then unioned with the default capability set of the container runtime.

Why this answer

The `capabilities.add` field in the `securityContext` is specifically designed to add Linux capabilities (such as `SYS_TIME`) to a container without granting full root privileges. This follows the principle of least privilege, allowing only the required capability to modify the system clock.

Exam trap

The trap here is that candidates often confuse `privileged: true` (which grants all capabilities but is overly permissive) with the more precise `capabilities.add` approach, or they mistakenly think `allowPrivilegeEscalation` is related to adding capabilities.

How to eliminate wrong answers

Option B is wrong because `privileged: true` grants all capabilities (including SYS_TIME) but also disables all security restrictions, which is excessive and violates the principle of least privilege. Option C is wrong because `allowPrivilegeEscalation: true` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), not the addition of specific capabilities. Option D is wrong because `capabilities.drop` is used to remove capabilities from the default set, not to add them.

Practice this question →
Page 1 of 2 · 137 questions totalNext →

Ready to test yourself?

Try a timed practice session using only Cks System Hardening questions.

Start 20-question session