Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 301375

720 questions total · 10pages · All types, answers revealed

Page 4

Page 5 of 10

Page 6
301
MCQmedium

What is the purpose of the `allowPrivilegeEscalation: false` setting in a container's security context?

A.It prevents the container from running as root.
B.It prevents processes from gaining additional privileges (e.g., via setuid).
C.It prevents the container from using host networking.
D.It prevents the container from accessing host devices.
AnswerB

Correct: it disables privilege escalation.

Why this answer

The `allowPrivilegeEscalation: false` setting in a container's security context directly controls whether processes within the container can gain more privileges than their parent process. This is achieved by dropping the `CAP_SETUID`, `CAP_SETGID`, and `CAP_SETPCAP` capabilities and, crucially, by setting the `no_new_privs` flag on the container's process, which prevents the use of setuid/setgid binaries and other privilege-escalation mechanisms. This is a core security control to mitigate container breakout via privilege escalation.

Exam trap

CNCF often tests the distinction between 'running as root' and 'privilege escalation' — candidates confuse `allowPrivilegeEscalation: false` with `runAsNonRoot: true`, but the former blocks the ability to gain new privileges regardless of the current user, while the latter only restricts the initial user ID.

How to eliminate wrong answers

Option A is wrong because preventing the container from running as root is achieved by setting `runAsUser: 1000` or `runAsNonRoot: true`, not by `allowPrivilegeEscalation: false`. Option C is wrong because preventing the container from using host networking is controlled by the `hostNetwork: false` setting in the Pod spec, not by the security context's privilege escalation flag. Option D is wrong because preventing access to host devices is done via `privileged: false` and not adding host device mounts, not by the `allowPrivilegeEscalation` setting.

302
Multi-Selectmedium

Which TWO of the following are effective measures to minimize the impact of a compromised microservice container in a Kubernetes cluster? (Choose two.)

Select 2 answers
A.Set resource limits (CPU/memory) on the container
B.Set the container's root filesystem as read-only
C.Apply a NetworkPolicy that restricts egress traffic to only necessary services
D.Run the container as root to simplify debugging
E.Use hostNetwork: true to share the host's network namespace
AnswersA, C

Resource limits prevent a compromised container from exhausting cluster resources.

Why this answer

Setting resource limits (CPU/memory) on a container is correct because it prevents a compromised microservice from consuming excessive cluster resources, which could lead to a denial-of-service (DoS) attack against other workloads. By enforcing limits via the container's cgroup constraints, the kernel throttles or OOM-kills the container if it exceeds its allocated resources, containing the blast radius of the compromise.

Exam trap

CNCF often tests the distinction between preventive controls (e.g., read-only filesystem, non-root user) and impact-minimization controls (e.g., resource limits, network policies), and candidates mistakenly choose read-only filesystem as an impact-minimization measure when it is actually a preventive measure.

303
MCQeasy

Which of the following flags should be set on the kube-apiserver to disable anonymous authentication?

A.--disable-anonymous-auth
B.--enable-anonymous-auth=false
C.--anonymous-auth=false
D.--anonymous-auth=off
AnswerC

This flag disables anonymous authentication.

Why this answer

The kube-apiserver uses the `--anonymous-auth` flag to control anonymous requests. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning unauthenticated requests (those without a valid bearer token or client certificate) will be rejected with a 401 Unauthorized response. This is a critical hardening step to prevent unauthorized access to the Kubernetes API server.

Exam trap

The trap here is that candidates confuse the flag name with a 'disable' or 'enable' prefix pattern common in other tools, or assume a non-boolean value like 'off' or 'false' string works, when Kubernetes strictly requires the exact `--anonymous-auth=false` syntax.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag name is `--anonymous-auth`. Option B is wrong because `--enable-anonymous-auth=false` is not a recognized flag; Kubernetes does not use an `enable-` prefix for this setting, and the flag must be `--anonymous-auth` with a boolean value. Option D is wrong because `--anonymous-auth=off` uses a string value 'off' instead of the required boolean `false`; the kube-apiserver expects a boolean (true/false), and 'off' will be interpreted as true (since it is a non-empty string), leaving anonymous auth enabled.

304
MCQmedium

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to a service account in the 'default' namespace. What is the security concern?

A.The binding should be a RoleBinding instead of ClusterRoleBinding
B.It grants too broad permissions to the service account
C.The service account name must be changed
D.The binding is fine as long as the service account is used in the default namespace
AnswerB

Correct. cluster-admin gives superuser access, which should be avoided for service accounts.

Why this answer

The 'cluster-admin' ClusterRole grants super-user permissions across the entire cluster, including access to all namespaces and all resources. Binding this role to a service account via a ClusterRoleBinding gives that service account unrestricted cluster-wide privileges, which violates the principle of least privilege. This is a significant security concern because if the service account is compromised, an attacker gains full control over the cluster.

Exam trap

The trap here is that candidates may focus on the binding type (ClusterRoleBinding vs RoleBinding) or namespace usage, rather than recognizing that the core issue is the excessive privileges of the 'cluster-admin' role itself, regardless of how it is bound.

How to eliminate wrong answers

Option A is wrong because a ClusterRoleBinding is necessary to bind a ClusterRole; a RoleBinding can only bind a ClusterRole to subjects within a specific namespace, but the security issue here is the excessive permissions of the 'cluster-admin' role itself, not the binding type. Option C is wrong because the service account name is irrelevant to the security concern; the problem is the permissions granted, not the identity. Option D is wrong because the binding is not fine; even if the service account is used only in the default namespace, the ClusterRoleBinding grants cluster-wide permissions, allowing the service account to access resources in any namespace, which is a severe security risk.

305
MCQhard

You are configuring kubelet security. Which flag prevents containers from modifying kernel parameters?

A.--read-only-port=0
B.--protect-kernel-defaults
C.--kernel-memcg-notification
D.--allow-privileged=false
AnswerB

This flag prevents containers from modifying kernel parameters.

Why this answer

The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter protections, preventing containers from modifying sensitive kernel parameters (e.g., via sysctl). This is a critical security hardening measure to maintain node stability and prevent container breakout through kernel tuning.

Exam trap

The trap here is that candidates confuse `--protect-kernel-defaults` with `--allow-privileged=false`, assuming that preventing privileged containers is sufficient to block kernel parameter changes, but non-privileged containers can still modify kernel parameters via sysctl unless explicitly restricted.

How to eliminate wrong answers

Option A is wrong because `--read-only-port=0` disables the read-only kubelet API port (10255), which reduces attack surface but does not prevent kernel parameter modification. Option C is wrong because `--kernel-memcg-notification` is a kubelet flag for memory cgroup notifications, unrelated to restricting kernel parameter changes. Option D is wrong because `--allow-privileged=false` prevents privileged containers but does not block non-privileged containers from modifying kernel parameters via sysctl or other mechanisms.

306
MCQeasy

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

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

Correct. apparmor_parser loads profiles.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

307
MCQmedium

You suspect a container has been compromised. You want to preserve the container's filesystem for forensic analysis before terminating the pod. Which approach should you use?

A.Exec into the container and delete suspicious files
B.Restart the kubelet on the node
C.Use kubectl cp to copy files from the container to a safe location
D.Immediately delete the pod to stop the attack
AnswerC

Correct. This preserves the filesystem for analysis.

Why this answer

To preserve evidence, you should not delete the pod immediately. Instead, use kubectl cp or a sidecar to copy files, or create a snapshot. But the simplest non-destructive step is to copy files from the container using 'kubectl cp' before deletion.

308
MCQhard

During a security incident, you need to snapshot the processes running inside a container without using kubectl exec. Which crictl command sequence can you use?

A.crictl pods and then crictl ps -a
B.crictl images and then crictl run <image>
C.crictl ps and then crictl exec <container-id> ps aux
D.crictl ps and then crictl inspect <container-id>
AnswerC

This lists running containers and then executes ps aux inside a specific container to snapshot processes.

Why this answer

crictl ps lists containers, then crictl exec (or crictl exec -i -t) runs a command in a container. However, crictl does not have a 'top' command; you would use ps inside the container. The question asks for a command sequence.

Option C is the most direct: list containers, then exec ps aux.

309
MCQmedium

Which crictl command is used to view the logs of a specific container in a node?

A.crictl logs <container-id>
B.crictl exec -it <container-id> sh
C.crictl pods
D.crictl ps -a
AnswerA

Correct: This command fetches logs.

Why this answer

'crictl logs <container-id>' retrieves the logs of a specific container. Option A is correct. Option B ('crictl exec -it <container-id> sh') runs a command in a running container, not logs.

Option C ('crictl pods') lists pods, not container logs. Option D ('crictl ps -a') lists all containers, but does not show logs.

310
MCQmedium

An audit policy is configured with level: Request. Which operations are recorded in the audit log?

A.Nothing, only the fact that a request occurred
B.Request metadata and the request body
C.Request and response metadata and bodies
D.Only metadata about the request
AnswerB

Request level includes metadata and request body.

Why this answer

When an audit policy is configured with `level: Request`, the API server logs the request metadata and the request body for all operations. This is defined in the Kubernetes audit policy specification, where the `Request` level captures the entire request object, including metadata and the body, but does not include the response. This level is useful for debugging and security analysis without the overhead of logging response data.

Exam trap

The CKS exam often tests the distinction between `Metadata`, `Request`, and `RequestResponse` levels, and the trap here is that candidates confuse `Request` with `Metadata`, thinking it only logs metadata, or mistakenly believe `Request` includes response data.

How to eliminate wrong answers

Option A is wrong because `level: Request` does record the request body and metadata, not just the fact that a request occurred (which would be `level: Metadata`). Option C is wrong because logging both request and response metadata and bodies corresponds to `level: RequestResponse`, not `Request`. Option D is wrong because logging only metadata about the request is the behavior of `level: Metadata`, which omits the request body.

311
MCQeasy

Which kubectl command creates a valid webhook configuration that validates pods against a policy?

A.kubectl apply -f webhookconfiguration.yaml
B.kubectl apply -f podpreset.yaml
C.kubectl apply -f mutatingwebhookconfiguration.yaml
D.kubectl apply -f validatingwebhookconfiguration.yaml
AnswerD

ValidatingWebhookConfiguration is the correct resource for validation webhooks.

Why this answer

A ValidatingWebhookConfiguration is the Kubernetes resource that intercepts API server requests to validate resources (e.g., pods) against an external policy before they are persisted. The command `kubectl apply -f validatingwebhookconfiguration.yaml` creates this configuration, which triggers a webhook call to an admission webhook server that returns an admission review with an 'allowed' or 'denied' decision.

Exam trap

The trap here is that candidates confuse ValidatingWebhookConfiguration with MutatingWebhookConfiguration, or assume a generic 'webhookconfiguration.yaml' is valid, but the CKS exam specifically tests the distinction between validation and mutation in admission webhooks.

How to eliminate wrong answers

Option A is wrong because 'webhookconfiguration.yaml' is not a standard Kubernetes API resource; the correct resource types are ValidatingWebhookConfiguration or MutatingWebhookConfiguration. Option B is wrong because PodPreset is a deprecated alpha resource that injects information into pods at creation time, not a webhook configuration for validating pods against a policy. Option C is wrong because a MutatingWebhookConfiguration is used for mutating (modifying) resources, not for validating them; validation requires a ValidatingWebhookConfiguration.

312
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

313
MCQhard

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

314
Multi-Selecthard

Which THREE of the following are required to configure encryption of secrets at rest in Kubernetes?

Select 3 answers
A.Specifying an encryption provider such as `aescbc` in the EncryptionConfiguration
B.An EncryptionConfiguration YAML file defining encryption providers and resources to encrypt
C.Running `kubectl get secrets --all-namespaces -o yaml | kubectl apply -f -` to rewrite existing secrets
D.Passing the `--encryption-provider-config` flag to the kube-apiserver
E.Modifying the etcd configuration to enable encryption at rest
AnswersA, B, D

The provider defines the encryption algorithm and keys.

Why this answer

The `aescbc` encryption provider is one of the supported providers in Kubernetes for encrypting secrets at rest. Specifying it in the `EncryptionConfiguration` tells the kube-apiserver which encryption algorithm to use when writing data to etcd. Without a provider like `aescbc`, secrets are stored in plaintext in etcd.

Exam trap

A common misconception is that modifying etcd configuration directly enables encryption at rest, when in fact encryption is a kube-apiserver concern managed via the `--encryption-provider-config` flag and `EncryptionConfiguration` resource.

315
MCQmedium

A security policy requires that all ServiceAccounts in a namespace do not automatically mount their tokens. How can this be achieved at the namespace level?

A.Set automountServiceAccountToken: false in each pod spec
B.Use a PodSecurityPolicy to deny token mounting
C.Set automountServiceAccountToken: false in the ServiceAccount definition
D.Delete the default ServiceAccount
AnswerC

This applies to all pods using that ServiceAccount.

Why this answer

Setting `automountServiceAccountToken: false` in the ServiceAccount definition applies the setting to all pods that use that ServiceAccount, effectively enforcing the policy at the namespace level when the default or all ServiceAccounts are configured this way. This is the correct approach because the ServiceAccount's `automountServiceAccountToken` field controls token mounting for pods referencing it, overriding any pod-level setting unless explicitly set in the pod spec.

Exam trap

CNCF often tests the distinction between namespace-level and pod-level controls, and the trap here is that candidates mistakenly think PodSecurityPolicy can control token mounting or that deleting the default ServiceAccount is a viable solution, when in fact the ServiceAccount's `automountServiceAccountToken` field is the intended namespace-wide mechanism.

How to eliminate wrong answers

Option A is wrong because setting `automountServiceAccountToken: false` in each pod spec is a per-pod solution, not a namespace-level enforcement; it requires manual configuration for every pod and does not scale or guarantee compliance across the namespace. Option B is wrong because PodSecurityPolicy (PSP) does not have a field to control ServiceAccount token mounting; PSP controls pod security contexts, volumes, and capabilities, but token mounting is governed by the ServiceAccount or pod spec, not PSP. Option D is wrong because deleting the default ServiceAccount does not prevent token mounting; Kubernetes will still create a new default ServiceAccount automatically, and pods without an explicit ServiceAccount will use the new default, which still mounts tokens by default.

316
Matchingmedium

Match each Kubernetes API server flag to its security function.

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

Concepts
Matches

Enables RBAC authorization

Comma-separated list of admission controllers to enable

Disables anonymous requests to the API server

Path to a CA file for verifying kubelet certificates

File containing PEM-encoded x509 RSA or ECDSA private or public keys for service account token signing

Why these pairings

Correct matches: --authorization-mode=RBAC enables RBAC; --anonymous-auth=false disables anonymous auth; --profiling=false disables profiling. Common confusions involve mixing authorization and authentication flags.

317
MCQmedium

You are configuring an Istio service mesh for mTLS between services. Which resource defines the TLS mode for traffic between services in a namespace?

A.PeerAuthentication
B.ServiceEntry
C.VirtualService
D.DestinationRule
AnswerA

Correct. PeerAuthentication specifies mTLS mode (STRICT, PERMISSIVE, etc.) for workloads.

Why this answer

PeerAuthentication is the correct resource because it defines the TLS mode (e.g., STRICT, PERMISSIVE, DISABLE) for mTLS between services within a namespace in Istio. It enforces the authentication policy for workloads, ensuring that all traffic between them uses mutual TLS as specified. This directly controls the TLS mode for inter-service communication at the namespace or mesh level.

Exam trap

The trap here is that candidates often confuse DestinationRule with PeerAuthentication, thinking DestinationRule's 'tls' field controls mTLS mode, but DestinationRule only configures client-side TLS settings (e.g., SNI) for outbound traffic, not the server-side authentication policy that PeerAuthentication enforces.

How to eliminate wrong answers

Option B (ServiceEntry) is wrong because it is used to add external services to the mesh, not to define TLS modes for internal traffic between services. Option C (VirtualService) is wrong because it defines traffic routing rules (e.g., weight-based routing, retries) and does not set TLS authentication policies. Option D (DestinationRule) is wrong because it configures traffic policies like load balancing and connection pool settings, but the TLS mode for mTLS is specifically governed by PeerAuthentication, not DestinationRule.

318
MCQmedium

Which crictl command can you use to view the logs of a specific container?

A.crictl inspect <container-id>
B.crictl exec <container-id> cat /var/log/syslog
C.crictl ps
D.crictl logs <container-id>
AnswerD

Correct. crictl logs retrieves the logs of the specified container.

Why this answer

`crictl logs` is the dedicated command to retrieve and display the logs of a specific container managed by a CRI-compatible runtime (e.g., containerd, CRI-O). It works similarly to `docker logs` and reads the container's stdout/stderr streams, which are captured by the container runtime.

Exam trap

The CKS exam often tests the distinction between `crictl` and `docker` commands, and the trap here is that candidates might confuse `crictl inspect` (which shows metadata) with log retrieval, or assume `crictl exec` can read logs from a file inside the container, ignoring that container logs are streamed to stdout/stderr by default.

How to eliminate wrong answers

Option A is wrong because `crictl inspect` returns detailed configuration and state information about a container (e.g., mounts, environment variables, resource limits), not its log output. Option B is wrong because `crictl exec` runs a command inside a running container, but `/var/log/syslog` is not the standard location for container logs; container logs are captured via stdout/stderr, not written to syslog by default. Option C is wrong because `crictl ps` lists running containers with their IDs, names, and statuses, but does not display log content.

319
Multi-Selecthard

Which THREE of the following are valid approaches to prevent containers from running as root in a Kubernetes cluster?

Select 3 answers
A.Use Pod Security Admission with the 'restricted' profile
B.Set the container's entrypoint to 'sudo'
C.Use OPA/Gatekeeper with a constraint that requires runAsNonRoot: true
D.Use a Seccomp profile that blocks root system calls
E.Use Kyverno with a policy that validates runAsNonRoot
AnswersA, C, E

The restricted profile enforces must-run-as-non-root.

Why this answer

Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards (PSS). The 'restricted' profile, as defined in the Kubernetes documentation, requires that containers run with `runAsNonRoot: true`, preventing root execution at the admission level without needing external tools.

Exam trap

The CKS exam often tests the distinction between preventing root execution (via `runAsNonRoot` or user ID constraints) and limiting kernel capabilities (via Seccomp or AppArmor), leading candidates to mistakenly choose Seccomp as a root-prevention mechanism.

320
MCQhard

A user creates a Deployment with image 'alpine:3.18' and the Pod status is 'ErrImagePull'. The admin checks the image policy and sees that only images with SHA digests are allowed. What is the fix?

A.Enable the AlwaysPullImages admission controller
B.Change the image to 'alpine:latest'
C.Add a non-root user to the Dockerfile
D.Change the image to 'alpine@sha256:...'
AnswerD

Using a SHA digest satisfies the policy requirement for immutable references.

Why this answer

The cluster policy requires images to be identified by SHA digest rather than tags. Using an image reference like 'alpine@sha256:...' ensures the image is pulled by its immutable digest, bypassing tag-based resolution and satisfying the policy. This is a common supply chain security measure to prevent tag mutability and ensure image integrity.

Exam trap

The trap here is that candidates often confuse admission controllers (like AlwaysPullImages) with image reference policies, or assume that changing to a different tag (like 'latest') will bypass the restriction, when in fact the policy explicitly requires a digest-based reference.

How to eliminate wrong answers

Option A is wrong because enabling the AlwaysPullImages admission controller forces image pulls on every Pod creation but does not address the requirement to use SHA digests; the image tag 'alpine:3.18' would still be rejected by the policy. Option B is wrong because changing the tag to 'alpine:latest' still uses a mutable tag, which violates the policy that only SHA digests are allowed; it would also introduce a different security risk by pulling an unpredictable version. Option C is wrong because adding a non-root user to the Dockerfile improves container security but has no effect on image pull policies or digest requirements; the Pod would still fail with ErrImagePull due to the tag-based reference.

321
Multi-Selecthard

Which THREE of the following are valid methods to enforce pod security standards in a Kubernetes cluster?

Select 3 answers
A.Use Kyverno policy engine
B.Run kube-bench on the cluster
C.Manual review of all pod specs
D.Use Open Policy Agent (OPA) with Gatekeeper
E.Enable PodSecurity admission plugin
AnswersA, D, E

Another admission controller.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce pod security standards by validating, mutating, and generating resources based on policies written as Kubernetes custom resources. It integrates with the Kubernetes API server via dynamic admission webhooks, allowing it to reject non-compliant pod specs before they are persisted.

Exam trap

CNCF often tests the distinction between auditing tools (like kube-bench) and admission controllers that enforce policies at runtime, leading candidates to mistakenly select kube-bench as an enforcement method.

322
MCQhard

A cluster uses Kyverno to enforce that all images come from a trusted registry. A new Deployment fails with a message that the image 'docker.io/library/nginx:latest' is not allowed. What Kyverno policy rule likely caused this?

A.A validate rule that checks the container's resource limits
B.A validate rule that checks the image registry
C.A generate rule that creates a ConfigMap
D.A mutating rule that adds a label to the pod
AnswerB

A validate rule with a pattern or deny condition can block images from unauthorized registries.

Why this answer

Kyverno uses validate rules to enforce policies by checking resource attributes against defined conditions. The error message indicates that the image 'docker.io/library/nginx:latest' was rejected because it does not come from a trusted registry. A validate rule with a pattern or deny condition that inspects the image field (e.g., `spec.containers[*].image`) and restricts it to a specific registry prefix (like `trusted-registry.io/*`) would cause this rejection.

Exam trap

The trap here is that candidates confuse Kyverno's 'validate' rules (which deny non-compliant resources) with 'mutate' or 'generate' rules, which do not block admission; the explicit rejection message indicates that a validate rule with a condition on the image registry denied the deployment.

How to eliminate wrong answers

Option A is wrong because a validate rule checking resource limits would reject a Pod based on CPU/memory constraints, not image registry origin. Option C is wrong because a generate rule creates or synchronizes resources (like ConfigMaps) but does not block or validate existing resources. Option D is wrong because a mutating rule modifies resources (e.g., adding labels) but does not enforce admission denials; it would not produce a rejection message.

323
MCQmedium

A developer wants to ensure that a pod can only receive traffic from pods with label 'app: frontend' in the same namespace. Which NetworkPolicy egress rule should be applied to the source pods?

A.Apply an egress rule on the target pod with 'to' podSelector matching 'app: frontend'
B.Apply an egress rule on the source pods with 'to' podSelector matching the target pod
C.Apply an ingress rule on the source pods with 'from' podSelector matching the target pod
D.Apply an ingress rule on the target pod with 'from' podSelector matching 'app: frontend'
AnswerD

Correct. Ingress rules on the target pod control which sources can send traffic to it.

Why this answer

The correct approach is to apply an ingress rule on the target pod, not an egress rule on the source pods. In Kubernetes NetworkPolicy, ingress rules control incoming traffic to the pods selected by the policy. Since the target pod needs to receive traffic only from pods with label 'app: frontend', you define a NetworkPolicy with a podSelector matching the target pod, and an ingress rule that uses a from selector with a podSelector matching 'app: frontend'.

This ensures that only pods with that label can send traffic to the target pod. Option D correctly describes this configuration, while options A, B, and C incorrectly apply rules on the wrong pods or use wrong directions.

324
Multi-Selectmedium

Which TWO of the following are recommended practices for securing container images and runtime?

Select 2 answers
A.Set runAsNonRoot to true in securityContext
B.Run containers as root inside the container for easier management
C.Set readOnlyRootFilesystem to true in securityContext
D.Mount the docker socket inside the container for debugging
E.Use the latest tag for all images
AnswersA, C

Ensures the container runs as a non-root user.

Why this answer

Setting `runAsNonRoot: true` in the securityContext ensures that the container's entrypoint runs with a user ID other than 0 (root), reducing the risk of container escape if an attacker gains code execution. Setting `readOnlyRootFilesystem: true` makes the container's filesystem read-only, preventing attackers from modifying critical system files or binaries. Both are key hardening practices recommended by Kubernetes security best practices.

Exam trap

A common pitfall is thinking that running as root inside a container is safe due to namespace isolation. However, root inside a container still has dangerous capabilities (e.g., CAP_SYS_ADMIN) that can lead to container escape, especially without proper seccomp or AppArmor profiles. This is a critical concept for the CNCF Kubernetes Security Specialist exam.

325
Multi-Selecthard

You are securing a Kubernetes cluster that runs workloads from multiple teams. The cluster uses a private container registry and an admission controller to enforce image policies. Which TWO of the following actions are most effective in preventing the use of unapproved or tampered container images? (Choose two correct answers.)

Select 2 answers
A.Use OPA Gatekeeper to enforce a policy that rejects pods using images with the 'latest' tag.
B.Configure imagePullSecrets for each namespace to ensure only authorized service accounts can pull images.
C.Deploy Kyverno with a policy that requires images to have a specific annotation indicating they passed a security scan.
D.Implement a NetworkPolicy that blocks egress traffic from the cluster to unauthorized container registries.
E.Set up an ImagePolicyWebhook admission controller that checks image signatures and only allows signed images from your registry.
AnswersC, E

Kyverno can enforce custom policies including image annotations that prove scanning.

Why this answer

Kyverno can enforce policies that require images to have specific annotations, such as one indicating a passed security scan. This ensures only images that have been verified by your security pipeline are allowed to run, directly preventing unapproved or tampered images from being deployed.

Exam trap

CNCF often tests the distinction between authentication/authorization and image integrity verification, where candidates mistakenly choose options that control access to registries (like imagePullSecrets or NetworkPolicy) instead of options that validate image content or approval status.

326
Multi-Selecthard

Which THREE of the following are recommended incident response steps when a container is compromised?

Select 3 answers
A.Ignore the incident and monitor for further activity
B.Copy the container's filesystem using kubectl cp for offline analysis
C.Capture the container logs using kubectl logs
D.Apply a NetworkPolicy to isolate the pod
E.Immediately terminate the pod to contain the threat
AnswersB, C, D

Correct. This preserves evidence without altering the running container.

Why this answer

Isolating the pod via NetworkPolicy, preserving evidence by copying the filesystem, and capturing logs are key steps. Terminating the pod immediately may lose evidence, and ignoring is not recommended.

327
MCQeasy

You need to configure the Kubernetes API server to log all requests at the Metadata level. Which flag should you use when starting kube-apiserver?

A.--audit-log-level=Metadata
B.--audit-policy-file=/etc/kubernetes/audit-policy.yaml
C.--audit-webhook-mode=Metadata
D.--audit-log-path=/var/log/audit.log
AnswerB

Why this answer

The --audit-policy-file flag points to a YAML file that defines the audit policy. The policy file specifies the level for different resources. Option B is correct.

Option A is not a valid flag; Option C sets a different level; Option D is used to set the audit log path.

328
MCQeasy

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

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

aa-status displays the current AppArmor profile status.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

329
MCQhard

During a security incident, you need to isolate a compromised pod named 'malicious-pod' in namespace 'default' to prevent it from communicating with other pods. Which command should you run?

A.kubectl run networkpolicy --image=nginx --restart=Never
B.kubectl delete pod malicious-pod
C.kubectl apply -f networkpolicy.yaml
D.kubectl create networkpolicy isolate --pod-selector=app=malicious --policy-types=Ingress,Egress
AnswerC

Correct. You must write a NetworkPolicy YAML that selects the malicious pod and denies all traffic, then apply it.

Why this answer

Pod isolation is achieved by applying a NetworkPolicy that denies ingress/egress traffic. 'kubectl apply -f networkpolicy.yaml' applies the policy. The policy must be written to deny all traffic.

330
Multi-Selecteasy

Which TWO of the following flags are used to secure the kubelet?

Select 2 answers
A.--protect-kernel-defaults
B.--anonymous-auth=false
C.--enable-admission-plugins
D.--audit-log-path
E.--authorization-mode=RBAC
AnswersA, B

Correct. This flag protects kernel defaults.

Why this answer

The `--protect-kernel-defaults` flag is used to secure the kubelet by ensuring that kernel tunable parameters (e.g., `vm.overcommit_memory`, `kernel.panic`) are set to safe values. If the kernel defaults are not properly configured, the kubelet will fail to start, preventing insecure kernel settings from being used. This flag is part of the kubelet's security hardening measures, as recommended by the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the distinction between kubelet flags and API server flags, so the trap here is that candidates may confuse `--authorization-mode=RBAC` or `--audit-log-path` as kubelet security settings when they are actually API server parameters.

331
MCQmedium

A security admin wants to ensure all pods in a cluster drop ALL Linux capabilities. Which of the following YAML snippets should be added to a PodSecurityPolicy (assuming PSP is enabled) or a pod spec?

A.capabilities: drop: "ALL"
B.capabilities: drop: - "NET_RAW"
C.capabilities: add: ["ALL"]
D.capabilities: drop: ["ALL"]
AnswerD

This drops all capabilities, which is a security best practice.

Why this answer

Dropping all Linux capabilities from a container is achieved by specifying `drop: ["ALL"]` in the PodSecurityPolicy or pod security context. This ensures the container runs with no capabilities, following the principle of least privilege. The correct syntax uses a YAML list (array) for the `drop` field, not a string.

Exam trap

The trap here is that candidates confuse the YAML syntax for dropping capabilities (must be a list) with a string value, or they think dropping a single capability like NET_RAW is sufficient to remove all capabilities. Also, note that PodSecurityPolicy is deprecated in Kubernetes 1.21 and removed in 1.25, so for newer clusters, use Pod Security Admission or a pod security context.

How to eliminate wrong answers

Option A is wrong because `drop: "ALL"` uses a string value instead of a list, which is invalid YAML syntax for the capabilities field; the Kubernetes API expects an array of strings. Option B is wrong because it only drops the `NET_RAW` capability, not all capabilities, leaving the container with other potentially dangerous capabilities. Option C is wrong because `add: ["ALL"]` adds all capabilities, which is the opposite of what the security admin wants and would grant maximum privileges.

332
MCQmedium

A security auditor runs kube-bench and reports that the kubelet is not configured with --protect-kernel-defaults. What is the impact of this misconfiguration?

A.Container runtime will not be able to pull images
B.The node will be unable to schedule pods
C.The kubelet will refuse to start
D.Kernel parameters may be modified, potentially reducing node security
AnswerD

Without --protect-kernel-defaults, kubelet does not enforce recommended kernel security settings.

Why this answer

The `--protect-kernel-defaults` flag ensures that the kubelet enforces kernel parameter hardening, preventing modifications that could weaken node security. Without it, a compromised or misconfigured pod could alter kernel settings (e.g., `net.ipv4.ip_forward`, `vm.overcommit_memory`), reducing the overall security posture of the node. This does not affect image pulling, pod scheduling, or kubelet startup.

Exam trap

The trap here is that candidates assume a missing security flag will cause an immediate failure (like kubelet not starting), when in reality the kubelet runs but the node becomes vulnerable to kernel parameter tampering.

How to eliminate wrong answers

Option A is wrong because the container runtime's ability to pull images depends on network connectivity and registry access, not on kernel parameter protection. Option B is wrong because pod scheduling is controlled by the scheduler and node conditions, not by the `--protect-kernel-defaults` flag; the node will still schedule pods. Option C is wrong because the kubelet will start without this flag; it only logs a warning or fails if the kernel parameters are not set correctly, but the flag itself does not prevent startup.

333
MCQeasy

Which admission plugin should be used to enforce Pod Security Standards at the namespace level?

A.PodSecurity
B.PodSecurityPolicy
C.NodeRestriction
D.SecurityContextDeny
AnswerA

This plugin enforces Pod Security Standards.

Why this answer

The PodSecurity admission plugin is the successor to PodSecurityPolicy (PSP) and is designed specifically to enforce Pod Security Standards (PSS) at the namespace level. It evaluates pods against the three predefined PSS levels (privileged, baseline, restricted) based on labels set on the namespace, and can be configured in warn, audit, or enforce mode. This plugin is built into the kube-apiserver and is the recommended approach for pod security in Kubernetes v1.25 and later.

Exam trap

CNCF often tests the fact that PodSecurityPolicy is deprecated and removed, so candidates who studied older material may mistakenly choose PodSecurityPolicy, not realizing it has been replaced by the PodSecurity admission plugin.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and it enforces security policies cluster-wide via a CRD, not at the namespace level using Pod Security Standards. Option C is wrong because NodeRestriction is an admission plugin that limits the Node API objects a kubelet can modify, and has nothing to do with pod security standards. Option D is wrong because SecurityContextDeny is an older admission plugin that rejects pods with certain security context settings, but it does not enforce the namespace-scoped Pod Security Standards and is not the recommended replacement for PSP.

334
MCQmedium

An administrator wants to prevent the kubelet from serving anonymous requests. Which flag should be set on the kubelet?

A.--client-ca-file=/etc/kubernetes/pki/ca.crt
B.--authorization-mode=Webhook
C.--anonymous-auth=false
D.--authentication-token-webhook=true
AnswerC

This disables anonymous authentication on the kubelet.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the kubelet, preventing unauthenticated requests from being processed. By default, anonymous authentication is enabled (`--anonymous-auth=true`), which allows any unauthenticated user to make requests to the kubelet API. Setting this flag to `false` ensures that only authenticated clients can interact with the kubelet, directly addressing the requirement to block anonymous requests.

Exam trap

The trap here is that candidates often confuse authentication with authorization—they think setting a client CA file or enabling webhook authorization will block anonymous requests, but those controls only affect already-authenticated users or authorization decisions, not the initial authentication step where anonymous access is allowed by default.

How to eliminate wrong answers

Option A is wrong because `--client-ca-file` configures the certificate authority used to validate client certificates for mutual TLS authentication, but it does not disable anonymous authentication—anonymous requests are still allowed unless explicitly blocked. Option B is wrong because `--authorization-mode=Webhook` sets the authorization mode to delegate authorization decisions to an external webhook, but it does not affect authentication; anonymous users can still be authenticated and then authorized. Option D is wrong because `--authentication-token-webhook=true` enables token-based authentication via a webhook, but it does not disable anonymous authentication—anonymous requests remain permitted unless `--anonymous-auth` is set to `false`.

335
MCQeasy

Which kubectl command creates a secret named 'mysecret' from a file called 'credentials.json'?

A.kubectl create secret generic mysecret --from-file=credentials.json
B.kubectl apply -f credentials.json
C.kubectl create configmap mysecret --from-file=credentials.json
D.kubectl create secret tls mysecret --cert=credentials.json
AnswerA

The --from-file flag creates a secret from the contents of a file, using the filename as the key.

Why this answer

`kubectl create secret generic` is the command to create a generic (opaque) secret from a file. The `--from-file` flag reads the contents of `credentials.json` and stores them as the secret's data, using the filename as the key by default. This is the standard method for injecting sensitive file-based data into a Kubernetes secret.

Exam trap

Kubernetes often tests the distinction between `kubectl create secret generic` and `kubectl create secret tls`, and the trap here is that candidates may confuse the `--from-file` flag (for generic secrets) with the `--cert`/`--key` flags (for TLS secrets) or mistakenly use `kubectl apply` on a raw data file instead of a manifest.

How to eliminate wrong answers

Option B is wrong because `kubectl apply -f credentials.json` expects a valid Kubernetes manifest (YAML/JSON) defining a resource, not a raw data file like `credentials.json`. Option C is wrong because `kubectl create configmap` creates a ConfigMap, not a Secret; ConfigMaps store non-sensitive data, while Secrets are base64-encoded and intended for sensitive information. Option D is wrong because `kubectl create secret tls` is specifically for TLS certificates and requires `--cert` and `--key` flags pointing to PEM-encoded certificate and key files, not a generic JSON file.

336
MCQeasy

A DevOps engineer notices that a container's stdout logs are not appearing in the `kubectl logs` output. The container runs a legacy application that writes logs to a file inside the container. What is the most efficient way to capture these logs without modifying the application?

A.Configure the kubelet to rotate logs from the container's filesystem.
B.Add a sidecar container that reads the log file and outputs to stdout.
C.Use `kubectl cp` to periodically copy logs from the container.
D.Install a syslog daemon in the container to forward logs.
AnswerB

The sidecar pattern streams file logs to stdout for kubectl logs.

Why this answer

Deploying a sidecar container that tails the log file and writes to its own stdout is the most efficient, Kubernetes-native pattern for capturing logs from applications that write to files. The sidecar container shares the same Pod and volume, reads the log file (e.g., using `tail -F`), and outputs to stdout, which is then collected by `kubectl logs` and the cluster-level logging pipeline. This approach requires no modification to the legacy application and leverages the existing container runtime and kubelet log collection.

Exam trap

CNCF often tests the sidecar logging pattern as the standard Kubernetes solution for capturing file-based logs, and the trap here is that candidates may incorrectly choose kubelet log rotation (Option A) thinking it applies to all container logs, when in fact it only applies to the container runtime's own stdout/stderr streams.

How to eliminate wrong answers

Option A is wrong because the kubelet handles log rotation only for container stdout/stderr streams, not for files written inside the container's filesystem; it cannot rotate arbitrary application log files. Option C is wrong because `kubectl cp` is a manual, non-scalable operation that requires external orchestration and does not provide real-time log streaming to `kubectl logs`. Option D is wrong because installing a syslog daemon inside the container would require modifying the container image or running additional processes, which contradicts the requirement of not modifying the application and adds unnecessary complexity.

337
MCQhard

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

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

This drops all and adds only SYS_PTRACE.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

338
MCQmedium

An administrator runs kube-bench on a cluster node and receives failures for CIS benchmark checks related to kubelet configuration. Which kubelet flag should be set to ensure that kernel defaults are not used when they might be insecure?

A.--protect-kernel-defaults
B.--read-only-port=0
C.--anonymous-auth=false
D.--kubelet-extra-args
AnswerA

This flag is explicitly checked by kube-bench for CIS compliance.

Why this answer

The `--protect-kernel-defaults` kubelet flag ensures that the kubelet will not use insecure kernel defaults by enforcing that certain sysctl settings (e.g., `kernel.panic`, `vm.overcommit_memory`) are set to secure values. If these kernel parameters are not explicitly configured to safe values, the kubelet will fail to start, preventing the node from running with potentially insecure kernel defaults. This directly addresses CIS benchmark checks that require hardening of the kubelet's interaction with the host kernel.

Exam trap

The trap here is that candidates often confuse `--protect-kernel-defaults` with other kubelet security flags like `--read-only-port` or `--anonymous-auth`, or mistakenly think `--kubelet-extra-args` is a direct kubelet flag, when in fact it is a kubeadm configuration option and not a solution for kernel default protection.

How to eliminate wrong answers

Option B is wrong because `--read-only-port=0` disables the read-only port (10255) on the kubelet, which prevents unauthenticated access to kubelet metrics, but it does not address kernel default security. Option C is wrong because `--anonymous-auth=false` disables anonymous authentication to the kubelet API, which is a separate CIS check for authentication hardening, not for kernel defaults. Option D is wrong because `--kubelet-extra-args` is a kubeadm configuration field used to pass additional flags to the kubelet, not a kubelet flag itself, and it does not specifically enforce kernel default protection.

339
Multi-Selecthard

Which THREE of the following practices help protect microservice applications against supply chain attacks? (Choose three.)

Select 3 answers
A.Use images from any public registry for flexibility
B.Use minimal base images (e.g., distroless or scratch) to reduce attack surface
C.Always use the latest tag to get the most recent patches
D.Scan images for vulnerabilities using tools like Trivy or Clair
E.Enable image verification using digital signatures (e.g., Notary or Cosign)
AnswersB, D, E

Smaller images have fewer packages that could contain vulnerabilities.

Why this answer

Using minimal base images like distroless or scratch significantly reduces the attack surface by eliminating unnecessary packages, libraries, and utilities that could contain vulnerabilities. This aligns with the principle of least functionality, as fewer components mean fewer potential entry points for an attacker to exploit in a supply chain attack.

Exam trap

CNCF often tests the misconception that using the latest tag is a safe practice for getting patches, when in fact it undermines supply chain security by breaking image immutability and reproducibility.

340
MCQeasy

What is the purpose of the --audit-log-path flag on the kube-apiserver?

A.It sets the maximum number of audit log files to retain.
B.It disables audit logging.
C.It enables audit logging and sets the output file path.
D.It specifies the path to the audit policy file.
AnswerC

This flag enables audit logging and specifies the log file location.

Why this answer

The `--audit-log-path` flag on the kube-apiserver enables audit logging and specifies the file path where audit events are written. Without this flag, audit logging is disabled by default. Setting this flag is the first step to capturing API request logs for security monitoring and compliance.

Exam trap

CNCF often tests the distinction between `--audit-log-path` (enables logging and sets output path) and `--audit-policy-file` (defines what to log), causing candidates to confuse the two flags.

How to eliminate wrong answers

Option A is wrong because the `--audit-log-maxbackup` flag, not `--audit-log-path`, controls the maximum number of audit log files to retain. Option B is wrong because the `--audit-log-path` flag enables audit logging, not disables it; disabling audit logging is the default behavior when the flag is omitted. Option D is wrong because the path to the audit policy file is set by the `--audit-policy-file` flag, not `--audit-log-path`.

341
MCQmedium

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

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

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

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

342
Multi-Selectmedium

Which TWO of the following are valid ways to securely manage secrets in Kubernetes? (Choose two.)

Select 2 answers
A.Mount Kubernetes Secrets as volumes into the pod.
B.Use environment variables from the pod spec referencing Secret keys.
C.Use an external secrets manager like HashiCorp Vault integrated with the pod.
D.Pass secrets as command-line arguments to the container.
E.Store secrets in ConfigMaps with base64 encoded data.
AnswersA, C

Volume mounts are more secure than env vars.

Why this answer

Mounting Kubernetes Secrets as volumes into the pod ensures that secret data is stored in the pod's filesystem as files, which are created with in-memory tmpfs to avoid writing to disk. This approach leverages Kubernetes' native secret handling, where the secret data is base64-decoded and presented as plaintext files, and access can be controlled via RBAC and PodSecurityPolicies. It also supports automatic rotation when secrets are updated, provided the pod is restarted or the volume is remounted.

Exam trap

Kubernetes often tests the misconception that environment variables are a secure way to inject secrets, when in fact they are vulnerable to exposure through process introspection and logging, making volume mounts or external secret stores the recommended approaches.

343
Multi-Selectmedium

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

Select 2 answers
A.Load all kernel modules to support any workload
B.Restrict hostNetwork, hostPID, and hostIPC access from containers
C.Enable SSH access for all users for troubleshooting
D.Disable unnecessary system services on the node
E.Allow containers to run as root
AnswersB, D

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

Why this answer

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

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

Exam trap

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

344
MCQeasy

What is the purpose of the CIS Kubernetes Benchmark?

A.To provide a set of security best practices for Kubernetes
B.To benchmark performance of Kubernetes clusters
C.To test network policies
D.To automate deployment of Kubernetes clusters
AnswerA

The CIS Benchmark outlines security recommendations.

Why this answer

The CIS Kubernetes Benchmark is a set of security best practices developed by the Center for Internet Security (CIS) specifically for hardening Kubernetes clusters. It provides prescriptive guidance on configuring cluster components (e.g., kube-apiserver, kubelet, etcd) to reduce the attack surface and meet compliance standards. Option A correctly identifies this purpose, as the benchmark is not about performance, networking, or automation.

Exam trap

The trap here is that candidates confuse the CIS Benchmark with a performance or automation tool, because 'benchmark' often implies performance testing in other contexts, but in Kubernetes security, it strictly refers to a compliance and hardening standard.

How to eliminate wrong answers

Option B is wrong because the CIS Kubernetes Benchmark focuses on security configuration, not performance benchmarking; performance metrics are measured by tools like the Kubernetes Performance and Scalability Working Group's benchmarks. Option C is wrong because while the benchmark includes recommendations for network policies, its scope is far broader, covering all aspects of cluster security (e.g., RBAC, secrets, pod security). Option D is wrong because the benchmark is a set of guidelines, not a deployment tool; automation of cluster deployment is handled by tools like kubeadm, Terraform, or Cluster API.

345
MCQmedium

A Kubernetes cluster has Kyverno installed. You want to enforce that all container images come from a trusted registry 'trusted-registry.example.com'. Which Kyverno policy rule type would you use?

A.validate with a deny condition
B.mutate
C.validate.deny
D.generate
AnswerA

Using a validate rule with a deny condition can block pods that use images from unauthorized registries.

Why this answer

Kyverno's `validate` rule type with a `deny` condition is specifically designed to reject resources that violate a policy. In this case, the policy would deny any Pod that references an image not matching the pattern `trusted-registry.example.com/*`, enforcing the trusted registry requirement at admission time.

Exam trap

The trap here is that candidates confuse the `validate.deny` syntax (which does not exist) with the correct approach of using a `validate` rule containing a `deny` condition, often because other tools like OPA/Gatekeeper use a `deny` rule type directly.

How to eliminate wrong answers

Option B is wrong because `mutate` rules modify resources (e.g., prefixing an image registry) but do not block non-compliant resources; they cannot enforce a deny. Option C is wrong because `validate.deny` is not a valid Kyverno rule type; the correct syntax is `validate` with a `deny` condition under the `validationFailureAction` or `deny` block. Option D is wrong because `generate` rules create new resources (e.g., default NetworkPolicies) and have no capability to validate or deny existing resources.

346
MCQhard

You need to ensure that all pods in a namespace have the label 'security: high' added automatically upon creation. Which admission controller should you use?

A.PodSecurityPolicy (deprecated)
B.ResourceQuota
C.ValidatingAdmissionPolicy
D.MutatingWebhookConfiguration
AnswerD

A mutating webhook can modify resources during admission, such as adding labels.

Why this answer

A MutatingWebhookConfiguration intercepts pod creation requests and can automatically add the label 'security: high' to pods in a namespace. This admission controller mutates the object before it is persisted, ensuring all pods receive the label without manual intervention.

Exam trap

In the CNCF CKS exam, candidates often confuse MutatingAdmissionPolicy with ValidatingAdmissionPolicy. Remember that only mutating admission controllers can modify objects; ValidatingAdmissionPolicy only checks and rejects.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy is deprecated and does not add labels; it enforces security contexts. Option B is wrong because ResourceQuota limits resource consumption, not labels. Option C is wrong because ValidatingAdmissionPolicy only validates requests and cannot mutate objects to add labels.

347
Multi-Selectmedium

Which THREE of the following are features of container sandboxing solutions like gVisor or Kata Containers?

Select 3 answers
A.They are compatible with the OCI runtime specification
B.They improve container performance over native runc
C.They can be used with RuntimeClass to select the sandbox runtime per pod
D.They provide an additional layer of isolation between containers and the host kernel
E.They use the host kernel directly for all system calls
AnswersA, C, D

Both gVisor (runsc) and Kata Containers implement the OCI runtime spec.

Why this answer

Both gVisor and Kata Containers implement the OCI (Open Container Initiative) runtime specification, which allows them to be used as drop-in replacements for runc. This compatibility ensures that container images and tools like containerd can interface with these sandboxed runtimes without modification, as they expose the same runtime lifecycle commands (create, start, delete).

Exam trap

The CKS exam often tests the misconception that sandboxing improves performance, when in reality the added isolation layer (user-space kernel or VM) introduces latency and resource overhead compared to native runc.

348
MCQmedium

A Falco rule is configured to detect privilege escalation via setuid binaries. Which syscall is commonly associated with this activity?

A.connect
B.setuid
C.open
D.execve
AnswerB

Correct. The setuid syscall changes the user ID of the process, commonly used in privilege escalation attacks.

Why this answer

The setuid syscall is used to change the user ID of the current process, which is a common method for privilege escalation. Falco rules often monitor setuid and setgid syscalls to detect such activity. Option A (connect) is a network syscall.

Option C (open) is a file operation syscall. Option D (execve) is used to execute a new program, but the direct privilege escalation is via setuid.

349
MCQmedium

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

A.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
B.VirtualService with tls.mode: SIMPLE
C.PeerAuthentication with mtls.mode: STRICT
D.ServiceEntry with resolution: NONE
AnswerC

PeerAuthentication enforces mTLS on inbound traffic; STRICT mode requires mutual TLS.

Why this answer

PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.

Exam trap

The trap here is confusing DestinationRule's `trafficPolicy.tls.mode: ISTIO_MUTUAL` with PeerAuthentication's `mtls.mode: STRICT`; candidates often mistakenly think DestinationRule enforces mTLS, but it only configures TLS for outbound traffic, not inbound authentication enforcement.

How to eliminate wrong answers

Option A is wrong because DestinationRule controls traffic routing and load balancing policies, not authentication; its `trafficPolicy.tls.mode: ISTIO_MUTUAL` only configures TLS settings for outbound connections to a specific host, not enforcing mTLS on inbound traffic. Option B is wrong because VirtualService is used for traffic routing and manipulation, not authentication; `tls.mode: SIMPLE` is not a valid field in VirtualService and does not relate to mTLS enforcement. Option D is wrong because ServiceEntry is used to register external services into the mesh, not to enforce authentication policies; `resolution: NONE` controls DNS resolution, not TLS mode.

350
MCQmedium

You suspect a pod is making unexpected outbound connections. Which tool can you use to inspect network connections from within the container?

A.kubectl port-forward
B.crictl exec
C.falco
D.kubectl logs
AnswerB

crictl exec can run ss or netstat inside the container.

Why this answer

`crictl exec` allows you to run commands inside a container managed by CRI-compatible runtimes (like containerd), enabling you to inspect network connections from within the container using tools like `ss`, `netstat`, or `ip`. This is the direct method to check outbound connections from the container's network namespace, which is isolated from the host.

Exam trap

The trap here is that candidates may choose `kubectl logs` thinking it shows network activity, but logs only capture application output, not kernel-level connection states, while `crictl exec` provides direct access to the container's network namespace.

How to eliminate wrong answers

Option A is wrong because `kubectl port-forward` is used to forward local ports to a pod for debugging or accessing applications, not to inspect network connections from within the container. Option C is wrong because Falco is a runtime security tool that monitors system calls and detects anomalous behavior at the host level, but it does not provide an interactive shell to inspect connections from inside the container. Option D is wrong because `kubectl logs` retrieves container logs (stdout/stderr), which typically do not contain real-time network connection information unless the application explicitly logs them.

351
MCQmedium

An admin runs 'kubectl auth reconcile -f rbac.yaml' and gets an error that the user does not have permission to create ClusterRoleBindings. What is the most likely cause?

A.The ClusterRoleBinding already exists.
B.The YAML file has a syntax error.
C.The Kubernetes API server is not reachable.
D.The user's kubeconfig context does not have RBAC permissions to create ClusterRoleBindings.
AnswerD

The error indicates insufficient permissions; the user needs a ClusterRoleBinding that grants the necessary permissions.

Why this answer

The error indicates that the user's current kubeconfig context lacks RBAC permissions to create ClusterRoleBindings. The `kubectl auth reconcile` command attempts to apply the RBAC resources defined in the YAML file, and if the user's credentials (typically from a certificate or token) do not include the `create` verb on `clusterrolebindings` in the RBAC authorization layer, the API server will reject the request with a 403 Forbidden error. This is a direct permission issue, not a connectivity or syntax problem.

Exam trap

The trap here is that candidates may confuse a permission error with a resource conflict (Option A) or a connectivity issue (Option C), but the specific error message 'does not have permission to create ClusterRoleBindings' directly points to insufficient RBAC privileges in the current kubeconfig context.

How to eliminate wrong answers

Option A is wrong because if the ClusterRoleBinding already exists, `kubectl auth reconcile` would attempt to update it (which requires `update` permission), but the error specifically mentions lack of permission to `create`, not a conflict error like 'AlreadyExists'. Option B is wrong because a syntax error in the YAML file would produce a parsing error from kubectl (e.g., 'error converting YAML to JSON'), not an RBAC permission error. Option C is wrong because if the API server were unreachable, the error would be a connection timeout or 'Unable to connect to the server', not a permission-denied message.

352
Multi-Selectmedium

Which TWO actions should be taken to secure etcd in a Kubernetes cluster?

Select 2 answers
A.Enable TLS authentication for etcd peer and client communication
B.Run etcd as a DaemonSet to ensure high availability
C.Disable client certificate authentication for etcd
D.Enable the NodeRestriction admission plugin on etcd
E.Restrict access to etcd using network policies or firewall rules
AnswersA, E

TLS ensures encrypted and authenticated communication.

Why this answer

Enabling TLS authentication for etcd peer and client communication ensures that all data in transit between etcd members and between etcd and the Kubernetes API server is encrypted and mutually authenticated. This prevents man-in-the-middle attacks and unauthorized access to the cluster's state store, which is a critical requirement for securing etcd as per the CIS Kubernetes Benchmark.

Exam trap

CNCF often tests the misconception that admission plugins like NodeRestriction apply to etcd, when in fact they are exclusively API server components and have no role in securing the etcd datastore itself.

353
MCQeasy

A security engineer wants to ensure that only images signed with a specific key are allowed to run in the cluster. Which tool can be used to sign container images?

A.kubesec
B.syft
C.cosign
D.trivy
AnswerC

Cosign supports signing container images and verifying signatures.

Why this answer

Cosign is the correct tool because it is specifically designed for signing and verifying container images using cryptographic keys, integrating directly with OCI-compliant registries. It supports keyless signing via Fulcio and transparency logs via Rekor, making it the standard choice for enforcing image signature verification in Kubernetes admission controllers like Kyverno or OPA.

Exam trap

CNCF often tests the distinction between image scanning (Trivy, Syft) and image signing (Cosign), so candidates mistakenly choose a vulnerability scanner or SBOM tool when the question explicitly asks for signing.

How to eliminate wrong answers

Option A is wrong because kubesec is a static analysis tool that evaluates Kubernetes resource manifests against security best practices, not a tool for signing container images. Option B is wrong because syft is a software bill of materials (SBOM) generator that produces dependency lists from container images, not a signing tool. Option D is wrong because trivy is a vulnerability scanner for container images, filesystems, and Git repositories, and does not provide image signing capabilities.

354
MCQmedium

You are tasked with enabling audit logging for the Kubernetes API server. Which API server flag must be used to specify the audit log file path?

A.--audit-log-path
B.--audit-log-dir
C.--audit-policy-file
D.--audit-log-file
AnswerA

This flag sets the path for the audit log file.

Why this answer

The `--audit-log-path` flag is the correct API server flag to specify the file path where audit logs are written. This flag defines the absolute or relative path to the audit log file, and the kube-apiserver will create or append to that file. Without this flag, no audit log file is generated, even if an audit policy is configured.

Exam trap

CNCF often tests the exact flag name `--audit-log-path` versus the plausible but incorrect `--audit-log-file`, exploiting the common assumption that the flag would be named after the file rather than the path.

How to eliminate wrong answers

Option B is wrong because `--audit-log-dir` is not a valid kube-apiserver flag; the correct flag for specifying the directory is `--audit-log-path`, which can include a directory path as part of the filename. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, not the log file path itself. Option D is wrong because `--audit-log-file` is not a valid flag; the correct flag name is `--audit-log-path`.

355
Multi-Selectmedium

Which TWO tools can generate an SBOM for a container image? (Select two.)

Select 2 answers
A.checkov
B.trivy
C.syft
D.cosign
E.kubesec
AnswersB, C

Trivy can generate SBOMs in CycloneDX or SPDX format.

Why this answer

Trivy is a comprehensive vulnerability scanner that can generate an SBOM (Software Bill of Materials) for container images using its `trivy image --format cyclonedx` or `trivy image --format spdx` commands, outputting in CycloneDX or SPDX formats. Syft is a dedicated SBOM generation tool from Anchore that produces detailed SBOMs from container images using `syft packages <image>` and supports multiple output formats including CycloneDX and SPDX. Both tools are specifically designed to inventory all software components within a container image, making them correct choices for SBOM generation.

Exam trap

The CNCF CKS exam often tests the distinction between tools that generate SBOMs (Trivy, Syft) versus tools that scan for vulnerabilities (Trivy can do both, but the question specifically asks for SBOM generation) or perform other supply chain tasks like signing (Cosign) or IaC scanning (Checkov), leading candidates to confuse a tool's primary function with its secondary capabilities.

356
Multi-Selecteasy

An auditor requires that all audit logs from the Kubernetes API server be stored for 90 days and be tamper-proof. Which TWO measures should be implemented?

Select 2 answers
A.Configure the audit log backend to write to an immutable object store like S3 with Object Lock
B.Enable the AuditDynamicConfiguration feature gate
C.Deploy Fluentd to forward logs to a central Elasticsearch cluster
D.Set the API server flag --audit-log-maxage=90
E.Set --audit-log-maxbackup=10 and --audit-log-maxsize=100
AnswersA, D

Immutable storage prevents log modification or deletion.

Why this answer

Storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Exam trap

CNCF often tests the distinction between log rotation/retention settings (like --audit-log-maxage) and true immutability features, leading candidates to incorrectly select options that only manage log file age without preventing tampering.

357
MCQeasy

What is the default authorization mode for a new Kubernetes cluster?

A.ABAC
B.Node
C.AlwaysDeny
D.RBAC
AnswerD

RBAC is the default in most modern distributions.

Why this answer

RBAC (Role-Based Access Control) is the default authorization mode for new Kubernetes clusters since version 1.8. When you initialize a cluster with kubeadm, the API server is automatically configured with the `--authorization-mode=RBAC` flag, enabling fine-grained access control based on roles and bindings.

Exam trap

CNCF often tests the misconception that ABAC is the default because it was the original authorization mode in early Kubernetes versions, but RBAC has been the default since v1.8 and is the recommended standard for security.

How to eliminate wrong answers

Option A is wrong because ABAC (Attribute-Based Access Control) is not the default; it requires manual configuration with `--authorization-mode=ABAC` and a policy file, and it is less secure and harder to manage than RBAC. Option B is wrong because Node authorization is a special-purpose mode used to authorize kubelet API requests, not the default for the entire cluster; it is typically combined with other modes like RBAC. Option C is wrong because AlwaysDeny is a legacy mode that denies all requests and is not used in production; it was removed in Kubernetes 1.10 and is never the default.

358
MCQhard

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

A.Use 'privileged' PSS with Warn mode
B.Use 'baseline' PSS with Audit mode
C.Use 'restricted' PSS with Enforce mode
D.Use 'baseline' PSS with Enforce mode
AnswerC

Restricted profile requires non-root and drops all capabilities except net bind service.

Why this answer

The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Exam trap

CNCF often tests the misconception that 'baseline' PSS is sufficient for most security needs, but the trap here is that 'baseline' still allows root and default capabilities, which are exactly the vectors exploited in container breakout attacks, making 'restricted' the only adequate choice for this specific risk.

How to eliminate wrong answers

Option A is wrong because 'privileged' PSS is the least restrictive policy, allowing all capabilities and root access, which would not mitigate breakout risks; 'Warn' mode only alerts but does not block non-compliant pods. Option B is wrong because 'baseline' PSS allows some default capabilities and does not enforce dropping all capabilities or preventing root, and 'Audit' mode only logs violations without enforcement. Option D is wrong because while 'baseline' PSS with 'Enforce' mode blocks some obvious misconfigurations, it still permits containers to run as root and retains default capabilities, leaving significant breakout vectors unaddressed.

359
MCQeasy

Which admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes?

A.NodeRestriction
B.PodNodeSelector
C.SecurityContextDeny
D.AlwaysPullImages
AnswerA

NodeRestriction ensures kubelets can only modify their own node objects.

Why this answer

The NodeRestriction admission plugin is recommended by the CIS Kubernetes Benchmark to restrict the kubelet's ability to modify nodes. It limits the kubelet's permissions to only modify its own node and its own pods, preventing it from altering other nodes or performing unauthorized operations. This plugin enforces a security boundary by rejecting requests that attempt to modify node labels, taints, or status outside the kubelet's assigned scope.

Exam trap

The trap here is that candidates often confuse admission plugins that control pod security (like SecurityContextDeny or PodNodeSelector) with the specific plugin that restricts kubelet node modification, leading them to pick a security-focused option that does not address the kubelet's API access.

How to eliminate wrong answers

Option B (PodNodeSelector) is wrong because it enforces namespace-level pod node selector constraints, not kubelet node modification restrictions. Option C (SecurityContextDeny) is wrong because it rejects pods with certain security context settings, such as privileged containers, but does not limit kubelet actions on nodes. Option D (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, addressing image freshness and security, not kubelet node modification control.

360
MCQeasy

A cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?

A.Configure Fluentd to collect network logs from each node.
B.Use Prometheus to scrape network metrics from kube-proxy.
C.Run kube-bench to audit network policies.
D.Deploy Cilium with Hubble for network flow visibility.
AnswerD

Cilium/Hubble provides pod-level network monitoring.

Why this answer

D is correct because Cilium, combined with Hubble, is specifically designed to provide deep network flow visibility and monitoring for Kubernetes pods. Hubble leverages eBPF to capture and report network traffic at the kernel level, offering granular observability into pod-to-pod communications, which directly meets the requirement for security analysis of network traffic between pods.

Exam trap

The trap here is that candidates may confuse general monitoring tools (Fluentd, Prometheus) or security auditing tools (kube-bench) with a purpose-built network flow visibility solution like Cilium/Hubble, which is the only option that directly addresses pod-to-pod traffic monitoring for security analysis.

How to eliminate wrong answers

Option A is wrong because Fluentd is a log collector and aggregator, not a network traffic monitoring tool; it collects log files (e.g., from containers or applications) but does not capture or analyze network flows between pods. Option B is wrong because Prometheus scrapes metrics (e.g., from kube-proxy for iptables rules or service endpoints) but does not provide real-time network flow visibility or capture individual packet-level communications between pods. Option C is wrong because kube-bench is a compliance auditor that checks Kubernetes clusters against CIS benchmarks, focusing on configuration security, not on monitoring live network traffic between pods.

361
MCQhard

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

A.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: privileged'
B.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: restricted'
C.Apply a PodSecurity admission label with 'pod-security.kubernetes.io/enforce: baseline'
D.Use a PodSecurityPolicy with 'requiredDropCapabilities: [NET_RAW]'
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

362
MCQeasy

Which Kubernetes resource can be used to enforce that a container's filesystem is read-only?

A.ResourceQuota
B.PodSecurityPolicy
C.SecurityContext
D.NetworkPolicy
AnswerC

SecurityContext with readOnlyRootFilesystem: true makes the container filesystem read-only.

Why this answer

The SecurityContext at the container level has a 'readOnlyRootFilesystem' field. When set to true, the container's root filesystem is read-only.

363
MCQmedium

An administrator wants to use gVisor to sandbox containers in a Kubernetes cluster. Which resource must be created to enable this?

A.RuntimeClass with handler: runsc
B.DaemonSet to install gVisor on nodes
C.PodSecurityPolicy with gVisor enabled
D.SecurityContext with runtime: gvisor
AnswerA

RuntimeClass allows selecting a container runtime. gVisor's runsc is specified as the handler.

Why this answer

To use gVisor as a container runtime sandbox in Kubernetes, you must create a RuntimeClass resource with the handler set to 'runsc'. This tells the kubelet which runtime handler to use when running pods that reference this RuntimeClass, enabling gVisor's user-space kernel (runsc) to intercept and sandbox system calls.

Exam trap

The CKS exam often tests the distinction between installing a runtime (DaemonSet) and enabling it via a Kubernetes API object (RuntimeClass), leading candidates to confuse node-level setup with cluster-level resource creation.

How to eliminate wrong answers

Option B is wrong because a DaemonSet can install gVisor binaries on nodes, but the actual enablement requires a RuntimeClass to select the runsc handler at pod creation time. Option C is wrong because PodSecurityPolicy (deprecated in 1.21) controls security contexts and admission, not runtime selection; gVisor is not a PSP feature. Option D is wrong because SecurityContext does not have a 'runtime' field; runtime selection is done via RuntimeClass, not via pod security context settings.

364
MCQmedium

A team wants to use an external secret manager (HashiCorp Vault) to inject secrets into pods. Which approach is most aligned with Kubernetes best practices?

A.Use a ConfigMap to mount secrets as files
B.Store secrets as environment variables in the pod spec
C.Use kubectl exec to copy secrets into the container at startup
D.Use a mutating webhook that injects a sidecar container to fetch secrets and mount them as volumes
AnswerD

This approach securely injects secrets without exposing them in the pod spec.

Why this answer

It follows the Kubernetes best practice of using a mutating admission webhook to inject a sidecar container (e.g., Vault Agent or Bank-Vaults) that authenticates with HashiCorp Vault, fetches secrets, and mounts them as volumes into the pod. This approach avoids storing secrets in etcd (as ConfigMaps or environment variables do) and eliminates the need for manual secret injection, aligning with the principle of least privilege and dynamic secret management.

Exam trap

The CKS exam often tests the misconception that ConfigMaps or environment variables are acceptable for secrets, but the exam emphasizes that any secret stored in etcd (even if base64-encoded) is not secure, and the only best-practice approach is to use external secret stores with sidecar injection or CSI drivers.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in etcd in plaintext (unless encrypted at rest) and are not designed for secret management; they are for non-confidential configuration data. Option B is wrong because storing secrets as environment variables in the pod spec exposes them in the pod’s spec (visible via kubectl describe) and in etcd, and they can be leaked through process listings or logs. Option C is wrong because using kubectl exec to copy secrets into a container at startup is an insecure, manual, and non-scalable practice that violates the principle of immutable infrastructure and leaves secrets in the container filesystem without proper lifecycle management.

365
MCQmedium

You are investigating a security incident where a container ran a shell inside a pod. Which Falco rule condition would trigger on a shell spawned in a container?

A.evt.type=clone and proc.name = 'shell'
B.evt.type=execve and proc.name contains 'sh'
C.proc.name in (sh, bash)
D.container.id != host and proc.name = shell
AnswerC

Correct: Falco conditions check process names to detect shell execution.

Why this answer

Falco rules use syscalls and process names to detect events. The condition 'proc.name in (sh, bash)' correctly matches processes named 'sh' or 'bash', which are common shells spawned in containers. Option A is incorrect because 'clone' is not the typical syscall for shell execution (execve is used).

Option B is incorrect because 'proc.name contains sh' would match any process with 'sh' in its name (e.g., 'sshd'), leading to false positives. Option D is incorrect because 'container.id != host' is unnecessary and 'proc.name = shell' does not match typical shell names like sh or bash.

366
Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers cannot run as root in a Kubernetes cluster? (Select TWO.)

Select 2 answers
A.Create a Gatekeeper Constraint that requires runAsNonRoot
B.Use a NetworkPolicy to block root containers
C.Set the kubelet flag --run-non-root
D.Enable the PodSecurity admission controller with the 'restricted' profile
E.Use a ServiceAccount to restrict root
AnswersA, D

Correct. Gatekeeper can enforce arbitrary policies.

Why this answer

Gatekeeper, using the Open Policy Agent (OPA) framework, can enforce custom policies via ConstraintTemplates. A Constraint requiring `runAsNonRoot: true` in the Pod security context ensures containers cannot run as root, providing a flexible, admission-time control that works across all namespaces.

Exam trap

The exam often tests the distinction between network-layer controls (NetworkPolicy) and identity objects (ServiceAccount) versus admission controllers that enforce security contexts, leading candidates to overestimate the scope of NetworkPolicies or ServiceAccounts.

367
Multi-Selecthard

Which THREE of the following are valid ways to enforce mTLS in an Istio service mesh? (Select 3)

Select 3 answers
A.DestinationRule with trafficPolicy.tls.mode set to ISTIO_MUTUAL
B.PeerAuthentication with mTLS mode set to STRICT
C.ServiceEntry with mTLS enabled for external services
D.AuthorizationPolicy with deny rules for non-mTLS traffic
E.NetworkPolicy with ingress rules to allow only TLS traffic
AnswersA, B, C

Configures client-side mTLS for traffic to a specific host.

Why this answer

A DestinationRule with `trafficPolicy.tls.mode` set to `ISTIO_MUTUAL` explicitly enforces mutual TLS for traffic to a specific host or subset, overriding the mesh-wide default. This ensures that both the client and server present certificates, providing strong identity-based authentication and encryption.

Exam trap

CNCF often tests the distinction between mTLS enforcement (which requires proxy-level TLS configuration) and reactive policies (like AuthorizationPolicy) that only filter based on mTLS metadata, leading candidates to mistakenly select options that merely check for mTLS rather than enforce it.

368
MCQeasy

Which command is used to sign a container image with Cosign?

A.cosign attest
B.cosign sign
C.cosign generate
D.cosign verify
AnswerB

cosign sign signs a container image.

Why this answer

The `cosign sign` command is used to sign container images and other artifacts, creating a digital signature that is stored alongside the image in the registry. This signature can later be verified with `cosign verify` to ensure the image's integrity and origin. The other options serve different purposes: `cosign attest` attaches an in-toto attestation, `cosign generate` creates key pairs, and `cosign verify` checks signatures.

Exam trap

A common pitfall on the CKS exam is confusing `cosign sign` (which creates a signature) with `cosign attest` (which creates an in-toto attestation) or `cosign verify` (which checks a signature). Candidates must remember that `sign` is the action that produces the cryptographic signature, while `verify` and `attest` are separate operations.

How to eliminate wrong answers

Option A is wrong because `cosign attest` is used to create an in-toto attestation (a signed statement about the image's build process or metadata), not to sign the image itself. Option C is wrong because `cosign generate` generates a key pair for signing, but does not perform the signing operation. Option D is wrong because `cosign verify` is used to validate an existing signature, not to create one.

369
MCQhard

A cluster uses Kubernetes v1.24 with Pod Security Admission enabled. The cluster administrator wants to enforce that all pods in the 'production' namespace run with the 'restricted' policy level, but some existing deployments use privileged containers. Which approach ensures that only new pods violating the policy are rejected, while existing pods continue to run?

A.Patch existing deployments to remove privileged containers, then add the label 'pod-security.kubernetes.io/enforce=restricted' to the namespace.
B.Add the namespace label 'pod-security.kubernetes.io/enforce=restricted' and leave existing pods unchanged; new pods violating the policy will be rejected.
C.Create a PodSecurityPolicy that restricts privileged containers and bind it to all service accounts in the namespace.
D.Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' and use the 'inform' mode to allow existing pods.
AnswerB

Correctly enforces the policy on new pods without affecting existing ones.

Why this answer

Pod Security Admission (PSA) in Kubernetes v1.24 enforces policies via namespace labels. Setting `pod-security.kubernetes.io/enforce=restricted` on the 'production' namespace will reject any new pod that violates the restricted policy, but existing pods are not re-evaluated and continue running. This behavior is by design: PSA evaluates pods at creation or update time, not retroactively, so existing workloads are unaffected.

Exam trap

The trap here is that candidates confuse Pod Security Admission with the deprecated PodSecurityPolicy, or assume that setting an enforce label will retroactively terminate existing pods, when in fact PSA only applies to new or updated pods.

How to eliminate wrong answers

Option A is wrong because patching existing deployments to remove privileged containers is unnecessary and contradicts the requirement to let existing pods continue running; PSA does not require modifying existing workloads. Option C is wrong because PodSecurityPolicy (PSP) was deprecated in Kubernetes v1.21 and removed in v1.25, and the question specifies v1.24 with Pod Security Admission enabled, making PSP irrelevant and non-functional. Option D is wrong because setting the label to 'enforce=restricted' already enforces the policy; 'inform' mode would only log violations without rejecting pods, which does not meet the requirement to reject new violating pods.

370
MCQmedium

An OPA/Gatekeeper constraint requires that all images' registries match a pattern. A Deployment uses 'myregistry.io/app:v1'. The admission controller rejects it. The admin runs 'kubectl get constraints' and sees the constraint is active. What is the next debugging step?

A.Disable the Gatekeeper webhook
B.Check the audit logs of Gatekeeper
C.Reapply the Deployment YAML
D.Describe the constraint and constraint template to see the denial reason
AnswerD

Describing shows violations and reasons.

Why this answer

When a Gatekeeper constraint is active but a resource is rejected, the next debugging step is to describe the constraint and its associated constraint template. The constraint template contains the Rego policy logic, and describing both objects reveals the specific denial reason, such as a pattern mismatch or a violation of the allowed registries list. This provides the exact error message from the OPA engine, enabling targeted troubleshooting without disabling or bypassing the admission controller.

Exam trap

The trap here is that candidates may think audit logs (Option B) are the primary source for real-time admission denials, when in fact the denial reason is embedded in the constraint’s status and admission response, not in periodic audit reports.

How to eliminate wrong answers

Option A is wrong because disabling the Gatekeeper webhook would bypass all policy enforcement, which is not a debugging step but a dangerous workaround that defeats the purpose of admission control. Option B is wrong because Gatekeeper audit logs are used for periodic compliance checks and reporting, not for real-time admission request denials; the denial reason is returned in the admission response and stored in the constraint status. Option C is wrong because reapplying the same Deployment YAML will not change the outcome if the constraint is active and the image registry does not match the allowed pattern; it would simply trigger the same rejection.

371
MCQmedium

An administrator runs kube-bench and receives a failing result for CIS control 1.1.1. What does this control typically check?

A.That the API server pod specification file permissions are set to 644 or more restrictive
B.That etcd is using TLS
C.That the API server audit log path is configured
D.That anonymous authentication is disabled on the API server
AnswerA

This is the check for control 1.1.1.

Why this answer

CIS control 1.1.1 specifically checks that the API server pod specification file (typically /etc/kubernetes/manifests/kube-apiserver.yaml) has permissions set to 644 or more restrictive (e.g., 600 or 640). This ensures that only authorized users (root or the kube-apiserver process) can read or modify the file, preventing unauthorized changes to critical API server configuration.

Exam trap

CNCF often tests candidates' ability to map CIS control numbers to their exact checks, so the trap here is that candidates confuse control 1.1.1 (file permissions) with other common API server hardening controls like TLS, audit logging, or authentication settings.

How to eliminate wrong answers

Option B is wrong because etcd TLS configuration is covered under a different CIS control (e.g., 2.1 or 2.2), not 1.1.1. Option C is wrong because API server audit log path configuration is checked under CIS control 1.2.1 or similar audit-related controls, not 1.1.1. Option D is wrong because disabling anonymous authentication on the API server is a separate control (e.g., 1.2.3 or 1.2.4), not part of control 1.1.1 which focuses on file permissions.

372
Multi-Selecteasy

Which TWO of the following are recommended practices for securing the Kubernetes API server? (Select TWO)

Select 2 answers
A.Set --cors-allowed-origins=* for easy access.
B.Disable TLS to improve performance.
C.Enable audit logging.
D.Set --insecure-port=8080 to allow non-TLS access.
E.Set --anonymous-auth=false.
AnswersC, E

Audit logs help detect and investigate suspicious activities.

Why this answer

Enabling audit logging on the API server records all requests to the cluster, providing an immutable record for security monitoring, incident response, and compliance. Audit logs are essential for detecting unauthorized access attempts, misconfigurations, and policy violations, and are a core requirement for Kubernetes security hardening.

Exam trap

CNCF often tests the misconception that disabling security features (like TLS or authentication) improves performance or simplifies access, when in fact these actions directly violate the principle of defense in depth and are explicitly discouraged in Kubernetes security best practices.

373
Multi-Selecteasy

Which TWO of the following are tools that can be used to generate an SBOM for a container image?

Select 2 answers
A.Trivy
B.Cosign
C.Syft
D.Clair
E.Kubesec
AnswersA, C

Trivy can generate SBOMs in addition to vulnerability scanning.

Why this answer

Trivy is a comprehensive vulnerability scanner that can also generate Software Bill of Materials (SBOM) for container images. It supports multiple output formats such as CycloneDX and SPDX, making it a valid tool for SBOM generation. Syft is specifically designed to generate SBOMs from container images and filesystems, producing output in formats like CycloneDX, SPDX, and Syft's own JSON format.

Both tools are widely used in supply chain security workflows.

Exam trap

The CKS exam often tests the distinction between tools that generate SBOMs (like Syft and Trivy) versus tools that consume, sign, or attach SBOMs (like Cosign), causing candidates to confuse signing capabilities with SBOM generation.

374
MCQmedium

A security engineer wants to integrate image scanning into a CI/CD pipeline. They are using a tool that can scan the filesystem of the build context before building the image. Which tool is best suited for this purpose?

A.Trivy (trivy fs)
B.Kubesec
C.Notary
D.Cosign
AnswerA

trivy fs scans the filesystem for vulnerabilities, ideal for scanning a build context.

Why this answer

Trivy's `fs` subcommand scans the filesystem of a build context (directory) for vulnerabilities and misconfigurations before the container image is built. This allows the security engineer to catch issues early in the CI/CD pipeline, such as vulnerable application dependencies or insecure configurations in Dockerfiles, without needing a built image. Trivy is purpose-built for this filesystem scanning use case, making it the correct choice.

Exam trap

The CKS exam often tests the distinction between tools that scan build context filesystems (like Trivy fs) versus tools that scan built container images (like Trivy image or Grype), causing candidates to confuse the pipeline stage where each tool applies.

How to eliminate wrong answers

Option B is wrong because Kubesec is a static analysis tool for Kubernetes resource manifests (YAML/JSON), not for scanning filesystem contents or build contexts. Option C is wrong because Notary is a tool for signing and verifying container image metadata (using TUF framework), not for scanning filesystems. Option D is wrong because Cosign is a tool for signing and verifying container image signatures (part of Sigstore), not for scanning build context filesystems.

375
MCQeasy

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

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

Privileged allows all capabilities and has no restrictions.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

Page 4

Page 5 of 10

Page 6

All pages