Knowledge + Practice

CCNA Cks System Hardening Questions

75 of 160 questions · Page 2/3 · Cks System Hardening topic · Answers revealed

Practice these questions Exam hub All questions

76

MCQeasy

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

A.kubectl get seccomp

B.kubectl get apparmor

C.aa-status

D.systemctl status apparmor

AnswerC

Correct. aa-status shows AppArmor status and loaded profiles.

Why this answer

The `aa-status` command is a standard Linux utility that displays the status of AppArmor, including whether it is enabled and which profiles are loaded. Since AppArmor is a Linux Security Module (LSM) enforced at the node level, not a Kubernetes resource, you must use a node-level command like `aa-status` to check its status. This command directly queries the AppArmor module in the kernel and lists all loaded profiles.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

77

MCQeasy

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

A.apparmor_parser

B.aa-enforce

C.aa-status

D.kubectl apply

AnswerA

Correct. apparmor_parser loads profiles.

Why this answer

The apparmor_parser command is used to load AppArmor profiles into the kernel.

Practice this question →

78

MCQmedium

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

A.capabilities: add: ["NET_BIND_SERVICE"]

B.capabilities: drop: ["ALL"]

C.capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"]

D.capabilities: drop: ["NET_BIND_SERVICE"] add: ["ALL"]

AnswerC

Correct. Drops all first, then adds the required capability.

Why this answer

The recommended approach is to drop ALL capabilities using 'ALL' and then add only the needed capabilities.

Practice this question →

79

MCQmedium

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

A.The container runs with the host's IPC namespace.

B.The container can access the host's network interfaces.

C.The container can mount the host's filesystem.

D.The container runs in the host's PID namespace.

AnswerD

Correct. The container shares the host's process namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

80

MCQhard

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

A.The securityContext.seccompProfile.defaultRuntimeProfile field must be set to 'custom-profile.json'.

B.The seccomp profile should be defined in the pod's annotations, not securityContext.

C.The custom-profile.json file is not present on the node filesystem.

D.The localhostProfile field must be an absolute path.

AnswerC

The seccomp profile must be present on the node at the specified path. If it's missing, the pod cannot start.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

81

MCQeasy

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

A.It sets a hard limit of 1 PID per pod, which may break workloads

B.It limits each container to 1000 PIDs

C.It disables PID limiting, allowing a single pod to consume all PIDs on the node, risking a fork bomb

D.It enforces a default PID limit of 100 per pod

AnswerC

-1 disables the limit, so a pod can exhaust node PIDs.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

82

MCQeasy

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

A.Use 'apparmor_parser --status'

B.Run 'kubectl get apparmorprofiles'

C.Read the file /sys/kernel/security/apparmor/profiles

D.Run 'aa-status' on the node

AnswerD

aa-status displays the current AppArmor profile status.

Why this answer

The 'aa-status' command shows the status of AppArmor profiles, including which profiles are loaded and in what mode. Option A is correct. The other options are not standard AppArmor commands.

Practice this question →

83

MCQhard

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

A.None; you must manually configure admission webhooks

B.Privileged

C.Restricted

D.Baseline

AnswerC

Restricted prohibits hostNetwork, hostPID, and hostIPC.

Why this answer

The 'restricted' Pod Security Standard prohibits the use of hostNetwork, hostPID, and hostIPC, among other restrictions. 'Baseline' allows these with some restrictions, while 'privileged' allows all. Option C is correct.

Practice this question →

84

MCQmedium

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

A.baseline

B.custom

C.restricted

D.privileged

AnswerC

Restricted is the most restrictive level and prohibits privileged containers.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

85

MCQhard

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

A.securityContext: capabilities: add: ['SYS_PTRACE']

B.securityContext: capabilities: drop: ['ALL'] add: ['SYS_PTRACE']

C.securityContext: capabilities: drop: ['ALL']

D.securityContext: privileged: true

AnswerB

This drops all and adds only SYS_PTRACE.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

86

MCQmedium

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

A.SeccompDefault

B.Unconfined

C.RuntimeDefault

D.Localhost

AnswerA

There is no 'SeccompDefault' type. The correct type is 'RuntimeDefault'.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

Practice this question →

87

Multi-Selectmedium

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

Select 2 answers

A.Load all kernel modules to support any workload

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

C.Enable SSH access for all users for troubleshooting

D.Disable unnecessary system services on the node

E.Allow containers to run as root

AnswersB, D

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

Why this answer

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

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

Exam trap

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

Practice this question →

88

MCQhard

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

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

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

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

D.Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'

AnswerC

Baseline policy drops NET_RAW and other dangerous capabilities while being less restrictive than restricted.

Why this answer

Option C is correct because the 'baseline' PodSecurity standard enforces the minimum restrictions that prevent privilege escalation, including dropping the NET_RAW capability by default. The 'baseline' profile is designed to be applied to namespaces where most workloads run, and it automatically adds NET_RAW to the required drop capabilities list, which directly addresses the administrator's goal without the overhead of the more restrictive 'restricted' profile.

Exam trap

CNCF often tests the distinction between the three PodSecurity standards, and the trap here is that candidates may choose 'restricted' (option B) because it is the most secure, but the question only requires dropping NET_RAW, which is already covered by the 'baseline' profile without imposing unnecessary restrictions like requiring non-root users or seccomp profiles.

How to eliminate wrong answers

Option A is wrong because the 'privileged' PodSecurity standard allows all capabilities, including NET_RAW, and does not enforce any capability drops, so it would not prevent containers from running with NET_RAW. Option B is wrong because the 'restricted' standard is overly restrictive for many workloads (e.g., it requires running as non-root, seccomp profiles, and dropping all capabilities), and while it would drop NET_RAW, it imposes additional constraints that are not necessary for the stated requirement. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.21 and removed in v1.25, and the question explicitly states that PSP is deprecated, so using it is not the recommended approach; the correct replacement is PodSecurity admission with the 'baseline' profile.

Practice this question →

89

Multi-Selectmedium

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

Select 2 answers

A.Localhost

B.RuntimeDefault

C.ContainerDefault

D.Unconfined

E.KubernetesDefault

AnswersA, B

Uses a custom profile from the node's filesystem.

Why this answer

Option A is correct because the `Localhost` seccomp profile type allows you to reference a custom seccomp profile stored as a JSON file on the node's filesystem. This is a valid profile type in Kubernetes, specified via the `localhostProfile` field in the pod's security context. Option B is correct because `RuntimeDefault` is a valid seccomp profile type that instructs the container runtime (e.g., containerd or CRI-O) to apply its own default seccomp profile, which typically blocks a set of dangerous syscalls while allowing normal operations.

Exam trap

CNCF often tests the misconception that `Unconfined` is not a valid seccomp profile type, but it is valid; the trap is that candidates may confuse `Unconfined` with a non-existent type like `ContainerDefault` or `KubernetesDefault`, or they may incorrectly think `RuntimeDefault` is not a standard option.

Practice this question →

90

MCQeasy

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

A.Restart containerd on each node to unload the module

B.Add 'blacklist overlayfs' to /etc/modprobe.d/ and run 'update-initramfs -u', then reboot nodes one by one after draining

C.Use 'rmmod overlayfs' after stopping all containers

D.Use 'modprobe -r overlayfs' on each node immediately

AnswerB

This ensures the module is not loaded on subsequent boots, and draining before reboot prevents disruption.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

91

MCQeasy

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

A.restricted

B.default

C.baseline

D.privileged

AnswerD

Privileged allows all capabilities and has no restrictions.

Why this answer

The 'privileged' level is the most permissive, with no restrictions.

Practice this question →

92

MCQmedium

A container runs with the default seccomp profile but the application needs to make a specific syscall that is blocked. Which approach should be taken?

A.Use the RuntimeDefault profile and add capabilities

B.Change the seccomp profile to another runtime default

C.Set seccompProfile to Unconfined

D.Create a custom seccomp profile that allows the syscall and apply it via type: Localhost

AnswerD

Correct. A custom profile allows fine-grained control.

Why this answer

Option D is correct because the default seccomp profile (RuntimeDefault) blocks a specific set of syscalls for security. When an application requires a blocked syscall, the proper approach is to create a custom seccomp profile that explicitly allows that syscall, then apply it to the container via `seccompProfile.type: Localhost` and reference the profile file. This maintains security by only relaxing the necessary restriction, rather than disabling the profile entirely.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

93

MCQmedium

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

A.capabilities.add

B.privileged: true

C.allowPrivilegeEscalation: true

D.capabilities.drop

AnswerA

Correct field to add capabilities.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

94

Multi-Selectmedium

You need to apply a Pod Security Standard that prevents containers from running as root and disallows privileged escalation. Which TWO levels enforce these requirements?

Select 2 answers

A.baseline

B.privileged

C.restricted

D.default

E.unrestricted

AnswersA, C

Baseline restricts privilege escalation and prevents running as root.

Why this answer

The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The baseline level disallows privileged escalation (allowPrivilegeEscalation: false) and prevents containers from running as root by requiring that runAsNonRoot be set to true. The restricted level enforces all baseline requirements plus additional constraints, such as dropping all capabilities and setting seccomp to RuntimeDefault, which also prevents root execution and privileged escalation.

Therefore, both baseline and restricted enforce these two specific requirements.

Exam trap

CNCF often tests the misconception that 'default' or 'unrestricted' are valid PSS levels, when in fact only privileged, baseline, and restricted exist, and candidates may confuse 'privileged' with 'unrestricted' or think that 'default' is a separate level.

Practice this question →

95

MCQmedium

An administrator needs to enforce the restricted Pod Security Standard on a namespace 'secure-ns'. Which kubectl command should they use?

A.kubectl label namespace secure-ns pod-security.kubernetes.io/enforce=restricted

B.kubectl label namespace secure-ns security=restricted

C.kubectl create podsecuritypolicy restricted -n secure-ns

D.kubectl annotate namespace secure-ns pod-security.kubernetes.io/enforce=restricted

AnswerA

This correctly sets the enforce label for the restricted level.

Why this answer

The correct command uses 'kubectl label' to set the enforce label to 'restricted'. Option C is correct.

Practice this question →

96

MCQmedium

A security admin wants to drop all Linux capabilities for a container and then add only CAP_NET_BIND_SERVICE. Which YAML snippet correctly achieves this?

A.securityContext: capabilities: drop: ['ALL'] add: ['NET_BIND_SERVICE'] privileged: true

B.securityContext: capabilities: drop: ['NET_BIND_SERVICE'] add: ['ALL']

C.securityContext: capDrop: ['ALL'] capAdd: ['NET_BIND_SERVICE']

D.securityContext: capabilities: drop: ['ALL'] add: ['NET_BIND_SERVICE']

AnswerD

This correctly drops all capabilities and adds the required one.

Why this answer

Option D is correct because it uses the standard Kubernetes `securityContext.capabilities` field with `drop: ['ALL']` to remove all Linux capabilities from the container, then `add: ['NET_BIND_SERVICE']` to grant only the `CAP_NET_BIND_SERVICE` capability. This is the proper YAML syntax for the desired capability set.

Exam trap

CNCF often tests the distinction between the correct `capabilities` object syntax and the incorrect flat field names like `capDrop`/`capAdd`, and the trap is that candidates confuse `privileged: true` with a fine-grained capability control, when in fact it bypasses all capability restrictions.

How to eliminate wrong answers

Option A is wrong because setting `privileged: true` grants all capabilities and disables most security restrictions, completely negating the effect of dropping and adding capabilities. Option B is wrong because it drops `NET_BIND_SERVICE` and adds `ALL`, which would grant all capabilities instead of only `NET_BIND_SERVICE`. Option C is wrong because `capDrop` and `capAdd` are not valid Kubernetes securityContext fields; the correct field names are `capabilities.drop` and `capabilities.add`.

Practice this question →

97

Multi-Selectmedium

Which THREE of the following are recommended practices for securing the etcd datastore?

Select 3 answers

A.Disable peer client cert authentication

B.Bind etcd to localhost only if not required to be accessible from other nodes

C.Allow anonymous access to etcd for performance

D.Enable encryption at rest for etcd data

E.Use TLS for all etcd client-to-server communication

AnswersB, D, E

Binding to localhost reduces the attack surface.

Why this answer

Binding etcd to localhost (127.0.0.1) when it does not need to be accessed from other nodes restricts network exposure, reducing the attack surface. This is a fundamental network hardening practice that prevents unauthorized remote access to the etcd datastore, which stores all cluster state and secrets.

Exam trap

The trap here is that candidates may think disabling authentication (Option A) or enabling anonymous access (Option C) improves performance or simplifies setup, but the CKS exam strictly enforces that security controls like mTLS and authentication must never be weakened for any reason.

Practice this question →

98

MCQmedium

You need to apply a seccomp profile to all containers in a pod. The profile is named 'custom-profile.json' and is stored on each node at /var/lib/kubelet/seccomp/. Complete the following YAML snippet: ```yaml apiVersion: v1 kind: Pod metadata: name: secure-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: ??? ``` What should replace ???

A.custom-profile.json

B.localhost/custom-profile.json

C.profile: custom-profile.json

D./var/lib/kubelet/seccomp/custom-profile.json

AnswerA

The localhostProfile field expects the filename relative to the seccomp directory.

Why this answer

The 'localhostProfile' field should contain the filename of the profile relative to the seccomp directory on the node. The full path is /var/lib/kubelet/seccomp/custom-profile.json, so the value should be 'custom-profile.json'. Option A is correct.

Option B is incorrect because it includes the full path, which is not needed. Option C is incorrect because 'localhost' is not a valid type. Option D is incorrect because the field is 'localhostProfile', not 'profile'.

Practice this question →

99

MCQhard

You are a security engineer for a large e-commerce company. The Kubernetes cluster runs on-premises and hosts critical payment processing applications. Recently, a security scan revealed that several pods are running with privileged escalation enabled, and some have a writable root filesystem. The cluster uses Kubernetes v1.26 with PodSecurity admission controller enabled but currently set to 'privileged' profile for all namespaces. The development teams require flexibility for some legacy applications that need to run with hostNetwork or hostPID. However, the security team wants to enforce a restricted profile for most namespaces while allowing exceptions. The CISO has mandated that no pod should run as root, and all pods must have read-only root filesystem and privilege escalation disabled. Additionally, any pod that requires hostNetwork or hostPID must be explicitly approved and placed in a separate namespace. You need to design a solution that meets these requirements with minimal operational overhead. What is the best course of action?

A.Deploy OPA Gatekeeper and create constraints to enforce read-only root filesystem, no privilege escalation, and non-root user, with exceptions via label selectors

B.Keep the current 'privileged' profile and rely on runtime security tools like Falco to detect violations

C.Use PodSecurity admission with 'restricted' profile for most namespaces by labeling them with 'pod-security.kubernetes.io/enforce=restricted', and create a separate namespace with 'baseline' profile for legacy apps that require hostNetwork/hostPID, after reviewing and approving each exception

D.Change the PodSecurity profile to 'restricted' cluster-wide and require all legacy apps to be rewritten to not need hostNetwork/hostPID

AnswerC

This uses native Kubernetes features, enforces the mandates, and allows controlled exceptions.

Why this answer

Option C is correct because PodSecurity admission (PSA) is the native Kubernetes mechanism for enforcing pod security standards with minimal operational overhead. By labeling most namespaces with 'pod-security.kubernetes.io/enforce=restricted', you enforce the CISO's mandates (non-root, read-only root filesystem, no privilege escalation) automatically. Creating a separate namespace with the 'baseline' profile allows legacy apps requiring hostNetwork/hostPID to run after explicit approval, while still blocking privileged escalation and other dangerous capabilities.

Exam trap

CNCF often tests the misconception that OPA Gatekeeper is always required for fine-grained policy enforcement, when in fact PodSecurity admission with 'baseline' and 'restricted' profiles can handle common exceptions like hostNetwork/hostPID without additional tooling.

How to eliminate wrong answers

Option A is wrong because deploying OPA Gatekeeper introduces significant operational overhead (managing constraint templates, rego policies, and label selectors) when the native PodSecurity admission controller already meets the requirements with simpler namespace labeling. Option B is wrong because keeping the 'privileged' profile and relying on Falco for detection only alerts on violations after they occur, failing the CISO's mandate to prevent pods from running as root or with writable root filesystem. Option D is wrong because changing the profile to 'restricted' cluster-wide would block all legacy apps that need hostNetwork/hostPID, as the 'restricted' profile explicitly denies these settings, and rewriting all legacy apps is not a minimal-overhead solution.

Practice this question →

100

MCQmedium

A pod in namespace 'secure' has the following securityContext: securityContext: runAsNonRoot: true runAsUser: 1000 capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] The pod fails to start. The namespace is enforced with the 'restricted' Pod Security Standard. What is the most likely reason?

A.The pod adds capabilities, which is not allowed by the restricted policy.

B.The runAsUser is set to 1000, which is not allowed by the restricted policy.

C.The pod sets runAsNonRoot to true, which is not allowed by the restricted policy.

D.The pod drops all capabilities, which is not allowed by the restricted policy.

AnswerA

Restricted policy prohibits adding capabilities beyond the default set; NET_BIND_SERVICE is not allowed.

Why this answer

The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.

Exam trap

CNCF often tests the nuance that the restricted policy forbids adding any capabilities, even if they are considered 'safe' or commonly used, and candidates may mistakenly think that dropping all capabilities is the violation or that runAsUser: 1000 is the issue.

How to eliminate wrong answers

Option B is wrong because the restricted policy does allow runAsUser values, provided they are not 0 (root); 1000 is a non-root user and is permitted. Option C is wrong because runAsNonRoot: true is actually required by the restricted policy, not disallowed. Option D is wrong because dropping all capabilities is not only allowed but is a requirement of the restricted policy, which mandates dropping all capabilities and adding none.

Practice this question →

101

MCQmedium

A DevOps engineer wants to ensure that all pods in a namespace have seccomp set to RuntimeDefault unless explicitly overridden. Which approach should be used to enforce this?

A.Add a PodSecurityPolicy that sets seccomp to RuntimeDefault

B.Use a cronjob to audit and modify pods that do not have seccomp set

C.Add a seccomp profile to the kubelet configuration

D.Configure the namespace with the label 'pod-security.kubernetes.io/enforce: restricted'

AnswerD

This enables Pod Security Admission with the restricted level, which requires seccomp to be set to RuntimeDefault or Localhost.

Why this answer

Option D is correct because the 'restricted' Pod Security Standard enforces seccomp to RuntimeDefault as a baseline requirement. By labeling the namespace with 'pod-security.kubernetes.io/enforce: restricted', the built-in Pod Security Admission controller automatically rejects any pod that does not set seccomp to RuntimeDefault (or a custom profile), without needing a separate policy or manual auditing.

Exam trap

The trap here is that candidates confuse kubelet-level seccomp configuration (which affects the kubelet, not pods) with pod-level enforcement, or they mistakenly think deprecated PSPs are still a valid solution for seccomp enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, so it cannot be used in modern clusters; also, PSP does not natively enforce seccomp profiles by default. Option B is wrong because a cronjob that audits and modifies pods is reactive, not proactive, and violates the principle of enforcement—pods without seccomp would already be running before the cronjob acts. Option C is wrong because kubelet configuration sets a seccomp profile for the kubelet process itself, not for pods; pod seccomp is controlled via securityContext in the pod spec or admission controllers.

Practice this question →

102

MCQmedium

A pod manifest is shown. What security issue remains in this configuration?

A.The container runs as root (user 0)

B.The container has a writable root filesystem

C.The container has dangerous capabilities

D.The container can escalate privileges

AnswerB

There is no readOnlyRootFilesystem: true, so the root filesystem is writable, which is a security risk.

Why this answer

Option B is correct because the pod manifest does not set `readOnlyRootFilesystem: true` in the container's security context. Without this setting, the container's root filesystem is writable by default, allowing an attacker who compromises the container to modify binaries, configuration files, or write malicious scripts to persistent storage, thereby increasing the attack surface and potentially enabling persistence or privilege escalation.

Exam trap

The trap here is that candidates often assume the default security context is secure, but Cisco tests the specific omission of `readOnlyRootFilesystem: true` as a distinct hardening requirement, even when other settings like `runAsNonRoot: true` are present.

How to eliminate wrong answers

Option A is wrong because the question does not specify that the container runs as root; the manifest may not set `runAsUser: 0`, and even if it did, running as root is not inherently a security issue if other controls (like dropping capabilities and read-only rootfs) are in place. Option C is wrong because the manifest does not show any added capabilities; by default, containers run with a restricted set of capabilities, and dangerous capabilities like CAP_SYS_ADMIN are not present unless explicitly added. Option D is wrong because the manifest does not set `allowPrivilegeEscalation: true`; by default, this is false in Kubernetes 1.24+ and prevents processes from gaining more privileges than their parent, so no escalation risk is introduced by the manifest as shown.

Practice this question →

103

MCQmedium

A pod is running with a custom seccomp profile located at /var/lib/kubelet/seccomp/my-profile.json. Which securityContext configuration correctly applies this profile?

A.seccompProfile: { type: RuntimeDefault }

B.seccompProfile: { type: Localhost, localhostProfile: my-profile.json }

C.seccompProfile: { type: Localhost, localhostProfile: /var/lib/kubelet/seccomp/my-profile.json }

D.seccompProfile: { type: Unconfined }

AnswerB

Correct. 'type: Localhost' tells Kubernetes to use a local file, and 'localhostProfile' specifies the filename relative to /var/lib/kubelet/seccomp/.

Why this answer

Option B sets the seccomp type to Localhost and specifies the path relative to /var/lib/kubelet/seccomp/. Option A incorrectly uses 'localhostProfile' but the field name is 'localhostProfile'? Actually the correct field is 'localhostProfile' but the type should be Localhost. Option C uses RuntimeDefault, not custom.

Option D uses Unconfined, which disables seccomp.

Practice this question →

104

MCQmedium

Which of the following is the correct way to drop all Linux capabilities for a container?

A.capability: drop: ["ALL"]

B.capabilities: drop: ["NET_RAW", "CHOWN"]

C.capabilities: drop: ["ALL"]

D.capabilities: add: ["ALL"]

AnswerC

Correct field and value.

Why this answer

Option C is correct because in a Kubernetes Pod security context, the `capabilities` field is a list of capabilities to add or drop. Dropping `ALL` removes all Linux capabilities from the container, which is the most restrictive and secure approach. The correct YAML syntax uses `capabilities:` (plural) with a `drop:` list containing `"ALL"`.

Exam trap

CNCF often tests the distinction between singular `capability` and plural `capabilities` in the YAML field name, as well as the difference between `drop: ["ALL"]` and `add: ["ALL"]`, to catch candidates who misremember the exact syntax or confuse dropping with adding capabilities.

How to eliminate wrong answers

Option A is wrong because it uses `capability:` (singular) instead of the correct `capabilities:` (plural) field name in the Pod security context. Option B is wrong because it drops only specific capabilities (`NET_RAW` and `CHOWN`) rather than all capabilities, which does not achieve the goal of dropping all Linux capabilities. Option D is wrong because it adds `ALL` capabilities, which grants every capability to the container, the opposite of what is required.

Practice this question →

105

MCQeasy

Which command is used to load an AppArmor profile into the kernel?

A.aa-status

B.apparmor_parser

C.aa-load

D.aa-enforce

AnswerB

apparmor_parser is the utility to load profiles into the kernel.

Why this answer

The 'apparmor_parser' command is used to load AppArmor profiles into the kernel. Options A and C are not valid AppArmor commands. Option D is used to check status.

Practice this question →

106

MCQmedium

An admin runs 'kubectl describe pod secure-pod' and sees 'seccompProfile: RuntimeDefault' under the container's security context. Which seccomp profile is being used?

A.A custom seccomp profile from '/var/lib/kubelet/seccomp/' is used

B.The container runtime's default seccomp profile is applied

C.The container runtime's seccomp profile is set to 'Unconfined'

D.Seccomp is disabled for this container

AnswerB

'RuntimeDefault' instructs the runtime to use its default seccomp profile.

Why this answer

When `seccompProfile` is set to `RuntimeDefault` in a container's security context, Kubernetes instructs the container runtime (e.g., containerd, CRI-O) to apply its own default seccomp profile. This profile is typically a restrictive set of syscalls that blocks dangerous or unnecessary system calls while allowing common operations. It is not a custom profile from the node's filesystem, nor does it disable seccomp or set it to unconfined.

Exam trap

The trap here is that candidates confuse `RuntimeDefault` with a custom profile stored on the node's filesystem, or mistakenly think it disables seccomp entirely, when in fact it instructs the runtime to apply its own pre-configured default seccomp filter.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` does not reference a custom profile from `/var/lib/kubelet/seccomp/`; that path is used for `Localhost` profiles only. Option C is wrong because `RuntimeDefault` explicitly applies the runtime's default profile, not `Unconfined`, which would disable seccomp entirely. Option D is wrong because `RuntimeDefault` means seccomp is enabled and enforced by the runtime's default rules, not disabled.

Practice this question →

107

MCQeasy

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

A.seccomp.security.alpha.kubernetes.io/pod

B.apparmor.security.beta.kubernetes.io/profile

C.container.apparmor.security.beta.kubernetes.io/<container_name>

D.container.apparmor.kubernetes.io/<container_name>

AnswerC

This annotation is the correct way to set an AppArmor profile per container.

Why this answer

The annotation 'container.apparmor.security.beta.kubernetes.io/<container_name>' is used to specify the AppArmor profile for a container. The other options are either non-existent or used for other purposes (e.g., seccomp).

Practice this question →

108

MCQmedium

A security auditor wants to verify that the AppArmor profile 'my-profile' is in enforce mode on a running container. Which command should they run inside the node?

A.cat /proc/<pid>/attr/current

B.dmesg | grep apparmor

C.apparmor_parser -r my-profile

D.cat /proc/<pid>/environ

AnswerA

Correct. This file shows the AppArmor mode (enforce, complain, unconfined) for the process.

Why this answer

Option C: cat /proc/<pid>/attr/current shows the AppArmor confinement status. Option A shows the system log, not current confinement. Option B shows the loaded profile definition.

Option D shows the process environment.

Practice this question →

109

MCQeasy

Which annotation is used to apply an AppArmor profile named 'custom-profile' to a container named 'app' in a pod?

A.apparmor.security.beta.kubernetes.io/container.app: localhost/custom-profile

B.security.beta.kubernetes.io/apparmor: localhost/custom-profile

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

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

AnswerD

This is the correct annotation format to apply an AppArmor profile to a specific container.

Why this answer

Option D is correct because the annotation for applying an AppArmor profile to a specific container in a pod follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation targets the container named 'app' with the profile 'custom-profile', which is loaded locally on the node.

Exam trap

The trap here is that candidates confuse the annotation prefix order (e.g., `apparmor.security.beta.kubernetes.io` vs. `container.apparmor.security.beta.kubernetes.io`) or mistakenly use a pod-level annotation instead of the correct container-level annotation.

How to eliminate wrong answers

Option A is wrong because the prefix `apparmor.security.beta.kubernetes.io/container.app` is incorrect; the correct prefix is `container.apparmor.security.beta.kubernetes.io`. Option B is wrong because `security.beta.kubernetes.io/apparmor` is a generic annotation that does not specify a container name, and it is not the correct format for per-container AppArmor profiles. Option C is wrong because `pod.apparmor.security.beta.kubernetes.io/app` uses a `pod.` prefix, which is not a valid annotation; AppArmor annotations are per-container, not per-pod.

Practice this question →

110

MCQmedium

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

A.annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

B.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }

C.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

D.annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }

AnswerC

Correct format.

Why this answer

Option C is correct because the AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Exam trap

CNCF often tests the distinction between the `container.` prefix for per-container annotations versus the deprecated pod-level annotation, and the mandatory `localhost/` prefix for locally loaded profiles, causing candidates to omit one or both.

How to eliminate wrong answers

Option A is wrong because it uses the deprecated `apparmor.security.beta.kubernetes.io/app` annotation format (without the `container.` prefix), which is not the correct way to apply a profile to a specific container. Option B is wrong because it omits the required `localhost/` prefix in the profile value, which would cause the profile to be treated as an unqualified name and likely fail to load. Option D is wrong because it uses the `seccomp` annotation (`container.seccomp.security.beta.kubernetes.io/`) instead of the AppArmor annotation, which is a completely different security mechanism.

Practice this question →

111

MCQmedium

An administrator creates a custom seccomp profile and places it at /var/lib/kubelet/seccomp/myprofile.json. Which securityContext field is used to apply this profile to a container?

A.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/myprofile.json"

B.seccompProfile: type: Localhost localhostProfile: "myprofile.json"

C.seccompProfile: type: RuntimeDefault localhostProfile: "myprofile.json"

D.seccompProfile: type: Unconfined localhostProfile: "myprofile.json"

AnswerB

Correct. This references the custom profile.

Why this answer

The seccompProfile field under securityContext with type: Localhost and localhostProfile: "myprofile.json" applies the custom profile.

Practice this question →

112

MCQhard

You have built a custom seccomp profile at /var/lib/kubelet/seccomp/audit.json. Which YAML snippet correctly applies this profile to a container?

A.securityContext: seccompProfile: type: RuntimeDefault

B.securityContext: seccompProfile: type: Localhost localhostProfile: "profiles/audit.json"

C.securityContext: seccomp: type: Localhost profile: "audit.json"

D.securityContext: seccompProfile: type: Localhost localhostProfile: "audit.json"

AnswerB

The profile is stored in /var/lib/kubelet/seccomp/profiles/audit.json. The relative path from the seccomp directory is 'profiles/audit.json'.

Practice this question →

113

Multi-Selecthard

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Select 2 answers

A.Enable the NodeRestriction admission controller

B.Set --anonymous-auth=true to allow all users

C.Enable audit logging to detect unauthorized attempts

D.Disable all authentication mechanisms and rely on network policies

E.Configure the API server to use TLS certificates for client authentication

AnswersA, E

Limits what nodes can modify, reducing attack surface.

Why this answer

The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Exam trap

CNCF often tests the distinction between preventive controls (like admission controllers and authentication) and detective controls (like audit logging), so candidates mistakenly select audit logging as a hardening measure when it only detects, not prevents, unauthorized access.

Practice this question →

114

MCQhard

An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?

A.SYS_ADMIN, SYS_MODULE, SYS_PTRACE

B.CHOWN, DAC_OVERRIDE, FOWNER

C.KILL, SETPCAP, SYS_CHROOT

D.NET_RAW, NET_ADMIN, NET_BIND_SERVICE

AnswerA

These capabilities allow kernel module loading, system administration, and process tracing, which can be exploited for escape.

Why this answer

Option A is correct because SYS_ADMIN, SYS_MODULE, and SYS_PTRACE are the most dangerous capabilities that enable container escape. SYS_ADMIN grants broad administrative privileges (e.g., mounting filesystems, accessing /proc/1/environ), SYS_MODULE allows loading kernel modules, and SYS_PTRACE permits tracing processes outside the container. Dropping these three capabilities is a key mitigation against kernel-level escapes.

Exam trap

CNCF often tests the misconception that all capabilities are equally dangerous, but the trap here is that candidates may choose networking or file capabilities (options B, C, D) because they sound security-relevant, while the actual escape vector relies on the three kernel-focused capabilities in option A.

How to eliminate wrong answers

Option B is wrong because CHOWN, DAC_OVERRIDE, and FOWNER are file permission capabilities that control ownership and access control, not kernel-level escape vectors; they are less critical for preventing container escapes. Option C is wrong because KILL, SETPCAP, and SYS_CHROOT are not primary escape enablers: KILL sends signals, SETPCAP manages capability sets, and SYS_CHROOT is a legacy syscall that is already restricted by default in modern runtimes. Option D is wrong because NET_RAW, NET_ADMIN, and NET_BIND_SERVICE are networking capabilities that affect packet crafting and interface configuration, not direct kernel access or module loading.

Practice this question →

115

Multi-Selecthard

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Select 3 answers

A.Disable unnecessary system services on nodes

B.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)

C.Open all ports on nodes to allow easy debugging

D.Run all containers as root user

E.Apply Pod Security Standards to enforce least privilege

AnswersA, B, E

Reduces attack surface by removing unused services.

Why this answer

Disabling unnecessary services (e.g., SSH if not needed), minimizing host access from containers (avoid hostPID, hostNetwork, hostIPC), and using Pod Security Standards to enforce least privilege are all effective hardening measures. Running containers as root is not recommended, and opening all ports increases the attack surface.

Practice this question →

116

Multi-Selecteasy

Which TWO of the following are valid modes for an AppArmor profile?

Select 2 answers

A.unconfined

B.complain

C.enforce

D.permissive

E.audit

AnswersB, C

In complain mode, violations are logged but not blocked.

Why this answer

AppArmor profiles operate in two primary modes: 'complain' (also known as 'learning' mode) and 'enforce' (also known as 'confined' mode). In complain mode, policy violations are logged but not blocked, allowing administrators to test and refine profiles. In enforce mode, violations are both logged and blocked, actively restricting the application's behavior according to the profile.

Exam trap

CNCF often tests the distinction between AppArmor and SELinux terminology, where candidates mistakenly apply SELinux concepts (like 'permissive' or 'enforcing') to AppArmor, which uses 'complain' and 'enforce' as its only two valid modes.

Practice this question →

117

Multi-Selectmedium

Which TWO of the following are valid Pod Security Standards levels?

Select 2 answers

A.secure

B.default

C.privileged

D.baseline

E.strict

AnswersC, D

Valid level.

Why this answer

The three Pod Security Standard levels are privileged, baseline, and restricted. The other options are not valid.

Practice this question →

118

MCQeasy

To reduce the attack surface, a security best practice is to drop all capabilities from a container and add only those required. Which securityContext field is used to drop all capabilities?

A.capabilities.disable: ["ALL"]

B.capabilities.remove: ["ALL"]

C.capabilities.drop: ["ALL"]

D.privileged: false

AnswerC

This correctly drops all capabilities from the container.

Why this answer

In Kubernetes, the `capabilities.drop` field in the securityContext is used to explicitly remove Linux capabilities from a container. Setting `capabilities.drop: ["ALL"]` drops all capabilities, effectively reducing the attack surface by ensuring the container starts with no privileges, and then specific capabilities can be added back via `capabilities.add` if needed.

Exam trap

CNCF often tests the exact Kubernetes API field name `capabilities.drop` versus common but incorrect synonyms like `disable` or `remove`, and candidates may confuse dropping all capabilities with simply disabling privileged mode.

How to eliminate wrong answers

Option A is wrong because `capabilities.disable` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option B is wrong because `capabilities.remove` is not a recognized field in the Kubernetes API; the field is specifically named `drop`. Option D is wrong because `privileged: false` only disables privileged mode, but the container still retains its default set of capabilities; it does not drop all capabilities.

Practice this question →

119

MCQhard

An administrator wants to ensure that containers in a pod cannot run with any Linux capabilities except the minimal required for the container runtime. The pod is subject to the 'restricted' Pod Security Standard. Which capability configuration should be set in the pod's security context?

A.capabilities: drop: ["ALL"]

B.capabilities: drop: ["NET_RAW", "CHOWN"]

C.capabilities: add: ["NET_BIND_SERVICE"]

D.capabilities: add: ["ALL"]

AnswerA

Under the restricted profile, you must drop all capabilities. Adding capabilities is not allowed.

Why this answer

The 'restricted' Pod Security Standard (PSS) requires that all Linux capabilities be dropped except those essential for the container runtime (e.g., CAP_NET_BIND_SERVICE is allowed by default in some runtimes, but the standard explicitly mandates dropping all capabilities). Option A correctly uses `drop: ["ALL"]` to remove every capability, ensuring the container runs with the minimal set required by the runtime, which aligns with the PSS 'restricted' profile. This approach enforces the principle of least privilege by preventing the container from gaining any unnecessary kernel privileges.

Exam trap

CNCF often tests the misconception that dropping only specific dangerous capabilities (like `NET_RAW` and `CHOWN`) is sufficient for the 'restricted' PSS, when in fact the standard requires dropping all capabilities to achieve the minimal privilege level.

How to eliminate wrong answers

Option B is wrong because dropping only `NET_RAW` and `CHOWN` does not satisfy the 'restricted' PSS requirement to drop all capabilities; it leaves other potentially dangerous capabilities (e.g., `SYS_ADMIN`, `NET_ADMIN`) intact, violating the standard. Option C is wrong because adding `NET_BIND_SERVICE` is unnecessary and contradicts the 'restricted' PSS, which expects no capabilities to be added; the runtime already provides minimal capabilities, and explicit adds can introduce privileges beyond the allowed set. Option D is wrong because adding `ALL` capabilities grants every Linux capability to the container, which directly violates the 'restricted' PSS and defeats the purpose of capability dropping, creating a severe security risk.

Practice this question →

120

MCQmedium

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

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

B.Leave capabilities unset to use the default set

C.Add only the necessary capabilities without dropping

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

AnswerD

Correct. Drop all default capabilities and add only those needed reduces the attack surface.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

121

Multi-Selectmedium

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

Select 2 answers

A.Setting the annotation 'seccomp.security.alpha.kubernetes.io/pod' on the pod

B.Using 'securityContext.seccompProfile.type: RuntimeDefault' with 'localhostProfile' set

C.Configuring the kubelet with --seccomp-default-profile flag

D.Using 'securityContext.seccompProfile.type: Localhost' with 'localhostProfile' set

E.Adding a seccomp profile to the container image and referencing it in the pod spec

AnswersA, D

This is a valid (though deprecated) method.

Why this answer

Option A is correct because the annotation 'seccomp.security.alpha.kubernetes.io/pod' was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to 1.19. This annotation is still valid in older clusters or when using the alpha API, and it directly specifies the seccomp profile path or type for the pod.

Exam trap

CNCF often tests the distinction between the deprecated annotation method and the current 'securityContext.seccompProfile' field, and the trap here is that candidates may think 'localhostProfile' can be combined with 'RuntimeDefault' or that profiles can be embedded in container images, which is incorrect.

Practice this question →

122

MCQmedium

Which of the following is NOT a recommended method to reduce the attack surface on Kubernetes nodes?

A.Using read-only root filesystems

B.Running containers as non-root

C.Running containers with privileged: true

D.Disabling unnecessary system services on nodes

AnswerC

Privileged containers have elevated capabilities, increasing attack surface.

Why this answer

Running containers with privileged access increases the attack surface. The other options are recommended hardening measures.

Practice this question →

123

MCQmedium

A cluster has PodSecurity admission enabled. A developer creates a pod with the following security context: 'securityContext: { capabilities: { drop: ["ALL"], add: ["NET_ADMIN"] } }'. The namespace is labeled 'pod-security.kubernetes.io/enforce: baseline'. Will the pod be allowed?

A.No, because baseline requires dropping ALL first

B.Yes, because the pod drops all capabilities before adding specific ones

C.No, because dropping ALL capabilities is not allowed by baseline

D.Yes, because the baseline policy allows adding NET_ADMIN

AnswerD

Baseline allows NET_ADMIN to be added.

Why this answer

Option D is correct because the Pod Security Standards (PSS) baseline policy explicitly allows adding the NET_ADMIN capability. The baseline policy restricts certain capabilities but does not prohibit adding NET_ADMIN; it only restricts capabilities that could lead to host-level privilege escalation. Dropping ALL capabilities first and then adding NET_ADMIN is a valid pattern that satisfies the baseline policy's requirements.

Exam trap

The trap here is that candidates assume 'baseline' is more restrictive than it actually is, or they confuse the 'restricted' policy's capability restrictions with the 'baseline' policy, leading them to incorrectly think NET_ADMIN is forbidden.

How to eliminate wrong answers

Option A is wrong because baseline does not require dropping ALL capabilities first; it only restricts a specific set of capabilities (e.g., CAP_SYS_ADMIN, CAP_NET_RAW) but allows others like NET_ADMIN. Option B is wrong because while the pod does drop ALL and then add NET_ADMIN, the reason it is allowed is not simply because of that order but because NET_ADMIN is permitted by baseline. Option C is wrong because dropping ALL capabilities is not prohibited by baseline; in fact, dropping ALL is a common security hardening practice and is allowed.

Practice this question →

124

MCQeasy

Which kubectl command is used to check the AppArmor status on a Kubernetes node?

A.kubectl describe node <node> | grep AppArmor

B.kubectl get apparmor

C.kubectl node-shell <node> -- aa-status

D.kubectl exec <pod> -- aa-status

AnswerC

Using 'kubectl node-shell' (or similar) to run 'aa-status' on the node is correct.

Why this answer

Option C is correct because `kubectl node-shell` provides a shell into the node's filesystem, allowing you to run `aa-status` directly on the node to check the AppArmor status. This is the standard method to verify AppArmor profiles and their enforcement state on a Kubernetes node, as AppArmor operates at the host kernel level and is not managed via the Kubernetes API.

Exam trap

The trap here is that candidates assume AppArmor status can be checked via standard Kubernetes API commands like `kubectl describe node` or `kubectl get`, when in reality it requires direct node-level access because AppArmor is a host-level security mechanism not abstracted by the Kubernetes API.

How to eliminate wrong answers

Option A is wrong because `kubectl describe node <node> | grep AppArmor` only shows the AppArmor annotations on the node object (like whether a pod requests a profile), not the actual AppArmor status or loaded profiles on the node. Option B is wrong because `kubectl get apparmor` is not a valid kubectl command; AppArmor is not a Kubernetes resource and cannot be queried via the API. Option D is wrong because `kubectl exec <pod> -- aa-status` runs the command inside a container, which typically lacks the necessary privileges and access to the host's AppArmor subsystem; `aa-status` must be executed on the node itself.

Practice this question →

125

MCQeasy

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

A.hostNetwork: true

B.hostPID: true

C.hostIPC: true

D.hostPID: false

AnswerD

Setting hostPID to false disables access to host processes, reducing attack surface.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

126

MCQhard

After deploying a pod with an AppArmor profile, the pod status shows 'ContainerCreating' for a long time and then fails. What is the most likely cause?

A.The AppArmor profile is not in the same namespace as the pod

B.The AppArmor profile is not loaded on the node

C.The pod's securityContext does not have 'apparmor: enabled'

D.The node does not support AppArmor

AnswerB

The container runtime checks for the profile; if missing, it fails to start.

Why this answer

If the AppArmor profile specified in the annotation is not loaded on the node, the container runtime will fail to start the container. Option A is correct. Option B is incorrect because the profile does not need to be in the same namespace.

Option C is incorrect because AppArmor profiles do not require a specific security context setting beyond the annotation. Option D is incorrect because the node must have AppArmor enabled.

Practice this question →

127

Multi-Selectmedium

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

Select 2 answers

A.kill

B.complain

C.enforce

D.audit

E.permissive

AnswersB, C

Complain mode logs violations but does not enforce.

Why this answer

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

Exam trap

CNCF often tests the distinction between AppArmor and SELinux modes, so the trap here is that candidates confuse SELinux's 'permissive' and 'enforcing' modes with AppArmor's 'complain' and 'enforce' modes, or incorrectly assume 'audit' or 'kill' are valid AppArmor profile modes.

Practice this question →

128

Multi-Selectmedium

Which TWO of the following are valid AppArmor profile modes?

Select 2 answers

A.complain

B.audit

C.enforce

D.unconfined

E.allow

AnswersA, C

Valid mode.

Why this answer

AppArmor has three modes: enforce (block violations), complain (log violations), and unconfined (no restrictions). Allow and audit are not modes.

Practice this question →

129

Multi-Selectmedium

A security auditor reviews a Kubernetes cluster and finds that several nodes have container runtimes with default configurations. Which TWO of the following actions should be taken to harden the container runtime?

Select 2 answers

A.Set readOnlyRootFilesystem in pod security contexts

B.Enable AppArmor profiles on the nodes

C.Set --no-new-privileges flag in the container runtime configuration

D.Configure Seccomp profiles to allow only necessary syscalls

E.Disable swap on all nodes

AnswersB, D

AppArmor restricts container processes to a minimal set of capabilities.

Why this answer

Option B is correct because enabling AppArmor profiles on nodes enforces mandatory access control (MAC) on container processes, restricting them to only the resources they need. This hardens the container runtime by confining containers beyond the default, often permissive, runtime configuration. AppArmor profiles are a key security mechanism for system hardening in Kubernetes.

Exam trap

CNCF often tests the distinction between pod-level security contexts (like readOnlyRootFilesystem) and node-level runtime hardening (like AppArmor or Seccomp), causing candidates to confuse pod security with runtime security.

Practice this question →

130

MCQmedium

A pod has the following security context: capabilities: { drop: ['ALL'] } and privileged: false. The pod fails to start because it requires the ability to run iptables commands. Which of the following should be added to the pod's security context?

A.privileged: true

B.capabilities: { add: ['SYS_ADMIN'] }

C.capabilities: { drop: ['NET_ADMIN'] }

D.capabilities: { add: ['NET_ADMIN'] }

AnswerD

NET_ADMIN is the capability required for iptables operations.

Why this answer

The pod needs to run iptables commands, which require the NET_ADMIN capability. Since the security context drops ALL capabilities, you must explicitly add NET_ADMIN back. Option D correctly adds NET_ADMIN, granting the necessary network administration privileges without making the container fully privileged.

Exam trap

The trap here is that candidates often confuse SYS_ADMIN with NET_ADMIN, assuming that broad system administration privileges are needed for network tools, when in fact iptables specifically requires the NET_ADMIN capability.

How to eliminate wrong answers

Option A is wrong because setting privileged: true grants all capabilities and disables most security mechanisms, which is excessive and violates the principle of least privilege. Option B is wrong because SYS_ADMIN is a broad capability that provides many system administration privileges (e.g., mount, namespace operations) but does not specifically include the ability to manipulate network filtering rules via iptables; iptables requires NET_ADMIN, not SYS_ADMIN. Option C is wrong because it drops NET_ADMIN, which is the exact capability needed to run iptables; this would prevent the pod from starting successfully.

Practice this question →

131

MCQhard

An administrator wants to reduce the attack surface of a Kubernetes node by disabling unnecessary system services. Which of the following services is considered unnecessary on a dedicated Kubernetes worker node and can be safely disabled?

A.containerd

B.sshd

C.cups

D.kubelet

AnswerC

CUPS (Common Unix Printing System) is unnecessary on a Kubernetes worker node.

Why this answer

Option C (cups) is correct because CUPS (Common Unix Printing System) is a print service that is unnecessary on a dedicated Kubernetes worker node, which does not require printing capabilities. Disabling it reduces the attack surface by removing a potential vector for privilege escalation or remote exploitation, as CUPS historically has had vulnerabilities like CVE-2024-35235. On a worker node, only essential services for container runtime, orchestration, and system management should run.

Exam trap

The trap here is that candidates may think sshd is unnecessary because Kubernetes nodes are managed via kubectl, but in practice, SSH access is critical for node-level troubleshooting, kernel updates, and emergency recovery, making it a required service unless a secure alternative like a serial console is in place.

How to eliminate wrong answers

Option A is wrong because containerd is the container runtime interface (CRI) implementation that manages container lifecycles on the node; disabling it would prevent the kubelet from running pods, making the node non-functional. Option B is wrong because sshd (SSH daemon) is typically required for secure remote administration, troubleshooting, and compliance auditing; while it can be restricted via firewall or SSH keys, it is not considered unnecessary on a worker node unless a dedicated bastion host or out-of-band management is used. Option D is wrong because kubelet is the primary node agent that communicates with the control plane, manages pod lifecycle, and reports node status; disabling it would effectively remove the node from the cluster.

Practice this question →

132

MCQhard

A cluster administrator wants to apply a custom seccomp profile located at '/var/lib/kubelet/seccomp/audit.json' to a pod. Which YAML snippet correctly configures the pod's security context to use this profile?

A.seccompProfile: type: Localhost localhostProfile: audit.json

B.seccompProfile: type: Unconfined localhostProfile: audit.json

C.seccompProfile: type: Localhost localhostProfile: /var/lib/kubelet/seccomp/audit.json

D.seccompProfile: type: RuntimeDefault localhostProfile: audit.json

AnswerA

Correct: type is Localhost and localhostProfile is just the filename.

Why this answer

Option A is correct because when using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` must specify only the filename (not the full path). Kubernetes automatically prepends the path `/var/lib/kubelet/seccomp/` to the filename, so `audit.json` resolves to the correct location.

Exam trap

CNCF often tests the misconception that `localhostProfile` requires the full filesystem path, when in fact only the filename is needed because Kubernetes prepends the kubelet's seccomp root directory.

How to eliminate wrong answers

Option B is wrong because `type: Unconfined` disables seccomp entirely and ignores the `localhostProfile` field, so the custom profile would not be applied. Option C is wrong because `localhostProfile` must be just the filename (e.g., `audit.json`), not the full path `/var/lib/kubelet/seccomp/audit.json`; Kubernetes appends the path from the kubelet's `--seccomp-default-profile` directory, and using the full path would cause a lookup failure. Option D is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile (e.g., Docker's default), not a custom local profile, and the `localhostProfile` field is ignored when type is not `Localhost`.

Practice this question →

133

MCQeasy

Which Linux capability must be added to a container to allow it to change the system time (e.g., using the 'date' command)?

A.CAP_SYS_NICE

B.CAP_SYS_RESOURCE

C.CAP_SYS_ADMIN

D.CAP_SYS_TIME

AnswerD

CAP_SYS_TIME allows setting the system clock and real-time clock.

Why this answer

The `CAP_SYS_TIME` capability is specifically required for a container to modify the system clock, including using the `date` command to set the time. Without this capability, the container's process will receive an EPERM error when attempting to change the system time, as the kernel enforces this restriction at the system call level (e.g., `settimeofday`, `clock_settime`).

Exam trap

CNCF often tests the distinction between `CAP_SYS_ADMIN` (a catch-all for many privileged operations) and `CAP_SYS_TIME` (the specific capability for clock manipulation), leading candidates to incorrectly select `CAP_SYS_ADMIN` because they assume it covers all system administration tasks.

How to eliminate wrong answers

Option A is wrong because `CAP_SYS_NICE` allows a process to raise or lower the nice value of other processes and set real-time scheduling priorities, but it does not grant permission to modify the system clock. Option B is wrong because `CAP_SYS_RESOURCE` controls resource limits (e.g., `setrlimit`, `setpriority`) and disk quota overrides, not time-setting operations. Option C is wrong because `CAP_SYS_ADMIN` is a broad capability that includes many privileged operations (e.g., `mount`, `swapon`, `setdomainname`), but changing the system time is specifically gated by `CAP_SYS_TIME`, not `CAP_SYS_ADMIN`; using `CAP_SYS_ADMIN` for this purpose would be an overprivilege and is not the correct capability.

Practice this question →

134

MCQhard

A pod is in a Pending state with the event: 'failed to generate spec: failed to validate seccomp profile: seccomp profile not found'. The profile is stored at /var/lib/kubelet/seccomp/custom.json on the node. Which of the following is the MOST likely cause?

A.The profile name is misspelled in the pod specification

B.The localhostProfile field contains an absolute path instead of a relative one

C.The node does not have seccomp enabled in the kubelet

D.The seccomp profile JSON is malformed

AnswerB

Correct. Kubernetes expects a relative path. Using an absolute path causes it to look for the file in an incorrect location.

Why this answer

The error 'seccomp profile not found' indicates the kubelet cannot locate the profile file. In Kubernetes, when using a seccomp profile stored on the node, the `localhostProfile` field must specify a relative path from the kubelet's seccomp root directory (default `/var/lib/kubelet/seccomp`). An absolute path like `/var/lib/kubelet/seccomp/custom.json` causes the kubelet to look for the file at that exact absolute path, but the seccomp validation logic expects a relative path and prepends the root, leading to a 'not found' error.

Exam trap

CNCF often tests the nuance that `localhostProfile` requires a relative path, not an absolute one, and candidates mistakenly think any valid filesystem path works or confuse this with container runtime seccomp paths.

How to eliminate wrong answers

Option A is wrong because a misspelled profile name would cause a different error (e.g., 'no such file or directory') but the error message explicitly says 'profile not found', not 'invalid name' or 'no such file'. Option C is wrong because if seccomp were not enabled in the kubelet, the pod would fail with a different error like 'seccomp is not enabled' or the pod would be rejected at admission, not with a 'profile not found' event. Option D is wrong because a malformed JSON would produce a 'failed to validate seccomp profile' error with details about parsing failure, not a 'not found' error.

Practice this question →

135

MCQmedium

An administrator creates a custom seccomp profile and wants to apply it to a pod. The profile file is named 'audit.json' and is placed in the default seccomp directory on the node. Which securityContext field should be used?

A.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json

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

C.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json

D.seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json

AnswerC

This is the correct way to specify a custom localhost seccomp profile in v1.29+.

Why this answer

In Kubernetes v1.29+, the seccomp profile is specified via 'securityContext.seccompProfile.type: Localhost' and 'securityContext.seccompProfile.localhostProfile: "audit.json"'. The default directory for localhost profiles is /var/lib/kubelet/seccomp/. Options A and B are incorrect because they use the old annotation-based approach or wrong field names.

Practice this question →

136

MCQeasy

Which of the following fields in a PodSecurityPolicy (or Pod Security Standards) prevents a container from running as root?

A.runAsUser: RunAsAny

B.runAsGroup: MustRunAsNonRoot

C.runAsUser: MustRunAsNonRoot

D.seLinuxContext: MustRunAsNonRoot

AnswerC

This rule requires containers to run as non-root user.

Why this answer

Option C is correct because `runAsUser: MustRunAsNonRoot` in a PodSecurityPolicy (or the equivalent Pod Security Standard `restricted` profile) enforces that the container's user ID (UID) must not be 0 (root). This directly prevents the container from running as root, as the security context will reject any pod that specifies `runAsUser: 0` or omits the field when the policy requires a non-root user.

Exam trap

CNCF often tests the distinction between `runAsUser` and `runAsGroup`, where candidates mistakenly think setting `runAsGroup: MustRunAsNonRoot` prevents root execution, but it only restricts the group ID, not the user ID.

How to eliminate wrong answers

Option A is wrong because `runAsUser: RunAsAny` allows any user ID, including root (UID 0), so it does not prevent running as root. Option B is wrong because `runAsGroup: MustRunAsNonRoot` controls the group ID (GID), not the user ID; a container can still run as root (UID 0) even if its group is non-root. Option D is wrong because `seLinuxContext: MustRunAsNonRoot` is not a valid SELinux context option; SELinux contexts use `MustRunAs`, `RunAsAny`, or `MustRunAs` with a range, and `MustRunAsNonRoot` does not exist in the SELinux context field.

Practice this question →

137

MCQhard

A custom seccomp profile is defined as follows: { "defaultAction": "SCMP_ACT_ALLOW", "architectures": ["SCMP_ARCH_X86_64"], "syscalls": [ { "names": ["mkdir", "chmod"], "action": "SCMP_ACT_ERRNO" } ] } The profile is placed at /var/lib/kubelet/seccomp/deny-mkdir.json. Which pod securityContext configuration correctly applies this profile?

A.annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/deny-mkdir"

B.seccompProfile: type: Localhost localhostProfile: "deny-mkdir.json"

C.seccompProfile: type: localhost localhostProfile: "deny-mkdir.json"

D.seccompProfile: type: RuntimeDefault

AnswerB

This correctly references the local profile file.

Why this answer

Option B is correct because in Kubernetes, the `seccompProfile` field in the pod or container security context uses the `type: Localhost` (case-sensitive) and `localhostProfile` specifies the filename relative to the kubelet's seccomp root directory (`/var/lib/kubelet/seccomp/`). The profile file `deny-mkdir.json` is placed at that path, so `localhostProfile: "deny-mkdir.json"` correctly references it. This configuration blocks `mkdir` and `chmod` syscalls while allowing all others, as defined by the custom profile.

Exam trap

CNCF often tests the case-sensitivity of `type: Localhost` (capital 'L') versus the incorrect lowercase `localhost`, and the distinction between the deprecated annotation-based approach and the current `seccompProfile` field in the security context.

How to eliminate wrong answers

Option A is wrong because it uses the legacy annotation `seccomp.security.alpha.kubernetes.io/pod`, which was deprecated in Kubernetes v1.19 and removed in v1.25; the current stable API uses the `seccompProfile` field in the security context. Option C is wrong because `type: localhost` is not valid — the correct value is `type: Localhost` with a capital 'L' (case-sensitive). Option D is wrong because `type: RuntimeDefault` applies the container runtime's default seccomp profile (e.g., Docker's default), not the custom `deny-mkdir.json` profile stored on the node.

Practice this question →

138

MCQmedium

An administrator wants to enforce the Pod Security Standard 'restricted' for all pods in the 'secure' namespace. Which kubectl command correctly enables the PodSecurity admission controller for that namespace?

A.kubectl annotate ns secure pod-security.kubernetes.io/enforce=restricted

B.kubectl label ns secure pod-security.kubernetes.io/enforce=restricted

C.kubectl label ns secure pod-security.kubernetes.io/enforce-version=restricted

D.kubectl label ns secure pod-security.kubernetes.io/audit=restricted

AnswerB

This sets the enforce level to restricted on the namespace, causing admission to reject pods that violate the restricted policy.

Why this answer

Option B is correct because the Pod Security Standards are enforced on namespaces using the `pod-security.kubernetes.io/enforce` label set to the desired policy level (e.g., `restricted`). The `kubectl label` command applies this label to the namespace, which triggers the PodSecurity admission controller to enforce the restricted policy on all pods created in that namespace.

Exam trap

The trap here is confusing labels with annotations or mixing up the `enforce`, `audit`, and `warn` modes, leading candidates to choose an annotation or the wrong label key for enforcement.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards are configured via labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be a label for the admission controller to recognize it. Option C is wrong because `enforce-version` is a separate label used to pin a specific version of the policy (e.g., `v1.24`), not to set the enforcement level; setting it to `restricted` is invalid. Option D is wrong because the `audit` label only enables audit-level logging of policy violations without enforcing them; the question specifically asks to enforce the restricted standard.

Practice this question →

139

MCQmedium

A pod spec includes the following securityContext: securityContext: seccompProfile: type: Localhost localhostProfile: custom-profile.json Where should the custom seccomp profile 'custom-profile.json' be placed on the node?

A./etc/seccomp/

B./etc/kubernetes/seccomp/

C./var/lib/kubelet/seccomp/profiles/

D./var/lib/kubelet/seccomp/

AnswerD

This is the default directory where kubelet looks for localhost seccomp profiles.

Why this answer

The default directory for localhost seccomp profiles is /var/lib/kubelet/seccomp/. The profile file must be located there.

Practice this question →

140

MCQmedium

A cluster administrator wants to enforce that all pods in the 'restricted' namespace use the Restricted Pod Security Standard. Which command achieves this?

A.kubectl annotate ns restricted pod-security.kubernetes.io/restricted=restricted

B.kubectl label ns restricted pod-security.kubernetes.io/enforce=privileged

C.kubectl create podsecuritypolicy restricted --namespace restricted

D.kubectl label ns restricted pod-security.kubernetes.io/enforce=restricted

AnswerD

This correctly labels the namespace with the 'enforce' level set to 'restricted'.

Practice this question →

141

MCQmedium

During a security audit, it was found that some pods have access to the host network. How can an administrator restrict host network access for all pods in the cluster?

A.Set --allow-privileged=false in kubelet configuration

B.Enable PodSecurity admission controller with baseline or restricted profile

C.Enable PodSecurityPolicy with 'hostNetwork: false'

D.Create NetworkPolicies that deny traffic to host network

AnswerB

The baseline and restricted profiles forbid host networking, effectively restricting it cluster-wide.

Why this answer

Option B is correct because the PodSecurity admission controller (GA in Kubernetes v1.25+) enforces predefined security standards (baseline or restricted) that, among other restrictions, prevent pods from using `hostNetwork: true`. This is the recommended replacement for the deprecated PodSecurityPolicy and provides a built-in, cluster-wide mechanism to restrict host network access without requiring external tools.

Exam trap

CNCF often tests the deprecation of PodSecurityPolicy (PSP) and expects candidates to know that the PodSecurity admission controller is the current and correct replacement, not the legacy PSP or network-level controls like NetworkPolicies.

How to eliminate wrong answers

Option A is wrong because `--allow-privileged=false` in kubelet configuration only prevents privileged containers on that specific node, but does not restrict the `hostNetwork` setting; a pod can still set `hostNetwork: true` without being privileged. Option C is wrong because PodSecurityPolicy (PSP) has been deprecated since Kubernetes v1.21 and removed in v1.25; while a PSP with `hostNetwork: false` would work in older clusters, it is no longer a viable solution for current CKS exam contexts. Option D is wrong because NetworkPolicies operate at Layer 3/4 and cannot block a pod from binding to the host's network stack; `hostNetwork: true` bypasses the pod network entirely, making NetworkPolicies ineffective.

Practice this question →

142

Multi-Selectmedium

Which TWO of the following are valid Pod Security Standard levels? (Select 2)

Select 2 answers

A.medium

B.high

C.default

D.privileged

E.restricted

AnswersD, E

Privileged is the most permissive level.

Why this answer

Option D is correct because the Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. The privileged level is the most permissive, allowing known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources. It is explicitly listed in the Kubernetes documentation as one of the three valid PSS levels.

Exam trap

CNCF often tests the exact three Pod Security Standard levels (privileged, baseline, restricted) and expects candidates to recognize that 'medium', 'high', and 'default' are distractors that sound plausible but are not part of the official Kubernetes specification.

Practice this question →

143

MCQmedium

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

A.Delete the namespace and redeploy all workloads

B.Increase the memory limit in the pod's container resource specification

C.Delete and recreate the pod to clear the crash loop

D.Increase the CPU request for the container

AnswerB

OOMKilled indicates the container exceeded its configured memory limit. Increasing the memory limit allows the container to use more memory and prevents the OOM kill.

Why this answer

Option B is correct. OOMKilled means the container exceeded its memory limit and was killed by the kernel OOM killer. The solution is to increase the memory limit in the container's resource specification.

Option A would not help — restarting the pod without addressing the root cause will result in the same failure. Option C addresses CPU, not memory. Option D (deleting the namespace) is destructive and unnecessary.

Practice this question →

144

Multi-Selecthard

Which TWO of the following are valid approaches to restrict which nodes a pod can run on?

Select 2 answers

A.Use nodeSelector in pod spec

B.Define NetworkPolicy to allow only certain nodes

C.Enable PodSecurity with baseline profile

D.Use tolerations in pod spec

E.Use nodeAffinity in pod spec

AnswersA, E

nodeSelector matches nodes with specific labels.

Why this answer

Option A is correct because `nodeSelector` is a simple field in the Pod spec that constrains which nodes a Pod can be scheduled on by matching against node labels. This is a native Kubernetes scheduling mechanism that directly restricts node placement based on key-value pairs defined on nodes.

Exam trap

CNCF often tests the distinction between scheduling constraints (`nodeSelector`, `nodeAffinity`) and scheduling permissions (`tolerations`), where candidates mistakenly think tolerations restrict placement when they actually only allow scheduling on tainted nodes.

Practice this question →

145

MCQeasy

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

A.NodeRestriction

B.AlwaysPullImages

C.ServiceAccount

D.PodSecurity

AnswerD

PodSecurity enforces the Pod Security Standards, including 'restricted' profile which prevents running as root.

Why this answer

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

Exam trap

CNCF often tests the misconception that NodeRestriction or ServiceAccount can enforce pod-level security policies, but these controllers serve entirely different purposes—NodeRestriction is for kubelet authorization, and ServiceAccount is for identity management, not for restricting root access.

How to eliminate wrong answers

Option A (NodeRestriction) is wrong because it limits the Node API access for kubelets, preventing them from modifying sensitive node objects, but it does not enforce any pod-level security policies like preventing root containers. Option B (AlwaysPullImages) is wrong because it ensures that container images are always pulled from the registry, which is a security measure against stale or tampered images, but it has no effect on the user ID under which a container runs. Option C (ServiceAccount) is wrong because it manages the automatic creation and mounting of service account tokens into pods, but it does not restrict the security context or user ID of the containers.

Practice this question →

146

MCQmedium

Which of the following host access settings should be avoided to minimize the attack surface from containers? (Select the setting that increases risk the most.)

A.hostPID: true

B.securityContext: capabilities: drop: ["ALL"]

C.readOnlyRootFilesystem: true

D.resources: limits: memory: "512Mi"

AnswerA

Allows container to see host processes, increasing attack surface.

Why this answer

Setting 'hostPID: true' allows the container to see all processes on the host, which greatly increases the attack surface. Option A is correct. Options B, C, and D are less risky: readOnlyRootFilesystem reduces risk, resource limits are good, and dropping capabilities reduces risk.

Practice this question →

147

MCQhard

You are creating a custom seccomp profile for a container that runs a binary requiring the 'write' syscall only. You place the profile JSON file at '/var/lib/kubelet/seccomp/profiles/write-only.json'. In the pod spec, which seccomp configuration correctly uses this profile?

A.securityContext: seccompProfile: type: RuntimeDefault localhostProfile: profiles/write-only.json

B.securityContext: seccompProfile: type: Localhost localhostProfile: /var/lib/kubelet/seccomp/profiles/write-only.json

C.securityContext: seccompProfile: type: Localhost localhostProfile: profiles/write-only.json

D.securityContext: seccompProfile: type: Localhost profile: write-only.json

AnswerC

Correctly specifies type Localhost and the profile path relative to /var/lib/kubelet/seccomp/.

Why this answer

Option C is correct because when using a custom seccomp profile with type 'Localhost', the 'localhostProfile' field must specify a path relative to the kubelet's seccomp root directory (default: /var/lib/kubelet/seccomp). The path 'profiles/write-only.json' is relative and resolves to /var/lib/kubelet/seccomp/profiles/write-only.json, matching the file location. The 'type' field must be 'Localhost' to reference a local profile file.

Exam trap

CNCF often tests the distinction between relative and absolute paths for 'localhostProfile', and the trap here is that candidates mistakenly use an absolute path (option B) or confuse the field name 'localhostProfile' with 'profile' (option D), while also testing that 'type: RuntimeDefault' cannot be combined with a custom profile path.

How to eliminate wrong answers

Option A is wrong because 'type: RuntimeDefault' uses the container runtime's default seccomp profile, not a custom one, and 'localhostProfile' is ignored when type is not Localhost. Option B is wrong because 'localhostProfile' must be a relative path from the kubelet's seccomp root directory, not an absolute path; using '/var/lib/kubelet/seccomp/profiles/write-only.json' would cause the kubelet to look for the file at /var/lib/kubelet/seccomp/var/lib/kubelet/seccomp/profiles/write-only.json, which does not exist. Option D is wrong because the field name is 'localhostProfile', not 'profile', and 'profile' is not a valid key in the seccompProfile object.

Practice this question →

148

MCQhard

An AppArmor profile is loaded in 'complain' mode. What happens when a pod with that profile attempts an action that violates the profile?

A.The pod is terminated.

B.The action is allowed but a log entry is created.

C.The action is allowed and no log is generated.

D.The action is blocked and an audit log is generated.

AnswerB

Complain mode allows the action and logs the violation.

Why this answer

In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

Exam trap

CNCF often tests the distinction between AppArmor modes, and the trap here is confusing 'complain' mode with 'enforce' mode, leading candidates to think violations are blocked or that no logging occurs.

How to eliminate wrong answers

Option A is wrong because termination only occurs in 'enforce' mode when a violation is blocked, not in complain mode. Option C is wrong because complain mode explicitly generates a log entry for each violation; no log would only happen if the profile were not loaded or in 'audit' mode without logging. Option D is wrong because blocking the action is the behavior of 'enforce' mode, not complain mode; audit logs are generated in both modes, but in complain mode the action is allowed.

Practice this question →

149

MCQmedium

An administrator runs 'aa-status' on a node and sees a profile in 'complain' mode. What does this indicate?

A.The profile logs violations but does not block them.

B.The profile is disabled and has no effect.

C.The profile is enforcing restrictions and blocking violations.

D.The profile is not loaded.

AnswerA

Correct. Complain mode logs but does not enforce.

Why this answer

In complain mode, AppArmor allows all actions but logs violations. It is used for testing and learning without enforcement.

Practice this question →

150

Multi-Selecthard

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

Select 3 answers

A.Run containers with non-root user and drop all capabilities

B.Install all available security patches and packages

C.Disable unnecessary system services like Bluetooth and ModemManager

D.Remove SSH access from all nodes

E.Use read-only root filesystem for containers where possible

AnswersA, C, E

Least privilege principle reduces potential damage.

Why this answer

Options A, C, and D are best practices for node hardening. Option B is not a best practice because installing unnecessary packages increases attack surface. Option E is not a standard practice; SSH might be needed for admin access but should be restricted, not necessarily removed entirely.

Practice this question →

← PreviousPage 2 of 3 · 160 questions totalNext →

Ready to test yourself?

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

Start 20-question session