Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 526600

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

Page 7

Page 8 of 10

Page 9
526
MCQhard

A security auditor requires that all container images used in the cluster are scanned for vulnerabilities before deployment. The team uses a private registry with image signing. Which solution enforces that only signed and scanned images are deployed?

A.Use Cosign to sign images and deploy a webhook that verifies signatures.
B.Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.
C.Use OPA Gatekeeper to verify that the image comes from the private registry.
D.Enable Binary Authorization on the cluster to enforce image attestation.
AnswerA

Cosign admission controller can enforce signature verification at pod creation.

Why this answer

Cosign is a tool for signing container images, and deploying a validating webhook (e.g., the cosigned admission controller) enforces that only images with valid signatures are admitted. This directly meets the requirement to deploy only signed and scanned images, as the webhook verifies the signature before the pod is created.

Exam trap

CNCF often tests the distinction between admission-time enforcement (webhooks) and post-deployment scanning (CronJobs), and the trap here is that candidates confuse scanning with enforcement, or assume Binary Authorization is a generic Kubernetes feature when it is actually GKE-specific.

How to eliminate wrong answers

Option B is wrong because a CronJob scanning images and updating a ConfigMap does not enforce admission-time control; it only provides a reactive list of allowed images, which can be bypassed or become stale. Option C is wrong because OPA Gatekeeper verifying the registry origin (e.g., checking the image path) does not verify image signatures or scan results; it only ensures the image comes from the private registry, not that it is signed or scanned. Option D is wrong because Binary Authorization is a Google Cloud-specific service (GKE) and is not a generic Kubernetes-native solution; it is not available in a standard CKS cluster environment.

527
MCQeasy

Which RBAC resource should be used to grant cluster-wide permissions to a user?

A.Role
B.RoleBinding
C.ClusterRole
D.ClusterRoleBinding
AnswerD

ClusterRoleBinding grants ClusterRole permissions cluster-wide.

Why this answer

ClusterRoleBinding is the correct resource because it binds a ClusterRole (which defines cluster-wide permissions) to a user, granting permissions across all namespaces. A ClusterRole itself only defines the rules; the binding is what actually grants those permissions to a specific subject. Therefore, to grant cluster-wide permissions to a user, you need a ClusterRoleBinding referencing a ClusterRole.

Exam trap

The trap here is that candidates often confuse a ClusterRole (which only defines rules) with a ClusterRoleBinding (which actually grants those rules to a subject), leading them to select Option C instead of D.

How to eliminate wrong answers

Option A is wrong because a Role is namespaced and can only grant permissions within a single namespace, not cluster-wide. Option B is wrong because a RoleBinding binds a Role (or ClusterRole) to a user but only within a specific namespace, so it cannot grant cluster-wide permissions. Option C is wrong because a ClusterRole only defines the set of permissions (rules) but does not grant them to any user; a binding is required to actually assign those permissions.

528
MCQmedium

Which kubectl command signs a container image using Cosign?

A.crictl sign myimage:latest
B.kubectl sign image myimage:latest
C.cosign sign myimage:latest
D.kubectl cosign sign myimage:latest
AnswerC

Cosign's sign command signs a container image.

Why this answer

Cosign is a standalone tool for signing and verifying container images, not a kubectl subcommand. The correct command is `cosign sign myimage:latest`, which signs the image and stores the signature in an OCI-compliant registry alongside the image. This is part of the supply chain security workflow for ensuring image integrity and provenance.

Exam trap

The CKS exam often tests the distinction between Kubernetes-native commands and external security tools, so the trap here is that candidates mistakenly assume `kubectl` has a built-in `sign` subcommand for container images, when in reality image signing is handled by dedicated tools like Cosign outside of kubectl.

How to eliminate wrong answers

Option A is wrong because `crictl` is a CLI for interacting with CRI-compatible container runtimes (e.g., containerd), not for signing images; it has no `sign` subcommand. Option B is wrong because `kubectl` does not have a `sign image` subcommand; kubectl manages Kubernetes resources, not image signing operations. Option D is wrong because `kubectl cosign` is not a valid kubectl plugin or subcommand; Cosign is invoked directly as `cosign`, not through kubectl.

529
MCQmedium

You need to enforce that no pod runs with privileged containers or runs as root. Which tool can define policies that block such pods at admission time?

A.Kubernetes Secret
B.PodDisruptionBudget
C.OPA Gatekeeper
D.NetworkPolicy
AnswerC

OPA Gatekeeper is an admission webhook that enforces policies, including security policies.

Why this answer

OPA Gatekeeper is a Kubernetes admission controller that enforces custom policies defined via the Constraint Framework (CF). It can reject pods that request privileged containers or run as root by evaluating constraints against the PodSecurityPolicy-like rules expressed in Rego, blocking them before they are persisted in etcd.

Exam trap

A common mistake is confusing runtime enforcement (e.g., AppArmor, seccomp) with admission-time enforcement (e.g., OPA Gatekeeper, PodSecurity Admission). Candidates often choose NetworkPolicy because it 'blocks' something, but it blocks network traffic, not pod creation.

How to eliminate wrong answers

Option A is wrong because a Kubernetes Secret is an object for storing sensitive data (e.g., passwords, tokens) and has no admission control capability to block pods based on security context. Option B is wrong because a PodDisruptionBudget (PDB) only controls the minimum number of available pods during voluntary disruptions (e.g., node drains) and does not evaluate pod security settings at admission time. Option D is wrong because a NetworkPolicy defines ingress/egress traffic rules at the network layer (L3/L4) and cannot inspect or block pod creation based on container privileges or user identity.

530
MCQeasy

You need to ensure that all pods in a cluster run with read-only root filesystems. Which Pod Security Standard (PSS) control field should be set to true?

A.spec.readOnlyRootFilesystem
B.securityContext.privileged: false
C.container.readOnly
D.securityContext.readOnlyRootFilesystem
AnswerD

Correct. Setting this field to true enforces a read-only root filesystem for the container.

Why this answer

The Pod Security Standard (PSS) control field `securityContext.readOnlyRootFilesystem` must be set to `true` at the pod or container security context level to enforce a read-only root filesystem. This setting prevents containers from writing to their root filesystem, reducing the attack surface by limiting the ability to drop malicious binaries or modify system files. It is a key control under the 'Restricted' PSS profile for minimizing microservice vulnerabilities.

Exam trap

The CKS exam often tests the distinction between pod-level and container-level security context fields, and candidates mistakenly look for a field under `spec` (like `spec.readOnlyRootFilesystem`) instead of the correct nested path `securityContext.readOnlyRootFilesystem` at the container level.

How to eliminate wrong answers

Option A is wrong because `spec.readOnlyRootFilesystem` is not a valid field; the correct field is nested under `securityContext` at the container level, not directly under `spec`. Option B is wrong because `securityContext.privileged: false` disables privileged mode but does not enforce a read-only root filesystem; it is a separate security control. Option C is wrong because `container.readOnly` is not a valid Kubernetes field; the correct field is `readOnlyRootFilesystem` within the container's `securityContext`.

531
MCQmedium

A security team wants to detect any attempt to read the /etc/shadow file inside a container. Which Falco rule condition would detect this syscall?

A.evt.type in (open, openat) and fd.name=/etc/shadow
B.evt.type=read and fd.name=/etc/shadow
C.evt.type=open and fd.name contains /etc/shadow
D.proc.name=cat and fd.name=/etc/shadow
AnswerA

Correct: open/openat syscall with exact match on shadow file.

Why this answer

Falco rules for file access typically use the 'open' or 'openat' syscall events. The 'evt.type in (open, openat)' matches both syscalls, and 'fd.name=/etc/shadow' exactly matches the target file. Option B is incorrect because a 'read' syscall alone doesn't indicate opening a file; the file descriptor is already open.

Option C is invalid because 'contains' is not a valid operator in Falco conditions. Option D is too narrow because it only triggers when the command is 'cat', missing other tools like 'less' or 'vim'.

532
MCQhard

A ClusterRoleBinding named 'admin-binding' binds the cluster-admin ClusterRole to a service account 'sa-admin' in namespace 'ns1'. What is the security concern?

A.The service account 'sa-admin' can access resources in all namespaces
B.ClusterRoleBinding should be replaced by RoleBinding for cluster-scoped resources
C.The service account token is automatically mounted
D.ClusterRoleBinding should not be used for service accounts
AnswerA

cluster-admin grants unrestricted access across the entire cluster.

Why this answer

A ClusterRoleBinding grants permissions cluster-wide, meaning the service account 'sa-admin' in namespace 'ns1' can access resources in all namespaces, not just its own. This violates the principle of least privilege by providing excessive access beyond the intended scope.

Exam trap

The trap here is that candidates may overlook that a ClusterRoleBinding grants permissions across all namespaces, focusing instead on the service account's namespace or token mounting, rather than the scope of the binding.

How to eliminate wrong answers

Option B is wrong because ClusterRoleBinding is specifically designed for cluster-scoped resources, not RoleBinding; RoleBinding is for namespace-scoped resources. Option C is wrong because automatic token mounting is a separate concern about pod security, not a direct security issue of the binding itself. Option D is wrong because ClusterRoleBinding can and should be used for service accounts when cluster-wide access is required, but the concern here is the unnecessary scope of access.

533
Multi-Selectmedium

Which TWO kubelet flags are recommended by the CIS Kubernetes Benchmark to enhance security? (Select TWO)

Select 2 answers
A.--anonymous-auth=false
B.--authentication-token-webhook=false
C.--read-only-port=10255
D.--protect-kernel-defaults=true
E.--authorization-mode=AlwaysAllow
AnswersA, D

Disables anonymous access to the kubelet.

Why this answer

Setting --anonymous-auth=false disables anonymous requests to the kubelet API, which is a CIS Benchmark recommendation to prevent unauthenticated access. Option D is correct because --protect-kernel-defaults=true ensures the kubelet checks and enforces kernel hardening parameters (e.g., sysctl settings) at startup, reducing the attack surface.

Exam trap

CNCF often tests the distinction between authentication and authorization flags, tricking candidates into thinking that disabling webhook authentication (--authentication-token-webhook=false) is secure, when in fact it removes a key validation layer.

534
MCQhard

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

A.The AppArmor profile is not in the same namespace as the pod
B.The AppArmor profile is not loaded on the node
C.The pod's securityContext does not have 'apparmor: enabled'
D.The node does not support AppArmor
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

535
MCQhard

An administrator wants to enable encryption at rest for secrets in a Kubernetes cluster. They create the following EncryptionConfiguration and place it at /etc/kubernetes/enc/enc.yaml. Which flag must be added to the kube-apiserver to use this configuration?

A.--feature-gates=EncryptionAtRest=true
B.--enable-encryption
C.--encryption-config=/etc/kubernetes/enc/enc.yaml
D.--encryption-provider-config=/etc/kubernetes/enc/enc.yaml
AnswerD

This is the correct flag to enable encryption at rest.

Why this answer

The kube-apiserver requires the `--encryption-provider-config` flag to specify the path to the EncryptionConfiguration YAML file. This flag tells the API server which encryption providers (e.g., `aescbc`, `secretbox`) to use for encrypting secrets at rest in etcd. Without this flag, the EncryptionConfiguration file is ignored and secrets remain unencrypted.

Exam trap

The trap here is that candidates may confuse the flag name `--encryption-provider-config` with the similar-sounding but incorrect `--encryption-config`, or assume a feature gate or generic enable flag is sufficient without providing the configuration file path.

How to eliminate wrong answers

Option A is wrong because `--feature-gates=EncryptionAtRest=true` is not a valid flag; encryption at rest is enabled via the `--encryption-provider-config` flag, not a feature gate. Option B is wrong because `--enable-encryption` does not exist as a kube-apiserver flag; the correct flag requires specifying the configuration file path. Option C is wrong because `--encryption-config` is not a recognized flag; the correct flag name is `--encryption-provider-config`.

536
MCQeasy

Which Kubernetes resource should be used to restrict egress traffic from pods?

A.NetworkPolicy with egress rules
B.PodSecurityPolicy
C.iptables rules on nodes
D.NetworkPolicy with ingress rules
AnswerA

Directly restricts egress.

Why this answer

NetworkPolicy with egress rules is the correct Kubernetes-native resource to restrict outbound traffic from pods. It uses label selectors, IP blocks, and port specifications to define which external destinations pods can reach, enforcing zero-trust network segmentation at the pod level.

Exam trap

The trap here is that candidates confuse egress (outbound) with ingress (inbound) rules, or assume PodSecurityPolicy can restrict network traffic, when it only governs pod security contexts like privileged mode and host namespaces.

How to eliminate wrong answers

Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security contexts and pod-level privileges, not network traffic direction. Option C is wrong because iptables rules on nodes are a low-level, node-centric approach that bypasses Kubernetes API management, lacks pod identity awareness, and is not a declarative Kubernetes resource. Option D is wrong because NetworkPolicy with ingress rules only controls incoming traffic to pods, not outgoing egress traffic.

537
MCQmedium

A Falco rule has the following output: 'Sensitive file opened for reading (user=root command=cat /etc/shadow)'. Which macro is most likely used in the rule condition?

A.shell_procs
B.outbound
C.binaries
D.sensitive_file_names
AnswerD

Correct. This macro is defined in Falco's default rules to detect access to sensitive files.

Why this answer

Falco has a macro called 'sensitive_file_names' that includes files like /etc/shadow, /etc/passwd, etc. The rule likely uses that macro to match on open syscalls targeting those files.

538
MCQhard

A security engineer wants to ensure that all container images in a Kubernetes cluster have a non-root user. Which admission controller can enforce this requirement?

A.ServiceAccount
B.PodSecurityPolicy (deprecated)
C.NodeRestriction
D.Kyverno
AnswerD

Kyverno can enforce policies like requiring runAsNonRoot: true.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce custom admission control rules, such as requiring containers to run as a non-root user. Unlike deprecated or built-in controllers, Kyverno allows you to define fine-grained policies (e.g., `autogen-check`) that validate or mutate Pod specs to ensure `runAsNonRoot: true` or `runAsUser: >0`.

Exam trap

A common pitfall is selecting PodSecurityPolicy because it was the traditional way to enforce security policies, but it is deprecated and removed in newer Kubernetes versions. The question specifically asks for an admission controller that can enforce a non-root user requirement. Built-in controllers like ServiceAccount or NodeRestriction cannot enforce custom pod security policies.

Kyverno (and OPA/Gatekeeper) are Kubernetes-native policy engines that act as dynamic admission controllers to validate or mutate pod specs. Candidates often overlook that Kyverno is a valid admission controller for such custom rules.

How to eliminate wrong answers

Option A is wrong because ServiceAccount is an API object for identity and access control, not an admission controller that can enforce container image user requirements. Option B is wrong because PodSecurityPolicy is deprecated and removed in Kubernetes v1.25, and while it could enforce non-root users, it is no longer a viable solution for current CKS exam objectives. Option C is wrong because NodeRestriction is an admission controller that limits Node API modifications, not container security contexts.

539
Multi-Selectmedium

Which TWO actions would help secure the Kubernetes Dashboard?

Select 2 answers
A.Restrict access to the Dashboard using NetworkPolicies or authentication
B.Use minimal RBAC permissions for Dashboard service account
C.Deploy Dashboard in the kube-system namespace
D.Bind Dashboard service account to cluster-admin
E.Expose Dashboard via NodePort for easy access
AnswersA, B

Network policies and strong authentication help secure the Dashboard.

Why this answer

Kubernetes NetworkPolicies can restrict ingress traffic to the Dashboard pod, ensuring only authorized sources can reach it. Additionally, enabling authentication (e.g., using the built-in token-based login or OIDC) prevents unauthenticated access, which is critical since the Dashboard has powerful cluster management capabilities.

Exam trap

CNCF often tests the misconception that placing a component in the kube-system namespace or using NodePort is acceptable for 'convenience,' but the CKS exam emphasizes that security controls like NetworkPolicies and minimal RBAC are mandatory, not optional.

540
Multi-Selecthard

Which THREE of the following are valid encryption providers that can be used in EncryptionConfiguration for encryption at rest?

Select 3 answers
A.aescbc
B.kms
C.aesgcm
D.rsa
E.secretbox
AnswersA, B, E

AES-CBC is a valid encryption provider.

Why this answer

(aescbc) is correct because AES-CBC is a symmetric encryption algorithm that Kubernetes supports natively in EncryptionConfiguration for encrypting Secrets at rest. It uses a 32-byte key for AES-256 encryption and is the most commonly used provider for this purpose.

Exam trap

CNCF often tests that candidates confuse AES-GCM (which is not supported) with AES-CBC (which is supported), or assume RSA (asymmetric) can be used for at-rest encryption when Kubernetes only supports symmetric or KMS-based providers.

541
Multi-Selectmedium

Which TWO of the following are benefits of using an SBOM (Software Bill of Materials) in supply chain security?

Select 2 answers
A.It allows for faster image pulls
B.It helps in identifying known vulnerabilities in dependencies
C.It ensures license compliance by tracking open source components
D.It reduces the size of the container image
E.It automatically patches vulnerabilities
AnswersB, C

By listing components, you can cross-reference with vulnerability databases.

Why this answer

An SBOM lists all components and dependencies in a software artifact, enabling teams to cross-reference against vulnerability databases (e.g., NVD) to identify known CVEs. This proactive identification is a core supply chain security practice, as mandated by frameworks like SLSA and EO 14028.

Exam trap

A common trap in the CKS exam is confusing the passive inventory role of an SBOM with active security actions or performance improvements. Candidates may think an SBOM directly patches vulnerabilities or speeds up image pulls, but it is merely a list of components that enables other tools to act.

542
Multi-Selectmedium

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

Select 2 answers
A.kill
B.complain
C.enforce
D.audit
E.permissive
AnswersB, C

Complain mode logs violations but does not enforce.

Why this answer

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

Exam trap

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

543
MCQhard

You have a Kyverno policy that validates image registries. The policy should allow only images from `myregistry.example.com`. Which Kyverno rule field should be used to check the image registry?

A.mutate
B.resources
C.imageRegistry
D.generate
AnswerC

imageRegistry is the correct field to define allowed image registries in a Kyverno rule.

Why this answer

The `imageRegistry` field in a Kyverno policy rule is specifically designed to validate image registries by matching the registry hostname against a pattern. In this case, setting `imageRegistry: "myregistry.example.com/*"` ensures only images from that registry are allowed, blocking others at admission time.

Exam trap

The trap here is that candidates confuse `imageRegistry` with `resources` or think validation is done via `mutate`, but only `imageRegistry` directly checks the registry portion of the container image reference.

How to eliminate wrong answers

Option A is wrong because `mutate` is used to modify resources during admission, not to validate image registries. Option B is wrong because `resources` defines which Kubernetes resource types the rule applies to (e.g., Pods), not the image registry check. Option D is wrong because `generate` creates new resources based on a template, not for validation of existing image registries.

544
MCQmedium

A security team wants to enforce that containers in a specific namespace cannot gain new capabilities. Which Pod security context field is used to achieve this?

A.capabilities.drop: ["ALL"]
B.privileged: false
C.allowPrivilegeEscalation: false
D.runAsNonRoot: true
AnswerC

Correct. This prevents privilege escalation.

Why this answer

`allowPrivilegeEscalation: false` directly controls whether a process can gain more privileges than its parent, which is the mechanism by which containers acquire new capabilities (e.g., via `setuid` binaries or `file capabilities`). Setting this to `false` prevents privilege escalation within the container, effectively blocking the acquisition of new capabilities beyond those initially granted. This field is defined in the Pod Security Context and is a key control for minimizing microservice vulnerabilities.

Exam trap

The trap is that candidates often choose capabilities.drop: ['ALL'] because it removes all capabilities, but the question asks for preventing containers from gaining new capabilities. allowPrivilegeEscalation: false prevents privilege escalation at runtime, which is the mechanism for gaining new capabilities beyond those initially granted.

How to eliminate wrong answers

Option A is wrong because `capabilities.drop: ["ALL"]` drops all capabilities from the container's bounding set, but it does not prevent the container from gaining new capabilities later (e.g., through a `setcap` binary or a privileged helper process); it only removes existing ones at start time. Option B is wrong because `privileged: false` is the default and disables privileged mode, but it does not specifically prevent capability escalation; a non-privileged container can still gain new capabilities via `setuid` or file capabilities if `allowPrivilegeEscalation` is not set to false. Option D is wrong because `runAsNonRoot: true` ensures the container runs as a non-root user, but it does not block the acquisition of new capabilities; a non-root user can still gain capabilities through `setcap` or other mechanisms if privilege escalation is allowed.

545
Multi-Selectmedium

Which THREE of the following are valid AppArmor profile modes?

Select 3 answers
A.complain
B.audit
C.enforce
D.unconfined
E.allow
AnswersA, C, D

Correct. Complain is a valid AppArmor profile mode where violations are logged but not blocked.

Why this answer

AppArmor has three valid profile modes: enforce, complain, and unconfined. In enforce mode, violations are blocked and logged; in complain mode, only logging occurs without blocking; in unconfined mode, the profile is loaded but no confinement is applied (essentially disabled). The other options are not valid profile modes: audit is a rule-level flag, and allow is not a mode.

Therefore, options A (complain), C (enforce), and D (unconfined) are all valid AppArmor profile modes.

Exam trap

CNCF-CKS often tests the distinction between profile modes and rule-level flags. Candidates may mistakenly think 'audit' or 'allow' are profile modes when they are actually rule-level keywords. Additionally, note that 'unconfined' is a valid profile mode, though sometimes overlooked.

546
Multi-Selectmedium

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

Select 2 answers
A.Set readOnlyRootFilesystem in pod security contexts
B.Enable AppArmor profiles on the nodes
C.Set --no-new-privileges flag in the container runtime configuration
D.Configure Seccomp profiles to allow only necessary syscalls
E.Disable swap on all nodes
AnswersB, D

AppArmor restricts container processes to a minimal set of capabilities.

Why this answer

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

Exam trap

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

547
MCQhard

A pod is failing to start with: 'Error: container has runAsNonRoot and image will run as root'. The pod spec sets securityContext.runAsNonRoot: true. The container image is 'nginx:latest' which runs as root. Which change allows the pod to run while maintaining security?

A.Remove runAsNonRoot: true
B.Add a PodSecurityPolicy that allows root
C.Set runAsUser: 1000 in the container securityContext
D.Use a mutating webhook to change the image
AnswerC

Runs as non-root user, satisfying runAsNonRoot.

Why this answer

Setting `runAsUser: 1000` in the container's securityContext overrides the default user (root) in the image, ensuring the container process runs as a non-root user (UID 1000). This satisfies the `runAsNonRoot: true` constraint at the pod level, which requires that the container's user ID is non-zero, while still maintaining security by not running as root.

Exam trap

CNCF often tests the distinction between pod-level and container-level securityContext settings, and the trap here is that candidates might think removing `runAsNonRoot` or using a deprecated PSP is acceptable, rather than directly setting a non-root user ID in the container's securityContext.

How to eliminate wrong answers

Option A is wrong because removing `runAsNonRoot: true` would allow the container to run as root, which violates the security requirement of running as non-root. Option B is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21+ and removed in 1.25; even if available, adding a policy that allows root would bypass the security constraint, not maintain it. Option D is wrong because using a mutating webhook to change the image (e.g., to a non-root image) is an indirect and unnecessary workaround; the direct fix is to set `runAsUser` in the container's securityContext, which is simpler and more explicit.

548
MCQmedium

A pod is stuck in 'Pending' state. You run 'kubectl describe pod mypod' and see the event: '0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the most likely solution?

A.Delete the pod and recreate it without any tolerations
B.Remove the taint from the node using 'kubectl taint nodes ...'
C.Add a toleration to the pod spec for the taint 'node-role.kubernetes.io/master'
D.Add a nodeSelector to the pod to match the node's labels
AnswerC

Correct. Adding a toleration allows the pod to be scheduled on the tainted node.

Why this answer

The pod cannot schedule because the node has a taint. To allow the pod to run on that node, add a toleration for that taint in the pod spec.

549
MCQmedium

Which admission plugin should be enabled to ensure that kubelet only serves pods bound to its node and prevents unauthorized node access?

A.NodeRestriction
B.AlwaysPullImages
C.NodeAffinity
D.PodSecurityPolicy
AnswerA

This plugin restricts kubelet permissions to pods on its own node.

Why this answer

The NodeRestriction admission plugin ensures that the kubelet only serves pods bound to its node by limiting the kubelet's ability to modify labels and taints on its own Node object, and by preventing the kubelet from modifying pods not scheduled to its node. This plugin is a key security control to prevent unauthorized node access and enforce the principle of least privilege for kubelet operations.

Exam trap

CNCF often tests the distinction between admission plugins that control pod-level security (like PodSecurityPolicy) versus those that control node-level authorization (like NodeRestriction), leading candidates to confuse PodSecurityPolicy as the answer for node access control.

How to eliminate wrong answers

Option B (AlwaysPullImages) is wrong because it forces image pull policy to Always for every pod, which prevents use of locally cached images but does not restrict kubelet node access or pod binding. Option C (NodeAffinity) is wrong because it is a scheduling constraint (expressed via nodeSelector or affinity rules) that influences pod placement, not an admission plugin that restricts kubelet behavior after scheduling. Option D (PodSecurityPolicy) is wrong because it enforces security context constraints on pods (e.g., privileged containers, host namespaces) and does not control kubelet node-level access or pod binding.

550
MCQeasy

You want to ensure that a container's root filesystem is immutable. Which field in the Pod spec should you set?

A.spec.containers[].securityContext.privileged
B.spec.hostNetwork
C.spec.containers[].securityContext.readOnlyRootFilesystem
D.spec.containers[].volumeMounts[].readOnly
AnswerC

Setting this to true makes the filesystem read-only.

Why this answer

The correct field is 'spec.containers[].securityContext.readOnlyRootFilesystem'. Setting this field to true makes the container's root filesystem read-only, effectively immutable. Option A (privileged) grants elevated capabilities but does not affect filesystem immutability.

Option B (hostNetwork) configures network namespace, not filesystem. Option D (volumeMounts[].readOnly) only applies to specific volumes, not the root filesystem.

551
MCQmedium

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

A.privileged: true
B.capabilities: { add: ['SYS_ADMIN'] }
C.capabilities: { drop: ['NET_ADMIN'] }
D.capabilities: { add: ['NET_ADMIN'] }
AnswerD

NET_ADMIN is the capability required for iptables operations.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

552
Multi-Selectmedium

Which TWO of the following are valid methods to verify the integrity of a container image? (Select 2)

Select 2 answers
A.Use trivy image to check for vulnerabilities
B.Compare the image SHA digest with a known good digest
C.Use cosign verify to check the image signature
D.Use docker history to view layers
E.Use kubectl describe pod to check image details
AnswersB, C

Using SHA digests ensures the image has not been tampered with.

Why this answer

Container images are identified by a content-addressable digest (SHA256 hash) that uniquely represents the image manifest. Verifying that the SHA digest of a pulled image matches a known good digest from a trusted source ensures the image has not been tampered with or altered in transit, as any change to the image layers or configuration would result in a different digest.

Exam trap

Candidates often confuse vulnerability scanning tools (which find known vulnerabilities) with integrity verification methods (which detect tampering). Trivy is a vulnerability scanner, not an integrity verification tool.

553
MCQhard

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

A.containerd
B.sshd
C.cups
D.kubelet
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

554
Multi-Selecteasy

Which TWO of the following are valid Kubernetes RuntimeClass handlers for container sandboxing? (Choose two.)

Select 2 answers
A.docker
B.runc
C.runsc
D.containerd
E.kata
AnswersC, E

gVisor's runtime handler is runsc.

Why this answer

(runsc) is correct because it is the handler for gVisor, a user-space kernel that provides an additional layer of sandboxing between the container and the host kernel. In Kubernetes, a RuntimeClass with handler 'runsc' instructs the container runtime (e.g., containerd) to launch the container using gVisor's runsc runtime, which intercepts system calls to enforce a security boundary.

Exam trap

The CKS exam often tests the distinction between container runtimes (like runc) and sandboxing runtimes (like runsc or kata), and the trap here is that candidates mistakenly select runc because it is a common runtime, but it does not provide sandboxing isolation.

555
MCQeasy

Which of the following is a best practice for securing container images in a CI/CD pipeline?

A.Using a minimal base image such as Alpine
B.Using the 'latest' tag for all base images to ensure the newest features
C.Running the container as root to avoid permission issues
D.Installing all available packages to ensure the application has all dependencies
AnswerA

Minimal images reduce vulnerabilities and attack surface.

Why this answer

Using a minimal base image like Alpine reduces the attack surface by minimizing the number of installed packages and potential vulnerabilities.

556
MCQhard

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

A.seccompProfile: type: Localhost localhostProfile: audit.json
B.seccompProfile: type: Unconfined localhostProfile: audit.json
C.seccompProfile: type: Localhost localhostProfile: /var/lib/kubelet/seccomp/audit.json
D.seccompProfile: type: RuntimeDefault localhostProfile: audit.json
AnswerA

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

557
MCQeasy

Which crictl command is used to list all running containers managed by the container runtime?

A.crictl images
B.crictl stats
C.crictl ps
D.crictl pods
AnswerC

crictl ps lists containers.

Why this answer

crictl ps lists containers, similar to docker ps.

558
Matchingmedium

Match each Kubernetes command to its function related to security.

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

Concepts
Matches

Check whether an action is allowed for a user or service account

Approve a certificate signing request (CSR)

Run a temporary interactive pod for troubleshooting

Create a secret from literals, files, or directories

Apply a PodSecurityPolicy configuration (deprecated)

Why these pairings

The correct matches are: 'kubectl auth can-i' checks permissions, 'kubectl certificate approve' handles CSRs, 'kubectl describe clusterrole' shows role details, and 'kubectl create serviceaccount' creates service accounts. Common confusions include mixing the functions of permission checking and resource creation.

559
MCQmedium

An administrator wants to enforce that only images signed by a trusted key can run in the cluster. They have configured cosign and want to use a Kubernetes admission controller. Which tool should they deploy?

A.Helm
B.Kube-bench
C.Prometheus
D.Kyverno with a verifyImages rule
AnswerD

Kyverno can be configured to verify container image signatures using cosign.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce admission controls via policies. Its `verifyImages` rule uses Cosign to check that container images are signed with a trusted public key before allowing them to run, making it the correct tool for this use case.

Exam trap

The trap here is that candidates may confuse tools like Helm or Prometheus with admission controllers, but only Kyverno (or OPA/Gatekeeper with custom rules) can enforce image signature verification via Cosign at the admission webhook level.

How to eliminate wrong answers

Option A is wrong because Helm is a package manager for Kubernetes used to deploy applications, not an admission controller for enforcing image signature verification. Option B is wrong because kube-bench is a security benchmark tool that checks clusters against CIS benchmarks, but it does not enforce admission policies or verify image signatures. Option C is wrong because Prometheus is a monitoring and alerting toolkit, not an admission controller; it cannot intercept API requests to validate image signatures.

560
MCQmedium

Which flag must be set on the kubelet to prevent it from using the default namespace for pods and to enforce that pods only use namespaces that match the node's assigned namespace?

A.--protect-kernel-defaults=true
B.--namespace-default=restricted
C.--authentication-token-webhook=true
D.--anonymous-auth=false
AnswerC

--authentication-token-webhook enables token authentication, not namespace enforcement.

Why this answer

The kubelet does not have a flag to directly enforce that pods only use namespaces matching the node's assigned namespace. Namespace enforcement for pods on a node is part of the NodeRestriction admission plugin on the API server, which restricts kubelet's ability to only update pods bound to its node. None of the listed kubelet flags provide this functionality. --authentication-token-webhook=true enables token authentication but does not enforce namespace restrictions.

Exam trap

A common trap is assuming that a specific kubelet flag exists for namespace enforcement. In reality, no such flag exists; namespace restrictions are enforced by the API server's NodeRestriction admission plugin, not by kubelet flags.

How to eliminate wrong answers

Option A is wrong because `--protect-kernel-defaults=true` is a security flag that ensures the kubelet does not modify kernel parameters (like sysctl settings) that could affect the host, but it has nothing to do with namespace enforcement or preventing the use of the default namespace. Option B is wrong because `--namespace-default=restricted` is not a valid kubelet flag; the kubelet does not have a flag to set a default namespace for pods, and namespace enforcement is handled via authentication and authorization, not a default namespace setting. Option C is wrong because `--authentication-token-webhook=true` enables the kubelet to use the Kubernetes API server's TokenReview API to validate bearer tokens (e.g., service account tokens), but by itself it does not prevent anonymous access or enforce namespace matching; it must be combined with `--anonymous-auth=false` to block unauthenticated requests.

561
MCQmedium

An administrator wants to verify that an image was signed by a specific key before deploying. Which Cosign command should be used?

A.cosign verify --key mykey.pub myimage
B.cosign sign --key mykey.pub myimage
C.cosign download myimage
D.cosign attest --predicate mypredicate myimage
AnswerA

This verifies the image signature using the public key.

Why this answer

The `cosign verify` command is used to verify the signature of a container image against a public key. By specifying `--key mykey.pub`, the administrator confirms that the image was signed with the corresponding private key before it can be deployed, ensuring supply chain integrity.

Exam trap

CNCF often tests the distinction between signing (`cosign sign`) and verifying (`cosign verify`), expecting candidates to know that `verify` is the correct command for checking an image's signature before deployment, not `sign` or `attest`.

How to eliminate wrong answers

Option B is wrong because `cosign sign` creates a signature, not verifies one; it requires a private key to sign an image, not a public key. Option C is wrong because `cosign download` retrieves the image's signatures or attestations but does not perform verification against a specific key. Option D is wrong because `cosign attest` attaches an in-toto attestation to an image, which is a separate process from verifying an existing signature.

562
MCQeasy

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

A.CAP_SYS_NICE
B.CAP_SYS_RESOURCE
C.CAP_SYS_ADMIN
D.CAP_SYS_TIME
AnswerD

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

563
MCQmedium

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

A.crictl ps
B.crictl exec
C.crictl logs
D.crictl inspect
AnswerC

crictl logs <container-id> retrieves container logs.

Why this answer

crictl logs <container-id> displays logs from a container. crictl ps lists containers, crictl exec runs a command in a container, and crictl inspect shows detailed container information.

564
MCQhard

You are a platform engineer at a financial services company. The production cluster runs a set of microservices that handle sensitive customer data. The cluster has been configured with Pod Security Standards (PSS) enforced via OPA/Gatekeeper. Recently, the security team identified that a new deployment of the `payment-processing` microservice is running with the `seccomp` profile set to `Unconfined`. This violates the company policy that requires all containers to use a runtime default seccomp profile. The deployment YAML does not explicitly set any security context for seccomp. The cluster's nodes are running containerd 1.6 with default seccomp profile enabled. The OPA constraint template checks that `securityContext.seccompProfile.type` is set to `RuntimeDefault` or `Localhost`. However, the deployment passes the OPA validation. What is the most likely reason the deployment is not being rejected by OPA, and how should you fix it?

A.The seccomp profile must be set via an admission controller, not OPA.
B.OPA/Gatekeeper is not properly installed or the constraint is not active.
C.The cluster's nodes do not support seccomp, so the profile is ignored.
D.The OPA constraint only checks pod-level `securityContext`, but the deployment uses container-level settings.
AnswerD

The constraint should iterate over containers in the pod spec to enforce seccomp at the container level.

Why this answer

The OPA constraint template checks `securityContext.seccompProfile.type` at the pod level, but the deployment does not set any security context at the pod level. The seccomp profile is only set at the container level (or defaults to `Unconfined` by the runtime), and the OPA constraint does not inspect container-level `securityContext`. This mismatch allows the deployment to pass validation even though the container is running with an unconfined seccomp profile.

Exam trap

The trap here is that candidates assume OPA constraints automatically check all levels of securityContext, but they must be explicitly written to inspect container-level settings, and the default behavior of the runtime can lead to a false sense of security.

How to eliminate wrong answers

Option A is wrong because OPA/Gatekeeper can enforce seccomp profiles via constraints; admission controllers are not required for seccomp enforcement. Option B is wrong because the scenario states the cluster is configured with PSS enforced via OPA/Gatekeeper, and the constraint is active (it checks pod-level securityContext), so the issue is not installation or activation. Option C is wrong because the nodes run containerd 1.6 with default seccomp profile enabled, so seccomp is supported and the profile is not ignored.

565
MCQmedium

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy: package k8srequiredlabels deny[{"msg": msg}] { input.request.kind.kind == "Pod" not input.request.object.metadata.labels["security-tier"] msg := "Pod must have label 'security-tier'" } After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

A.The pod is created and the label is automatically added
B.The pod creation is denied with a message
C.Only the first pod without the label is denied; subsequent ones are allowed
D.The pod is created but logged as a violation
AnswerB

Correct. The deny rule blocks admission and returns the message.

Why this answer

The Gatekeeper ConstraintTemplate defines a Rego policy that denies any Pod creation request that lacks the 'security-tier' label. When the user creates a Pod without this label, the admission webhook evaluates the policy and returns a denial message 'Pod must have label 'security-tier'', preventing the Pod from being created. Gatekeeper operates as a validating admission webhook, so it rejects the request before the object is persisted in etcd.

Exam trap

The exam often tests the distinction between validating and mutating admission webhooks—candidates may mistakenly think Gatekeeper can auto-add labels (mutating behavior) or that it only logs violations (audit mode), but the Rego policy here uses 'deny' which causes immediate rejection.

How to eliminate wrong answers

Option A is wrong because Gatekeeper does not automatically add missing labels; it only validates and denies or allows requests based on the policy. Option C is wrong because Gatekeeper evaluates every admission request independently; there is no 'first-only' behavior—each Pod without the label is denied consistently. Option D is wrong because Gatekeeper denies the request outright when the policy is violated; it does not create the Pod and log the violation—that behavior would require a mutating webhook or an audit-only mode, which is not configured here.

566
MCQmedium

You need to detect when a container attempts to mount the host's Docker socket. Which Falco macro or condition would you use?

A.fd.name=/var/run/docker.sock
B.fd.name=/var/run/containerd.sock
C.fd.name=/var/run/docker
D.fd.name=/run/docker.sock
AnswerA

Why this answer

Falco has a default macro 'docker_socket' that matches the path '/var/run/docker.sock'. Using fd.name=/var/run/docker.sock in a condition will detect access to the socket. Option A is correct.

Option B is a valid path but not the standard. Option C is a directory. Option D is a different socket.

567
MCQeasy

A DevOps team wants to ensure that only signed images from a trusted registry are deployed in the cluster. They plan to use a webhook to intercept pod creation. Which tool is best suited for this task?

A.kubectl with --validate flag
B.Helm with signed charts
C.etcd with encryption at rest
D.Kyverno with a verifyImages rule
E.Prometheus with alerting rules
AnswerD

Kyverno supports image signature verification via cosign.

Why this answer

Kyverno is a Kubernetes-native policy engine that can enforce image signature verification via its `verifyImages` rule. It intercepts pod creation through a dynamic admission webhook, checking that container images are signed with a trusted key (e.g., using Sigstore/Cosign) before the pod is admitted. This directly meets the requirement to only allow signed images from a trusted registry.

Exam trap

The trap here is that candidates confuse Helm chart signing (which verifies chart provenance) with container image signing, leading them to select Option B, even though Helm does not verify the images inside the chart at pod creation time.

How to eliminate wrong answers

Option A is wrong because `kubectl --validate` only performs client-side schema validation on the manifest, not image signature verification. Option B is wrong because Helm with signed charts ensures the Helm chart itself is signed, but does not verify the container images referenced within the chart at deployment time. Option C is wrong because etcd encryption at rest protects data stored in etcd (e.g., Secrets) but does not intercept pod creation or verify image signatures.

Option E is wrong because Prometheus with alerting rules monitors metrics and triggers alerts, but cannot enforce admission control or block pod creation based on image signatures.

568
Multi-Selecthard

Which THREE of the following are true about Istio PeerAuthentication? (Select THREE.)

Select 3 answers
A.It can be used to enable mTLS for all workloads in a namespace
B.It configures how traffic is routed between services
C.It can specify TLS mode as STRICT, PERMISSIVE, or DISABLE
D.It requires a DestinationRule to define the TLS settings
E.It can be applied to specific workloads using label selectors
AnswersA, C, E

Correct.

Why this answer

Istio PeerAuthentication defines the mutual TLS (mTLS) mode for traffic between services within a mesh. When applied at the namespace level, it enforces the specified mTLS mode (e.g., STRICT) for all workloads in that namespace, ensuring that all inter-service communication uses TLS certificates for identity and encryption.

Exam trap

Candidates often confuse the role of Istio PeerAuthentication (which controls mTLS mode) with DestinationRule (which controls traffic routing and TLS settings for outbound connections). They may incorrectly think a DestinationRule is required for PeerAuthentication to work, when in fact PeerAuthentication is independent and only sets the mTLS policy for inbound traffic.

569
MCQmedium

A service account 'monitor' needs to list pods in all namespaces. Which minimal RBAC configuration should you use?

A.ClusterRole with get pods, then ClusterRoleBinding
B.Role with get pods in kube-system, then RoleBinding
C.ClusterRole with get pods, then RoleBinding in default namespace
D.Role in each namespace with get pods, then RoleBinding
AnswerA

This grants the permission across all namespaces.

Why this answer

A ClusterRole with 'get pods' permission grants access to pods across all namespaces, and a ClusterRoleBinding binds that ClusterRole to the 'monitor' service account cluster-wide. This is the minimal RBAC configuration for listing pods in all namespaces, as a Role and RoleBinding are namespace-scoped and cannot grant cross-namespace access.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, thinking a ClusterRole can be bound to a namespace via a RoleBinding to grant cluster-wide access, but RoleBinding only applies the permissions within that specific namespace.

How to eliminate wrong answers

Option B is wrong because a Role in kube-system with a RoleBinding only grants access to pods in the kube-system namespace, not all namespaces. Option C is wrong because a RoleBinding in the default namespace binds the ClusterRole only to that namespace, not cluster-wide, so the service account cannot list pods in other namespaces. Option D is wrong because creating a Role in each namespace with a RoleBinding is not minimal—it requires manual duplication and maintenance across all namespaces, whereas a single ClusterRoleBinding achieves the same goal more efficiently.

570
MCQhard

You have deployed a DaemonSet to run a logging agent on every node. After an update, the new pods are stuck in 'Pending' state. You run 'kubectl describe pod ds-pod-xxxxx' and see '0/3 nodes are available: 3 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate'. What is the MOST likely cause?

A.The DaemonSet has a nodeSelector that doesn't match any nodes
B.The DaemonSet uses hostNetwork which conflicts with existing pods
C.The DaemonSet does not have tolerations for the node taints
D.The nodes are cordoned
AnswerC

The taint prevents scheduling unless the pod has a matching toleration.

Why this answer

The error message indicates that the pod cannot be scheduled because all three nodes have a taint (specifically `node-role.kubernetes.io/master`), and the DaemonSet's pod template does not include a corresponding toleration. By default, control-plane nodes are tainted to prevent general workloads from running on them, so a DaemonSet intended to run on all nodes must include tolerations for these taints. Without tolerations, the scheduler will not place the pod on tainted nodes, leaving it in Pending state.

Exam trap

The trap here is that candidates often assume DaemonSets automatically run on all nodes regardless of taints, but in reality, DaemonSets respect taints and tolerations just like any other workload, and failing to add tolerations for control-plane taints is a common misconfiguration.

How to eliminate wrong answers

Option A is wrong because a nodeSelector mismatch would produce a different error (e.g., '0/3 nodes are available: 3 node(s) didn't match node selector'), not a taint-related message. Option B is wrong because hostNetwork conflicts would cause pod startup failures (e.g., port collisions) or CrashLoopBackOff, not a scheduling failure due to taints. Option D is wrong because cordoned nodes would show a specific condition like 'node(s) cordoned' in the describe output, not a taint-based message; cordoning prevents new pods from being scheduled but does not produce a taint-related error.

571
MCQmedium

A cluster administrator wants to audit all pod creations and modifications using an admission webhook. Which resource type should be created to register the webhook?

A.ValidatingWebhookConfiguration
B.WebhookConfiguration
C.MutatingWebhookConfiguration
D.AdmissionWebhook
AnswerA

ValidatingWebhookConfiguration is used to register admission webhooks that can validate requests (allow/deny) based on custom logic.

Why this answer

A ValidatingWebhookConfiguration is the correct resource type to register an admission webhook that audits pod creations and modifications. This resource tells the API server which external HTTP callbacks to invoke during the admission process, specifically for validation (non-mutating) purposes. It defines the rules for matching API requests (e.g., operations like CREATE and UPDATE on pods) and the webhook endpoint that receives AdmissionReview requests.

Exam trap

The CKS exam often tests the distinction between ValidatingWebhookConfiguration and MutatingWebhookConfiguration, trapping candidates who assume any admission webhook uses a generic 'WebhookConfiguration' or that auditing requires mutation.

How to eliminate wrong answers

Option B (WebhookConfiguration) is wrong because no such top-level API resource exists in Kubernetes; the correct terms are ValidatingWebhookConfiguration and MutatingWebhookConfiguration. Option C (MutatingWebhookConfiguration) is wrong because it is used for webhooks that modify objects before they are persisted, not for auditing (read-only validation). Option D (AdmissionWebhook) is wrong because it is not a Kubernetes API resource; it is a generic concept referring to the admission webhook mechanism, not a specific configuration object.

572
MCQmedium

A security audit reveals that etcd does not encrypt data at rest. Which resource must be created to enable encryption?

A.Secret with encryption key
B.Deployment for etcd with encryption flag
C.ConfigMap with encryption key
D.EncryptionConfiguration YAML file and pass it to the API server via --encryption-provider-config
AnswerD

The EncryptionConfiguration resource defines the encryption configuration.

Why this answer

Kubernetes enables etcd data-at-rest encryption through an EncryptionConfiguration YAML file, which defines how to encrypt resources at the API server level. This file is passed to the kube-apiserver via the `--encryption-provider-config` flag, allowing providers like `aescbc` or `secretbox` to encrypt etcd data transparently.

Exam trap

The trap here is that candidates often confuse etcd encryption with TLS or secret management, assuming a Secret or ConfigMap alone enables encryption, when in fact the EncryptionConfiguration YAML is the mandatory resource that the API server reads to apply encryption at rest.

How to eliminate wrong answers

Option A is wrong because a Secret with an encryption key is not a resource that Kubernetes directly consumes for etcd encryption; the key must be referenced within an EncryptionConfiguration. Option B is wrong because etcd does not have a deployment or encryption flag in Kubernetes; encryption is configured on the API server, not etcd itself. Option C is wrong because a ConfigMap is not used for encryption keys; the EncryptionConfiguration is a dedicated YAML resource, and keys are typically stored in Secrets or files, not ConfigMaps.

573
MCQmedium

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

A.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json
B.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json
C.securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json
D.seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

574
MCQmedium

A Falco rule has the condition: 'evt.type=open and fd.name contains /etc/shadow and container.id != host'. What is being detected?

A.Any process opening /etc/shadow on the host
B.A container process writing to /etc/shadow
C.A process reading /etc/passwd
D.A container process opening /etc/shadow
AnswerD

The condition matches open syscalls on /etc/shadow from processes in containers.

Why this answer

The rule detects open syscalls on files whose name contains '/etc/shadow', occurring outside the host (i.e., inside containers). This indicates a container process is opening the shadow file.

575
MCQmedium

A company uses kube-bench to scan their cluster. The report shows a warning: 'Ensure that the --authorization-mode argument is set to Node,RBAC'. What is the best way to fix this?

A.Add --authorization-mode=AlwaysDeny to the API server
B.Restart the API server with --authorization-webhook-config-file
C.Set --authorization-mode=RBAC only
D.Edit the kube-apiserver manifest to add --authorization-mode=Node,RBAC
AnswerD

Sets both Node and RBAC as required.

Why this answer

Kube-bench checks that the API server's `--authorization-mode` includes both `Node` and `RBAC` in that order. The `Node` authorizer must come first to handle node-specific requests efficiently, followed by `RBAC` for user and service account authorization. Editing the kube-apiserver manifest (typically `/etc/kubernetes/manifests/kube-apiserver.yaml`) to add `--authorization-mode=Node,RBAC` ensures the static pod is automatically restarted by the kubelet with the correct configuration.

Exam trap

The trap here is that candidates may think setting only `RBAC` is sufficient because it is the most common authorization mode, but the CKS exam specifically tests the requirement that `Node` must precede `RBAC` to handle node-level authorization correctly.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysDeny` is a deprecated mode that denies all requests, which would break the cluster entirely and does not satisfy the requirement for Node and RBAC. Option B is wrong because `--authorization-webhook-config-file` configures an external webhook authorizer, but the warning specifically requires Node and RBAC modes, not a webhook; adding a webhook without Node and RBAC would still fail the kube-bench check. Option C is wrong because setting `--authorization-mode=RBAC` only omits the `Node` authorizer, which is necessary for kubelet and node identity authorization; this would cause node-related requests to be incorrectly handled and fail the kube-bench check.

576
MCQeasy

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

A.runAsUser: RunAsAny
B.runAsGroup: MustRunAsNonRoot
C.runAsUser: MustRunAsNonRoot
D.seLinuxContext: MustRunAsNonRoot
AnswerC

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

577
Multi-Selecteasy

Which TWO of the following are valid audit stages in Kubernetes? (Choose two.)

Select 2 answers
A.ResponseFull
B.ResponseComplete
C.RequestReceived
D.RequestProcessing
E.RequestComplete
AnswersB, C

Valid stage.

Why this answer

Valid audit stages in Kubernetes are RequestReceived, ResponseStarted, ResponseComplete, and Panic. Therefore, the correct answers are ResponseComplete (B) and RequestReceived (C). Options A (ResponseFull) and D (RequestProcessing) are not valid audit stages.

578
Multi-Selecteasy

Which TWO of the following are recommended settings for the Kubernetes API server according to the CIS Kubernetes Benchmark? (Select TWO)

Select 2 answers
A.--authorization-mode=AlwaysAllow
B.--anonymous-auth=false
C.--authorization-mode=RBAC
D.--anonymous-auth=true
E.--enable-admission-plugins=AlwaysAdmit
AnswersB, C

Disables anonymous requests to the API server.

Why this answer

The CIS Kubernetes Benchmark recommends disabling anonymous authentication by setting `--anonymous-auth=false` on the API server. This ensures that all requests must be authenticated, preventing unauthenticated access to the cluster's control plane.

Exam trap

CNCF often tests the distinction between authentication and authorization, so candidates may incorrectly think disabling anonymous auth is unnecessary if RBAC is enabled, but anonymous users can still bypass RBAC if anonymous auth is left on.

579
MCQhard

A ClusterRole named 'secret-reader' is defined with rules to get, list, and watch secrets. A RoleBinding in namespace 'app' binds this ClusterRole to a service account. Which of the following best describes the permissions of the service account?

A.The service account has no permissions because ClusterRole cannot be used with RoleBinding.
B.The service account can only get secrets in the 'app' namespace.
C.The service account can get, list, and watch secrets in all namespaces.
D.The service account can get, list, and watch secrets only in the 'app' namespace.
AnswerD

RoleBinding grants permissions only in its namespace.

Why this answer

A RoleBinding in a specific namespace grants the permissions defined in the referenced ClusterRole, but only within that namespace. Since the RoleBinding is in the 'app' namespace, the service account receives the get, list, and watch permissions for secrets only within the 'app' namespace, not cluster-wide. This is the standard behavior of RoleBinding when binding to a ClusterRole.

Exam trap

The trap here is that candidates often confuse RoleBinding with ClusterRoleBinding, assuming that using a ClusterRole automatically grants cluster-wide permissions, when in fact the binding type determines the scope.

How to eliminate wrong answers

Option A is wrong because a ClusterRole can be used with a RoleBinding; the RoleBinding scopes the ClusterRole's permissions to the RoleBinding's namespace. Option B is wrong because the ClusterRole grants get, list, and watch permissions, not just get. Option C is wrong because a RoleBinding does not grant cluster-wide permissions; only a ClusterRoleBinding would grant permissions across all namespaces.

580
MCQeasy

In the context of service mesh (e.g., Istio), which resource is used to enforce mutual TLS (mTLS) between services in a specific namespace?

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

Defines mTLS settings for workloads.

Why this answer

PeerAuthentication is the correct resource because it defines the mutual TLS (mTLS) mode for workloads within a namespace or mesh. In Istio, PeerAuthentication allows you to enforce STRICT mTLS, which requires all traffic between services in the specified namespace to use TLS certificates for both client and server authentication, preventing plaintext or unauthenticated communication.

Exam trap

The CKS exam often tests the distinction between PeerAuthentication (for mTLS enforcement on incoming traffic) and DestinationRule (for TLS settings on outgoing traffic), causing candidates to confuse the two resources.

How to eliminate wrong answers

Option B (VirtualService) is wrong because it is used for traffic routing, such as canary deployments or A/B testing, not for enforcing mTLS policies. Option C (DestinationRule) is wrong because it defines traffic policies like load balancing or connection pool settings, and while it can configure TLS settings for outgoing traffic, it does not enforce mTLS on incoming requests at the namespace level. Option D (ServiceEntry) is wrong because it is used to add external services to the mesh for traffic management, not to enforce authentication policies between internal services.

581
Multi-Selectmedium

Which TWO actions are part of the CIS Kubernetes Benchmark recommendations?

Select 2 answers
A.Enable audit logging on the API server
B.Allow all service accounts to list secrets
C.Expose the API server on port 8080
D.Disable anonymous authentication on the API server
E.Use HTTP for kubelet communication
AnswersA, D

Audit logging is recommended for security monitoring.

Why this answer

The CIS Kubernetes Benchmark recommends enabling audit logging on the API server to record all requests and responses, which is essential for security monitoring, forensics, and compliance. Audit logs capture the sequence of activities, including who performed an action, what resource was accessed, and the outcome, enabling detection of unauthorized or suspicious behavior.

Exam trap

CNCF often tests the misconception that disabling anonymous authentication is optional or that audit logging is only for debugging, when in fact both are mandatory hardening steps per the CIS Benchmark to prevent unauthorized access and ensure accountability.

582
Multi-Selecthard

Which THREE of the following are valid ways to secure etcd in a Kubernetes cluster? (Select THREE)

Select 3 answers
A.Allow anonymous access to etcd for ease of management
B.Enable encryption at rest for etcd data
C.Expose etcd on a public IP for external monitoring
D.Use etcd RBAC to restrict access to the etcd datastore
E.Enable TLS client-to-server authentication
AnswersB, D, E

Encryption at rest protects data if etcd storage is compromised.

Why this answer

Enabling encryption at rest for etcd data ensures that the stored Kubernetes secrets and cluster state are encrypted on disk using a provider like AES-CBC or AES-GCM. This protects sensitive data if the underlying storage is compromised, and is a required hardening step for compliance with standards like PCI-DSS or SOC 2.

Exam trap

The trap here is that candidates may confuse 'encryption at rest' with 'encryption in transit' (which is TLS), or mistakenly think that etcd RBAC (Option D) is not a valid security measure, when in fact etcd supports its own RBAC via `etcdctl` commands to restrict access to keys and users.

583
MCQhard

You are the lead security engineer for a large financial institution. The organization runs a Kubernetes cluster with 500+ microservices. The supply chain security team has implemented the following measures: (1) All images are built from a minimal base image (distroless) and scanned with Trivy before being pushed to a private registry. (2) Images are signed using cosign with a key stored in a hardware security module (HSM). (3) Kyverno policies enforce that only signed images from the private registry can run, and also enforce that containers run as non-root. (4) A binary authorization (binauthz) style admission controller verifies attestations. Recently, a critical vulnerability (CVE-2024-0001) was discovered in a popular open-source library used by several microservices. The library is included as a dependency in the base image. The vulnerability is remotely exploitable and has a CVSS score of 9.8. The security team needs to remediate this quickly. They have already patched the library and updated the base image. What is the BEST course of action to ensure all running pods use the new image?

A.Update the image tag in each Deployment's spec to point to the new patched image, then perform a rolling update. The admission controller will verify signatures and attestations for the new image.
B.SSH into each node, pull the new image, and use kubectl exec to update the library inside running containers.
C.Temporarily disable the admission controller that verifies signatures and then update the image tags.
D.Delete all running pods and let the ReplicaSets recreate them from the existing image.
AnswerA

This ensures all pods are updated with a verified, patched image in a controlled manner.

Why this answer

Updating the image tag in each Deployment triggers a rolling update, which creates new pods with the patched image. The admission controller (Kyverno) will verify the cosign signature and binary authorization attestation for the new image, ensuring supply chain security is maintained. This approach is the standard Kubernetes method for deploying image updates while preserving security controls.

Exam trap

CNCF often tests the misconception that manual intervention (SSH, exec) or disabling security controls is acceptable for urgent fixes, when in fact the correct path is to update the deployment manifest and let Kubernetes orchestrate the change while keeping all security checks active.

How to eliminate wrong answers

Option B is wrong because SSHing into nodes and using kubectl exec to update libraries inside running containers violates the immutable infrastructure principle; changes are ephemeral and lost on pod restart, and this bypasses admission controls, leaving pods unsigned and unverified. Option C is wrong because temporarily disabling the admission controller that verifies signatures creates a window where unsigned or malicious images could be deployed, undermining the entire supply chain security posture. Option D is wrong because deleting pods without updating the image tag causes ReplicaSets to recreate pods from the existing (vulnerable) image, failing to remediate the CVE.

584
MCQeasy

Which of the following is a recommended practice for securing Kubernetes Dashboard?

A.Deploy Dashboard with minimal RBAC permissions and access it via kubectl proxy.
B.Expose Dashboard using a NodePort service with a ClusterRole binding to cluster-admin.
C.Use a LoadBalancer service without authentication.
D.Disable HTTPS and expose Dashboard on port 80.
AnswerA

Minimal permissions and kubectl proxy provide secure access without public exposure.

Why this answer

Deploying the Kubernetes Dashboard with minimal RBAC permissions and accessing it via `kubectl proxy` follows the principle of least privilege and avoids exposing the Dashboard to the network. `kubectl proxy` creates a local HTTP proxy to the Kubernetes API server, which authenticates the user's kubeconfig credentials, ensuring that only authorized users can reach the Dashboard and that the Dashboard itself has no direct network exposure.

Exam trap

The trap here is that candidates often think exposing the Dashboard via NodePort or LoadBalancer is acceptable for convenience, but the CKS exam emphasizes that any direct network exposure of the Dashboard without strong authentication and TLS is a critical security violation.

How to eliminate wrong answers

Option B is wrong because exposing the Dashboard via a NodePort service with a ClusterRole binding to `cluster-admin` grants unrestricted superuser access to anyone who can reach the NodePort, bypassing authentication and authorization controls. Option C is wrong because using a LoadBalancer service without authentication exposes the Dashboard to the internet or internal network without any credential check, allowing unauthorized access to the cluster. Option D is wrong because disabling HTTPS and exposing the Dashboard on port 80 transmits all traffic in cleartext, violating TLS encryption requirements and making the Dashboard vulnerable to man-in-the-middle attacks.

585
MCQhard

An OPA/Gatekeeper ConstraintTemplate is written to enforce that all Deployments have the label 'app.kubernetes.io/name'. However, the Constraint does not deny Deployments without the label. What is the most likely cause?

A.The Rego rule does not set 'violation' to true when the label is missing
B.The Constraint is not bound to any namespaces
C.The Deployment has the label set but with a different value
D.Gatekeeper is not installed in the cluster
AnswerA

Correct. The ConstraintTemplate must have a Rego rule named 'violation' that evaluates to true when the resource violates the policy.

Why this answer

Gatekeeper ConstraintTemplates use Rego to define violation rules. A common mistake is to use 'violation' with a generic message but not actually deny the request. The Rego must contain a 'deny' rule or use the 'violation' keyword correctly.

In Gatekeeper, the default Rego rule name is 'violation' and it must be set to true when a violation occurs. If the rule is empty or incorrectly written, it will not deny.

586
MCQeasy

Which of the following flags should be set to `false` to disable anonymous authentication to the Kubernetes API server?

A.--disable-anonymous=true
B.--auth-mode=RBAC
C.--anonymous-auth=false
D.--enable-anonymous-auth=false
AnswerC

This flag disables anonymous authentication.

Why this answer

Setting `--anonymous-auth=false` on the kube-apiserver disables anonymous requests. By default, anonymous authentication is enabled (set to `true`), allowing unauthenticated users to access the API server. Disabling it is a critical hardening step to prevent unauthorized access.

Exam trap

CNCF often tests the exact flag name and syntax, so the trap here is confusing `--anonymous-auth` with non-existent flags like `--disable-anonymous` or `--enable-anonymous-auth`, or mixing up authentication with authorization flags like `--authorization-mode`.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous=true` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth`. Option B is wrong because `--auth-mode=RBAC` is not a valid flag (the correct flag is `--authorization-mode=RBAC`) and it controls authorization, not authentication. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth` which takes a boolean value directly.

587
MCQhard

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

A.annotations: seccomp.security.alpha.kubernetes.io/pod: "localhost/deny-mkdir"
B.seccompProfile: type: Localhost localhostProfile: "deny-mkdir.json"
C.seccompProfile: type: localhost localhostProfile: "deny-mkdir.json"
D.seccompProfile: type: RuntimeDefault
AnswerB

This correctly references the local profile file.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

588
MCQmedium

A security team deploys the above pod and profile. The pod runs but a security scan reports that mount-related syscalls are being allowed instead of logged. What is the most likely reason?

A.The SYS_ADMIN capability overrides the seccomp policy.
B.The seccomp profile is not stored in the correct location, so the container runs without seccomp.
C.The defaultAction SCMP_ACT_ALLOW overrides the specific syscalls.
D.The profile uses SCMP_ACT_LOG which does not block syscalls; it only logs them.
AnswerB

The path is relative; profile must be in /var/lib/kubelet/seccomp/.

Why this answer

The seccomp profile must be stored in `/var/lib/kubelet/seccomp/` for the `localhost` source to work. If the profile is placed elsewhere, the kubelet cannot read it, and the container runs without any seccomp restriction, allowing mount-related syscalls to proceed instead of being logged or blocked.

Exam trap

CNCF often tests the requirement that seccomp profiles must reside in `/var/lib/kubelet/seccomp/` for `localhost` profiles to be applied, and candidates mistakenly assume any valid path works or that the profile is silently ignored rather than causing a runtime failure.

How to eliminate wrong answers

Option A is wrong because SYS_ADMIN capability does not override seccomp; seccomp filters are enforced independently of capabilities, and capabilities cannot disable a seccomp profile. Option C is wrong because `defaultAction: SCMP_ACT_ALLOW` only sets the default action for syscalls not explicitly listed; it does not override the specific syscalls listed in the profile — those specific syscalls would still be handled by their own actions. Option D is wrong because `SCMP_ACT_LOG` does log syscalls without blocking them, but the question states syscalls are being allowed instead of logged, meaning the profile is not applied at all, not that it is applied with LOG action.

589
MCQhard

A cluster administrator wants to ensure that all Secrets are encrypted at rest using AES-CBC with a key managed by the local Kubernetes API server. Which configuration is required?

A.Enable etcd encryption by setting --experimental-encryption-provider-config
B.Use Secret resource's 'data' field with base64 encoding
C.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'aescbc' provider
D.Set --encryption-provider-config flag to a file containing EncryptionConfiguration with 'identity' provider
AnswerC

Correct. This enables AES-CBC encryption at rest.

Why this answer

The `--encryption-provider-config` flag on the kube-apiserver points to a YAML file containing an `EncryptionConfiguration` resource. Within that configuration, specifying the `aescbc` provider enables AES-CBC encryption for Secrets at rest, with the encryption key managed locally by the API server. This is the only option that satisfies the requirement for AES-CBC encryption with a locally managed key.

Exam trap

A common trap in Kubernetes exams is confusing the deprecated `--experimental-encryption-provider-config` flag with the current `--encryption-provider-config` flag. Also, remember that base64 encoding is not encryption; it only obfuscates data.

How to eliminate wrong answers

Option A is wrong because `--experimental-encryption-provider-config` is a deprecated flag (removed in Kubernetes 1.13+); the current stable flag is `--encryption-provider-config`. Option B is wrong because base64 encoding is not encryption—it is a reversible encoding that provides no confidentiality protection, and Secrets stored with base64 in etcd are still in plaintext. Option D is wrong because the `identity` provider stores data in plaintext (no encryption), which does not meet the requirement for encryption at rest.

590
MCQmedium

Which Kubernetes admission controller is responsible for mutating and validating pod requests based on policies defined by OPA Gatekeeper?

A.PodSecurityPolicy
B.ValidatingAdmissionWebhook
C.ServiceAccount
D.NodeRestriction
AnswerB

Gatekeeper registers a ValidatingWebhookConfiguration to intercept and validate pod requests.

Why this answer

OPA Gatekeeper uses the ValidatingAdmissionWebhook admission controller to intercept pod creation requests and enforce policies defined as ConstraintTemplates and Constraints. This webhook validates requests against Rego policies before they are persisted, rejecting non-compliant pods. The ValidatingAdmissionWebhook is the correct mechanism because Gatekeeper does not mutate requests—it only validates them.

Exam trap

In the CKS exam, candidates often confuse OPA Gatekeeper with mutating admission webhooks. Gatekeeper uses ValidatingAdmissionWebhook to enforce policies, not MutatingAdmissionWebhook, as it only validates requests and does not mutate them.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy is a deprecated admission controller that enforces pod security standards based on PSP objects, not OPA Gatekeeper policies. Option C is wrong because ServiceAccount is an admission controller that handles default service account injection and token mounting, not policy enforcement via OPA. Option D is wrong because NodeRestriction limits node self-updates to the kubelet, not pod admission based on OPA Gatekeeper policies.

591
MCQeasy

A DevOps engineer needs to restrict the outbound network traffic from pods running in namespace 'secure-ns'. Which NetworkPolicy configuration achieves this by default?

A.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an empty egress section.
B.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing all traffic.
C.No NetworkPolicy is needed because egress is denied by default.
D.Apply a NetworkPolicy that selects pods in 'secure-ns' and has an egress rule allowing traffic to port 53.
AnswerA

An empty egress rule blocks all egress traffic.

Why this answer

By default, Kubernetes NetworkPolicies are additive and deny-all unless explicitly allowed. Applying a NetworkPolicy with an empty egress section (no egress rules) to pods in 'secure-ns' effectively denies all outbound traffic from those pods, because the policy's egress field defaults to an empty list, which matches no traffic. This is the standard Kubernetes behavior for restricting egress.

Exam trap

The trap here is that candidates often assume egress is denied by default (Option C), but Kubernetes allows all egress until a NetworkPolicy explicitly restricts it, and an empty egress section in a policy is the correct way to achieve a deny-all for outbound traffic.

How to eliminate wrong answers

Option B is wrong because an egress rule allowing all traffic (e.g., an empty `to` and `ports` block) would permit all outbound traffic, not restrict it. Option C is wrong because egress is not denied by default; Kubernetes allows all egress traffic unless a NetworkPolicy explicitly restricts it. Option D is wrong because allowing traffic only to port 53 (DNS) would permit DNS queries but still deny all other outbound traffic, which is more permissive than the required full restriction.

592
MCQmedium

An administrator wants to enforce mutual TLS (mTLS) between all services in an Istio service mesh. Which resource should be configured?

A.AuthorizationPolicy
B.ServiceEntry
C.VirtualService
D.PeerAuthentication
AnswerD

PeerAuthentication is used to configure mTLS mode (STRICT, PERMISSIVE, DISABLE) for workloads.

Why this answer

PeerAuthentication is the correct resource because it defines the TLS mode for traffic between services within the Istio mesh. By setting the mode to STRICT, mTLS is enforced, requiring all service-to-service communication to use mutual TLS. This is the Istio-native way to enable mTLS at the mesh or namespace level.

Exam trap

A common pitfall in CNCF exams is confusing PeerAuthentication (mTLS enforcement) with AuthorizationPolicy (access control after mTLS). PeerAuthentication sets the TLS mode for service-to-service communication, while AuthorizationPolicy governs which requests are allowed.

How to eliminate wrong answers

Option A is wrong because AuthorizationPolicy controls access to services based on roles and identities (RBAC), not the TLS mode of the connection; it works on top of mTLS but does not enforce it. Option B is wrong because ServiceEntry is used to add external services to the mesh, not to configure mTLS between internal services. Option C is wrong because VirtualService manages traffic routing rules (e.g., weight-based routing, retries), not the security or encryption of the connection.

593
MCQmedium

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

A.kubectl annotate ns secure pod-security.kubernetes.io/enforce=restricted
B.kubectl label ns secure pod-security.kubernetes.io/enforce=restricted
C.kubectl label ns secure pod-security.kubernetes.io/enforce-version=restricted
D.kubectl label ns secure pod-security.kubernetes.io/audit=restricted
AnswerB

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

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

594
MCQeasy

Which flag must be set on the kube-apiserver to disable anonymous authentication?

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

This flag disables anonymous authentication as required by CIS benchmarks.

Why this answer

The `--anonymous-auth=false` flag on the kube-apiserver disables anonymous authentication. When this flag is set to false, the API server rejects requests from unauthenticated users, enforcing that all requests must present valid credentials. This is a critical hardening measure to prevent unauthorized access to the cluster control plane.

Exam trap

The trap here is that candidates confuse the kube-apiserver flag syntax with similar flags from other Kubernetes components (e.g., kubelet's `--anonymous-auth-enabled`), leading them to pick the incorrect `--anonymous-auth-enabled=false` option.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth-enabled=false` is not a valid kube-apiserver flag; the correct flag is `--anonymous-auth` without the `-enabled` suffix. Option B is wrong because `--enable-anonymous-auth=false` is also not a valid flag; the kube-apiserver uses `--anonymous-auth` to control anonymous access, not `--enable-anonymous-auth`. Option D is wrong because `--disable-anonymous` is not a recognized flag; the kube-apiserver does not have a `--disable-anonymous` option, and the correct approach is to set `--anonymous-auth=false`.

595
MCQhard

A CI pipeline fails with the error 'cosign: error: unable to verify image: no matching signatures' when running 'cosign verify --key pubkey.pem myregistry/myapp:latest'. The image was previously signed with a private key. What is the MOST likely cause?

A.The public key is incorrect
B.The registry requires authentication
C.Cosign is not installed correctly
D.The image tag was overwritten without signing
AnswerD

Overwriting a tag with a new, unsigned image removes the previous signature.

Why this answer

If the image tag was overwritten (e.g., pushed again without signing), the old signatures are lost and the new image is unsigned.

596
Multi-Selectmedium

Which TWO of the following are valid audit stages in Kubernetes?

Select 3 answers
A.ResponseReceived
B.Panic
C.ResponseStarted
D.RequestReceived
E.RequestSent
AnswersB, C, D

Panic is a valid audit stage that captures events that cause a panic in the API server.

Why this answer

Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the given options, RequestReceived (D), ResponseStarted (C), and Panic (B) are all valid stages. Options A (ResponseReceived) and E (RequestSent) are not standard stages.

597
MCQeasy

You need to enforce that all containers in a namespace run with a read-only root filesystem. Which OPA Gatekeeper resource would you use to define the policy?

A.Constraint
B.ValidatingWebhookConfiguration
C.ConstraintTemplate
D.ConfigMap
AnswerC

ConstraintTemplate defines the Rego logic (rules) for the policy.

Why this answer

A ConstraintTemplate in OPA Gatekeeper defines the reusable policy logic (Rego rules) that enforces a specific constraint, such as requiring containers to run with a read-only root filesystem. The ConstraintTemplate is then instantiated by a Constraint resource to apply the policy to a namespace. Without the ConstraintTemplate, there is no policy definition to enforce.

Exam trap

The trap here is that candidates confuse the Constraint (which applies the policy) with the ConstraintTemplate (which defines the policy logic), leading them to select Option A instead of C.

How to eliminate wrong answers

Option A is wrong because a Constraint is an instance of a policy that references a ConstraintTemplate, but it does not define the policy logic itself; it only applies the template to specific resources. Option B is wrong because a ValidatingWebhookConfiguration is a Kubernetes resource that registers a webhook endpoint with the API server, but it is not an OPA Gatekeeper resource for defining policy; Gatekeeper uses its own webhook under the hood, but the policy definition is done via ConstraintTemplates. Option D is wrong because a ConfigMap is a generic Kubernetes resource for storing configuration data, not for defining OPA Gatekeeper policies; it lacks the Rego language and schema enforcement capabilities of a ConstraintTemplate.

598
MCQeasy

Which flag disables anonymous authentication on the Kubernetes API server?

A.--disable-anonymous-auth
B.--anonymous-auth=false
C.--anonymous-auth=true
D.--no-anonymous-auth
AnswerB

Correct flag to disable anonymous authentication.

Why this answer

The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. By default, anonymous requests are allowed (equivalent to `--anonymous-auth=true`), so setting this flag to `false` prevents unauthenticated users from accessing the API server, which is a key hardening requirement for the CKS exam.

Exam trap

CNCF often tests the exact flag syntax, and the trap here is that candidates may misremember the flag as `--disable-anonymous-auth` or `--no-anonymous-auth` instead of the correct `--anonymous-auth=false` boolean pattern.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous-auth` is not a valid kube-apiserver flag; the correct flag uses a boolean value with `--anonymous-auth`. Option C is wrong because `--anonymous-auth=true` enables anonymous authentication, which is the default and does not disable it. Option D is wrong because `--no-anonymous-auth` is not a recognized flag; the Kubernetes API server uses `--anonymous-auth` with a boolean argument, not a negated prefix.

599
MCQmedium

A security admin wants to ensure that only images signed with a specific key can run in the cluster. Which admission controller should be enabled?

A.PodSecurityPolicy
B.MutatingAdmissionWebhook
C.ImagePolicyWebhook
D.ValidatingAdmissionWebhook
AnswerC

ImagePolicyWebhook allows an external webhook to validate images based on signatures.

Why this answer

The ImagePolicyWebhook admission controller allows a cluster to enforce that only container images signed with a specific key can run. It intercepts pod creation requests and queries an external webhook to verify the image signature before admitting the pod. This directly meets the requirement of restricting execution to signed images.

Exam trap

The distinction between generic webhook controllers (MutatingAdmissionWebhook and ValidatingAdmissionWebhook) and the purpose-built ImagePolicyWebhook is a common point of confusion. Candidates often mistakenly choose a generic webhook when the question explicitly asks for the admission controller designed for image signature enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints (e.g., privilege escalation, host namespaces) but does not verify image signatures. Option B is wrong because MutatingAdmissionWebhook can modify objects (e.g., inject sidecars) but does not inherently validate image signatures; it could be used to call an external service, but the question asks for the admission controller that should be enabled, and ImagePolicyWebhook is the dedicated built-in controller for image signature verification. Option D is wrong because ValidatingAdmissionWebhook validates objects against custom logic but, like MutatingAdmissionWebhook, is a generic webhook mechanism; the specific built-in controller for image signature enforcement is ImagePolicyWebhook.

600
MCQeasy

Which flag is used when starting kube-apiserver to enable audit logging?

A.--audit-log-path
B.--audit-webhook-config-file
C.--feature-gates=Audit=true
D.--audit-policy-file
AnswerD

This flag is required to enable audit logging; it points to a YAML file defining the audit policy.

Why this answer

The --audit-policy-file flag specifies the path to the audit policy file, which is required to enable audit logging.

Page 7

Page 8 of 10

Page 9

All pages