CCNA System Hardening Questions — Page 2 of 2

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

Labelling the namespace with the enforce label makes the Pod Security admission controller reject any pod violating the restricted profile at creation time. This satisfies the requirement to enforce, rather than merely warn or audit, the restricted standard namespace-wide.

Why this answer

The Pod Security Standards (PSS) are enforced via labels on namespaces, using the key `pod-security.kubernetes.io/enforce` with the value `restricted`. This instructs the built-in Pod Security Admission controller to reject any pod that violates the restricted profile in the `secure-ns` namespace.

Exam trap

The trap here is that candidates confuse labels with annotations or think that the old `PodSecurityPolicy` API is still the correct mechanism, but the CKS exam tests the modern Pod Security Standards via namespace labels.

How to eliminate wrong answers

Option B is wrong because `security=restricted` is not a recognized label for Pod Security Standards; the correct label key is `pod-security.kubernetes.io/enforce`. Option C is wrong because `PodSecurityPolicy` (PSP) is deprecated and removed since Kubernetes v1.25, and the command `kubectl create podsecuritypolicy` is not the correct way to enforce the restricted standard; PSS uses admission controller labels, not PSP objects. Option D is wrong because `kubectl annotate` uses annotations, not labels, and the Pod Security Admission controller specifically reads labels (not annotations) to determine the enforcement level.

Practice this question →

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 is correct because it first removes every capability from the container's permitted and effective sets, then adds back exactly one capability, NET_BIND_SERVICE, which is required to bind sockets to ports below 1024. This follows the principle of least privilege, ensuring the container only has the minimum kernel access needed. It is the standard pattern for running unprivileged containers that still need low-port binding.

Why this answer

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 →

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 etcd to localhost only is a recommended practice when the etcd instance does not need to be reached from other nodes, such as when kube-apiserver runs on the same host. By listening only on the loopback interface, you eliminate the entire external network attack surface, preventing remote attackers from even connecting to etcd. This is a simple but effective network-layer security control that reduces exposure to unauthorized access.

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 →

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

With `type: Localhost`, the kubelet resolves `localhostProfile` relative to its configured seccomp root directory, `/var/lib/kubelet/seccomp/`. Supplying `custom-profile.json` therefore points to the exact node path given in the stem. Absolute paths or directory prefixes would fail, since the field expects a path relative to that root.

Why this answer

When using a seccomp profile of type Localhost in Kubernetes, the `localhostProfile` field must specify only the filename of the profile (e.g., `custom-profile.json`). The kubelet automatically prepends the default seccomp profile path (`/var/lib/kubelet/seccomp/`) to the filename, so providing the full path would be incorrect.

Exam trap

The trap here is that candidates often assume they must provide the full absolute path to the profile file, but Kubernetes requires only the filename (or relative path) because the kubelet automatically prepends the default seccomp directory.

How to eliminate wrong answers

Option B is wrong because `localhost/custom-profile.json` is not a valid value for `localhostProfile`; the field expects just the filename, not a path with a `localhost/` prefix. Option C is wrong because `profile: custom-profile.json` is not a valid syntax for the `localhostProfile` field; the field is a string, not a key-value pair. Option D is wrong because `/var/lib/kubelet/seccomp/custom-profile.json` includes the full absolute path, but the kubelet already prepends `/var/lib/kubelet/seccomp/` to the value of `localhostProfile`, so specifying the full path would result in a double path (e.g., `/var/lib/kubelet/seccomp//var/lib/kubelet/seccomp/custom-profile.json`), causing the profile to not be found.

Practice this question →

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

The restricted Pod Security Standard (PSS) explicitly forbids any capability additions beyond the default set; a container that adds NET_BIND_SERVICE (or any other Linux capability) violates the 'capabilities' constraint, which requires that the effective capability set match the default and that all capabilities be dropped. Since this pod adds a capability rather than merely retaining defaults, it fails the restricted profile's validation and is rejected.

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 →

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

Applying the label `pod-security.kubernetes.io/enforce: restricted` to the namespace enables Pod Security Admission in enforce mode, which is a built-in admission controller. The `restricted` level of the Pod Security Standards requires Pods to set `securityContext.seccompProfile.type` to `RuntimeDefault` or `Localhost`, among other hardened settings. Any Pod that fails these requirements is immediately rejected at admission time, ensuring that all Pods in the namespace have seccomp enabled. This is the declarative, namespace-scoped mechanism that replaced PodSecurityPolicy.

Why this answer

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 →

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

Without readOnlyRootFilesystem set to true in the container's securityContext, the container can write to its root filesystem. This leaves the pod able to modify its own image layers, which is the remaining security issue in the manifest.

Why this answer

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

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

seccompProfile: { type: Localhost, localhostProfile: my-profile.json } is correct because Localhost explicitly tells Kubernetes to load a seccomp profile from a file on the node, and localhostProfile names that file relative to the kubelet's seccomp root directory, which defaults to /var/lib/kubelet/seccomp/. As long as my-profile.json is placed in that directory, Kubernetes constructs the absolute path /var/lib/kubelet/seccomp/my-profile.json and applies it to the container. This is the intended way to reference a custom profile, and the exact filename must match the file that exists on the node.

Why this answer

When using a custom seccomp profile stored on the node, the `type` must be `Localhost` and the `localhostProfile` field must specify only the filename (not the full path). Kubernetes automatically prepends the default seccomp profile path `/var/lib/kubelet/seccomp/` to the `localhostProfile` value, so `my-profile.json` resolves to the correct location.

Exam trap

The trap here is that candidates mistakenly provide the full absolute path in `localhostProfile`, not realizing that Kubernetes automatically prepends the default seccomp directory, leading to a double-path error.

How to eliminate wrong answers

Option A is wrong because `RuntimeDefault` uses the container runtime's default seccomp profile, not the custom profile at `/var/lib/kubelet/seccomp/my-profile.json`. Option C is wrong because `localhostProfile` should contain only the profile filename (e.g., `my-profile.json`), not the full absolute path; specifying the full path would cause Kubernetes to look for the file at `/var/lib/kubelet/seccomp//var/lib/kubelet/seccomp/my-profile.json`, which does not exist. Option D is wrong because `Unconfined` disables seccomp entirely, which is the opposite of applying a custom seccomp profile and violates the principle of least privilege.

Practice this question →

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

This is the correct and idiomatic way to drop all Linux capabilities in a Kubernetes container. The plural `capabilities` field is recognized by the securityContext schema, and the special case-insensitive token `ALL` (conventionally uppercase) instructs the runtime to remove every capability from the container's effective, permitted, and inherited sets. The result is a process with no capabilities, ideal for least-privilege workloads.

Why this answer

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 →

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` compiles an AppArmor profile from its text source and loads it into the kernel, satisfying the requirement to activate a profile. It is the standard userspace tool for this task, unlike `aa-status`, which only reports loaded profiles, or `apparmor_status`, which merely displays enforcement state.

Why this answer

The `apparmor_parser` command is used to load AppArmor profiles into the kernel by parsing the profile file and adding it to the kernel's security module. This is the standard utility for loading, reloading, and removing AppArmor profiles, making option B correct.

Exam trap

The trap here is that candidates confuse `aa-enforce` (which changes the mode of an already loaded profile) with loading a profile, or they assume `aa-load` is a real command due to its intuitive name.

How to eliminate wrong answers

Option A is wrong because `aa-status` is used to check the status of AppArmor profiles (e.g., which profiles are loaded or enforced), not to load them into the kernel. Option C is wrong because `aa-load` is not a valid AppArmor command; the correct command for loading profiles is `apparmor_parser`. Option D is wrong because `aa-enforce` is used to set an already loaded profile to enforce mode, not to load the profile itself.

Practice this question →

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

When the pod's seccomp profile is set to `RuntimeDefault`, the container runtime (e.g., containerd or CRI-O) applies its own default seccomp filter, which restricts a known set of dangerous or unnecessary system calls while still allowing normal container operations. This is a deliberate security configuration that enables seccomp enforcement without requiring an operator to craft and distribute a custom profile. It is the recommended baseline for secure pods because it blocks a larger attack surface than leaving seccomp unconfined.

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 →

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 is the correct annotation for applying an AppArmor profile to an individual container. The key embeds the container name, letting the kubelet map the profile to the container's processes, and the value uses forms like `runtime/default`, `localhost/<profile>`, or `unconfined`. It is a beta annotation but remains the standard way to enforce AppArmor on clusters that predate the newer structured `appArmorProfile` field.

Why this answer

The annotation `container.apparmor.security.beta.kubernetes.io/<container_name>` is the standard annotation used to apply an AppArmor profile to a specific container within a pod. The `<container_name>` placeholder must be replaced with the actual container name, and the annotation value specifies the profile (e.g., `localhost/profile-name` or `runtime/default`). This annotation is in the `security.beta.kubernetes.io` API group, reflecting its beta status in Kubernetes.

Exam trap

Candidates often confuse the annotation format for AppArmor with that of seccomp or forget the `container.` prefix and the required `security.beta` subdomain, leading them to pick Option B or D.

How to eliminate wrong answers

Option A is wrong because `seccomp.security.alpha.kubernetes.io/pod` is the annotation for applying seccomp profiles, not AppArmor profiles. Option B is wrong because `apparmor.security.beta.kubernetes.io/profile` is a malformed annotation; the correct annotation requires the `container.` prefix and the container name as a suffix, not just `/profile`. Option D is wrong because `container.apparmor.kubernetes.io/<container_name>` omits the required `security.beta` subdomain, which is part of the official annotation key for AppArmor support in Kubernetes.

Practice this question →

MCQmedium

An administrator needs to apply a seccomp profile to a Pod. The profile is defined in a file named audit.json located on each node at /var/lib/kubelet/seccomp/profiles/audit.json. The cluster is running Kubernetes 1.25. Which seccomp type should be used in the Pod's securityContext to reference this profile?

A.Localhost

B.Unconfined

C.RuntimeDefault

D.DockerDefault

AnswerA

The Localhost seccomp type allows referencing a profile file that resides on the node's filesystem. The path is relative to the kubelet's seccomp profile root directory, typically /var/lib/kubelet/seccomp. Given the file at /var/lib/kubelet/seccomp/profiles/audit.json, the correct localhostProfile value would be profiles/audit.json, and the type must be Localhost.

Why this answer

To use a custom seccomp profile stored on the node, the seccomp type must be set to Localhost, and the localhostProfile field must specify the path relative to the kubelet's seccomp root directory. RuntimeDefault uses a predefined profile, Unconfined disables seccomp, and DockerDefault is not a valid Kubernetes seccomp type. Therefore, Localhost is the correct choice.

Exam trap

The trap here is assuming that RuntimeDefault can be customized with a file path; only Localhost supports referencing a profile file on the node.

Practice this question →

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

This is the authoritative per-process interface. The kernel exposes the current AppArmor security label for each task via /proc/<pid>/attr/current; it returns the profile name and mode, such as 'worker-profile (enforce)' or 'unconfined'. Reading this file directly reveals the live confinement state, making it the correct audit check.

Why this answer

The file `/proc/<pid>/attr/current` contains the current AppArmor confinement status for a given process. Reading this file for a container's PID inside the node will show the profile name and mode (e.g., `my-profile (enforce)`), directly confirming that the profile is in enforce mode.

Exam trap

The trap here is that candidates might confuse system-wide AppArmor status commands (like `dmesg` or `apparmor_status`) with the per-process verification method required to check a specific container's enforcement mode.

How to eliminate wrong answers

Option B is wrong because `dmesg | grep apparmor` shows kernel log messages related to AppArmor events (e.g., denials or loading), but it does not show the current enforcement state of a specific profile on a running container. Option C is wrong because `apparmor_parser -r my-profile` reloads the profile from its definition file, but it does not query the current mode of a running process. Option D is wrong because `cat /proc/<pid>/environ` displays the environment variables of a process, which has no relation to AppArmor profile status.

Practice this question →

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 for applying an AppArmor profile to a specific container. The key is constructed by appending the container name 'app' to the prefix 'container.apparmor.security.beta.kubernetes.io/', and the value 'localhost/custom-profile' refers to a locally loaded AppArmor profile named 'custom-profile'. The kubelet will enforce this profile on the container's process at runtime, providing the desired Mandatory Access Control restrictions.

Why this answer

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 →

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

This is the correct AppArmor annotation. The key `container.apparmor.security.beta.kubernetes.io/app` targets the container named `app` with the `container.` prefix, and the value `localhost/my-profile` correctly references a node‑local AppArmor profile under `/etc/apparmor.d`. Kubelet loads and applies this profile before launching the container, enforcing the configured restrictions.

Why this answer

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 →

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

This is correct because the localhostProfile value is resolved relative to the kubelet's seccomp profile root (default /var/lib/kubelet/seccomp). So 'myprofile.json' becomes /var/lib/kubelet/seccomp/myprofile.json, which is exactly where the administrator placed the custom profile. The type field is also correctly set to Localhost, indicating that this custom file should be used.

Why this answer

When using a custom seccomp profile stored on the node, the `type` must be `Localhost`, and the `localhostProfile` field must contain only the filename (e.g., `myprofile.json`), not the full path. Kubernetes automatically prepends `/var/lib/kubelet/seccomp/` to the filename, so specifying the full path would cause the profile to be looked up in the wrong location, resulting in a failure to apply the profile.

Exam trap

The trap here is that candidates mistakenly include the full file path in `localhostProfile`, not realizing the kubelet automatically prepends its seccomp directory, leading to a profile-not-found error.

How to eliminate wrong answers

Option A is wrong because it specifies the full path `/var/lib/kubelet/seccomp/myprofile.json` in `localhostProfile`, but Kubernetes expects only the filename (e.g., `myprofile.json`) when `type: Localhost` is used; the full path is automatically constructed from the kubelet's seccomp root directory. Option C is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile and does not accept a `localhostProfile` field; specifying one would be ignored or cause a validation error. Option D is wrong because `type: Unconfined` disables seccomp entirely and does not use a `localhostProfile`; providing one is contradictory and invalid.

Practice this question →

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"

AnswerD

This correctly uses the `seccompProfile` field with `type: Localhost` and `localhostProfile: "audit.json"`. The `localhostProfile` path is interpreted relative to the kubelet's seccomp root directory, `/var/lib/kubelet/seccomp`, so it resolves exactly to `/var/lib/kubelet/seccomp/audit.json`, matching the location where you placed the profile. This option is the only one that uses the modern API and the correct path.

Why this answer

The seccomp profile is stored at `/var/lib/kubelet/seccomp/audit.json`. The `localhostProfile` field expects a relative path from the base directory `/var/lib/kubelet/seccomp/`. Therefore, `audit.json` correctly resolves to the full path.

The `seccompProfile` API with `type: Localhost` is the current method for applying custom profiles.

Exam trap

The trap here is that candidates confuse the deprecated `seccomp` field (used in older Kubernetes versions) with the current `seccompProfile` API, or they assume a bare filename like `audit.json` works without the required relative path prefix.

How to eliminate wrong answers

Option A is wrong because `type: RuntimeDefault` applies the container runtime's default seccomp profile, not a custom profile at the specified path. Option C is wrong because it uses the deprecated `seccomp` field and `profile` key instead of the current `seccompProfile` API with `localhostProfile`. Option D is wrong because `localhostProfile: "audit.json"` is a bare filename, not a relative path; Kubernetes requires a relative path (e.g., `profiles/audit.json`) to locate the profile under `/var/lib/kubelet/seccomp/`.

Practice this question →

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

The NodeRestriction admission controller enforces that a kubelet may only modify the Node object it is assigned to, and cannot alter sensitive labels such as kubernetes.io/role or any label with a node.kubernetes.io/ prefix, nor request the node.k8s.io/v1 Node API for other nodes. This directly reduces the attack surface of a compromised worker node by preventing label-based privilege escalation or denial-of-service via node object corruption, working in tandem with Node authorization to enforce the principle of least privilege for node identity.

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 →

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 permit privileged kernel operations: SYS_ADMIN enables mount and namespace manipulation, SYS_MODULE loads kernel modules, and SYS_PTRACE inspects other processes. Dropping them removes the primitives container escapes rely on, satisfying the stem's requirement to restrict host kernel access.

Why this answer

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 →

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

Disabling system services that aren't required for node operation is a fundamental host-hardening step. Every running service represents a potential vector for exploitation: it may open network listeners, expose APIs, or ship with unpatched vulnerabilities. On Kubernetes nodes, the principle is to minimize the attack surface to the essentials (kubelet, container runtime, system daemons like sshd only if required), often enforced via CIS benchmarks and immutable node images. Unused services such as CUPS, NFS, or telnet should be masked, as they increase the risk of host compromise and are never needed for pod workloads.

Why this answer

Disabling unnecessary system services on Kubernetes nodes reduces the number of running processes and open ports that could be exploited by an attacker. Services like telnet, rsh, or unused SNMP daemons provide additional attack vectors. This aligns with the principle of minimalism in system hardening, as recommended by the CIS Kubernetes Benchmark.

Exam trap

The CNCF CKS exam often tests the misconception that opening all ports aids debugging, but in Kubernetes, debugging should be done via kubectl exec or ephemeral containers, not by exposing node ports. Additionally, running containers as root is a common mistake that violates Pod Security Standards and the principle of least privilege.

Practice this question →

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

Complain mode is one of the two official AppArmor modes. When a profile is loaded in complain mode, AppArmor logs every operation that would be denied under enforce mode, but it does not actually block any of those operations. This mode is primarily used for testing and fine-tuning profiles before switching them to enforce mode, making it a legitimate and valid mode.

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 →

MCQmedium

A Pod must be prevented from reading or writing to its container root filesystem. The application only writes to an emptyDir mount at /tmp. Which securityContext field should be set in the Pod specification to enforce this at the container level?

A.runAsNonRoot: true

B.privileged: false

C.readOnlyRootFilesystem: true

D.allowPrivilegeEscalation: false

AnswerC

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, which directly prevents any writes to the root filesystem. The emptyDir volume mounted at /tmp remains writable because it is a separate mount. This is the standard Kubernetes securityContext field for enforcing an immutable root filesystem at the container level.

Why this answer

The readOnlyRootFilesystem field in the container securityContext mounts the root filesystem as read-only, directly preventing writes. Other securityContext fields such as privileged, allowPrivilegeEscalation, and runAsNonRoot improve container isolation but do not restrict filesystem writability. Mounting a writable emptyDir at /tmp allows the application to continue writing to the required path while the rest of the root filesystem remains immutable.

Exam trap

The trap here is assuming that running as non-root or disabling privilege escalation also makes the root filesystem read-only, when only readOnlyRootFilesystem controls filesystem writability.

Practice this question →

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

Privileged is the first and most permissive Pod Security Standard level. It intentionally imposes no restrictions on the pod security context, allowing privileged containers, host namespaces, and arbitrary capabilities. This level is commonly used for system-level pods such as cluster add-ons that require direct host access. It is a valid level according to the Pod Security Standards.

Why this answer

The Pod Security Standards (PSS) define three levels: privileged, baseline, and restricted. 'Privileged' is the most permissive level, allowing all known privilege escalations and is intended for system-level workloads that require unrestricted access to host resources.

Exam trap

The CKS exam often tests the exact naming of the three Pod Security Standards levels, and candidates mistakenly invent plausible-sounding names like 'secure', 'default', or 'strict' instead of the official terms 'privileged', 'baseline', and 'restricted'.

Practice this question →

100

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

Setting `capabilities.drop: ["ALL"]` explicitly removes every Linux capability from the container's effective, permitted, and inheritable sets, so even a root UID cannot perform privileged operations such as raw socket creation, binding to ports below 1024 (if governed by capability), or mounting filesystems. This is the correct least-privilege baseline; if a workload genuinely needs a specific capability, it can be added back selectively via `capabilities.add`. It directly reduces the kernel attack surface by denying access to privileged kernel operations.

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 →

101

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

Dropping ALL is mandatory under the restricted Pod Security Standard. This entry clears every Linux capability from the container's bounding set, so processes start with zero capabilities beyond the default set (which is effectively none). The policy explicitly requires `drop: ["ALL"]` and forbids any `add` entries; this is the only option that fully satisfies that control and is therefore valid.

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 →

102

MCQmedium

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

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

B.Leave capabilities unset to use the default set

C.Add only the necessary capabilities without dropping

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

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

103

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 for applying a seccomp profile at the pod level. The annotation's value can be 'localhost/<profile-name>' to reference a profile stored on the node, or 'runtime/default' for the runtime's default. Although superseded by the securityContext.seccompProfile field, this annotation is still honored by the kubelet, making it a legitimate (if legacy) way to configure a custom profile.

Why this answer

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 →

104

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

Setting privileged: true in a Kubernetes pod security context is explicitly not recommended because it disables almost all container isolation features: it grants every Linux capability, removes seccomp restrictions, and allows the container to access host devices, the host kernel, and perform operations like loading kernel modules or altering network settings. The privilegeEscalation flag is implicitly forced to true, meaning the container process gains all capabilities of the root user and can use raw sockets, mount filesystems, and read/write to /dev. This effectively turns the container into a process running with host-level root privileges, making a single compromised process equivalent to a full host compromise. Such a configuration dramatically increases the attack surface and should never be used in a security-conscious cluster, making it the correct answer.

Why this answer

Setting `privileged: true` in a container's security context grants it elevated capabilities equivalent to running as root on the host, including access to all kernel namespaces and devices. This directly increases the attack surface by allowing the container to perform host-level operations, such as loading kernel modules or modifying network settings, which violates the principle of least privilege. The CKS exam emphasizes that privileged containers should be avoided unless absolutely necessary, and they are never a recommended method for reducing the attack surface.

Exam trap

The trap here is that candidates may confuse 'privileged containers' with 'containers running as root' and incorrectly think that running as non-root is the only requirement, when in fact privileged mode grants far more dangerous host-level access regardless of the user ID.

How to eliminate wrong answers

Option A is wrong because using read-only root filesystems prevents containers from writing to their own filesystem, which limits the impact of a compromise by making it harder for an attacker to persist or modify binaries. Option B is wrong because running containers as non-root (e.g., with `runAsUser: 1000`) reduces the risk of privilege escalation by ensuring the container process does not have root UID 0 inside the container, which is a fundamental security best practice. Option D is wrong because disabling unnecessary system services on nodes (e.g., stopping unused daemons like `cups` or `rpcbind`) reduces the number of potential entry points for an attacker, directly shrinking the node's attack surface.

Practice this question →

105

MCQeasy

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

A.hostNetwork: true

B.hostPID: true

C.hostIPC: true

D.hostPID: false

AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

106

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

When you set an annotation like container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile>, the CRI runtime checks whether an AppArmor profile named <profile> is currently loaded in the node's kernel, e.g., using /sys/kernel/security/apparmor/profiles or aa-status. If it is not loaded, the container runtime rejects the pod with an error such as 'failed to load AppArmor profile', causing the pod to stay in a pending/container-creating state. The profile must be installed and loaded (via apparmor_parser) prior to pod creation; Kubernetes never loads it automatically.

Why this answer

When a pod remains in 'ContainerCreating' state and then fails, it often indicates that the node cannot apply the specified AppArmor profile. The most likely cause is that the profile referenced in the pod annotation (e.g., 'container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/<profile-name>') is not loaded into the node's kernel. Without the profile loaded, the container runtime (e.g., containerd or CRI-O) cannot enforce the policy, causing the pod creation to hang and eventually fail.

Exam trap

The exam often tests the distinction between AppArmor being enabled on the node versus the profile being loaded; candidates may incorrectly choose 'node does not support AppArmor' when the actual issue is a missing profile, or confuse the annotation-based configuration with a non-existent securityContext field.

How to eliminate wrong answers

Option A is wrong because AppArmor profiles are not Kubernetes namespace-scoped; they are loaded into the node's kernel and referenced by name, not by namespace. Option C is wrong because AppArmor is enabled via pod annotations (e.g., 'container.apparmor.security.beta.kubernetes.io/<container-name>'), not via a 'securityContext.apparmor: enabled' field, which does not exist in the Kubernetes API. Option D is wrong because if the node did not support AppArmor at all, the pod would typically fail immediately with an error like 'AppArmor is not enabled on this node', not remain in 'ContainerCreating' for a long time; the long delay suggests the profile is missing but the node supports AppArmor.

Practice this question →

107

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 is a non-enforcing AppArmor profile mode that logs every operation that violates the profile's rules to the kernel ring buffer or audit logs, but does not block them. Often called "learning mode," it lets administrators develop and tune profiles by observing real application behavior without breaking functionality. It is the inverse of enforce mode and is selected with the `complain` keyword in the profile definition or the `aa-complain` utility.

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 →

108

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

Enabling AppArmor profiles on the nodes is a container runtime hardening measure. AppArmor, a Linux security module, confines each container process to a defined profile that restricts file accesses, network operations, and other privileges, effectively limiting the capabilities to a minimal set. When the runtime (e.g., containerd) is configured with AppArmor, the profile is enforced by the kernel for every container, providing a strong, node-level isolation control that aligns with the auditor's requirement.

Why this answer

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 →

109

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

Adding NET_ADMIN grants precisely the capability required for iptables operations, as it allows control over network administration tasks such as netfilter rules, routing tables, and socket attributes. This is the minimal privilege needed to accomplish the goal, following the least-privilege principle. It is the correct choice because it grants the necessary power without exposing the container to the broader risks associated with privileged mode or SYS_ADMIN.

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 →

110

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 a printing subsystem with a network-exposed daemon, cupsd, that implements IPP and legacy printing protocols. Kubernetes worker nodes do not need to act as print servers, and CUPS has historically had shell-injection and remote code execution vulnerabilities. Disabling or uninstalling CUPS eliminates a non-operational, network-listening service, directly reducing the node's attack surface. This makes it the correct service to remove.

Why this answer

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

111

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

This is the correct configuration. With type: Localhost, the kubelet is instructed to load a seccomp profile from the node's seccomp root directory (default /var/lib/kubelet/seccomp). The localhostProfile field must contain only the filename, relative to that directory, not a full path. Here, 'audit.json' is exactly that, so the kubelet will correctly locate the profile at /var/lib/kubelet/seccomp/audit.json and apply its rules to the container.

Why this answer

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 →

112

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 is the exact capability that grants a process permission to set or adjust the system clock and the hardware real-time clock (RTC). It covers the settimeofday(), stime(), clock_settime(), and adjtimex() syscalls, so a container with this capability can change the current date and time on the host. For a container to change time, this capability must be explicitly added to its securityContext.capabilities.add list, since it is not part of the default allowed capability set in Docker or Kubernetes.

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 →

113

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 syntax in v1.29 and later: type: Localhost tells the kubelet to load a profile from the node's seccomp profile directory, and localhostProfile: audit.json specifies the exact file name. The file must be present on the node under the kubelet's seccomp root (commonly /var/lib/kubelet/seccomp) before the Pod can start. This field was added to replace the old annotation, and it is the stable, validated API for custom profiles.

Why this answer

In Kubernetes, when using a custom seccomp profile stored on the node's default seccomp directory, the `securityContext.seccompProfile.type` must be set to `Localhost` and the profile filename is specified via the `localhostProfile` field. This field expects the filename (e.g., `audit.json`) relative to the node's default seccomp path (`/var/lib/kubelet/seccomp`). The `type: Localhost` instructs kubelet to load the profile from the node's filesystem.

Exam trap

The CKS exam often tests the distinction between the deprecated annotation-based approach and the current `securityContext.seccompProfile` fields, and the trap here is that candidates confuse the field name `localhostProfile` with `file` or `profile`, or mistakenly think the annotation is still the standard method.

How to eliminate wrong answers

Option A is wrong because `securityContext.seccompProfile.file` is not a valid field; the correct field name is `localhostProfile`. Option B is wrong because `securityContext.seccompProfile.profile` is not a valid field; the correct field is `localhostProfile`. Option D is wrong because the annotation `seccomp.security.alpha.kubernetes.io/pod` is a deprecated alpha API that was used in older Kubernetes versions (pre-1.19) and is not the current recommended way; the modern approach uses the `securityContext.seccompProfile` field.

Practice this question →

114

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

MustRunAsNonRoot for runAsUser validates the container's effective user ID: if the image's USER directive is root or the pod explicitly sets securityContext.runAsUser: 0, admission rejects the pod. This is the standard control for enforcing non-root execution because it directly governs the UID that determines privilege in Linux. This is the correct answer.

Why this answer

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

115

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 is the correct approach. The field seccompProfile is part of the Pod securityContext, and type: Localhost tells kubelet to load a custom profile file from the kubelet's seccomp localhost directory (typically /var/lib/kubelet/seccomp/). The localhostProfile field must contain the exact filename (e.g., deny-mkdir.json) that exists on the node, and the profile file must be valid JSON defining syscall rules, such as returning EPERM for mkdir and mkdirat. This configuration precisely applies the custom deny-mkdir profile to the pod's containers.

Why this answer

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 →

116

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 is the correct command because `kubectl label` sets the `pod-security.kubernetes.io/enforce` label on the namespace, which is exactly what the Pod Security Admission plug-in reads to decide the policy level and mode. Setting its value to `restricted` puts the namespace in enforce mode with the most stringent policy standard, so any pod that does not meet the restricted profile's security requirements will be rejected by the admission controller. Labels are the designated API mechanism for namespace-level PSA configuration, and this key is case-sensitive and must be spelled exactly as shown.

Why this answer

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 →

117

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 is the correct command because it labels the namespace with the enforce label that Pod Security Admission reads, and sets it to the 'restricted' Pod Security Standard. As a result, any pod created in that namespace that does not satisfy the restricted profile—such as those without seccomp profiles or with added capabilities—is rejected at admission time. The label format is exactly pod-security.kubernetes.io/enforce=restricted.

Why this answer

The `kubectl label` command with the key `pod-security.kubernetes.io/enforce` and value `restricted` applies the Restricted Pod Security Standard to the namespace. This label instructs the Pod Security Admission controller to enforce the most restrictive policy, rejecting any pod that violates the standard. The command targets the namespace 'restricted' as required.

Exam trap

The trap here is that candidates confuse the deprecated PodSecurityPolicy (PSP) with the newer Pod Security Standards (PSS) and try to use `kubectl create podsecuritypolicy` or incorrect annotation syntax, when the correct approach is to label the namespace with the `pod-security.kubernetes.io/enforce` key.

How to eliminate wrong answers

Option A is wrong because `kubectl annotate` does not trigger Pod Security Standards; it uses annotations, not labels, and the syntax `pod-security.kubernetes.io/restricted=restricted` is invalid (the correct label key is `pod-security.kubernetes.io/enforce`). Option B is wrong because it sets the value to `privileged`, which enforces the least restrictive standard, not the Restricted standard. Option C is wrong because `PodSecurityPolicy` (PSP) is deprecated and removed in Kubernetes 1.25+; the question refers to Pod Security Standards (PSS) which are configured via labels on namespaces, not via PSP objects.

Practice this question →

118

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

Pod Security Admission (PSA) is the built-in admission controller that enforces the Pod Security Standards, and both the `baseline` and `restricted` policies require `hostNetwork` to be set to `false` (with `restricted` also forbidding other host namespaces). By applying a PSA level of `baseline` or `restricted` at the cluster, namespace, or label-based level, the API server will reject any new pod that tries to use host networking. This is the recommended, current replacement for the removed PodSecurityPolicy, and it directly blocks the offending capability. Note that PSA only applies to newly created pods, so existing pods must be recreated or patched to bring them into compliance.

Why this answer

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 →

119

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 one of the three valid Pod Security Standard levels and is the most permissive. It disables nearly every security restriction, allowing privileged containers, host namespace sharing, hostPath volumes, and unrestricted capabilities. This level is intended for system-critical workloads such as cluster add-ons or monitoring agents that require broad host access, but it provides no hardening; because it is an actual PSS level, it is correct.

Why this answer

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 →

120

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

Raising the container's memory limit directly addresses the OOMKilled termination, which occurs when the container exceeds its configured memory limit and the kernel kills the process. Since the pod ran successfully for days before failing, the workload's memory demand has grown beyond the current ceiling, so increasing the limit satisfies that constraint.

Why this answer

The pod is in CrashLoopBackOff due to OOMKilled, meaning the container is being terminated by the Linux kernel's Out-Of-Memory (OOM) killer because it exceeds its memory limit. Increasing the memory limit in the container's resource specification allows the container to allocate more memory without being killed, directly addressing the root cause.

Exam trap

Many candidates mistakenly think that restarting the pod (Option C) will fix transient issues, but here the OOMKilled state is a persistent resource constraint, not a transient failure.

How to eliminate wrong answers

Option A is wrong because deleting the namespace and redeploying all workloads is an extreme, disruptive action that does not fix the underlying memory limit issue and would cause unnecessary downtime. Option C is wrong because deleting and recreating the pod will not resolve the OOMKilled condition; the new pod will still hit the same memory limit and crash again. Option D is wrong because increasing the CPU request does not affect memory allocation; the OOM killer is triggered by memory exhaustion, not CPU pressure.

Practice this question →

121

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

A nodeSelector is a hard scheduling constraint defined in the pod spec that restricts the pod to nodes carrying a specific label. It uses simple equality-based matching: the pod's key-value pair must exactly match a label on the node, and if no node matches, the pod remains Pending. Unlike nodeAffinity, nodeSelector supports only the 'equals' operation with no logical operators or preferences, making it a concise but less expressive tool for selecting nodes with static labels such as disktype=ssd.

Why this answer

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

122

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 is the correct answer because it is a built-in admission controller that enforces the Pod Security Standards, specifically the 'restricted' profile, which mandates that containers run as a non-root user (e.g., runAsNonRoot: true and runAsUser set to a non-zero ID). It validates the Pod's securityContext during creation and rejects any Pod that attempts to run as root. This directly implements the administrator's policy to restrict root execution.

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 →

123

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

Setting `hostPID: true` grants a container direct access to the host’s process ID namespace, allowing it to view and potentially interact with all processes running on the host. This violates the principle of namespace isolation, which is the core constraint the stem targets for minimising attack surface. Exposing host PID enables privilege escalation or information leakage from other containers or system services.

Why this answer

Setting `hostPID: true` allows a container to share the host's process ID namespace, enabling it to see all processes running on the host. This breaks the fundamental isolation that containers should provide, giving a compromised container direct visibility into host processes and the ability to potentially interact with them (e.g., sending signals). This significantly increases the attack surface and is the most dangerous setting among the options.

Exam trap

The CKS exam often tests the misconception that resource limits or read-only filesystems are more critical for security than namespace isolation, but the core principle is that sharing the host PID namespace breaks container isolation at the kernel level, which is far more dangerous than misconfiguring capabilities or resource constraints.

How to eliminate wrong answers

Option B is wrong because dropping all capabilities with `drop: ["ALL"]` is a security best practice that minimizes the kernel capabilities available to the container, reducing the attack surface. Option C is wrong because setting `readOnlyRootFilesystem: true` mounts the container's root filesystem as read-only, preventing writes to the container's filesystem and mitigating tampering or malware persistence. Option D is wrong because setting memory limits with `resources.limits.memory: "512Mi"` is a resource constraint that prevents a container from consuming excessive host memory, which helps mitigate denial-of-service risks and is a recommended security control.

Practice this question →

124

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

This snippet correctly defines a custom seccomp profile by setting `type: Localhost` and providing `localhostProfile: profiles/write-only.json`, a relative path. The kubelet resolves this path relative to its seccomp profile directory, typically `/var/lib/kubelet/seccomp`, so the actual file must exist at `/var/lib/kubelet/seccomp/profiles/write-only.json`. This is the only one of the four options that would successfully load the write-only profile.

Why this answer

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 →

125

MCQhard

A Kubernetes cluster uses containerd as the container runtime. The security team wants to restrict a specific container so it cannot create raw network packets. The container image runs as root and the Pod specification does not drop any capabilities. Which Linux capability should be dropped from the container's securityContext to prevent raw packet creation while still allowing binding to privileged ports?

A.NET_RAW

B.NET_BIND_SERVICE

C.SYS_ADMIN

D.NET_ADMIN

AnswerA

NET_RAW allows the creation of raw sockets, which are required to craft raw network packets. Dropping NET_RAW removes this ability while leaving other networking capabilities such as NET_BIND_SERVICE intact, so the container can still bind to privileged ports. This directly satisfies the requirement without over-restricting the container.

Why this answer

The NET_RAW capability is what allows a process to create raw sockets and craft raw network packets. Dropping NET_RAW from the container's securityContext removes this ability while preserving NET_BIND_SERVICE so the container can still bind to privileged ports. This is the least-privilege approach: it targets exactly the unwanted capability without removing unrelated networking permissions.

Exam trap

The trap here is confusing NET_RAW with NET_ADMIN; NET_RAW specifically governs raw sockets, while NET_ADMIN covers broader network configuration.

Practice this question →

126

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

AppArmor complain mode, also known as log mode, loads the profile without enforcing it. Every denied-access event in enforce mode is instead allowed and simultaneously written to the audit log (e.g., /var/log/audit/audit.log or journalctl). This mode is used for testing and fine-tuning profiles before switching to enforce mode.

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 →

127

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

In AppArmor, complain mode (also called learning mode) is what aa-status reports when a profile is loaded but configured without enforcement. The kernel still intercepts and evaluates every access attempt against the profile's rule set, but instead of denying a disallowed operation, it merely records an audit event to the kernel log or audit subsystem. This is distinct from any disabled or unloaded state, because the profile is active and its rules are being evaluated, just without the final denial action, making it the correct interpretation of a logged violation without blocking.

Why this answer

AppArmor profiles in 'complain' mode log policy violations to the system log (e.g., /var/log/syslog or audit.log) but do not enforce them, meaning the actions are allowed while being recorded. This is distinct from 'enforce' mode, where violations are blocked. The 'aa-status' command shows the current mode of loaded profiles.

Exam trap

The CKS exam often tests the distinction between 'complain' and 'enforce' modes, and the trap here is that candidates confuse 'complain' with 'disabled' or think it means the profile is not loaded, when in fact it is loaded and logging but not blocking.

How to eliminate wrong answers

Option B is wrong because a profile in 'complain' mode is still loaded and active, not disabled; disabling a profile would remove it from the kernel's policy or set it to 'unconfined'. Option C is wrong because 'enforce' mode is the one that blocks violations, not 'complain' mode. Option D is wrong because 'aa-status' only lists loaded profiles; if a profile were not loaded, it would not appear in the output at all.

Practice this question →

128

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

Running as non-root with all Linux capabilities dropped removes privileged kernel operations from the container, so a compromised process cannot escalate to node-level control. This directly shrinks the node's attack surface by denying container-to-host privilege paths.

Why this answer

Option A is correct because running containers as a non-root user and dropping all Linux capabilities (e.g., via securityContext runAsNonRoot: true and capabilities.drop: ["ALL"]) prevents a compromised container from gaining root privileges or abusing kernel capabilities on the node. Option C is correct because disabling unneeded host services such as Bluetooth (bluetooth.service) and ModemManager (ModemManager.service) removes daemons and attack vectors that are irrelevant to a Kubernetes node's role. Option E is correct because a read-only root filesystem (securityContext readOnlyRootFilesystem: true) blocks attackers from writing malicious binaries or modifying files inside the container, limiting persistence and lateral movement.

Option B is not a best practice as stated: installing all available packages increases the attack surface, whereas the correct practice is to apply security patches and keep the installed package set minimal. Option D is not a best practice because removing SSH access from all nodes eliminates a legitimate administrative and troubleshooting channel; SSH should instead be restricted, key-based, and network-limited rather than universally removed.

Exam trap

A common misconception is that completely removing SSH access from nodes is a valid hardening step. However, the correct approach is to restrict SSH access (e.g., disable root login, use SSH keys, limit to specific IPs) rather than eliminating it, as SSH is often needed for emergency node access.

Practice this question →

129

MCQmedium

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

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

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

C.Run 'systemctl stop swap'

D.Run 'kubelet --disable-swap'

AnswerA

Running 'swapoff -a' deactivates all currently active swap devices and files immediately, while removing the swap entry from /etc/fstab guarantees that swap will not be re-enabled at boot. This dual action is required for Kubernetes because the kubelet, when using cgroup v2, treats any active swap as a failure condition; even a persistent swap that is only occasionally used can cause unpredictable memory allocation behavior. Without editing fstab, the system would re-enable swap on restart, leaving the node non-compliant.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

130

MCQeasy

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

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

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

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

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

AnswerB

This is the canonical way to apply a custom AppArmor profile to a specific container. The annotation key format `container.apparmor.security.beta.kubernetes.io/<container_name>` tells the kubelet that the profile applies only to the container named `app` within the Pod. The value `localhost/my-profile` instructs the kubelet to load the profile named `my-profile` from the node's local AppArmor profiles directory. This annotation must be placed on the Pod metadata, not on the container spec.

Why this answer

The AppArmor profile annotation for a container must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation is in the `security.beta.kubernetes.io` API group (beta, not alpha) and targets the specific container by name. The value must include the `localhost/` prefix to indicate a profile loaded on the node, not a built-in or default profile.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

131

MCQmedium

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

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

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

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

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

AnswerB

This is the correct approach: the Pod Security admission controller's 'enforce' label on a namespace tells the API server to reject Pods that violate the specified level. Setting it to 'baseline' activates Baseline profile checks, which block non-conformant Pods (for example, those using privileged containers or host namespaces) during admission. The value must be one of privileged, baseline, or restricted, and it directly enforces the standard on the namespace.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

132

MCQeasy

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

A.Unconfined

B.RuntimeDefault

C.Default

D.Localhost

AnswerB

RuntimeDefault instructs the container runtime to apply its built-in default seccomp profile, satisfying the stem's requirement without supplying a custom JSON file. Unlike Localhost, which loads a profile from a node path, RuntimeDefault delegates filtering to the runtime itself, blocking dangerous syscalls by default.

Why this answer

The `RuntimeDefault` seccomp profile type instructs the container runtime (e.g., containerd, CRI-O) to apply its own built-in default seccomp profile. This profile is defined by the runtime and typically blocks around 44 system calls that are considered dangerous or unnecessary for containers, providing a secure baseline without requiring a custom profile.

Exam trap

Kubernetes often tests the distinction between `Default` (which is not a valid Kubernetes seccomp type) and `RuntimeDefault` (the correct type for applying the runtime's default profile), causing candidates to mistakenly choose `Default` due to its intuitive name.

How to eliminate wrong answers

Option A is wrong because `Unconfined` disables seccomp entirely, allowing all system calls and providing no security restriction. Option C is wrong because `Default` is not a valid seccomp profile type in Kubernetes; the correct term is `RuntimeDefault`. Option D is wrong because `Localhost` is used to reference a custom seccomp profile file stored on the node's filesystem, not the runtime's default.

Practice this question →

133

Multi-Selectmedium

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

Select 3 answers

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

B.Use minimal base container images

C.Disable unnecessary system services on nodes

D.Expose the host network to containers for better performance

E.Run containers as root to simplify permissions

AnswersA, B, C

Disabling hostPID and hostNetwork stops containers sharing the node's process and network namespaces, so a compromised pod cannot inspect host processes or bypass network policy. This directly reduces node attack surface by removing privileged namespace access that would otherwise permit container escape and lateral movement across the cluster.

Why this answer

Option A is correct because disabling hostPID and hostNetwork prevents containers from sharing the node's process namespace and network stack, which blocks container escapes and lateral movement to host processes or interfaces. Option B is correct because minimal base images (e.g., distroless or Alpine) contain fewer packages, libraries, and utilities, shrinking the exploitable vulnerability surface inside the container. Option C is correct because disabling unnecessary system services on nodes (e.g., unused daemons, package managers, or listening ports) removes potential entry points and reduces the node's overall attack surface.

Option D is incorrect because exposing the host network to containers increases risk by allowing direct access to node interfaces and services, which is the opposite of a hardening best practice. Option E is incorrect because running containers as root grants excessive privileges and makes privilege escalation or container breakout far more damaging; least-privilege non-root users are preferred.

Exam trap

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

Practice this question →

134

MCQeasy

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

A.hostIPC

B.privileged

C.hostPID

D.hostNetwork

AnswerD

Setting `hostNetwork: false` (the default) places the container in its own network namespace with a virtual Ethernet pair, so it only sees the Pod IP and cannot bind to or sniff the host's IP addresses and ports. Without `hostNetwork: true`, the container's network stack is isolated from the host, preventing direct access to host interfaces, routes, and iptables rules. This boolean is the precise network isolation control in the Pod spec.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

135

MCQhard

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

A.The pod must run as privileged to use AppArmor

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

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

D.The profile is not loaded on the node

AnswerC

AppArmor profiles can be run in complain (audit) mode, where every access is allowed but violations are logged, or in enforce mode, where disallowed accesses are blocked. In complain mode the profile is technically loaded and appears to be in effect, yet it imposes no real restrictions on the container's system calls. To secure the workload, the profile must be set to enforce mode (e.g., using 'aa-enforce' or writing to /sys/kernel/security/apparmor). The question describes a profile that exists but fails to restrict, which exactly matches complain mode behavior.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

136

MCQhard

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

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

B.PSPs were replaced by NetworkPolicies in 1.25

C.PSP support was removed from Kubernetes in 1.25

D.The PSP was not applied to the correct namespace

AnswerC

Correct: PodSecurityPolicy support was removed in Kubernetes 1.25. The PSP API (policy/v1beta1) was deprecated in v1.21 and removed entirely in v1.25, meaning any PSP manifest, even if syntactically valid, will be rejected by the API server and the admission plugin will no longer enforce anything. This is exactly why the administrator's PSP fails to take effect in a 1.25 cluster; the entire subsystem has been excised.

Why this answer

PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Exam trap

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

How to eliminate wrong answers

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

Practice this question →

137

MCQeasy

Which command loads an AppArmor profile into the kernel?

A.apparmor_load /path/to/profile

B.aa-load /path/to/profile

C.aa-status /path/to/profile

D.apparmor_parser -r /path/to/profile

AnswerD

`apparmor_parser -r /path/to/profile` is the legitimate way to load (or replace) an AppArmor profile: it reads the textual profile file, parses it into the binary policy format, and writes that policy to the kernel through the AppArmor securityfs interface. The `-r` flag means 'replace' an existing profile with the same name; to add a new profile, you would use `-a` or omit the flag (the default is add). Because the kernel only understands the compiled policy, apparmor_parser is the required userspace bridge and thus correctly loads the profile.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Practice this question →