Courseiva

CCNA Cks System Hardening Questions

75 of 160 questions · Page 1/3 · 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

Restricted enforces dropping all capabilities and only adding back required ones, meeting the requirement.

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

Sharing the host's PID namespace lets the container see all host processes.

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 minimizes disruption by testing seccomp before enforcing, and then hardens kubelet.

Why this answer

Option D is correct because 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

This directly reduces privileges by avoiding root execution and preventing writes to the filesystem.

Why this answer

Option C is correct because 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 actively denies actions not allowed by the profile.

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 sets the enforce level to restricted for the namespace.

Why this answer

Option C is correct because 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 can reject images from untrusted registries based on external policy.

Why this answer

Option D is correct because 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

Correct. Drop ALL removes all capabilities, then add NET_BIND_SERVICE adds it back.

Why this answer

Dropping ALL removes all capabilities, then adding NET_BIND_SERVICE gives only that one capability.

Practice this question →
9
MCQeasy

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

A.CAP_NET_RAW
B.CAP_DAC_OVERRIDE
C.CAP_SETUID
D.CAP_SYS_ADMIN
AnswerC

CAP_SETUID allows changing user ID, which is required for setuid binaries to function.

Why this answer

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

Exam trap

CNCF often tests the distinction between capabilities that control privilege escalation (CAP_SETUID) versus those that grant broad system access (CAP_SYS_ADMIN) or file permission bypass (CAP_DAC_OVERRIDE), leading candidates to pick the more familiar but incorrect option.

How to eliminate wrong answers

Option A (CAP_NET_RAW) is wrong because it controls the ability to use raw and packet sockets (e.g., for crafting custom packets or performing ARP spoofing), not privilege escalation via setuid binaries. Option B (CAP_DAC_OVERRIDE) is wrong because it allows bypassing discretionary access control (file permission checks), which could enable reading/writing arbitrary files but does not directly control the ability to execute setuid binaries to gain new privileges. Option D (CAP_SYS_ADMIN) is wrong because it is a broad capability that grants many system administration operations (e.g., mount, namespace manipulation), but it does not specifically govern the setuid mechanism; dropping it would not prevent a container from using setuid binaries to escalate privileges.

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

Raw sockets (e.g., for ICMP) are blocked, reducing the attack surface.

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 →
11
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

Correct format: key is container name, value is 'localhost/' followed by profile name.

Why this answer

Option C is correct because 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 →
12
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 filters syscalls.

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

A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?

A.Run the container with privileged: true
B.Add SYS_ADMIN capability to the container
C.Use allowedUnsafeSysctls in pod securityContext for safe sysctls like net.ipv4.tcp_syncookies
D.Modify kubelet's --sysctl-whitelist to include the needed sysctl
AnswerC

Namespaced sysctls can be set without full privileges if allowed by the cluster.

Why this answer

Option C is correct because Kubernetes provides a secure mechanism to modify kernel parameters via `allowedUnsafeSysctls` in the Pod's `securityContext`. This approach allows specific sysctls (e.g., `net.ipv4.tcp_syncookies`) to be set without granting full privileged access or dangerous capabilities. It ensures that only explicitly whitelisted sysctls are permitted, reducing the attack surface while meeting the developer's requirement.

Exam trap

CNCF often tests the misconception that `SYS_ADMIN` capability is the minimal privilege needed for sysctl modifications, but in reality, it grants far more power than necessary, and the correct secure approach is to use `allowedUnsafeSysctls` in the Pod's security context.

How to eliminate wrong answers

Option A is wrong because running a container with `privileged: true` grants all capabilities and disables all security restrictions, which is excessive and insecure for modifying only kernel parameters. Option B is wrong because adding `SYS_ADMIN` capability grants broad administrative privileges (e.g., namespace manipulation, filesystem operations) beyond just modifying sysctls, violating the principle of least privilege. Option D is wrong because modifying the kubelet's `--sysctl-whitelist` is a deprecated and insecure approach; it applies globally to all pods on the node and does not provide per-pod granular control, unlike the Pod-level `allowedUnsafeSysctls` field.

Practice this question →
14
MCQmedium

During a security audit, it is found that containers running in a cluster have CAP_NET_RAW capability by default. The team wants to drop this capability for all containers. Which approach should be taken?

A.Use a mutating admission webhook to add a finalizer that drops capabilities
B.Create a PodSecurityPolicy with requiredDropCapabilities: [NET_RAW] and assign it to a role binding
C.Configure kubelet with --allowed-unsafe-sysctls to restrict capabilities
D.Modify each deployment to include securityContext.capabilities.drop: [NET_RAW]
AnswerB

PSP (or PSA) enforces the drop for all pods in the cluster.

Why this answer

Option B is correct because PodSecurityPolicy (PSP) is the native Kubernetes mechanism to enforce cluster-wide security constraints, including dropping specific capabilities like NET_RAW. By defining a PSP with `requiredDropCapabilities: [NET_RAW]` and binding it to a role via RoleBinding or ClusterRoleBinding, all containers in the cluster will automatically have that capability removed, ensuring consistent enforcement without modifying individual workloads.

Exam trap

The trap here is that candidates confuse PodSecurityPolicy with deprecated or alternative mechanisms (like manual deployment edits or unrelated kubelet flags), or mistakenly think a mutating webhook with a finalizer can alter security contexts, when in fact finalizers serve a completely different purpose in Kubernetes lifecycle management.

How to eliminate wrong answers

Option A is wrong because a mutating admission webhook can modify pods, but adding a finalizer does not drop capabilities; finalizers are used for cleanup logic before deletion, not for security context modifications. Option C is wrong because `--allowed-unsafe-sysctls` on the kubelet controls which unsafe sysctls are permitted, not capabilities; capabilities are managed via the container runtime and security context, not sysctl settings. Option D is wrong because modifying each deployment manually is not a scalable or auditable approach for cluster-wide enforcement; it violates the principle of centralized security policy and is error-prone in large environments.

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

If loaded in complain mode, the profile does not enforce restrictions, only logs violations.

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 →
16
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 reduces the attack surface directly.

Why this answer

The best approach is to disable and remove unnecessary services on the node. This directly reduces the attack surface. Option A is correct.

Option B is incorrect because disabling only during maintenance leaves the node vulnerable during normal operation. Option C is incorrect because firewalls can block ports but services may still be exploitable. Option D is incorrect because AppArmor can confine services but does not remove them.

Practice this question →
17
MCQeasy

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

A.securityContext: dropCapabilities: ALL
B.securityContext: capabilities: drop: ALL
C.securityContext: capabilities: drop: ["all"]
D.securityContext: capabilities: remove: ALL
AnswerB

Correct: 'drop: ALL' drops all capabilities.

Why this answer

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

Exam trap

CNCF often tests the distinction between the correct `capabilities.drop` field and common misspellings like `dropCapabilities` or `remove`, and the requirement for uppercase `ALL` versus lowercase `all`.

How to eliminate wrong answers

Option A is wrong because `dropCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option C is wrong because it uses lowercase `"all"` instead of uppercase `ALL`; Kubernetes expects the string `ALL` in uppercase to match the Linux capability naming convention. Option D is wrong because `remove` is not a valid key under `capabilities`; the correct key is `drop`.

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

Securing etcd is critical because it stores all cluster data.

Practice this question →
19
MCQhard

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

A.Restrict SSH access to the node using firewall rules
B.Disable unnecessary system services (e.g., telnet, rsh) on the node
C.Drop the NET_RAW capability from all containers running on the node
D.Apply the latest security patches to the host kernel
AnswerC

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

Why this answer

Option C is 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 →
20
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.cap_drop: ["ALL"] cap_add: ["NET_BIND_SERVICE"]
B.cap_drop: ["NET_RAW"]
C.cap_add: ["ALL"]
D.cap_add: ["NET_BIND_SERVICE"]
AnswerA

Dropping all then adding only needed capabilities is the correct approach for least privilege.

Why this answer

Option A is correct because the security policy requires dropping all Linux capabilities and only adding the necessary ones. The configuration `cap_drop: ["ALL"]` removes every capability from the container, and `cap_add: ["NET_BIND_SERVICE"]` explicitly adds back only the `CAP_NET_BIND_SERVICE` capability, which allows binding to privileged ports (below 1024). This follows the principle of least privilege by starting from a clean slate and granting only what is needed.

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 →
21
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 restrict which images can be pulled from registries
D.Use minimal base images like distroless or scratch
E.Run containers as root to avoid permission issues
AnswersA, C, D

Identifies known CVEs.

Why this answer

Option A is correct because 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.

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 →
22
Multi-Selecthard

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

Select 2 answers
A.Add annotation: seccomp.security.alpha.kubernetes.io/pod: audit.json
B.Add annotation per container: container.seccomp.security.alpha.kubernetes.io/<name>: localhost/audit.json
C.Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json
D.Add annotation: seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json
E.Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json
AnswersC, D

This is the current recommended way.

Why this answer

Option C is correct because in Kubernetes v1.19+, the `securityContext.seccompProfile` field is the stable API for configuring seccomp profiles. Setting `type: Localhost` and `localhostProfile: audit.json` instructs the kubelet to load the profile from the node's local seccomp directory (typically `/var/lib/kubelet/seccomp/audit.json`). This is the recommended approach for applying a node-local seccomp profile to a pod or container.

Exam trap

CNCF often tests the distinction between the deprecated alpha annotation format (which requires the `localhost/` prefix in the value) and the stable `securityContext.seccompProfile` API, and candidates mistakenly omit the `localhost/` prefix in the annotation value or confuse the field names `localhostProfile` vs `profile`.

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

Correct. The profile is assumed to be in /var/lib/kubelet/seccomp/.

Why this answer

The correct way to reference a localhost seccomp profile is to set type: Localhost and localhostProfile: the profile filename.

Practice this question →
24
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 displays loaded profiles and their modes.

Why this answer

'aa-status' shows the status of AppArmor including loaded profiles. Option A is correct. 'apparmor_status' is an alias; but 'aa-status' is the standard. Option B shows seccomp status.

Option C lists files in a directory. Option D is not a command.

Practice this question →
25
MCQmedium

A security engineer needs to apply a custom AppArmor profile to a pod. The profile is named 'k8s-apparmor-example-deny-write' and is loaded on the node. Which annotation should be added to the pod's metadata to enforce this profile?

A.apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"
B.container.apparmor.security.beta.kubernetes.io/pod-name: "k8s-apparmor-example-deny-write"
C.container.apparmor.security.beta.kubernetes.io/container-name: "localhost/k8s-apparmor-example-deny-write"
D.container.apparmor.security.beta.kubernetes.io/container-name: "k8s-apparmor-example-deny-write"
AnswerC

This annotation correctly references the local profile using the 'localhost/' prefix.

Why this answer

Option C is correct because the AppArmor annotation for a container follows the format `container.apparmor.security.beta.kubernetes.io/<container-name>` and the profile name must be prefixed with `localhost/` when referencing a profile loaded on the node. The annotation value `"localhost/k8s-apparmor-example-deny-write"` correctly specifies the node-local profile.

Exam trap

CNCF often tests the requirement for the `localhost/` prefix in the annotation value, causing candidates to pick Option D which omits it, or Option A which uses the wrong annotation key format.

How to eliminate wrong answers

Option A is wrong because the annotation prefix is `container.apparmor.security.beta.kubernetes.io/`, not `apparmor.security.beta.kubernetes.io/`. Option B is wrong because the annotation suffix should be the container name, not the pod name. Option D is wrong because it omits the required `localhost/` prefix; without it, Kubernetes treats the value as an invalid profile reference.

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

This configuration enforces the restricted profile, which drops all capabilities except the minimal default set.

Why this answer

The restricted Pod Security Standard drops all capabilities except those required for default operation, and does not allow 'cap_add' beyond the restricted set. The correct enforcement is to use 'restricted' level with 'enforce' mode. Option A is the correct configuration.

Option B uses 'baseline' which is less restrictive. Option C is incorrect because 'privileged' allows all capabilities. Option D is incorrect because 'warn' does not enforce.

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

Correct. seccompProfile is used in the security context.

Why this answer

Option A is correct because 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 →
28
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

Correct. This label enforces the restricted Pod Security Standard at the namespace level.

Why this answer

Option C is correct because 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 →
29
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

This is a deprecated method but still valid in older clusters.

Why this answer

Seccomp profiles can be set via the container's securityContext.seccompProfile field (option A) or via the deprecated pod annotation (option D). Option B is a PSP field, not applicable to seccomp. Option C is for AppArmor.

Option E is not a valid annotation.

Practice this question →
30
MCQhard

A security team wants to ensure that no pod runs with privileged access. They have created a PodSecurityPolicy (PSP) that sets 'privileged: false'. However, a pod with privileged: true still gets created. What is the most likely cause?

A.The user creating the pod does not have a RoleBinding that grants use of the PSP
B.The pod has a higher priority than the PSP
C.The PodSecurityPolicy admission controller is not enabled
D.The PodSecurityPolicy is defined after the pod creation
AnswerA

Without authorization, the PSP does not apply; the user may be using a default PSP that allows privileged.

Why this answer

A is correct because PodSecurityPolicy (PSP) requires the user or service account creating the pod to have a RoleBinding or ClusterRoleBinding that grants the `use` verb on the PSP resource. Without this RBAC authorization, the PSP is not enforced for that user, even if the PSP exists and the admission controller is enabled. The pod with `privileged: true` bypasses the PSP because the creating identity lacks the necessary RBAC permissions to trigger the PSP's validation.

Exam trap

CNCF often tests the misconception that simply creating a PSP is enough to enforce restrictions, but the trap here is that PSP enforcement requires explicit RBAC binding—without it, the PSP is effectively ignored for the pod's creator.

How to eliminate wrong answers

Option B is wrong because pod priority does not override PSP enforcement; PSP is an admission controller that evaluates all pods regardless of priority class. Option C is wrong because if the PodSecurityPolicy admission controller were not enabled, no PSP would be enforced at all, but the question states a PSP was created and the pod still gets created, implying the controller is active (otherwise the PSP would be irrelevant). Option D is wrong because PSPs are cluster-scoped resources evaluated at pod creation time; the order of creation does not affect enforcement—if the PSP exists before the pod creation attempt, it applies.

Practice this question →
31
MCQmedium

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

A.The container is missing a memory limit and gets OOMKilled
B.The namespace has a PodSecurity enforce level that restricts hostPID and hostNetwork
C.The 'hostPID' and 'hostNetwork' fields cannot be combined
D.The pod lacks the necessary Linux capabilities
AnswerB

HostPID and hostNetwork are restricted in baseline and restricted levels, causing the pod to be rejected or crash.

Why this answer

The pod violates the Pod Security Standard of the namespace. If the namespace has an enforce label set to 'baseline' or 'restricted', it would block hostPID/hostNetwork unless the pod is exempted. Option A is correct because the PodSecurity admission plugin would deny the pod or at least warn.

Option B is less likely as OOMKilled would show a different status. Option C is not a known issue. Option D is plausible but not the most direct cause given the scenario.

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

This correctly references the custom profile.

Why this answer

To use a custom seccomp profile, set type to 'Localhost' and localhostProfile to the path relative to the seccomp directory. Option A is correct. Option B uses 'RuntimeDefault' which is not custom.

Option C uses 'Unconfined'. Option D is invalid.

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

Correct. RuntimeDefault applies the runtime's default seccomp profile.

Why this answer

Option D: RuntimeDefault uses the container runtime's default seccomp profile, which is typically the Docker/default profile. Option A is false; RuntimeDefault does not disable seccomp. Option B is false; it uses runtime's default, not custom.

Option C is false; it does not require any special permissions.

Practice this question →
34
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 default directory for seccomp profiles.

Why this answer

For 'Localhost' seccomp profiles, the profile file must be placed in the kubelet's seccomp directory, which defaults to '/var/lib/kubelet/seccomp/'. The path provided in 'localhostProfile' is relative to that directory. So the full path becomes '/var/lib/kubelet/seccomp/profiles/audit.json'.

Option A is correct.

Practice this question →
35
MCQeasy

Which of the following securityContext settings prevents a container from using host network namespace?

A.hostIPC: false
B.hostNetwork: true
C.hostNetwork: false
D.hostPID: false
AnswerC

Correct. Setting hostNetwork to false (default) prevents use of host network.

Why this answer

Option C is correct because setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.

Exam trap

CNCF often tests the distinction between the three namespace-related securityContext fields (`hostNetwork`, `hostIPC`, `hostPID`), and the trap here is that candidates confuse `hostIPC` or `hostPID` with network isolation, assuming any `false` setting prevents host network access.

How to eliminate wrong answers

Option A is wrong because `hostIPC: false` controls access to the host's Inter-Process Communication (IPC) namespace (e.g., shared memory segments), not the network namespace. Option B is wrong because `hostNetwork: true` would actually allow the container to share the host's network namespace, which is the opposite of preventing it. Option D is wrong because `hostPID: false` controls whether the container can see host processes via the PID namespace, not the network namespace.

Practice this question →
36
Drag & Dropmedium

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

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

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

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

Correct. apparmor_parser loads the 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 →
38
MCQmedium

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

A.aa-status
B.aa-profile --status
C.aa-enabled
D.cat /sys/kernel/security/apparmor/profiles
AnswerA

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

Why this answer

Option A is correct because `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 →
39
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

The error indicates AppArmor is not available on the node. It needs to be enabled in the kernel and the apparmor_parser used to load profiles.

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 →
40
Multi-Selecteasy

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

Select 2 answers
A.Audit
B.Disabled
C.Complain
D.Enforce
E.Unconfined
AnswersC, D

Logs violations but does not enforce.

Why this answer

AppArmor has three modes: enforce, complain, and unconfined. The question asks for two valid modes, so 'enforce' and 'complain' are correct. 'Unconfined' is also valid but is a mode that disables AppArmor for a profile. Since the question asks for two, we can pick enforce and complain. 'Disabled' is not a valid mode, and 'audit' is not a mode.

Practice this question →
41
Multi-Selectmedium

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

Select 2 answers
A.Setting 'securityContext.seccompProfile.type' in the pod spec
B.Adding annotation 'container.apparmor.security.beta.kubernetes.io/<container>'
C.Including 'seccomp' profile in PodSecurityPolicy
D.Including 'seccompProfile' under 'spec.securityContext' at the pod level
E.Adding annotation 'seccomp.security.alpha.kubernetes.io/pod'
AnswersA, E

This is the current recommended way.

Why this answer

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

Exam trap

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

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

Unconfined disables seccomp, so no syscall filtering occurs.

Why this answer

Unconfined means no seccomp filtering is applied, so the container can make any syscall. Option B is correct.

Practice this question →
43
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: localhost/k8s-apparmor-example
AnswerA

This correctly specifies the container name and the profile using 'localhost/' prefix.

Why this answer

Option A is correct because 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 →
44
MCQhard

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

A.hostNetwork: false
B.hostNetwork: true
C.hostIPC: true
D.hostPID: true
AnswerA

Setting hostNetwork to false prevents the container from using the host network, thus preventing sniffing.

Why this answer

Setting 'hostNetwork: true' gives the container access to the host's network stack, allowing it to sniff traffic. Setting it to false prevents this.

Practice this question →
45
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 displays loaded AppArmor profiles and their modes.

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 →
46
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

hostPID gives containers access to the host process namespace, which increases risk.

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 →
47
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
AnswersC, D

NodeRestriction limits the kubelet's ability to modify node and pod objects, reducing the impact of a compromised kubelet.

Why this answer

Option C is correct because the NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing a compromised node from escalating privileges or tampering with other workloads. This is a key Kubernetes-native control to harden the kubelet's authorization scope.

Exam trap

CNCF often tests the distinction between authentication (verifying identity) and authorization (limiting actions); candidates may confuse enabling authentication (Option B) with hardening authorization, but the question specifically asks for methods that harden against unauthorized access, which includes both authentication and authorization controls, and the correct answers (C and D) focus on authorization and mutual TLS authentication respectively.

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

NodeRestriction does not affect pod creation; the error likely comes from PSP/PSA.

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 →
49
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

Prevents containers from writing to the filesystem, reducing risk of malware.

Why this answer

Option A is correct because 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 →
50
MCQmedium

A cluster is running Kubernetes 1.24. The security team wants to enforce that all pods run with a read-only root filesystem. Which approach is most effective?

A.Use OPA Gatekeeper to deny pods without readOnlyRootFilesystem
B.Enable PodSecurityPolicy with readOnlyRootFilesystem: true
C.Enable PodSecurity admission controller with restricted profile
D.Set --read-only-port=0 in kubelet
AnswerC

The restricted profile enforces readOnlyRootFilesystem: true as part of the policy.

Why this answer

Option C is correct because in Kubernetes 1.24, PodSecurityPolicy (PSP) has been removed, and the PodSecurity admission controller with the restricted profile is the built-in replacement that enforces a read-only root filesystem for all pods. The restricted profile sets `securityContext.readOnlyRootFilesystem: true` by default, ensuring compliance without external tools.

Exam trap

CNCF often tests the removal of PodSecurityPolicy in Kubernetes 1.25 and expects candidates to know that the PodSecurity admission controller with the restricted profile is the direct replacement, not OPA Gatekeeper or deprecated PSP.

How to eliminate wrong answers

Option A is wrong because OPA Gatekeeper is an external admission controller that requires additional installation and maintenance; while it can enforce readOnlyRootFilesystem, it is not the most effective built-in approach in Kubernetes 1.24. Option B is wrong because PodSecurityPolicy was deprecated in Kubernetes 1.21 and removed in 1.25, so it is unavailable in a 1.24 cluster (though still present, it is deprecated and not the recommended approach). Option D is wrong because `--read-only-port=0` in kubelet disables the read-only port (10255) for the kubelet API, which is unrelated to enforcing a read-only root filesystem for pods.

Practice this question →
51
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 configuration should be used?

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

Baseline allows adding NET_ADMIN.

Why this answer

Option A is correct because the baseline Pod Security Standard (PSS) restricts only privileged capabilities but allows adding specific capabilities like NET_ADMIN via the `capabilities.add` field in the securityContext. The baseline profile permits most capabilities except those that are explicitly restricted (e.g., CAP_SYS_ADMIN), so adding NET_ADMIN directly is compliant without needing to drop all capabilities first.

Exam trap

CNCF often tests the distinction between the baseline and restricted Pod Security Standards, where candidates mistakenly think they must drop all capabilities (as required by restricted) even when the baseline profile is in effect, leading them to choose option C unnecessarily.

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 →
52
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

RuntimeDefault instructs the container runtime (e.g., containerd) to apply its own default seccomp policy.

Why this answer

Option D is correct because 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 →
53
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. The enforce level blocks pods that violate the policy.

Why this answer

The baseline policy does not allow privileged containers. The admission controller will reject the pod creation.

Practice this question →
54
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 mode blocks violations and logs them.

Why this answer

AppArmor profiles can be in enforce or complain mode. Unconfined is a state (no profile), not a mode. Profile modes are enforce, complain, and kill (not listed).

Options C and D are not modes.

Practice this question →
55
MCQmedium

A security policy requires that containers should drop all capabilities and only add back the specific capabilities needed. Which YAML snippet correctly implements this for a container?

A.securityContext: capabilities: drop: ["ALL"] add: ["ALL"]
B.securityContext: capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"]
C.securityContext: capabilities: drop: ["CHOWN","DAC_OVERRIDE"]
D.securityContext: capabilities: add: ["NET_BIND_SERVICE"] drop: ["ALL"]
AnswerB

Correctly drops all capabilities then adds only the needed one, following the principle of least privilege.

Why this answer

Option B is correct because it first drops all capabilities with `drop: ["ALL"]` and then adds back only the specific capability needed (`NET_BIND_SERVICE`), which satisfies the security policy of least privilege. The order of `drop` and `add` in the YAML does not matter; Kubernetes processes both directives to produce the final capability set.

Exam trap

CNCF often tests the misconception that the order of `add` and `drop` in the YAML matters, or that dropping only a few capabilities is sufficient, when the policy explicitly requires dropping all capabilities first and then adding back only what is needed.

How to eliminate wrong answers

Option A is wrong because it adds back `ALL` capabilities after dropping them, effectively granting every capability and violating the policy of least privilege. Option C is wrong because it only drops two specific capabilities (`CHOWN` and `DAC_OVERRIDE`) but does not drop all capabilities, leaving many others enabled by default. Option D is wrong because although it drops all capabilities and adds `NET_BIND_SERVICE`, the order of `add` and `drop` in the YAML is irrelevant; the real issue is that the answer choices are designed to test recognition of the correct syntax, and D is identical in effect to B but presented in a different order, which is not a technical error but the exam expects the canonical form shown in B.

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

This deprecated annotation can still be used to apply seccomp profiles.

Why this answer

Option B is correct because 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 →
57
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)
AnswersB, D, E

Baseline restricts capabilities but does not require dropping all.

Why this answer

The baseline standard restricts: (A) privilege escalation (allowPrivilegeEscalation must be false), (B) running as root (must set runAsNonRoot: true), and (C) adds some capability restrictions. (D) is not a baseline restriction; hostNetwork is allowed in baseline. (E) is not a restriction; seccomp is not required in baseline.

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

Allows pod creation to proceed if webhook is unavailable.

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 →
59
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

Correct: enforce blocks violations, complain logs them.

Why this answer

Option A is correct because 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 →
60
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

An admission webhook can enforce policies cluster-wide automatically.

Why this answer

Option C is correct because 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 →
61
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

Correct. With hostPID, the container can see all host processes, increasing the risk of container escape.

Why this answer

Both hostNetwork and hostPID expose the container to host-level resources, but hostPID allows the container to see all host processes and potentially interfere with them, which is a direct risk to other workloads and the host itself.

Practice this question →
62
MCQeasy

A security engineer is hardening a Kubernetes node and wants to ensure that kubelet does not accept requests from unauthorized sources. Which kubelet configuration change should be made?

A.Set --anonymous-auth=true
B.Set --read-only-port=10255
C.Set --authentication-token-webhook=false
D.Set --anonymous-auth=false
AnswerD

Disables anonymous authentication, preventing unauthorized access.

Why this answer

Setting `--anonymous-auth=false` on the kubelet disables anonymous requests, meaning the kubelet will reject any request that does not present valid authentication credentials. This is a critical hardening measure to ensure only authenticated and authorized sources (e.g., the API server) can interact with the kubelet’s HTTPS API, preventing unauthorized nodes or attackers from querying or modifying pod/container state.

Exam trap

CNCF often tests the misconception that disabling anonymous auth is unnecessary if the read-only port is closed, but the trap is that anonymous auth controls the main HTTPS port (10250), which is the primary attack surface for kubelet API abuse.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth=true` explicitly allows unauthenticated requests, which is the opposite of what hardening requires. Option B is wrong because `--read-only-port=10255` opens an unsecured, read-only HTTP endpoint that bypasses authentication entirely, exposing sensitive node and pod information without any authorization checks. Option C is wrong because `--authentication-token-webhook=false` disables the webhook token review mechanism, which would prevent the kubelet from validating bearer tokens against the API server; this weakens authentication rather than strengthening it.

Practice this question →
63
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 to apply an AppArmor profile to a container.

Why this answer

The annotation 'container.apparmor.security.beta.kubernetes.io/<container_name>' is used to specify the AppArmor profile for a container. Option A is correct because it uses the proper prefix and container name placeholder.

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

Privileged level allows unrestricted access to host namespaces.

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 →
65
Multi-Selectmedium

Which TWO of the following are valid AppArmor profile modes?

Select 2 answers
A.Complain
B.Enforce
C.Audit
D.Disable
E.Permissive
AnswersA, B

In complain mode, violations are logged but not blocked.

Why this answer

AppArmor has three modes: enforce (profiles are enforced), complain (violations are logged but not blocked), and unconfined (no AppArmor). Options A and C are correct. 'audit' is not a mode; 'disable' is not a mode.

Practice this question →
66
MCQeasy

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

A.apparmor_load /path/to/profile
B.apparmor_parser -r /path/to/profile
C.aa-status
D.aa-enforce /path/to/profile
AnswerB

This command loads or replaces an AppArmor profile.

Why this answer

The 'apparmor_parser' command is used to load AppArmor profiles into the kernel. Option A is correct. Options B, C, and D are not valid commands for loading AppArmor profiles.

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

Correct. The default is RuntimeDefault.

Why this answer

As of Kubernetes 1.29, the default seccomp profile for containers is RuntimeDefault, which uses the container runtime's default profile.

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

This is the correct syntax to add NET_ADMIN capability to a container.

Why this answer

Option D is correct because in Kubernetes, the correct field to add a specific Linux capability to a container is `capabilities.add`, and the correct YAML key is `add`, not `cap_add`. The `cap_add` key is used in Docker Compose, not in Kubernetes pod or container security contexts. The `NET_ADMIN` capability allows the container to perform network administration tasks such as interface configuration, firewall management, and routing table manipulation.

Exam trap

CNCF often tests the distinction between Docker Compose syntax (`cap_add`) and Kubernetes syntax (`add`), and the requirement that `capabilities` must be set at the container level, not the pod level, to catch candidates who confuse container runtime configuration with Kubernetes API fields.

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 →
69
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

Option A is correct because 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 →
70
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

Prevents running as root, reducing the impact of container escape.

Why this answer

Options A, C, and D are recommended security practices. Option B increases attack surface, and option E is about monitoring, not reducing attack surface.

Practice this question →
71
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 loads the profile; -r replaces if already loaded.

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

HostPID allows viewing processes, and hostNetwork allows using the host network stack, which can be abused.

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 →
73
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

This directly prevents privilege escalation, which is a key security control.

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

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

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

Correct annotation to set AppArmor profile per container.

Why this answer

The annotation 'container.apparmor.security.beta.kubernetes.io/<container_name>' is the standard way to specify an AppArmor profile for a container in a pod.

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

AlwaysPullImages forces image pull but does not block untrusted registries.

Why this answer

Option C is correct because, 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 →
Page 1 of 3 · 160 questions totalNext →

Ready to test yourself?

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

Start 20-question session