997 questions total · 14pages · All types, answers revealed
A cluster administrator wants to enforce that containers run with a read-only root filesystem. Which security context field should be set?
This is the correct field to set the root filesystem read-only.
Why this answer
readOnlyRootFilesystem: true makes the container's root filesystem read-only.
Which three of the following are valid methods to restrict access to etcd? (Choose three.)
etcd supports RBAC to control which users can perform operations.
Why this answer
Option A is correct because etcd supports Role-Based Access Control (RBAC) natively since version 3.0. By enabling RBAC on etcd, you can define roles and permissions to restrict which users or processes can read or write to specific keys or prefixes. This is a direct method to secure the etcd datastore against unauthorized access.
Exam trap
CNCF often tests the distinction between access control (who can connect to etcd) and data protection (encryption at rest), leading candidates to incorrectly select encryption as a method to restrict access.
Which THREE of the following are valid Rego policy constructs used in OPA Gatekeeper ConstraintTemplates to enforce security policies? (Choose three)
This is the standard way to report violations in Gatekeeper Rego policies.
Why this answer
In OPA Gatekeeper, Rego policies typically use violation, deny, or allow rules to enforce policies. Violation is specific to Gatekeeper's ConstraintTemplate framework, while deny and allow are general Rego constructs.
A security team wants to ensure that all container images in a cluster are scanned for critical CVEs before they are run. They decide to use an admission controller. Which Kubernetes built-in admission controller should they configure?
ImagePolicyWebhook is the correct built-in admission controller that can be configured to check images against external scanning services before allowing pod creation.
Why this answer
The ImagePolicyWebhook admission controller is the built-in mechanism that allows you to gate pod creation based on image policy decisions. The other options are not built-in admission controllers.
Developer A runs 'cosign verify --key cosign.pub myregistry/myimage:tag' and receives an error: 'No signatures found'. Developer B previously ran 'cosign sign --key cosign.key myregistry/myimage:tag'. What is the most likely cause of the verification failure?
If the signature is not pushed, the verify command will find no signatures.
Why this answer
Option A is correct. The error 'No signatures found' indicates that the image does not have a signature attached to it. This could happen if the signing command did not push the signature to the registry.
Option B is irrelevant because the image tag exists. Option C is incorrect because the signing command uses the private key. Option D is incorrect; the verification command uses the public key, but the error is about missing signatures, not key mismatch.
A cluster administrator wants to run some workloads in a sandboxed environment using gVisor. Which Kubernetes resource must be created first to allow pods to request the gVisor runtime?
The RuntimeClass resource defines the runtime handler (e.g., runsc) that gVisor uses.
Why this answer
Option C is correct. A RuntimeClass is required to define the container runtime (e.g., gVisor). Pods then specify `runtimeClassName` to use that runtime.
Option A is not correct because RuntimeClass is not a pod spec field but a separate resource. Option B is not correct because a custom resource definition is not needed for built-in RuntimeClass. Option D is not correct because a new PodSecurityPolicy is not required.
A pod is scheduled on a node that has AppArmor enabled, and the pod has the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write'. The profile 'deny-write' is loaded. However, the nginx container is able to write to the filesystem. What is the most likely issue?
If loaded in complain mode, the profile does not enforce restrictions, only logs violations.
Why this answer
The most likely issue is that the AppArmor profile 'deny-write' was loaded in complain mode using the `apparmor_parser` with the `-C` flag. In complain mode, AppArmor logs policy violations but does not enforce them, allowing the container to write to the filesystem despite the profile being applied. The annotation is correctly formatted, and the profile is loaded, so enforcement depends on the mode.
Exam trap
CNCF often tests the distinction between enforce and complain modes in AppArmor, where candidates assume a loaded profile is always enforced, but the `-C` flag changes behavior to logging-only.
How to eliminate wrong answers
Option A is wrong because a privileged container would bypass AppArmor entirely, but the question states the profile is loaded and the annotation is set, so the issue is about enforcement mode, not privilege. Option C is wrong because `allowPrivilegeEscalation` controls whether processes can gain more privileges than their parent, but it does not affect AppArmor profile enforcement; AppArmor enforces regardless of privilege escalation settings. Option D is wrong because the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write' is correctly formatted per Kubernetes conventions, using the profile name prefixed with 'localhost/'.
You run 'kubectl auth can-i --list --as=system:serviceaccount:kube-system:my-sa' and see that my-sa has cluster-admin access. What is the BEST way to reduce privileges?
Removing the binding eliminates the excessive privileges.
Why this answer
Option B is correct because the service account 'my-sa' has cluster-admin privileges due to a ClusterRoleBinding that binds it to the 'cluster-admin' ClusterRole. Deleting that specific ClusterRoleBinding removes the excessive permissions without affecting other subjects or the underlying ClusterRole, which is shared and may be needed by other users or components. This is the most targeted and least disruptive approach to reduce privileges.
Exam trap
CNCF often tests the misconception that modifying a ClusterRole or recreating a service account is sufficient to revoke privileges, when in reality the binding is the source of the permission grant and must be removed directly.
How to eliminate wrong answers
Option A is wrong because deleting and recreating the service account does not remove the existing ClusterRoleBinding; the new service account would still be bound to the same ClusterRoleBinding and retain cluster-admin access. Option C is wrong because creating a new RoleBinding with fewer privileges in the kube-system namespace does not revoke the existing ClusterRoleBinding; the service account would still have cluster-admin access from the binding, and RoleBindings are namespace-scoped and cannot override a ClusterRoleBinding. Option D is wrong because modifying the 'cluster-admin' ClusterRole would affect all subjects bound to it, including other service accounts and users, potentially breaking critical system components that rely on its permissions.
To disable service account token automount for a pod, which field should be set to false in the pod spec?
Setting this to false prevents automatic token mounting.
Why this answer
In Kubernetes, the `automountServiceAccountToken` field in the Pod spec, when set to `false`, prevents the automatic mounting of the service account token (a JWT) into the pod's containers. This is a security hardening measure to reduce the attack surface, as the token could be used to authenticate to the Kubernetes API server if compromised. The default behavior is `true`, meaning the token is automatically mounted unless explicitly disabled.
Exam trap
The trap here is that candidates confuse the Pod spec field name with the ServiceAccount-level field or invent plausible-sounding names like `automountToken` or `enableServiceAccountToken`, while the exact API field is `automountServiceAccountToken`.
How to eliminate wrong answers
Option B is wrong because `serviceAccountToken` is not a valid field in the Pod spec; the correct field is `automountServiceAccountToken`. Option C is wrong because `automountToken` is not a recognized Kubernetes field; the exact API field name is `automountServiceAccountToken`. Option D is wrong because `enableServiceAccountToken` does not exist in the Pod spec; the field to disable automount is `automountServiceAccountToken`, not an enable/disable toggle.
Which TWO of the following are valid RuntimeClass handlers for container sandboxing?
Handler for gVisor.
Why this answer
gVisor uses the runsc handler. Kata Containers use kata or kata-qemu. runc is the default runtime for regular containers, not sandboxing. docker is not a RuntimeClass handler. crun is another runtime but not specifically for sandboxing.
During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes from the node level without entering the container?
This runs ps aux inside the container, listing all processes.
Why this answer
kubectl exec into the container and running 'ps aux' is the standard way to view processes inside the container. The other options: kubectl top pod shows resource usage, not processes; kubectl logs shows logs; kubectl describe pod shows metadata.
A developer wants to create a Deployment that runs as a non-root user. Which YAML snippet correctly sets the security context to run the container with UID 1000?
Setting runAsUser at the container level ensures the container runs with that UID.
Why this answer
Option A is correct. The securityContext field at the container level with runAsUser: 1000 ensures the container runs as a non-root user. Option B uses runAsGroup which is for group ID, not user ID.
Option C places securityContext at the pod level, which also works but is not the only correct approach. Option D uses the incorrect field name 'runAsNonRoot' which is a boolean and does not set the UID.
A node in your cluster is running unnecessary services that increase the attack surface. Which of the following is the BEST approach to reduce the attack surface on the node?
Disabling and removing unnecessary services reduces the attack surface directly.
Why this answer
The best approach is to disable and remove unnecessary services on the node. This directly reduces the attack surface. Option A is correct.
Option B is incorrect because disabling only during maintenance leaves the node vulnerable during normal operation. Option C is incorrect because firewalls can block ports but services may still be exploitable. Option D is incorrect because AppArmor can confine services but does not remove them.
Which of the following is the correct way to drop all capabilities from a container in a pod specification?
Correct: 'drop: ALL' drops all capabilities.
Why this answer
Option B is correct because in Kubernetes, to drop all capabilities from a container, you must set `capabilities.drop` to `ALL` under the `securityContext`. The `capabilities` field is a standard part of the container's security context, and `drop` is the correct key to specify capabilities to remove. Using `ALL` (uppercase) ensures all capabilities defined by the Linux kernel (e.g., CAP_NET_RAW, CAP_SYS_ADMIN) are dropped, which is a best practice for minimizing privilege escalation risks.
Exam trap
CNCF often tests the distinction between the correct `capabilities.drop` field and common misspellings like `dropCapabilities` or `remove`, and the requirement for uppercase `ALL` versus lowercase `all`.
How to eliminate wrong answers
Option A is wrong because `dropCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option C is wrong because it uses lowercase `"all"` instead of uppercase `ALL`; Kubernetes expects the string `ALL` in uppercase to match the Linux capability naming convention. Option D is wrong because `remove` is not a valid key under `capabilities`; the correct key is `drop`.
Match each etcd security configuration to its description.
Drag a concept onto its matching description — or click a concept then click the description.
Encrypts communication between etcd clients and the etcd server
Encrypts communication between etcd cluster members
Requires clients to present a valid certificate to access etcd
Encrypts etcd data stored on disk (requires manual configuration)
Limits which users or clients can perform operations on etcd keys
Why these pairings
Securing etcd is critical because it stores all cluster data.
Which TWO of the following are valid audit stages in Kubernetes? (Select 2)
ResponseStarted is a valid audit stage, logged when the response headers are sent.
Why this answer
The valid audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived and ResponseComplete are among them. 'RequestEvaluated' and 'ResponseSent' are not valid stages.
After setting up etcd encryption at rest using EncryptionConfiguration with aescbc, which resource stores the encryption key?
The encryption key is defined in the EncryptionConfiguration YAML file under the 'keys' section. This file is passed to the API server via --encryption-provider-config.
Why this answer
When etcd encryption at rest is configured via an EncryptionConfiguration file, the encryption key is defined within that file itself under the 'keys' field for the specified provider (e.g., aescbc). The EncryptionConfiguration file is passed to the kube-apiserver via the --encryption-provider-config flag, and the key material is read from this file at startup. No separate Secret or ConfigMap stores the key; the file is the authoritative source.
Exam trap
The trap here is that candidates assume encryption keys must be stored in a Kubernetes Secret (like other secrets in kube-system), but the EncryptionConfiguration file itself is the sole storage for the key material, and it is not managed as a Kubernetes resource.
How to eliminate wrong answers
Option A is wrong because there is no 'etcd' namespace in Kubernetes; etcd runs as a static pod or systemd service, and ConfigMaps are not used to store encryption keys for etcd. Option B is wrong because while Secrets in kube-system store sensitive data like service account tokens, the etcd encryption key is not stored as a Kubernetes Secret; it resides in the EncryptionConfiguration file. Option D is wrong because annotations on the etcd pod are metadata only and cannot store the encryption key; the key is not injected via annotations.
Which of the following is a static analysis tool for Kubernetes manifests that can be used to find misconfigurations?
Kubesec scans Kubernetes manifests for security issues.
Why this answer
Kubesec is a static analysis tool that evaluates Kubernetes resource YAML against security best practices and assigns a score.
What is the correct way to specify a container image using a SHA digest instead of a tag for immutable deployments?
The digest uniquely identifies the image content.
Why this answer
Using the digest ensures the exact image is used. Option B is correct.
What is the purpose of using a non-root user in a container image?
Non-root users have fewer privileges, limiting the impact of a breach.
Why this answer
Running containers as a non-root user reduces the risk of privilege escalation attacks. If an attacker compromises the container, they will have limited permissions.
Which TWO of the following are required to enable encryption of Kubernetes Secrets at rest?
Defines the encryption providers and keys.
Why this answer
EncryptionConfiguration is the resource that defines encryption providers and keys. The kube-apiserver must be configured with the --encryption-provider-config flag pointing to that file. --feature-gates is not needed as encryption is GA. etcd encryption is not directly configured via etcdctl.
You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?
This is a container-level hardening measure. While beneficial, it does not directly harden the node itself.
Why this answer
Option C is the least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.
Exam trap
The trap here is that candidates confuse container-level security controls (like dropping capabilities) with node-level hardening, assuming any security measure applied to containers also hardens the underlying node, when in fact node hardening requires direct OS and infrastructure changes.
How to eliminate wrong answers
Option A is wrong because restricting SSH access via firewall rules directly reduces the node's network attack surface by limiting administrative access, which is a fundamental node hardening practice. Option B is wrong because disabling unnecessary services like telnet and rsh eliminates legacy, unencrypted protocols that could be exploited to compromise the node, making it a critical hardening step. Option D is wrong because applying the latest security patches to the host kernel addresses known vulnerabilities in the node's core operating system, which is essential for node-level security.
You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?
Trivy fs scans the filesystem for vulnerabilities and misconfigurations in files including Dockerfiles and Kubernetes manifests.
Why this answer
Trivy fs scans a filesystem for vulnerabilities and misconfigurations, including Dockerfiles and Kubernetes manifests. Option A is correct.
Which admission controller is responsible for validating and mutating requests based on webhooks?
These admission controllers enable custom webhooks for validation and mutation.
Why this answer
ValidatingAdmissionWebhook and MutatingAdmissionWebhook are the admission controllers that call external webhooks. The question asks which controller handles both; the webhook infrastructure is managed by these controllers.
Which etcd security measure should be implemented to ensure only authorized clients can access the etcd cluster?
TLS ensures that only clients presenting valid certificates can connect to etcd.
Why this answer
Option C is correct because enabling TLS client-to-server authentication (mutual TLS) ensures that only clients presenting a valid certificate signed by a trusted Certificate Authority (CA) can communicate with the etcd cluster. This cryptographically verifies the client's identity, preventing unauthorized access and man-in-the-middle attacks. Without client certificate validation, any client with network access could potentially interact with etcd, compromising the Kubernetes control plane.
Exam trap
CNCF often tests the distinction between authentication (verifying identity) and authorization (controlling actions), so candidates may mistakenly choose RBAC (Option D) thinking it controls access, when in fact TLS client authentication is the prerequisite for ensuring only authorized clients can connect.
How to eliminate wrong answers
Option A is wrong because enabling anonymous authentication on etcd would allow unauthenticated clients to access the cluster, directly contradicting the requirement to restrict access to authorized clients only. Option B is wrong because configuring etcd to listen on localhost only restricts network access to the local machine, which is impractical for a multi-node etcd cluster and does not provide authentication or authorization for clients that do have access. Option D is wrong because etcd RBAC (role-based access control) controls what operations an authenticated user can perform, but it does not authenticate the client itself; without TLS client authentication, an attacker could still connect and attempt to exploit RBAC misconfigurations.
Which TWO of the following are recommended CIS benchmark practices for securing etcd? (Choose two.)
CIS recommends using TLS to secure communication between the API server and etcd.
Why this answer
Option A is correct because the CIS benchmark for etcd recommends using TLS certificates for client-to-server communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores critical cluster state and secrets.
Exam trap
CNCF often tests the misconception that disabling authentication reduces latency and is acceptable for performance, but the CIS benchmark explicitly requires authentication and encryption for all etcd communication, and candidates may overlook the security implications of running etcd as root or exposing it publicly.
An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?
EncryptionConfiguration is a resource that defines how to encrypt data at rest. The kube-apiserver reads it via the flag.
To enforce Pod Security Standards at the namespace level, which admission plugin must be enabled on the API server?
This plugin enforces Pod Security Standards.
Why this answer
Pod Security Standards (PSS) are enforced at the namespace level using the PodSecurity admission plugin, which was introduced in Kubernetes v1.23 and graduated to stable in v1.25. This plugin evaluates pods against the predefined security levels (privileged, baseline, restricted) based on labels on the namespace, replacing the deprecated PodSecurityPolicy.
Exam trap
CNCF often tests the distinction between the deprecated PodSecurityPolicy (PSP) and the current PodSecurity admission plugin, leading candidates to mistakenly select PSP because they recall 'Pod Security' in the name, but PSP is no longer available in recent Kubernetes versions.
How to eliminate wrong answers
Option A is wrong because SecurityContextDeny is a deprecated admission plugin that only rejects pods with specific security context settings (like privileged containers) but does not implement the three-tier Pod Security Standards. Option B is wrong because NodeRestriction is an admission plugin that limits the kubelet's ability to modify node and pod objects, not related to enforcing pod security policies. Option C is wrong because PodSecurityPolicy (PSP) is a deprecated admission plugin that was removed in Kubernetes v1.25; it enforced security policies at the cluster level via PSP resources, not at the namespace level using Pod Security Standards.
A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?
Dropping all then adding only needed capabilities is the correct approach for least privilege.
Why this answer
Option A is correct because the security policy requires dropping all Linux capabilities and only adding the necessary ones. The configuration `cap_drop: ["ALL"]` removes every capability from the container, and `cap_add: ["NET_BIND_SERVICE"]` explicitly adds back only the `CAP_NET_BIND_SERVICE` capability, which allows binding to privileged ports (below 1024). This follows the principle of least privilege by starting from a clean slate and granting only what is needed.
Exam trap
CNCF often tests the misconception that simply adding a capability is sufficient, without realizing that the default capability set includes many capabilities (e.g., `CHOWN`, `DAC_OVERRIDE`, `FOWNER`, `FSETID`, `KILL`, `SETGID`, `SETUID`, `SETPCAP`, `NET_BIND_SERVICE`, `NET_RAW`, `SYS_CHROOT`, `MKNOD`, `AUDIT_WRITE`, `SETFCAP`) and that dropping all first is mandatory to enforce least privilege.
How to eliminate wrong answers
Option B is wrong because `cap_drop: ["NET_RAW"]` only drops the `CAP_NET_RAW` capability, leaving all other capabilities intact, which violates the requirement to drop all capabilities first. Option C is wrong because `cap_add: ["ALL"]` adds every capability, which is the opposite of dropping all capabilities and contradicts the security policy. Option D is wrong because `cap_add: ["NET_BIND_SERVICE"]` without a preceding `cap_drop: ["ALL"]` only adds the capability on top of the default set, which still includes many unnecessary capabilities, failing to meet the 'drop all' requirement.
Which Kyverno policy action is used to automatically mutate a resource to add a sidecar container for security?
Mutate rules can automatically modify resources, such as injecting sidecars.
Why this answer
Kyverno's 'mutate' rule can modify resources during admission, such as injecting a sidecar container.
Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?
Identifies known CVEs.
Why this answer
Option A is correct because scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide.
Exam trap
CNCF often tests the misconception that `imagePullSecrets` (Option C) are used to restrict which images can be pulled from registries, but in reality, `imagePullSecrets` only authenticate to private registries and do not enforce any access control or policy on which images are allowed to be pulled; for restriction, you need an admission controller like OPA/Gatekeeper or a registry firewall.
Which TWO of the following are correct ways to apply a seccomp profile named 'audit.json' located on each node? (Select two.)
This is the current recommended way.
Why this answer
Option C is correct because in Kubernetes v1.19+, the `securityContext.seccompProfile` field is the stable API for configuring seccomp profiles. Setting `type: Localhost` and `localhostProfile: audit.json` instructs the kubelet to load the profile from the node's local seccomp directory (typically `/var/lib/kubelet/seccomp/audit.json`). This is the recommended approach for applying a node-local seccomp profile to a pod or container.
Exam trap
CNCF often tests the distinction between the deprecated alpha annotation format (which requires the `localhost/` prefix in the value) and the stable `securityContext.seccompProfile` API, and candidates mistakenly omit the `localhost/` prefix in the annotation value or confuse the field names `localhostProfile` vs `profile`.
A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?
Scans the final image and prevents vulnerable images from being pushed to the registry.
Why this answer
Option C is correct because integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.
Exam trap
CNCF often tests the distinction between shift-left security (preventing vulnerabilities at build time) versus runtime enforcement (admission controllers), and the trap here is that candidates choose admission controllers (Option A) because they seem to block vulnerable images, but they fail to realize that the image must already exist in the registry and may have been built with vulnerabilities, whereas CI/CD scanning prevents the image from being created in the first place.
How to eliminate wrong answers
Option A is wrong because a Kubernetes admission controller like Kyverno can only reject pods at deployment time, but the image may already be in the registry with known CVEs, and the admission controller relies on metadata or external scans that may not be up-to-date; it also does not prevent the image from being built or stored. Option B is wrong because scanning only the base image before building the application image does not account for vulnerabilities introduced by the application layer or dependencies added during the build process, leaving the final image potentially vulnerable. Option D is wrong because manually reviewing vulnerability reports after deployment is reactive and does not prevent vulnerable images from running in production, violating the requirement to ensure no container runs with critical vulnerabilities.
Which TWO of the following are recommended settings from the CIS Kubernetes Benchmark for the kube-apiserver? (Select 2)
Disables anonymous authentication.
Why this answer
Option A is correct because disabling anonymous authentication with `--anonymous-auth=false` ensures that all requests to the kube-apiserver must be authenticated, preventing unauthenticated access. This is a key hardening measure recommended by the CIS Kubernetes Benchmark to enforce identity verification for every API call.
Exam trap
CNCF often tests the distinction between flags that apply to different control plane components; candidates mistakenly apply profiling or insecure bind settings from other components to the kube-apiserver, or confuse `--client-cert-auth` with the actual `--client-ca-file` flag.
A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?
Correct. The profile is assumed to be in /var/lib/kubelet/seccomp/.
Why this answer
The correct way to reference a localhost seccomp profile is to set type: Localhost and localhostProfile: the profile filename.
Which TWO of the following are valid ways to enforce that a container runs as a non-root user?
This enforces that the container cannot run as root.
You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?
This is the correct resource for configuring encryption at rest.
Why this answer
Option D is correct because the Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.
Exam trap
CNCF often tests the exact resource name and API group, and the trap here is that candidates confuse `EncryptionConfiguration` with made-up names like `EtcdEncryption` or `SecretEncryption`, or incorrectly assume it belongs to the core `v1` API group instead of `apiserver.config.k8s.io`.
How to eliminate wrong answers
Option A is wrong because `EtcdEncryption` is not a valid Kubernetes resource; the correct resource is `EncryptionConfiguration`. Option B is wrong because `EncryptionConfig` with `apiVersion v1` does not exist; the resource is `EncryptionConfiguration` under `apiserver.config.k8s.io`, not core `v1`. Option C is wrong because `SecretEncryption` is not a real resource; Kubernetes uses `EncryptionConfiguration` to configure encryption at rest, not a resource named after the object type.
You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?
Disables anonymous auth and uses webhook authorization.
Why this answer
Option D is correct because setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.
Exam trap
The trap here is that candidates confuse kubelet authorization modes with API server authorization modes, mistakenly selecting `RBAC` (Option A) which is not a valid kubelet flag, while overlooking that `Webhook` is the correct mode to enforce RBAC-like policies on the kubelet.
How to eliminate wrong answers
Option A is wrong because `--authorization-mode=RBAC` is not a valid kubelet flag; the kubelet supports `AlwaysAllow`, `Webhook`, and `ABAC` modes, but RBAC is an API server authorization mode, not a kubelet one. Option B is wrong because `--anonymous-auth=true` allows anonymous requests, which contradicts the requirement to disallow them, and `--authorization-mode=ABAC` is deprecated and less secure than Webhook for dynamic authorization. Option C is wrong because `--authorization-mode=AlwaysAllow` permits all authenticated requests without any authorization checks, failing to restrict APIs to only those explicitly allowed.
An admin wants to check which AppArmor profiles are loaded. Which command should they run?
aa-status displays loaded profiles and their modes.
Why this answer
'aa-status' shows the status of AppArmor including loaded profiles. Option A is correct. 'apparmor_status' is an alias; but 'aa-status' is the standard. Option B shows seccomp status.
Option C lists files in a directory. Option D is not a command.
Which THREE are valid methods to enforce that only images from a specific registry can be deployed in a Kubernetes cluster? (Select three.)
ImagePolicyWebhook can enforce image policies including registry allowlists.
Why this answer
OPA/Gatekeeper, ImagePolicyWebhook, and Kyverno can enforce registry allowlists. PodSecurityPolicy is deprecated and removed; NetworkPolicy does not control image sources.
A security engineer needs to apply a custom AppArmor profile to a pod. The profile is named 'k8s-apparmor-example-deny-write' and is loaded on the node. Which annotation should be added to the pod's metadata to enforce this profile?
This annotation correctly references the local profile using the 'localhost/' prefix.
Why this answer
Option C is correct because the AppArmor annotation for a container follows the format `container.apparmor.security.beta.kubernetes.io/<container-name>` and the profile name must be prefixed with `localhost/` when referencing a profile loaded on the node. The annotation value `"localhost/k8s-apparmor-example-deny-write"` correctly specifies the node-local profile.
Exam trap
CNCF often tests the requirement for the `localhost/` prefix in the annotation value, causing candidates to pick Option D which omits it, or Option A which uses the wrong annotation key format.
How to eliminate wrong answers
Option A is wrong because the annotation prefix is `container.apparmor.security.beta.kubernetes.io/`, not `apparmor.security.beta.kubernetes.io/`. Option B is wrong because the annotation suffix should be the container name, not the pod name. Option D is wrong because it omits the required `localhost/` prefix; without it, Kubernetes treats the value as an invalid profile reference.
A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?
This configuration enforces the restricted profile, which drops all capabilities except the minimal default set.
Why this answer
The restricted Pod Security Standard drops all capabilities except those required for default operation, and does not allow 'cap_add' beyond the restricted set. The correct enforcement is to use 'restricted' level with 'enforce' mode. Option A is the correct configuration.
Option B uses 'baseline' which is less restrictive. Option C is incorrect because 'privileged' allows all capabilities. Option D is incorrect because 'warn' does not enforce.
Which command can be used to check if the API server has anonymous authentication enabled?
This shows the kube-apiserver's flags including anonymous-auth.
Why this answer
Option B is correct because the kube-apiserver pod's manifest (or its runtime configuration) contains the `--anonymous-auth` flag. By inspecting the pod's YAML with `kubectl describe pod kube-apiserver -n kube-system` and grepping for `anonymous-auth`, you can see whether the flag is set to `true` (enabled) or `false` (disabled). This is the direct way to check the API server's runtime configuration for anonymous authentication.
Exam trap
CNCF often tests the misconception that RBAC commands (like `kubectl auth can-i`) can detect server-level flags, when in fact they only test authorization after authentication has already succeeded, making them useless for checking if anonymous auth is enabled.
How to eliminate wrong answers
Option A is wrong because `kubectl get clusterrole cluster-admin -o yaml` shows the permissions of the `cluster-admin` ClusterRole, which has no bearing on whether the API server accepts anonymous requests; anonymous authentication is a server-level flag, not a RBAC setting. Option C is wrong because `kubectl get node -o yaml` displays node metadata and status, which contains no information about the API server's authentication configuration. Option D is wrong because `kubectl auth can-i --list --as=system:anonymous` checks what actions the `system:anonymous` user can perform *after* authentication, but it does not reveal whether anonymous authentication is enabled; if anonymous auth is disabled, the command would fail with an authentication error, but the command itself does not inspect the server's flag.
An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?
Cordoning a node marks it as unschedulable, resulting in SchedulingDisabled.
Why this answer
The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon <node>', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.
Exam trap
CNCF often tests the distinction between taints (which affect scheduling based on tolerations) and cordoning (which makes the node completely unschedulable), leading candidates to confuse taint-based scheduling restrictions with the explicit unschedulable flag.
How to eliminate wrong answers
Option A is wrong because if the kubelet were not running, the node status would be 'NotReady' or 'Unknown', not 'Ready,SchedulingDisabled'. Option C is wrong because insufficient resources would cause the node to report conditions like 'MemoryPressure' or 'DiskPressure', not the specific 'SchedulingDisabled' marker. Option D is wrong because a NoSchedule taint prevents pod scheduling via the scheduler's taint-toleration mechanism, but the node status would still show 'Ready' without the 'SchedulingDisabled' suffix; the node remains schedulable for pods that tolerate the taint.
A Falco rule has priority: CRITICAL and condition: evt.type=execve and proc.name!=bash. What does this rule detect?
Without a container filter, the rule applies to all execve events, including host.
Why this answer
It triggers on execve syscalls where the process name is not bash, but the condition doesn't specify container context, so it may fire on host processes as well.
A security team wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?
Falco on the host can detect container process anomalies without modifying images.
Why this answer
Falco, deployed as a DaemonSet with an eBPF probe, can monitor system calls at the kernel level without modifying container images or requiring agents inside containers. This allows it to detect anomalous process executions in real time by analyzing syscall events from the host, which is the most suitable approach for runtime security monitoring in Kubernetes.
Exam trap
CNCF often tests the distinction between admission control (e.g., OPA Gatekeeper) and runtime monitoring (e.g., Falco), where candidates mistakenly choose a policy enforcement tool for detection tasks.
How to eliminate wrong answers
Option A is wrong because CRI-O does not natively log all container process starts to syslog; it manages container runtime operations but lacks built-in process-level auditing. Option C is wrong because Kubernetes audit logging captures API server requests (e.g., pod creation), not process executions within containers, so it cannot detect anomalous process starts. Option D is wrong because OPA Gatekeeper enforces admission control policies on pod specs (e.g., allowed process lists) but does not monitor runtime behavior or detect anomalies after a container is running.
Which admission plugin should be enabled on the kubelet to ensure it only registers nodes and sets labels as allowed by the Node REST API?
NodeRestriction limits the kubelet's self-modification capabilities, enhancing security.
Why this answer
The NodeRestriction admission plugin is the correct choice because it limits the kubelet's ability to modify node and pod labels, ensuring that nodes can only register themselves and set labels that are explicitly allowed by the Node REST API. This plugin enforces a whitelist of labels that the kubelet can set, preventing privilege escalation through label manipulation.
Exam trap
CNCF often tests the NodeRestriction plugin by pairing it with other admission controllers like PodSecurity or AlwaysPullImages, leading candidates to confuse node-level restrictions with pod-level security policies.
How to eliminate wrong answers
Option A is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on pods, not node registration or label restrictions. Option C is wrong because DenyEscalatingExec is a deprecated admission plugin that prevents exec and attach commands to pods with escalated privileges, unrelated to node registration. Option D is wrong because AlwaysPullImages forces every pod to pull container images with the specified pull policy, which does not control node registration or label setting.
A pod has been compromised. You want to isolate it from other pods while preserving its network state for forensics. Which NetworkPolicy rule achieves this?
This denies all traffic to/from that specific pod.
Why this answer
A NetworkPolicy with podSelector matching the compromised pod and ingress/egress rules that deny all traffic except to specific endpoints needed for investigation.
Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)
Correct. seccompProfile is used in the security context.
Why this answer
Option A is correct because the `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.
Exam trap
CNCF often tests the misconception that seccomp only applies to privileged containers or that it can only deny syscalls, when in fact it is a general-purpose syscall filter for all containers and supports both allow and deny actions.
Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)
Parent process name; shell often spawned by another process.
Why this answer
Falco's 'proc.name' matches the process name (e.g., bash, sh). 'container.id' identifies the container. 'evt.type' is for syscall type, not process name. 'k8s.ns.name' is namespace, not shell detection. 'fd.name' is file path.
Which tool can generate an SBOM for a container image?
Syft generates SBOMs from container images.
Why this answer
Syft is a CLI tool that generates Software Bill of Materials (SBOM) from container images and filesystems.
Which of the following is a BEST practice for securing container images in a Dockerfile?
This follows the principle of least privilege.
Why this answer
Using a non-root user in the container reduces the impact of a compromise. The other options are insecure or less effective.
An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?
PeerAuthentication with mtls.mode: STRICT enforces mTLS for all services in the namespace.
Why this answer
PeerAuthentication is the Istio resource that defines how traffic is handled at the sidecar proxy level. Setting mode: STRICT requires mTLS for all traffic in the namespace.
Which command is used with Cosign to sign a container image?
Correct command to sign an image.
Why this answer
Cosign is a tool for signing and verifying container images. The 'cosign sign' command signs an image, and 'cosign verify' verifies a signature.
An administrator wants to enforce that all pods in a namespace use the restricted Pod Security Standard. Which of the following commands correctly enables this enforcement?
Correct. This label enforces the restricted Pod Security Standard at the namespace level.
Why this answer
Option C is correct because the Pod Security Standards are enforced via labels on the namespace, and the `pod-security.kubernetes.io/enforce` label with value `restricted` tells the Pod Security Admission controller to reject any pod that violates the restricted policy. This is the only way to actively block non-compliant pods from being created in the namespace.
Exam trap
CNCF often tests the distinction between labels and annotations, and the trap here is that candidates confuse `kubectl annotate` with `kubectl label` for setting Pod Security Standard enforcement, or they pick `audit` or `warn` thinking they enforce the policy.
How to eliminate wrong answers
Option A is wrong because `pod-security.kubernetes.io/audit` only logs violations without blocking them, so it does not enforce the policy. Option B is wrong because Pod Security Standards use labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be applied as a label for the admission controller to recognize it. Option D is wrong because `pod-security.kubernetes.io/warn` only generates a warning message for the user but still allows the pod to be created, so it does not enforce the restricted standard.
Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)
This is a deprecated method but still valid in older clusters.
Why this answer
Seccomp profiles can be set via the container's securityContext.seccompProfile field (option A) or via the deprecated pod annotation (option D). Option B is a PSP field, not applicable to seccomp. Option C is for AppArmor.
Option E is not a valid annotation.
You need to encrypt Kubernetes secrets at rest using aescbc. Which YAML snippet defines the EncryptionConfiguration correctly?
Correct structure with aescbc and identity fallback.
Why this answer
Option A is correct because it defines an EncryptionConfiguration with the correct apiVersion (apiserver.config.k8s.io/v1), kind (EncryptionConfiguration), and a valid provider list. It uses the aescbc provider with a base64-encoded key (c2VjcmV0LWtleS0zMi1ieXRlcw==) for encrypting secrets, and includes the identity provider as a fallback to allow reading existing unencrypted data. This configuration ensures that secrets are encrypted at rest using AES-CBC with a properly encoded 32-byte key.
Exam trap
CNCF often tests the requirement that the aescbc provider's secret must be base64-encoded (not plain text) and that the correct apiVersion/kind must be used, leading candidates to pick options with plain-text keys or wrong resource types.
How to eliminate wrong answers
Option B is wrong because the secret value for the aescbc provider must be base64-encoded, not a plain-text key like 'my-plain-text-key'; Kubernetes expects the key to be base64-decoded to obtain the raw 32-byte key for AES-CBC. Option C is wrong because it uses an incorrect apiVersion 'v1' and kind 'EncryptionConfig' — the correct apiVersion is 'apiserver.config.k8s.io/v1' and kind is 'EncryptionConfiguration'. Option D is wrong because it uses the 'secretbox' provider, which implements XSalsa20-Poly1305 encryption, not AES-CBC; the question specifically requires aescbc.
An administrator runs 'kubectl describe pod secure-pod' and sees that the pod is in a Pending state with the event 'Error: ImagePullBackOff' and the message 'unauthorized: authentication required'. The image is stored in a private registry. What is the most likely cause?
The error indicates authentication failure. Creating an imagePullSecret with valid registry credentials and adding it to the pod spec resolves the issue.
Why this answer
The 'unauthorized: authentication required' error indicates that the cluster cannot authenticate to the private registry. The fix is to create an imagePullSecret with valid registry credentials and reference it in the pod spec. Option A is incorrect because the image exists.
Option B is incorrect because DNS resolution would produce a different error. Option D is a valid practice but not the cause.
A security team wants to ensure that no pod runs with privileged access. They have created a PodSecurityPolicy (PSP) that sets 'privileged: false'. However, a pod with privileged: true still gets created. What is the most likely cause?
Without authorization, the PSP does not apply; the user may be using a default PSP that allows privileged.
Why this answer
A is correct because PodSecurityPolicy (PSP) requires the user or service account creating the pod to have a RoleBinding or ClusterRoleBinding that grants the `use` verb on the PSP resource. Without this RBAC authorization, the PSP is not enforced for that user, even if the PSP exists and the admission controller is enabled. The pod with `privileged: true` bypasses the PSP because the creating identity lacks the necessary RBAC permissions to trigger the PSP's validation.
Exam trap
CNCF often tests the misconception that simply creating a PSP is enough to enforce restrictions, but the trap here is that PSP enforcement requires explicit RBAC binding—without it, the PSP is effectively ignored for the pod's creator.
How to eliminate wrong answers
Option B is wrong because pod priority does not override PSP enforcement; PSP is an admission controller that evaluates all pods regardless of priority class. Option C is wrong because if the PodSecurityPolicy admission controller were not enabled, no PSP would be enforced at all, but the question states a PSP was created and the pod still gets created, implying the controller is active (otherwise the PSP would be irrelevant). Option D is wrong because PSPs are cluster-scoped resources evaluated at pod creation time; the order of creation does not affect enforcement—if the PSP exists before the pod creation attempt, it applies.
Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?
A mutating webhook can automatically inject the setting.
Why this answer
Options A and D are correct. Setting `readOnlyRootFilesystem: true` in the container's securityContext enforces a read-only root filesystem. A mutating webhook can also add this setting automatically.
Option B is incorrect because `runAsNonRoot` does not affect filesystem writability. Option C is incorrect because `securityContext.fsGroup` is about file ownership. Option E is incorrect because `emptyDir` volumes are writable but do not enforce a read-only root.
An administrator runs 'kubectl run test-pod --image=nginx --dry-run=client -o yaml > pod.yaml', then adds 'hostPID: true' and 'hostNetwork: true' to the pod's spec. After applying with 'kubectl apply -f pod.yaml', the pod is created but immediately goes into 'CrashLoopBackOff'. What is the likely cause?
HostPID and hostNetwork are restricted in baseline and restricted levels, causing the pod to be rejected or crash.
Why this answer
The pod violates the Pod Security Standard of the namespace. If the namespace has an enforce label set to 'baseline' or 'restricted', it would block hostPID/hostNetwork unless the pod is exempted. Option A is correct because the PodSecurity admission plugin would deny the pod or at least warn.
Option B is less likely as OOMKilled would show a different status. Option C is not a known issue. Option D is plausible but not the most direct cause given the scenario.
You need to create a NetworkPolicy that allows only ingress traffic from pods with label 'app: frontend' in the same namespace. Which policyType and ingress rule should you use?
Correct: This restricts ingress to pods with label app: frontend.
Why this answer
The correct policy uses 'policyTypes: [Ingress]' and an ingress rule with a podSelector matching 'app: frontend'. Option B uses podSelector: {} which selects all pods, option C has no ingress rule, option D uses namespaceSelector incorrectly.
A security policy requires that all container images must have a signed attestation. Which Cosign command would an admin add to the CI pipeline to create this attestation?
Creates a signed attestation with a predicate.
Why this answer
Cosign can create in-toto attestations that include metadata about the image. The 'cosign attest' command creates an attestation and signs it.
An audit policy is configured with the following rule: - level: RequestResponse users: ["system:serviceaccount:kube-system:admin"] verbs: ["get", "list"] resources: - group: "" resources: ["secrets"] What will be logged when the service account 'admin' in kube-system performs a GET request on a Secret?
RequestResponse level logs both the request and the response objects.
Why this answer
The rule matches the user, verb, and resource, and sets level to RequestResponse. According to audit policy, this means the log entry will include the request and the response (metadata and body). Option A is correct.
A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?
This correctly references the custom profile.
Why this answer
To use a custom seccomp profile, set type to 'Localhost' and localhostProfile to the path relative to the seccomp directory. Option A is correct. Option B uses 'RuntimeDefault' which is not custom.
Option C uses 'Unconfined'. Option D is invalid.
A compromised pod is making unexpected outbound connections. You want to isolate the pod by blocking all egress traffic while keeping it running for forensic analysis. Which action is correct?
Correct. A NetworkPolicy with an empty egress list (or egress: []) will deny all egress traffic by default. This isolates the pod while keeping it running.
Why this answer
Applying a NetworkPolicy that denies all egress traffic (podSelector: {} with no egress rules) while allowing all ingress (to continue receiving requests) will isolate the pod. The policy must target the specific pod via podSelector. Option C achieves this.
You need to enforce that all images deployed in the cluster are signed by a trusted key. Which Kubernetes admission control mechanism would you use?
ImagePolicyWebhook can be configured to verify image signatures by calling an external service.
Why this answer
ImagePolicyWebhook is an admission controller that can validate image signatures before allowing a pod to run. Option C is correct.
You need to configure a NetworkPolicy that allows egress traffic only to an external database at IP 10.0.0.5 on port 5432, and denies all other egress. Which policy BEST achieves this?
This policy allows egress only to the specified IP and port, and denies all other egress due to default deny.
Why this answer
The correct policy has an egress rule that allows traffic to 10.0.0.5 on port 5432, and no other egress rules, so all other egress is denied by default.
Which THREE of the following are valid methods to disable automount of service account tokens for a pod?
Correct service account level setting.
Why this answer
Option C is correct because setting `automountServiceAccountToken: false` in the ServiceAccount YAML disables automatic mounting of the service account token for all pods that use that ServiceAccount. This is a declarative way to prevent the Kubernetes API server from injecting the token volume into pods, which is a key security hardening step to reduce the attack surface from compromised pods.
Exam trap
CNCF often tests the distinction between the Pod spec field (`spec.automountServiceAccountToken`) and the ServiceAccount field, and candidates may incorrectly think that environment variables or API server flags can disable token mounting, when only the `automountServiceAccountToken` boolean field in the Pod or ServiceAccount spec is valid.
A pod is configured with securityContext: { seccompProfile: { type: RuntimeDefault } }. Which of the following is true about this configuration?
Correct. RuntimeDefault applies the runtime's default seccomp profile.
Why this answer
Option D: RuntimeDefault uses the container runtime's default seccomp profile, which is typically the Docker/default profile. Option A is false; RuntimeDefault does not disable seccomp. Option B is false; it uses runtime's default, not custom.
Option C is false; it does not require any special permissions.
Which TWO of the following are best practices for securing secrets in Kubernetes? (Select 2)
External secret managers provide better security, auditing, and rotation capabilities.
Why this answer
Mounting secrets as volumes and using external secret managers are recommended best practices to minimize exposure.
Which THREE of the following are best practices for Dockerfile security? (Select THREE)
Pinning with digest ensures the exact image is used and prevents tag mutability.
Why this answer
Using multi-stage builds reduces size, specifying USER non-root reduces privilege, and pinning base image SHA ensures immutability. Installing tools for debugging is not recommended as it increases attack surface.
A pod is created with the following security context: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json Where must the 'audit.json' file be placed on the node?
This is the default directory for seccomp profiles.
Why this answer
For 'Localhost' seccomp profiles, the profile file must be placed in the kubelet's seccomp directory, which defaults to '/var/lib/kubelet/seccomp/'. The path provided in 'localhostProfile' is relative to that directory. So the full path becomes '/var/lib/kubelet/seccomp/profiles/audit.json'.
Option A is correct.
Which of the following securityContext settings prevents a container from using host network namespace?
Correct. Setting hostNetwork to false (default) prevents use of host network.
Why this answer
Option C is correct because setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.
Exam trap
CNCF often tests the distinction between the three namespace-related securityContext fields (`hostNetwork`, `hostIPC`, `hostPID`), and the trap here is that candidates confuse `hostIPC` or `hostPID` with network isolation, assuming any `false` setting prevents host network access.
How to eliminate wrong answers
Option A is wrong because `hostIPC: false` controls access to the host's Inter-Process Communication (IPC) namespace (e.g., shared memory segments), not the network namespace. Option B is wrong because `hostNetwork: true` would actually allow the container to share the host's network namespace, which is the opposite of preventing it. Option D is wrong because `hostPID: false` controls whether the container can see host processes via the PID namespace, not the network namespace.
Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)
This is a common security best practice.
Why this answer
Option A ensures pods don't run as root. Option B restricts host filesystem access. Option E ensures all pods use a non-default seccomp profile.
Option C (allowing privileged containers) is the opposite of best practice. Option D (allowing host network) is also not a best practice.
Practice CKS by domain
Target a specific domain to shore up weak areas.