Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 1–75

845 questions total · 12pages · All types, answers revealed

Take a mock examExam hub

Page 1 of 12

Page 2
1
MCQmedium

What is the purpose of the --authorization-mode=RBAC flag on the API server?

A.It enables role-based access control for the API server
B.It disables anonymous authentication
C.It enables the NodeRestriction admission plugin
D.It enables audit logging for RBAC events
AnswerA

The --authorization-mode=RBAC flag configures the Kubernetes API server to evaluate every request against RBAC objects such as Role, RoleBinding, ClusterRole, and ClusterRoleBinding. This mode determines whether a principal (user, group, or ServiceAccount) is permitted to perform a specific verb (e.g., get, create, delete) on an API resource or non-resource endpoint. RBAC is the standard, recommended authorization mechanism for production clusters because it provides fine-grained, deny-by-default access control. Without this flag set to RBAC, the API server may fall back to permissive modes like AlwaysAllow.

Why this answer

The `--authorization-mode=RBAC` flag configures the Kubernetes API server to use Role-Based Access Control (RBAC) as its authorization mode. This means that when a request reaches the API server, after authentication, the authorization module checks the request against RBAC roles and role bindings to determine if the user or service account has permission to perform the requested action. Without this flag, the API server would default to other modes (e.g., AlwaysAllow) or require explicit configuration of a different authorizer.

Exam trap

CNCF often tests the distinction between authorization modes and other API server flags (like admission plugins or audit logging), so candidates may confuse `--authorization-mode=RBAC` with enabling audit logging or admission controllers, when in fact each flag controls a completely separate subsystem.

How to eliminate wrong answers

Option B is wrong because anonymous authentication is controlled by the `--anonymous-auth` flag (defaults to true), not by the `--authorization-mode` flag; disabling anonymous auth is a separate configuration. Option C is wrong because the NodeRestriction admission plugin is enabled via the `--enable-admission-plugins` flag, not through the authorization mode flag. Option D is wrong because audit logging for RBAC events is configured via the `--audit-policy-file` flag and audit policy rules, not by setting the authorization mode to RBAC.

Full explanation →
2
MCQmedium

A security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

A.Privileged
B.Custom
C.Baseline
D.Restricted
AnswerD

The restricted level is the Pod Security Standard that directly fulfills the requirement: it mandates that every container set securityContext.capabilities.drop to ALL and permits adding back only the NET_BIND_SERVICE capability when required, such as for binding to low-numbered ports. It also enforces runAsNonRoot, a non-zero runAsUser, allowPrivilegeEscalation: false, and the RuntimeDefault seccomp profile. This capability-denylist-plus-allowlist approach matches the security engineer's intent to eliminate all non-essential capabilities.

Why this answer

The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

Exam trap

CNCF often tests the misconception that 'Baseline' is sufficient for strict capability control, but Baseline only blocks known dangerous capabilities (e.g., `CAP_SYS_ADMIN`) and does not require dropping all capabilities, so candidates must recognize that only Restricted enforces a full drop-all policy.

How to eliminate wrong answers

Option A is wrong because the Privileged profile allows unrestricted capabilities and does not enforce dropping any, which is the opposite of the requirement. Option B is wrong because 'Custom' is not a valid Pod Security Standard; the three built-in standards are Privileged, Baseline, and Restricted. Option C is wrong because the Baseline profile only prevents known privilege escalations but does not require dropping all capabilities by default, so it does not enforce the strict capability policy needed.

Full explanation →
3
Multi-Selectmedium

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Select 2 answers
A.Pass secrets as environment variables
B.Embed secrets directly in the pod YAML definition
C.Mount secrets as volumes in pods
D.Store secrets as plain text in ConfigMap
E.Use an external secrets manager like HashiCorp Vault with CSI driver
AnswersC, E

Mounting secrets as volumes in pods is the Kubernetes-native best practice because the secret is rendered as individual files on a tmpfs volume, which is memory-backed and not written to disk. File permissions default to 0444, and can be tightened to 0400; additionally, when the secret is updated, kubelet eventually updates the mounted files, allowing for rotation without restarting the pod. This approach avoids exposure via /proc/environ and limits access to containers that explicitly mount the volume.

Why this answer

Kubernetes allows secrets to be mounted as volumes in pods, which is a secure approach as the secret data is stored in tmpfs (RAM-backed filesystem) and not written to disk on the node. This method avoids exposing secrets in environment variables that can be leaked through process dumps or logs, and it supports automatic updates when secrets are modified.

Exam trap

A common pitfall is selecting option A (passing secrets as environment variables) because it seems convenient, but environment variables can be exposed through /proc, logs, and debugging commands. The correct secure approaches are mounting secrets as volumes (C) and using external secrets managers (E).

Full explanation →
4
MCQhard

In a Falco rule, you have the condition: 'evt.type=execve and proc.name=bash and container.id!=host'. What does this rule detect?

A.A non-root bash process on the host
B.A bash shell being spawned inside a container
C.An interactive shell session inside a container
D.A bash process reading /etc/shadow
AnswerB

The condition matches execve system calls where the executed process is bash and the container ID is not the host, so it fires on shells spawned inside containers. This detects interactive or scripted bash execution within containerised workloads, not host-level bash.

Why this answer

The rule triggers when a bash shell is executed (execve) inside any container (container.id != host). It does not check for interactive use; it simply detects bash execution.

Full explanation →
5
MCQmedium

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

A.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
B.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
C.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
D.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`
AnswerB

This constraint correctly enforces the non-root requirement by denying any pod in which any container does not set `securityContext.runAsNonRoot` to true. In Rego, a missing field evaluates as false, so `runAsNonRoot != true` catches both explicit `false` and undefined cases, blocking containers that could run as root. The constraint scope on Pods ensures every container in the spec is evaluated without exception.

Why this answer

The goal is to deny any Pod whose containers do not explicitly set runAsNonRoot to true. In Rego, the deny rule must fire when the condition is violated, so the correct expression is `input.review.object.spec.containers[_].securityContext.runAsNonRoot != true`. This matches containers that either omit the field or set it to false, which is exactly the insecure state the admin wants to block.

The Constraint then binds this template to Pods via match.kinds.

Exam trap

CKS often tests the direction of the Rego condition — candidates mistakenly write `== true` when the deny rule must fire on the insecure state (`!= true`), inverting the policy.

How to eliminate wrong answers

Option A is wrong because `runAsNonRoot == true` denies Pods that are already compliant (non-root), inverting the policy's intent. Option C is wrong because it checks capabilities.drop != "ALL", which is a different security control (dropping Linux capabilities) and does not enforce non-root execution. Option D is wrong because checking `runAsUser == 0` only catches containers that explicitly set UID 0; it misses containers that omit runAsUser entirely and may still run as root by default.

Full explanation →
6
MCQeasy

To ensure a container's filesystem is read-only, which field should be set to 'true' in the container spec?

A.securityContext.readOnlyRootFilesystem
B.securityContext.runAsNonRoot
C.container.fsGroup
D.podSpec.containers.readonly
AnswerA

securityContext.readOnlyRootFilesystem is a boolean field within a container's security context. When set to true, it mounts the container's root filesystem as read-only, blocking any writes to the container layer. This forces all writable data to be stored in explicitly mounted volumes, such as emptyDir or persistent volumes, which is a key security hardening measure.

Why this answer

The `securityContext.readOnlyRootFilesystem` field, when set to `true`, mounts the container's root filesystem as read-only. This prevents any writes to the container's filesystem, enhancing security by making it immutable. It is the correct field to ensure a read-only filesystem.

Exam trap

CKS often tests the exact field name for read-only root filesystem; candidates may confuse it with other securityContext fields like runAsNonRoot or fsGroup.

How to eliminate wrong answers

Option B is wrong because `securityContext.runAsNonRoot` controls the user ID under which the container runs, not filesystem permissions. Option C is wrong because `container.fsGroup` sets the group ownership for volumes, not the root filesystem read-only status. Option D is wrong because `podSpec.containers.readonly` is not a valid Kubernetes field; the correct field is `securityContext.readOnlyRootFilesystem`.

Full explanation →
7
Multi-Selecthard

A security auditor recommends limiting the use of host namespaces in pods. Which THREE of the following fields, if set to true, expose the host namespace to a container?

Select 3 answers
A.hostPID
B.hostIPC
C.hostFS
D.hostUsers
E.hostNetwork
AnswersA, B, E

Setting hostPID: true mounts the host's PID namespace into the container, allowing it to see all processes running on the node, including those of other pods and system daemons. This breaks namespace isolation and creates a severe privilege escalation risk because the container could discover secrets in process arguments or signal critical system processes. It should only be used in highly trusted, admin-controlled pods.

Why this answer

Setting `hostPID: true` in a Pod spec allows the container to share the host's process ID namespace. This means the container can see and interact with all processes running on the host node, which breaks process isolation and can lead to privilege escalation or information leakage.

Exam trap

CNCF often tests the distinction between actual Pod spec fields (`hostPID`, `hostIPC`, `hostNetwork`) and non-existent or runtime-specific fields like `hostFS` or `hostUsers`, which candidates might confuse with host namespace options.

Full explanation →
8
MCQhard

After running kube-bench, you see a failing check: '1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive'. What is the remediation?

A.Change permissions of /var/lib/kubelet/config.yaml to 600
B.Change permissions of /var/log/audit.log to 600
C.Change permissions of /etc/kubernetes/manifests/kube-apiserver.yaml to 600
D.Change permissions of /etc/kubernetes/manifests/kube-controller-manager.yaml to 600
AnswerC

This is the static pod manifest that kubelet reads to launch the API server. Restricting it to root:root and mode 600 prevents unprivileged users from tampering with the API server's arguments, such as disabling authentication or adding insecure flags. Since the check is explicitly about this file's permissions, setting 600 directly resolves the failure.

Why this answer

Check 1.1.1 from kube-bench specifically targets the API server pod specification file, which is located at /etc/kubernetes/manifests/kube-apiserver.yaml. The remediation is to set its permissions to 600 or more restrictive to prevent unauthorized read or write access, as this file contains critical configuration parameters for the API server.

Exam trap

CNCF often tests the exact mapping between kube-bench check IDs and their corresponding file paths, so the trap here is confusing the API server pod spec file with other static pod manifests (like controller-manager) or configuration files (like kubelet config or audit logs).

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/config.yaml is the kubelet configuration file, not the API server pod spec, and its permissions are covered by a different kube-bench check (e.g., 4.1.1). Option B is wrong because /var/log/audit.log is an audit log file, not a pod specification file, and its permissions are addressed by checks related to audit logging, not check 1.1.1. Option D is wrong because /etc/kubernetes/manifests/kube-controller-manager.yaml is the controller manager pod spec, which is a separate component; check 1.1.1 is specific to the API server pod spec file.

Full explanation →
9
Multi-Selectmedium

Which TWO of the following are valid methods to secure the etcd datastore in a Kubernetes cluster?

Select 2 answers
A.Enable TLS encryption for client-to-server communication.
B.Enable peer authentication using TLS certificates.
C.Use HTTP instead of HTTPS for better performance.
D.Disable client authentication to simplify configuration.
E.Expose the etcd port (2379) on a public IP for easier monitoring.
AnswersA, B

TLS encryption for client-to-server communication is mandatory for protecting the data plane between the Kubernetes API server and etcd. It ensures that all cluster secrets, ConfigMaps, and resource definitions are encrypted in transit, preventing sniffing and man-in-the-middle attacks. Additionally, TLS provides server identity verification, allowing clients to authenticate the etcd endpoint and avoid connecting to a rogue server. Without this, sensitive cluster state would be transmitted in plaintext, compromising the entire control plane.

Why this answer

Enabling TLS encryption for client-to-server communication ensures that all data transmitted between etcd clients (such as the Kubernetes API server) and the etcd server is encrypted, preventing eavesdropping and man-in-the-middle attacks. This is a fundamental security measure for protecting sensitive cluster state and secrets stored in etcd.

Exam trap

The trap here is that candidates may think enabling TLS for client-to-server communication is optional or that peer authentication is not required, but the CKS exam emphasizes that both client and peer TLS are mandatory for securing etcd in a hardened cluster.

Full explanation →
10
MCQmedium

A developer wants to ensure that a pod always uses a specific version of an image that cannot be changed without updating the manifest. Which image reference should be used?

A.myimage@sha256:abcdef...
B.myimage:latest
C.myimage:v1.0
D.myimage:1.0.0
AnswerA

A digest reference pins the pod to the exact image content by its sha256 hash. Unlike a mutable tag, the digest cannot be repointed, so the running image stays identical unless the manifest is edited to a new digest.

Why this answer

(myimage@sha256:abcdef...) uses a digest-based image reference, which pins the image to an immutable content hash. This ensures that the exact same image is always pulled, regardless of tag updates, and any change to the image would require updating the manifest. This aligns with the requirement that the image version cannot be changed without modifying the manifest.

Exam trap

A common misconception is that semantic version tags (e.g., 'v1.0' or '1.0.0') are immutable, but in reality, tags are mutable pointers that can be reassigned, whereas only digest references provide true immutability.

How to eliminate wrong answers

Option B (myimage:latest) is wrong because the 'latest' tag is mutable and can be updated to point to a different image without changing the manifest, violating the requirement. Option C (myimage:v1.0) is wrong because tags like 'v1.0' can be reassigned to a different image digest, allowing the image to change without a manifest update. Option D (myimage:1.0.0) is wrong for the same reason as C—semantic version tags are mutable and can be overwritten, so they do not guarantee immutability.

Full explanation →
11
MCQmedium

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

A.capabilities: { remove: ["ALL"] }
B.capabilities: { drop: ["ALL"] }
C.capabilities: { none: true }
D.securityContext: { capabilities: { drop: ["ALL"] } }
AnswerD

This is correct because the `securityContext` at the container level is the only place where Linux capabilities are configured in Kubernetes. The `capabilities.drop` list accepts `"ALL"` as a special token that removes every capability from the container's effective and permitted sets, giving a minimal attack surface. Because it is nested under `securityContext`, the kubelet applies it when creating the container via the container runtime.

Why this answer

In Kubernetes, to drop Linux capabilities from a container, you must use the `capabilities.drop` field inside `securityContext`. Option D correctly nests `capabilities` under `securityContext`. Option B is incorrect because it places `capabilities` directly under the container spec without the `securityContext` wrapper, which is not valid in most Kubernetes API versions.

Options A and C use invalid keywords (`remove` and `none`). Therefore, only Option D is correct.

Exam trap

CNCF often tests the distinction between `drop` and `remove` in the capabilities field, where `drop` is the correct Kubernetes API field name, and `remove` is a common but incorrect alternative that candidates might mistakenly use.

How to eliminate wrong answers

Option A is wrong because `remove` is not a valid field in the Kubernetes capabilities specification; the correct field is `drop`. Option C is wrong because `none: true` is not a valid syntax for managing capabilities in Kubernetes; capabilities must be explicitly dropped using the `drop` field. Option D is wrong because while the structure `securityContext: { capabilities: { drop: ["ALL"] } }` is technically correct, the question asks for the correct YAML snippet, and option B is the only one that directly provides the correct snippet without extraneous nesting; however, note that option D is also marked as correct in the answer options, but the question expects a single correct answer, and option B is the most concise and direct representation.

Full explanation →
12
MCQhard

You are tasked with securing the kubelet. Which flag must be set on the kubelet to enable the NodeRestriction admission plugin?

A.--admission-control=NodeRestriction on the kubelet
B.--enable-admission-plugins=NodeRestriction on the kubelet
C.--node-restriction=true on the kubelet
D.--enable-admission-plugins=NodeRestriction on the kube-apiserver
AnswerD

The correct approach is to enable the NodeRestriction admission controller on the kube-apiserver using --enable-admission-plugins=NodeRestriction. This plugin is part of the API server's admission chain and works together with the Node authorizer to restrict kubelet requests. For example, it prevents a compromised kubelet from modifying any Node object other than its own or from writing to Pod objects. This flag must be placed in the kube-apiserver's startup configuration, not on the kubelet.

Why this answer

The NodeRestriction admission plugin is an admission controller that runs on the kube-apiserver, not on the kubelet. It limits the Node and Pod objects a kubelet can modify, enforcing that nodes can only modify their own node object and pods bound to them. The flag `--enable-admission-plugins=NodeRestriction` on the kube-apiserver activates this plugin, which is a key security control for hardening the cluster.

Exam trap

The trap here is that candidates confuse the kubelet's role with the kube-apiserver's role, assuming admission plugins are configured on the kubelet because the NodeRestriction plugin directly affects kubelet behavior, but in reality admission plugins are always server-side components on the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kubelet does not have an `--admission-control` flag; admission plugins are configured on the kube-apiserver, and the deprecated `--admission-control` flag was replaced by `--enable-admission-plugins`. Option B is wrong because the kubelet does not support the `--enable-admission-plugins` flag; that flag is exclusive to the kube-apiserver, and the kubelet has no concept of admission plugins. Option C is wrong because there is no `--node-restriction` flag on the kubelet; the NodeRestriction admission plugin is enabled via the kube-apiserver, not through a boolean flag on the kubelet.

Full explanation →
13
MCQmedium

You need to audit all API requests to the cluster. Which set of apiserver flags should be configured?

A.--audit-log-path, --audit-policy-file
B.--audit-log-maxage, --audit-log-maxbackup
C.--audit-webhook-config-file, --audit-webhook-mode
D.--audit-dynamic-configuration
AnswerA

These two flags together activate file-based audit logging in kube-apiserver: --audit-policy-file defines the policy rules that determine which requests are logged and what data is included, while --audit-log-path specifies the file path where the audit events are written. Without both, the apiserver either has no audit policy (and fails to start with the log path set) or simply does not emit audit records. They are the minimal set required to persistently capture API request activity.

Why this answer

To audit all API requests to the cluster, configure `--audit-log-path` to write audit events to a file and `--audit-policy-file` to provide an audit policy that matches all API requests. The policy file must contain a rule that logs all requests; otherwise only the requests matching the policy rules are audited.

Exam trap

CNCF often tests the distinction between enabling audit logging and configuring its advanced features, so candidates mistakenly pick rotation or webhook options thinking they are the primary enablers.

How to eliminate wrong answers

Option B is wrong because `--audit-log-maxage` and `--audit-log-maxbackup` control log rotation and retention, not the enabling of audit logging itself. Option C is wrong because `--audit-webhook-config-file` and `--audit-webhook-mode` configure a webhook backend for audit events, but they still require `--audit-policy-file` to define which events to send; they are not the minimal set to enable auditing. Option D is wrong because `--audit-dynamic-configuration` enables runtime changes to the audit policy, but it is an additional feature that requires a base audit policy file to be already configured; it does not enable auditing by itself.

Full explanation →
14
MCQmedium

A security engineer needs to verify that a container image pulled from a private registry was signed by the organization's authorized build pipeline before allowing it to run in the cluster. The signatures are stored alongside the image in the OCI registry. Which command should the engineer use to perform this verification?

A.cosign verify --key cosign.pub registry.example.com/app:1.2.3
B.cosign sign --key cosign.key registry.example.com/app:1.2.3
C.cosign attach signature --signature sig.json registry.example.com/app:1.2.3
D.cosign generate-key-pair
AnswerA

This command uses the cosign public key to verify the signature attached to the image in the OCI registry. It checks that the image was signed by the corresponding private key, ensuring authenticity and integrity before deployment. This directly addresses the requirement to confirm the image was signed by the authorized pipeline.

Why this answer

To verify an image's signature in an OCI registry, cosign verify is the correct command. It uses the public key to validate the signature, ensuring the image was signed by the trusted private key. This step is critical in a supply chain security workflow to prevent running unauthorized or tampered images.

Exam trap

The trap here is confusing signing operations with verification, assuming that any cosign command involving signatures will check authenticity.

Full explanation →
15
MCQmedium

You are managing a Kubernetes cluster that hosts multiple microservices. The cluster uses Kubernetes v1.25. Recently, a security audit identified that containers are running with the default seccomp profile (unconfined). The security team has requested that all containers use a seccomp profile that blocks unnecessary syscalls. You need to implement this cluster-wide without breaking existing applications. The audit also found that the kubelet's anonymous authentication is enabled, which should be disabled. Additionally, you need to ensure that the kubelet's NodeRestriction admission controller is enabled to limit what nodes can do. Which of the following is the most appropriate sequence of actions?

A.Disable anonymous authentication immediately, then enable NodeRestriction, and finally apply the restrictive seccomp profile
B.Apply the 'runtime/default' seccomp profile cluster-wide immediately, then disable anonymous auth, and finally enable NodeRestriction
C.Enable NodeRestriction first, then apply a restrictive seccomp profile, and last disable anonymous authentication
D.First, configure the kubelet to use a seccomp profile that logs violations (e.g., 'runtime/default' with log), then after verifying no breakage, switch to 'runtime/default'. Then disable anonymous authentication and enable NodeRestriction admission controller
AnswerD

This order works because it first configures the kubelet to use a seccomp profile that logs violations, such as a Localhost profile that maps default-blocked syscalls to SCMP_ACT_LOG instead of SCMP_ACT_ERRNO. After observing logs for a period and confirming that no application-required syscall is being denied, you can switch to enforcing 'runtime/default' with low risk. Then, disabling anonymous authentication closes unauthenticated access to the kubelet/API, and enabling NodeRestriction constrains what a compromised kubelet can change, completing the hardening. This phased approach, validate-then-enforce, prevents downtime and gives you evidence for every security decision.

Why this answer

It follows the principle of least disruption: first, it applies the 'runtime/default' seccomp profile in logging mode to detect any blocked syscalls without breaking applications. After verifying no breakage, it switches to enforcing mode. Then, it disables anonymous authentication and enables the NodeRestriction admission controller, both of which are non-disruptive configuration changes.

This sequence minimizes risk to existing workloads while meeting all audit requirements.

Exam trap

The trap here is that candidates rush to apply the restrictive seccomp profile immediately (options A, B, C) without considering the need for a gradual rollout via logging mode to avoid breaking existing applications, which is a key CKS focus on safe system hardening.

How to eliminate wrong answers

Option A is wrong because disabling anonymous authentication immediately could break cluster components that rely on it (e.g., kubelet health checks) before verifying dependencies, and applying a restrictive seccomp profile without testing could crash applications. Option B is wrong because applying 'runtime/default' immediately without logging mode first risks breaking existing applications that depend on blocked syscalls. Option C is wrong because enabling NodeRestriction first is safe but applying a restrictive seccomp profile without prior logging validation could cause application failures, and disabling anonymous authentication last leaves a security gap during the process.

Full explanation →
16
MCQmedium

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

A.Store the API key in a ConfigMap and expose it as an environment variable
B.Hardcode the API key in the container image
C.Store the API key in a Kubernetes Secret and mount it as a volume inside the container
D.Store the API key in a Kubernetes Secret and expose it as an environment variable
AnswerC

Mounting the Secret as a volume avoids exposing the API key in environment variables, which can leak via process listings or crash dumps. It satisfies the requirement for secure injection into the container without baking credentials into the image or manifest.

Why this answer

Mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Exam trap

CNCF often tests the misconception that environment variables from Secrets are equally secure as volume mounts, but the trap is that environment variables are more exposed to runtime leaks and cannot be rotated without pod restart, whereas volume mounts offer better isolation and live update capabilities.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets like API keys. Option B is wrong because hardcoding secrets in a container image embeds them in the image layers, making them accessible to anyone with image pull access and violating immutable infrastructure principles. Option D is wrong because exposing a Secret as an environment variable increases the risk of leakage through container logs, debugging endpoints, or the `/proc/self/environ` file, and does not support seamless secret rotation without pod restart.

Full explanation →
17
Multi-Selectmedium

Which TWO of the following are valid Falco rule priorities?

Select 2 answers
A.MEDIUM
B.WARNING
C.HIGH
D.CRITICAL
E.LOW
AnswersB, D

WARNING is one of the eight valid Falco priorities, sitting between NOTICE and ERROR in the severity ordering. It is intended for events that are security-relevant and should be surfaced to operators, but are not as severe as an error or critical condition. For example, spawning a new shell inside a running container without a known parent process is often assigned WARNING priority to alert on potential lateral movement without flooding the alerting pipeline. It is a suitable default for many behavioral rules that warrant attention but not immediate incident response.

Why this answer

Falco rule priorities follow the syslog severity scale, and both WARNING (option B) and CRITICAL (option D) are valid members of that scale, sitting between NOTICE/ERROR and ALERT/EMERGENCY respectively. The full set of valid Falco priorities is EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, and DEBUG, so any rule's priority field must be one of these exact strings. MEDIUM (option A), HIGH (option C), and LOW (option E) are not part of the syslog/Falco priority enumeration — they resemble generic severity labels from other tools but are not accepted values in a Falco rule definition.

Exam trap

The trap is assuming Falco uses intuitive severity labels like LOW, MEDIUM, or HIGH, when it actually uses syslog-style names such as WARNING, CRITICAL, ERROR, and DEBUG.

Full explanation →
18
MCQmedium

A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?

A.Use seccomp profiles to block privilege escalation syscalls
B.Apply AppArmor profiles to all control plane pods
C.Configure control plane containers to run as non-root user and with read-only root filesystem
D.Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces
AnswerC

Setting runAsNonRoot: true and an explicit runAsUser (for example, 1000) in the pod security context, along with readOnlyRootFilesystem: true, directly removes root privileges and makes the container's immutable root filesystem fail-closed on any write attempt. This is the most effective hardening for control plane components because it attacks both privilege escalation and tampering of the container's filesystem at the source, rather than filtering specific kernel or program actions.

Why this answer

Running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.

Exam trap

CNCF often tests the distinction between runtime security mechanisms (seccomp, AppArmor) and container-level privilege controls (user ID, read-only filesystem), leading candidates to choose a syscall or MAC profile instead of the direct least-privilege configuration.

How to eliminate wrong answers

Option A is wrong because seccomp profiles restrict system calls (syscalls) but do not control the user identity under which a container runs or prevent privilege escalation via user namespace manipulation; they are a complementary measure, not a primary least-privilege approach. Option B is wrong because AppArmor profiles enforce mandatory access control on a per-program basis but do not change the user context of the container process; they also require a profile to be loaded on the node, which may not be available for all control plane components. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, and even when available, it only enforces policies at the pod admission level, not directly on the container runtime configuration; moreover, control plane components are often managed as static pods or systemd services, not through the Kubernetes API, making PSP inapplicable.

Full explanation →
19
MCQmedium

An administrator creates an EncryptionConfiguration with aescbc and saves it to /etc/kubernetes/enc/enc.yaml. Which flag must be added to the kube-apiserver to enable encryption at rest?

A.--encryption-config=/etc/kubernetes/enc/enc.yaml
B.--enable-encryption
C.--encryption-provider=aescbc
D.--encryption-provider-config=/etc/kubernetes/enc/enc.yaml
AnswerD

This is the correct flag to enable encryption at rest in kube-apiserver. --encryption-provider-config expects the file path to a YAML configuration that lists the resources (such as secrets) and the ordered encryption providers (identity, aescbc, secretbox, etc.) with their keys. When this flag is set, the apiserver encrypts data written to etcd and decrypts it on reads, allowing transparent encryption of Kubernetes Secrets and other supported resources.

Why this answer

The kube-apiserver requires the `--encryption-provider-config` flag to specify the path to the EncryptionConfiguration YAML file that defines the encryption provider (e.g., aescbc) and resources to encrypt. This flag enables encryption at rest for Kubernetes secrets and other API data stored in etcd.

Exam trap

The trap here is that candidates confuse the valid `--encryption-provider-config` flag with similar-sounding but invalid flags like `--encryption-config` or `--encryption-provider`, or assume a simple `--enable-encryption` toggle exists, when in reality encryption at rest requires a detailed configuration file.

How to eliminate wrong answers

Option A is wrong because `--encryption-config` is not a valid kube-apiserver flag; the correct flag is `--encryption-provider-config`. Option B is wrong because `--enable-encryption` does not exist; encryption at rest is configured via a provider configuration file, not a boolean flag. Option C is wrong because `--encryption-provider` is not a valid flag; the encryption provider (e.g., aescbc) is specified inside the EncryptionConfiguration YAML, not as a separate command-line argument.

Full explanation →
20
Multi-Selectmedium

Which TWO AppArmor modes are available? (Select 2)

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

Enforce mode applies the loaded profile's rules and actively blocks any operation they deny, logging violations. This satisfies the question's requirement for a valid AppArmor mode, alongside complain mode, which permits actions but records them.

Why this answer

AppArmor provides exactly two operational modes for a profile: enforce (option A) and complain (option B). In enforce mode, the profile's rules are actively applied and any access that violates the policy is denied and logged, which is the default mode for loaded profiles. In complain mode, violations are not blocked but are instead logged as complaints, allowing administrators to test and refine a profile before enforcing it.

The other options are not AppArmor modes: audit (C) is not a mode but rather a logging facility/flag, allow (D) is not an AppArmor mode (it resembles SELinux terminology or a policy rule action), and unconfined (E) describes a process with no profile attached, not a selectable profile mode.

Exam trap

The CNCF CKS exam often tests the distinction between AppArmor modes and profile rule keywords, leading candidates to confuse 'audit' (a rule keyword) or 'unconfined' (a process state) with actual operational modes.

Full explanation →
21
MCQhard

An etcd cluster uses TLS for peer and client communication. Which command correctly tests connectivity to an etcd member with client certificate authentication?

A.etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health
B.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health
C.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health
D.etcdctl --endpoints=http://10.0.0.1:2379 endpoint health
AnswerB

This is the correct command because it supplies all three components required for mutual TLS against an etcd cluster: --cacert sets the CA certificate used to verify the server's identity, --cert provides the client certificate, and --key provides the corresponding private key for that client certificate. With these flags, etcdctl can establish an authenticated and encrypted HTTPS connection, successfully complete the TLS handshake, and then query the /health endpoint to check cluster status. The command precisely follows the standard pattern for etcd client authentication when the cluster enforces both server-side and client-side certificate verification.

Why this answer

It provides all three required TLS components for mutual TLS (mTLS) authentication: the CA certificate (`--cacert`) to verify the server's identity, the client certificate (`--cert`) for the client's identity, and the client key (`--key`) to prove possession of the private key. The `endpoint health` command then performs a TLS handshake and checks the etcd member's health over HTTPS. Without any of these three, the connection will fail due to certificate validation errors or missing client authentication.

Exam trap

CNCF often tests the misconception that only the client certificate is needed for mTLS, causing candidates to forget the `--key` flag, or that only the CA certificate is sufficient for client authentication, leading them to omit the client certificate and key entirely.

How to eliminate wrong answers

Option A is wrong because it omits the `--cacert` flag, so the client cannot verify the server's TLS certificate against the trusted CA, causing a TLS handshake failure. Option C is wrong because it omits the `--cert` and `--key` flags, so the client cannot provide its own certificate for mutual TLS authentication, and the etcd server will reject the connection if client certificate authentication is enforced. Option D is wrong because it uses `http://` instead of `https://`, bypassing TLS entirely; if the etcd cluster requires TLS, this command will either be rejected or communicate over an unencrypted channel, failing the connectivity test.

Full explanation →
22
MCQhard

A cluster administrator wants to enforce the Pod Security Standard 'restricted' at the namespace level. Which command applies the PodSecurity admission label to the 'prod' namespace?

A.kubectl label namespace prod pod-security.kubernetes.io/warn=restricted
B.kubectl label namespace prod pod-security.kubernetes.io/audit=restricted
C.kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted
D.kubectl annotate namespace prod security.kubernetes.io/pod-security=restricted
AnswerC

This command correctly applies the `pod-security.kubernetes.io/enforce` label with the value `restricted`, which makes the Pod Security Admission controller reject any Pod that fails the restricted Pod Security Standard. The enforcement is mandatory: the Pod admission request is denied and the API server returns an error. This is the standard, documented mechanism for enforcing a Pod Security Standard at the namespace level.

Why this answer

The `enforce` label is the only one that actively blocks pods that violate the specified Pod Security Standard (PSS) level. The command `kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted` applies the 'restricted' policy at the namespace level, causing the PodSecurity admission controller to reject any pod that does not comply with the restricted profile.

Exam trap

The trap here is that candidates confuse the three modes (enforce, audit, warn) and often pick `warn` or `audit` thinking they provide enforcement, or they mistakenly use an annotation instead of a label, which is not recognized by the PodSecurity admission controller.

How to eliminate wrong answers

Option A is wrong because the `warn` label only generates a warning message when a non-compliant pod is created, but does not block the pod. Option B is wrong because the `audit` label adds an audit event to the audit log for non-compliant pods, but does not enforce or block them. Option D is wrong because it uses an incorrect annotation key (`security.kubernetes.io/pod-security`) and the `annotate` command instead of `label`; the correct mechanism uses labels with the `pod-security.kubernetes.io/enforce` key.

Full explanation →
23
MCQmedium

A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?

A.Role with 'list' on pods, RoleBinding in observability
B.ClusterRole with 'get' on pods, ClusterRoleBinding
C.ClusterRole with 'list' on pods, RoleBinding in observability
D.ClusterRole with 'list' on pods, ClusterRoleBinding
AnswerD

A ClusterRole is not bound to any namespace, and a ClusterRoleBinding grants its permissions cluster-wide or across all namespaces. By combining the 'list' verb on pods with these two cluster-scoped resources, the monitor ServiceAccount can list pods in every namespace. This is the standard and correct way to grant cross-namespace pod enumeration in RBAC.

Why this answer

A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide access if the role is a ClusterRole, but in reality the binding's scope (namespace vs. cluster) determines the effective scope of the permissions.

How to eliminate wrong answers

Option A is wrong because a Role is namespaced and cannot grant permissions across all namespaces; also, a RoleBinding only applies within its namespace. Option B is wrong because the verb 'get' only allows retrieving a specific pod, not listing pods; the required verb is 'list'. Option C is wrong because a RoleBinding cannot bind a ClusterRole to grant cluster-wide access; it would only apply the ClusterRole's permissions within the 'observability' namespace, not across all namespaces.

Full explanation →
24
MCQeasy

In a Falco rule, what does the 'priority' field indicate?

A.The syscall filter condition
B.The format of the output message
C.The severity level of the event
D.The rule name
AnswerC

The `priority` field indicates the severity level of the event that the rule generates, using Falco's enumerated values from DEBUG (lowest) to EMERGENCY (highest). It is unrelated to the condition, output, or rule name, and it allows operators and integrated systems to apply different response thresholds, such as suppressing low-severity notifications or escalating high-severity alerts to pager escalation.

Why this answer

In a Falco rule, the priority field specifies the severity level of the event, such as EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL, or DEBUG. It determines how the alert is classified and can be used to filter or route notifications based on importance.

Exam trap

The trap is confusing the rule's structural fields: candidates may associate priority with the condition or output, but priority strictly denotes the severity classification of the event.

How to eliminate wrong answers

Option A is wrong because the syscall filter condition is defined in the 'condition' field (e.g., evt.type=open), not in priority. Option B is wrong because the output message format is defined in the 'output' field, which uses format specifiers like %proc.name and %fd.name. Option D is wrong because the rule name is defined in the 'rule' field, which is the human-readable identifier for the rule.

Full explanation →
25
MCQmedium

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

A.EncryptionProvider
B.SecretEncryptionConfig
C.KMSProvider
D.EncryptionConfiguration
AnswerD

EncryptionConfiguration is the correct API resource, defined in apiserver.config.k8s.io/v1, that specifies encryption providers and their keys for etcd data. You pass it to the kube-apiserver via the --encryption-provider-config flag, and it governs how resources like Secrets are encrypted at rest. This is the only valid object among the options for configuring at-rest encryption.

Why this answer

Kubernetes uses an `EncryptionConfiguration` object to configure encryption at rest for secrets and other resources in etcd. This YAML-based resource defines which providers (e.g., `aescbc`, `kms`, `secretbox`) are used to encrypt data before it is written to the underlying storage. The API server reads this configuration from a file specified via the `--encryption-provider-config` flag, enabling transparent encryption and decryption of resource data.

Exam trap

A common Kubernetes certification pitfall is confusing the `EncryptionConfiguration` resource (the top-level configuration object) with the individual provider types like `KMSProvider` or `aescbc` that are listed inside it. Candidates may pick a provider name instead of the configuration resource itself.

How to eliminate wrong answers

Option A is wrong because `EncryptionProvider` is not a valid Kubernetes resource; the correct term is `EncryptionConfiguration`, which references provider types like `aescbc` or `kms` within its `resources` array. Option B is wrong because `SecretEncryptionConfig` is a fictional resource name; Kubernetes does not have a dedicated resource for secret-only encryption, and the `EncryptionConfiguration` object applies to any resource type listed in its `resources` field. Option C is wrong because `KMSProvider` is not a standalone resource; it is a provider type (e.g., `kms` or `kmstool`) that can be used inside an `EncryptionConfiguration` to delegate encryption to an external Key Management Service like AWS KMS or GCP Cloud KMS.

Full explanation →
26
MCQmedium

An administrator wants to ensure that containers in the 'secure-app' namespace cannot write to their own filesystem. Which pod security context setting should be used?

A.securityContext: { runAsNonRoot: true }
B.securityContext: { privileged: false }
C.securityContext: { capabilities: { drop: ["ALL"] } }
D.securityContext: { readOnlyRootFilesystem: true }
AnswerD

Setting readOnlyRootFilesystem: true causes the container runtime to mount the container's root filesystem as read-only, so the write layer is not writable from the container's perspective; any attempt to modify an existing file or create a new file in the root directory tree will fail with EROFS. This directly prevents an attacker who compromises the container from persisting changes in the container layer, though ephemeral writes can still be accommodated by mounting volumes (e.g., emptyDir) at specific paths such as /tmp. It is the only option among those listed that enforces the filesystem-level read-only requirement.

Why this answer

Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing any process inside the container from writing to it. This directly satisfies the requirement that containers cannot write to their own filesystem. Writable volumes can still be mounted separately for legitimate write needs.

Exam trap

CKS often tests the confusion between capability dropping and filesystem immutability — candidates who pick capabilities: drop ALL miss that write access to the root filesystem is controlled by the mount flag, not by Linux capabilities.

How to eliminate wrong answers

Option A is wrong because runAsNonRoot: true only enforces that the container process does not run as UID 0 — it says nothing about filesystem write access. Option B is wrong because privileged: false merely disables privileged mode (which grants host device and capability access); it does not make the root filesystem read-only. Option C is wrong because dropping all Linux capabilities removes kernel-level privileges but does not prevent writes to the container's own filesystem, which is a mount-level property, not a capability.

Full explanation →
27
MCQeasy

A developer wants to verify the signature of a container image before deploying it. Which command should they use along with Cosign?

A.cosign verify
B.cosign generate-key-pair
C.cosign sign
D.cosign attest
AnswerA

cosign verify is the correct command because it validates an image's digital signature against a specified public key, confirming both the image's integrity and its authenticated origin. It fetches the image's signature from a registry or OCI artifact, decrypts it with the provided public key, and compares the digest to the image's current digest, failing if they do not match. This is the standard verification step in a supply chain security workflow, often used in CI/CD pipelines to enforce that only signed images are deployed.

Why this answer

The `cosign verify` command is used to check the cryptographic signature of a container image against a public key, ensuring the image's integrity and authenticity. This is the correct tool for a developer who needs to confirm that the image has not been tampered with and was signed by a trusted entity before deployment.

Exam trap

The CNCF CKS exam often tests the distinction between signing and verifying, so candidates may confuse `cosign sign` (which creates a signature) with `cosign verify` (which validates one), especially when the question asks about verifying an existing signature.

How to eliminate wrong answers

Option B is wrong because `cosign generate-key-pair` creates a new public/private key pair for signing, not for verifying an existing signature. Option C is wrong because `cosign sign` applies a signature to an image, which is the opposite of verification. Option D is wrong because `cosign attest` creates an in-toto attestation (a signed metadata statement about the image), but it does not directly verify the image's signature; verification of attestations requires a separate command like `cosign verify-attestation`.

Full explanation →
28
MCQeasy

You want to scan a container image for vulnerabilities before deploying it. Which command uses the Trivy tool to scan an image?

A.trivy check nginx:latest
B.trivy image nginx:latest
C.trivy fs nginx:latest
D.trivy scan nginx:latest
AnswerB

The trivy image subcommand targets a container image reference, pulling and analysing its layers for known CVEs. Specifying nginx:latest scans that image directly, satisfying the requirement to check vulnerabilities before deployment without needing a running container or exported filesystem.

Why this answer

Trivy uses the `image` subcommand to scan a container image for vulnerabilities. The correct syntax is `trivy image <image_name>`, which pulls the image (if not already present) and scans its OS packages and application dependencies against known vulnerability databases. Option B is correct because it follows this exact syntax.

Exam trap

CNCF-CKS often tests the exact subcommand names for tools like Trivy, expecting candidates to know that `image` is the correct subcommand for scanning container images, not generic verbs like `check` or `scan`.

How to eliminate wrong answers

Option A is wrong because `trivy check` is not a valid Trivy subcommand; Trivy uses `image` for container image scanning. Option C is wrong because `trivy fs` scans a filesystem directory, not a container image. Option D is wrong because `trivy scan` is not a valid Trivy subcommand; the correct subcommand for image scanning is `image`.

Full explanation →
29
MCQmedium

A security auditor runs kube-bench on a Kubernetes node and reports that the check '1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive' fails. What is the most appropriate remediation?

A.Delete the API server manifest file
B.Run 'chmod 755 /etc/kubernetes/manifests/kube-apiserver.yaml'
C.Restart the kubelet service
D.Run 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml'
AnswerD

chmod 644 sets the file mode to rw-r--r--, granting read access to all users but write access only to the owner (root). This satisfies the CIS Kubernetes Benchmark requirement that control plane manifest files be 644 or more restrictive, preventing unprivileged users from modifying the API server configuration. Because the kubelet reads these manifests as root, read permission is sufficient, and the removal of group/other write permission aligns with least privilege.

Why this answer

The CIS benchmark for Kubernetes requires the API server manifest file to have permissions of 644 or more restrictive (e.g., 600, 640, or 644) to prevent unauthorized modifications. Running 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml' sets the file to read-write for the owner and read-only for group and others, satisfying the benchmark. The kubelet automatically detects the change and reloads the static pod, so no restart is needed.

Exam trap

The trap here is that candidates often assume a service restart is required after a file permission change, but the kubelet automatically detects manifest file modifications, making a restart redundant and incorrect.

How to eliminate wrong answers

Option A is wrong because deleting the API server manifest file would remove the static pod definition, causing the API server to stop and the cluster to become unavailable. Option B is wrong because 'chmod 755' sets permissions to rwxr-xr-x, which is less restrictive than 644 (it grants execute permissions to all), failing the CIS check. Option C is wrong because restarting the kubelet service is unnecessary; the kubelet watches the manifest directory for changes and automatically reloads the static pod when the file permissions are updated.

Full explanation →
30
Multi-Selectmedium

You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?

Select 3 answers
A.Use environment variables from Vault with a script
B.Store Vault tokens in a Kubernetes Secret and mount them
C.Use the Vault Agent Sidecar Injector to inject secrets into pods
D.Use the Vault CSI Provider to mount secrets as volumes
E.Store Vault tokens in a ConfigMap and mount them into pods
AnswersB, C, D

Storing a Vault token in a Kubernetes Secret and mounting that Secret as a volume or env var is technically valid — the token itself is protected at rest by etcd encryption (if enabled) and access is governed by RBAC, so it acts as a static bootstrap credential. However, this approach has a significant security downside: the Vault token is a long-lived, high-privilege credential that, once copied into the Secret, does not rotate automatically and could be exfiltrated if the Secret or its decrypted contents are exposed. It works for simple use cases, but because the token remains valid until its TTL or an explicit revocation, it is less secure than using Vault Agent or CSI, which handle dynamic, short-lived secrets.

Why this answer

Storing Vault tokens in a Kubernetes Secret and mounting them into pods is a valid integration approach. The token is retrieved from Vault (e.g., via a Kubernetes auth method) and stored as a Secret, which is then mounted as a volume or environment variable, allowing the application to authenticate with Vault and fetch secrets dynamically.

Exam trap

The trap here is that candidates may think environment variables or ConfigMaps are acceptable for secrets, but the CKS exam emphasizes that ConfigMaps are for non-sensitive data and environment variables can leak secrets via logs or /proc, while Vault integration requires secure token handling via Secrets or dedicated injectors.

Full explanation →
31
MCQeasy

A DevOps team wants to ensure that all container images are pulled from a trusted registry only. Which cluster-level configuration should be applied?

A.Configure kubelet with --pod-manifest-path pointing to a whitelist
B.Enable PodSecurity with restricted profile
C.Use NetworkPolicy to block traffic to untrusted registries
D.Enable ImagePolicyWebhook admission controller
AnswerD

ImagePolicyWebhook is an admission controller that intercepts Pod create and update operations and sends an ImageReview payload containing each container's image name to an external HTTP/HTTPS service. The webhook responds with an admission decision, allowing an administrator to reject any image that doesn't come from a trusted registry, tag, or digest. This is the standard built-in mechanism for applying a centralized, registry-aware image policy to every Pod submitted through the API server.

Why this answer

The ImagePolicyWebhook admission controller allows you to configure a cluster-level admission plugin that intercepts all Pod creation requests and validates the container images against an external webhook backend. This backend can enforce policies such as allowing only images from a trusted registry (e.g., `mytrustedregistry.io/*`), rejecting any image that does not match the whitelist. It operates at the API server level, ensuring that no Pod with an untrusted image can be created in the cluster.

Exam trap

CNCF often tests the distinction between admission controllers that validate image sources (ImagePolicyWebhook) versus those that enforce Pod security contexts (PodSecurity), leading candidates to mistakenly choose PodSecurity when the question is about registry trust.

How to eliminate wrong answers

Option A is wrong because `--pod-manifest-path` is used by the kubelet to load static Pods from a local directory, not to enforce registry whitelisting; it has no mechanism to validate image sources. Option B is wrong because PodSecurity (formerly PodSecurityPolicy) restricts Pod security contexts (e.g., privileged containers, host namespaces), not the registry from which images are pulled. Option C is wrong because NetworkPolicy controls network traffic at the IP/port level (Layer 3/4) and cannot inspect or block the source registry of container images; it cannot prevent a Pod from pulling an image from an untrusted registry.

Full explanation →
32
Multi-Selecteasy

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Select 2 answers
A.gVisor (runsc)
B.Docker
C.containerd
D.runc
E.Kata Containers
AnswersA, E

gVisor (runsc) is an OCI runtime that provides application-level sandboxing: it intercepts system calls made by container processes and handles them with the Sentry, a user-space kernel implemented in Go, instead of passing them directly to the host kernel. This design dramatically reduces the kernel attack surface for workloads that run in untrusted pods. In Kubernetes, runsc is exposed through a RuntimeClass, letting the scheduler place specific pods onto the gVisor runtime.

Why this answer

gVisor (runsc) is a container sandboxing technology that provides a user-space kernel for containers, isolating them from the host kernel. Kubernetes supports gVisor via RuntimeClass, allowing pods to be scheduled with the 'runsc' runtime for enhanced security.

Exam trap

Candidates often confuse container runtimes (like containerd and runc) with container sandboxing technologies (like gVisor and Kata Containers). In the CNCF exam, only sandboxing technologies are supported via RuntimeClass for enhanced isolation.

Full explanation →
33
MCQmedium

A container is running with the following securityContext: securityContext: capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] Which capabilities will the container have?

A.All capabilities except NET_BIND_SERVICE
B.Only NET_BIND_SERVICE
C.No capabilities
D.All default capabilities plus NET_BIND_SERVICE
AnswerB

This is the correct interpretation: the container runs with exactly one Linux capability, `NET_BIND_SERVICE`. When `capabilities.drop` contains `ALL`, the container runtime begins with a completely empty capability set for the process, stripping away all default capabilities such as `CHOWN`, `DAC_OVERRIDE`, and `FOWNER`. Then `capabilities.add` with `NET_BIND_SERVICE` adds back just that one capability, allowing the process to bind to privileged ports (below 1024) but nothing else. This is a common least-privilege pattern for services that need to serve traffic on port 80 or 443.

Why this answer

The securityContext first drops all capabilities with `drop: ["ALL"]`, which removes every capability from the container's bounding set. Then `add: ["NET_BIND_SERVICE"]` adds back only that single capability. Therefore, the final effective set is exactly `NET_BIND_SERVICE`, making option B correct.

Exam trap

Kubernetes often tests the misconception that `drop: ["ALL"]` only removes non-default capabilities, or that adding a capability after dropping all restores the default set; the trap is that the order of operations is sequential and additive, so the final set is exactly what is added, not a union of defaults and additions.

How to eliminate wrong answers

Option A is wrong because dropping ALL and then adding NET_BIND_SERVICE does not leave all capabilities except NET_BIND_SERVICE; the drop operation removes everything, and the add operation only restores the specified capability, so the container ends up with only NET_BIND_SERVICE. Option C is wrong because the add directive explicitly grants NET_BIND_SERVICE, so the container does have that capability, not none. Option D is wrong because the default capabilities are not present; the `drop: ["ALL"]` overrides any defaults, leaving only the explicitly added capability.

Full explanation →
34
MCQmedium

Which of the following is correct about dropping the 'NET_RAW' capability?

A.It prevents the container from binding to a privileged port (<1024)
B.It prevents the container from using the 'ping' command
C.It prevents the container from creating raw sockets, which can be used for packet crafting attacks
D.It prevents the container from making any network connections
AnswerC

CAP_NET_RAW governs the ability to create raw sockets via socket(AF_INET, SOCK_RAW, protocol), which allows a process to craft arbitrary IP packets, spoof addresses, and forge protocol headers. Dropping this capability prevents such packet crafting attacks and also stops raw-socket packet sniffing on the host network, substantially reducing attack surface. Because normal applications use SOCK_STREAM or SOCK_DGRAM, their TCP/UDP traffic is unaffected, making this a precise least-privilege control.

Why this answer

The `NET_RAW` capability controls access to raw and packet sockets (AF_PACKET, SOCK_RAW). Dropping it prevents the container from creating raw sockets, which are often used for crafting custom packets, performing ARP spoofing, or launching other network-layer attacks. This is a key hardening measure to reduce the container's ability to manipulate network traffic at the low level.

Exam trap

CNCF often tests the misconception that 'ping' requires `NET_RAW`, but in modern Linux, ping can use a privileged datagram socket (ICMP_ECHO via SOCK_DGRAM) or setuid, so dropping `NET_RAW` does not always break ping.

How to eliminate wrong answers

Option A is wrong because binding to a privileged port (<1024) is controlled by the `CAP_NET_BIND_SERVICE` capability, not `NET_RAW`. Option B is wrong because the `ping` command typically uses ICMP echo requests, which can be sent via a datagram socket (SOCK_DGRAM) or raw socket; on many systems, ping falls back to a privileged datagram socket, so dropping `NET_RAW` does not necessarily prevent ping from working. Option D is wrong because dropping `NET_RAW` does not affect standard TCP/UDP connections; those use socket types (SOCK_STREAM, SOCK_DGRAM) that are governed by other capabilities like `CAP_NET_ADMIN` or `CAP_NET_RAW` only for raw sockets.

Full explanation →
35
Multi-Selecthard

You are deploying a workload that must be isolated from other workloads on the same node. You want to use a container sandboxing runtime to provide an additional security boundary. Which TWO of the following are true regarding the use of gVisor or Kata Containers in a Kubernetes cluster? (Choose two.)

Select 2 answers
A.They are only supported on Windows nodes and cannot run on Linux.
B.They require a RuntimeClass resource and a corresponding handler configured on the node.
C.They provide kernel-level isolation by running each container in its own virtual machine or user-space kernel.
D.They can be enabled by setting the pod's securityContext.privileged field to true.
E.They automatically encrypt all container images at rest on the node.
AnswersB, C

Both gVisor and Kata Containers are implemented as container runtimes that must be registered with the container runtime interface (CRI) on each node. A RuntimeClass object references the handler name, and the pod's spec.runtimeClassName selects it. Without the RuntimeClass and node-level handler, the pod cannot be scheduled with the sandboxed runtime, making this a necessary configuration step.

Why this answer

Sandboxed runtimes like gVisor and Kata Containers require a RuntimeClass and a node-level handler to be selected by pods. They add isolation by using a user-space kernel or a lightweight VM, reducing the risk of container escapes. They are not enabled via privileged mode, do not encrypt images, and are not limited to Windows nodes.

Exam trap

The trap here is confusing sandboxing with privileged mode, which actually removes isolation, or assuming sandboxing provides image encryption rather than runtime isolation.

Full explanation →
36
MCQmedium

A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?

A.The container is running without any capabilities
B.The container has all capabilities enabled, which is a security risk
C.The container has dropped all capabilities except NET_BIND_SERVICE
D.The container has default Docker capabilities, which is secure
AnswerB

The CapEff value is a full mask, meaning every capability supported by the kernel is present in the container process's effective set. With all capabilities, the process can invoke privileged syscalls such as mount(), ptrace(), and operations guarded by CAP_SYS_ADMIN, essentially matching root on the host for capability-restricted actions. This dramatically increases the host attack surface if the container is compromised, so the configuration is a significant security risk.

Why this answer

The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.

Exam trap

CNCF often tests the distinction between 'default Docker capabilities' (which are secure and limited) and 'all capabilities' (which is a severe vulnerability), and the trap here is that candidates may confuse 'all capabilities' with the default set or think that dropping all capabilities is the only insecure state.

How to eliminate wrong answers

Option A is wrong because the container is explicitly configured with all capabilities enabled, not running without any capabilities (which would be the case with `--cap-drop=ALL`). Option C is wrong because the configuration grants all capabilities, not a minimal set like only `NET_BIND_SERVICE`; dropping all but one capability would be a secure practice, not a vulnerability. Option D is wrong because default Docker capabilities (a restricted set like `CHOWN`, `DAC_OVERRIDE`, `FSETID`, `FOWNER`, `MKNOD`, `NET_RAW`, `SETGID`, `SETUID`, `SETFCAP`, `SETPCAP`, `NET_BIND_SERVICE`, `SYS_CHROOT`, `KILL`, `AUDIT_WRITE`) are considered secure for most workloads, but this configuration explicitly grants all capabilities, which is far less restrictive and insecure.

Full explanation →
37
MCQhard

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

A.container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile
B.apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile
C.container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/my-custom-profile
D.container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce
AnswerC

This is the correct format for per-container AppArmor confinement. The key `container.apparmor.security.beta.kubernetes.io/<container_name>` tells the kubelet to apply the specified profile to the container identified by `<container_name>`. The value `localhost/my-custom-profile` instructs the kubelet to load a profile named `my-custom-profile` from the node's AppArmor profile directory (typically `/etc/apparmor.d`). The kubelet verifies that the profile is loaded before starting the container; if it isn't, the pod is rejected.

Why this answer

The AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>` with the value `localhost/<profile_name>`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Exam trap

CNCF often tests the exact annotation key format and the necessity of the `localhost/` prefix, leading candidates to omit the `container.` prefix or the `localhost/` value, or to confuse the annotation structure with other security contexts like seccomp or SELinux.

How to eliminate wrong answers

Option A is wrong because the annotation prefix is `container.apparmor.security.beta.kubernetes.io/`, not `container.apparmor.kubernetes.io/` — the latter is not a valid Kubernetes annotation key for AppArmor. Option B is wrong because the annotation key is missing the `container.` prefix and the value is missing the `localhost/` prefix; the correct value must be `localhost/my-custom-profile`, not just `my-custom-profile`. Option D is wrong because the annotation key incorrectly places the profile name in the key itself and uses `enforce` as the value; the correct format uses the container name in the key and `localhost/<profile_name>` as the value.

Full explanation →
38
MCQmedium

You need to ensure that the kubelet only serves authenticated and authorized requests. Which flag(s) should be set on the kubelet?

A.--anonymous-auth=false and --authorization-mode=AlwaysAllow
B.--anonymous-auth=true and --authorization-mode=Webhook
C.--authenticated=true and --authorization=RBAC
D.--anonymous-auth=false and --authorization-mode=Webhook
AnswerD

This is the correct configuration because --anonymous-auth=false ensures that every request to the kubelet must present a valid credential, such as a client certificate or bearer token, thereby fulfilling the 'only serve authenticated requests' requirement. Additionally, --authorization-mode=Webhook makes the kubelet send SubjectAccessReview requests to the API server, which then applies RBAC rules to decide whether an authenticated identity is permitted to perform a specific action. Together they enforce both authentication and fine-grained authorization, aligning with Kubernetes security best practices and preventing unauthorized or overly broad access to the kubelet API.

Why this answer

Setting `--anonymous-auth=false` disallows unauthenticated requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server's SubjectAccessReview), ensuring that only authenticated and authorized requests are served. This combination enforces both authentication and authorization, which is required for hardening the kubelet.

Exam trap

CNCF often tests the misconception that `--authorization-mode=RBAC` is a valid kubelet flag, but the kubelet only supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny` for authorization, and RBAC is configured on the API server, not directly on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysAllow` bypasses all authorization checks, allowing any authenticated request to proceed, which violates the requirement to serve only authorized requests. Option B is wrong because `--anonymous-auth=true` allows unauthenticated requests, which directly contradicts the need to serve only authenticated requests. Option C is wrong because `--authenticated` is not a valid kubelet flag; the correct flag is `--anonymous-auth`, and `--authorization=RBAC` is not a valid flag (the correct flag is `--authorization-mode` and RBAC is not a supported mode for the kubelet; the kubelet supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny`).

Full explanation →
39
MCQeasy

What is the primary benefit of using external secret managers (e.g., HashiCorp Vault) in Kubernetes?

A.They ensure that secrets are never stored in etcd
B.They prevent all unauthorized access to secrets
C.They provide better control over secret rotation, auditing, and access policies
D.They eliminate the need for Kubernetes Secrets entirely
AnswerC

External secret managers centralize lifecycle controls such as automated rotation, expiration enforcement, and granular IAM-based access policies that are not supported natively by Kubernetes Secrets. They also produce detailed audit logs of who accessed which secret and when, enabling compliance and forensic analysis. This operational advantage over static Kubernetes Secrets is the primary reason organizations adopt them.

Why this answer

External secret managers such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault provide centralized lifecycle management for secrets, including automated rotation, detailed audit logging, and fine-grained access policies. In Kubernetes, integrating these tools (via CSI drivers or operators) gives teams stronger governance than native Kubernetes Secrets, which lack built-in rotation and rich auditing. The primary benefit is therefore better control over rotation, auditing, and access policies.

Exam trap

CKS often tests the misconception that external secret managers eliminate secrets from etcd — in reality, syncSecret and native Secret usage can still persist them, so the correct answer focuses on governance benefits, not absolute elimination.

How to eliminate wrong answers

Option A is wrong because external secret managers do not guarantee secrets are never stored in etcd — if the secret is synced into a Kubernetes Secret object, it is still stored in etcd unless the integration injects it directly into the pod (e.g., via CSI volume) without creating a Secret. Option B is wrong because no tool can prevent all unauthorized access; external managers improve access control but do not make it absolute. Option D is wrong because external secret managers complement, not eliminate, Kubernetes Secrets — many integrations still use Secret objects as a delivery mechanism.

Full explanation →
40
MCQeasy

What is the purpose of the 'seccomp' feature in Kubernetes?

A.To restrict file system access for a container
B.To restrict the system calls a container can make
C.To restrict the Linux capabilities a container can use
D.To restrict network access for a container
AnswerB

Seccomp (secure computing mode) is a Linux kernel feature that constrains a containerized process to a specific set of allowed system calls. In Kubernetes, you define a profile via seccompProfile (Unconfined, RuntimeDefault, or Localhost) and the container runtime loads the BPF filter to intercept syscalls; any call not in the allowlist is rejected or triggers a default action. This shrinks the kernel attack surface by blocking dangerous syscalls such as mount, ptrace, or kexec_load, which is the core purpose of seccomp.

Why this answer

Seccomp (secure computing mode) is a Linux kernel feature that allows a process to specify a filter for the system calls it can make. In Kubernetes, seccomp profiles can be applied to pods or containers to restrict the allowed syscalls, reducing the kernel attack surface. This is a key mechanism for container runtime security, distinct from filesystem, capability, or network controls.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and Linux capabilities (privilege granularity), so candidates may confuse restricting capabilities with restricting syscalls.

How to eliminate wrong answers

Option A is wrong because restricting file system access is achieved via read-only root filesystems, securityContext with readOnlyRootFilesystem, or AppArmor/SELinux profiles, not seccomp. Option C is wrong because restricting Linux capabilities is done via the 'capabilities' field in securityContext (e.g., drop: ALL), while seccomp filters syscalls at a lower level. Option D is wrong because restricting network access is managed by NetworkPolicies, not seccomp.

Full explanation →
41
MCQmedium

You are writing a Falco rule to detect when a container tries to read /etc/shadow. Which condition should you use?

A.fd.name=/etc/shadow and container.id != host
B.fd.name=/etc/passwd
C.container.id != host
D.fd.name=/etc/shadow
AnswerA

This rule precisely targets a containerized process attempting to read /etc/shadow, the file that stores password hashes on most Linux systems. The condition container.id != host is essential because it restricts the match to events originating from containers, excluding the host itself. This combination avoids false positives from legitimate admin actions while capturing the exact behavior indicative of credential harvesting in a container.

Why this answer

The correct condition 'fd.name=/etc/shadow and container.id != host' ensures the accessed file is /etc/shadow and the event originates from a container (not the host). Option A correctly includes both conditions. Option B specifies /etc/passwd (wrong file).

Option C only checks that it's from a container but does not restrict the file. Option D checks the file but does not exclude host events.

Full explanation →
42
MCQhard

A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?

A.The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.
B.The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.
C.The pod will be created because NodeRestriction does not restrict hostPath volumes.
D.The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.
AnswerC

The pod is admitted because the NodeRestriction admission controller only limits the kubelet's ability to update Node resources, such as preventing it from changing arbitrary labels or taints on nodes it does not own. It does not evaluate Pod specs at all, so a hostPath volume within a pod is unaffected. HostPath usage is instead constrained by Pod Security Standards or cluster-specific admission policies.

Why this answer

The NodeRestriction admission plugin limits the node labels that a kubelet can set and restricts pods from modifying their node affinity to gain access to node-specific resources. However, it does not restrict the use of hostPath volumes. Therefore, a pod with a hostPath volume pointing to /var/log and a nodeSelector for 'worker-1' will be created, as long as the nodeSelector matches an existing node label and the hostPath volume is otherwise permitted by the PodSecurityPolicy or other security contexts.

Exam trap

The trap here is that candidates often confuse NodeRestriction with other admission plugins like PodSecurityPolicy or think it enforces broad security restrictions, when in fact it only targets node label and kubelet certificate behavior.

How to eliminate wrong answers

Option A is wrong because the hostPath volume is relevant: it must be allowed by the cluster's security policies (e.g., PodSecurityPolicy, OPA), but NodeRestriction does not block it. Option B is wrong because NodeRestriction does not restrict hostPath volumes; it only restricts node label modifications and kubelet self-approval of certificates. Option D is wrong because nodeSelector does not conflict with NodeRestriction; NodeRestriction does not evaluate nodeSelector values for conflicts.

Full explanation →
43
MCQeasy

Which tool is used to generate an SBOM (Software Bill of Materials) for a container image?

A.Clair
B.Kubesec
C.Trivy
D.Syft
AnswerD

Syft scans container images and outputs a Software Bill of Materials listing packages and versions, satisfying the requirement to generate an SBOM. It inspects image layers directly, supporting formats such as SPDX and CycloneDX, which is precisely the artefact the question demands.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) from container images and filesystems. It uses a pluggable cataloger system to extract package metadata (e.g., dpkg, RPM, APK, Python, Java JARs) and outputs the SBOM in formats like CycloneDX or SPDX, which are the standard formats for supply chain transparency.

Exam trap

The CKS exam often tests the distinction between dedicated SBOM tools (Syft) and vulnerability scanners that may also generate SBOMs (Trivy), so candidates mistakenly choose Trivy because it is more widely known, but Syft is the correct answer for the specific task of SBOM generation.

How to eliminate wrong answers

Option A is wrong because Clair is a static analysis tool for vulnerability scanning of container images, not an SBOM generator; it compares packages against CVE databases. Option B is wrong because Kubesec is a Kubernetes resource security scanner that evaluates Pod security contexts and RBAC, not container image content or SBOM generation. Option C is wrong because Trivy is a comprehensive vulnerability scanner that can also produce SBOMs as a secondary feature, but its primary purpose is vulnerability detection, and the question specifically asks for the tool 'used to generate an SBOM' — Syft is the dedicated, purpose-built SBOM tool, while Trivy's SBOM generation is a later-added capability and not its core function.

Full explanation →
44
MCQhard

A cluster has a ValidatingWebhookConfiguration that intercepts Pod CREATE requests. The webhook server is unavailable. What happens when a user tries to create a pod?

A.The webhook is automatically disabled
B.The API server crashes
C.The pod creation is rejected until the webhook becomes available
D.The pod is created without webhook validation
AnswerC

A ValidatingWebhookConfiguration with failurePolicy set to Fail rejects requests when the webhook server cannot be reached. Because the webhook intercepts Pod CREATE, admission fails closed, so the pod creation is rejected until the server recovers.

Why this answer

When a ValidatingWebhookConfiguration is defined and the webhook server is unavailable, the default failure policy is `Fail`, which causes the API server to reject the Pod CREATE request. This ensures that security validation is not bypassed due to webhook downtime, maintaining the cluster's security posture. The pod creation is blocked until the webhook becomes available again, as specified by the `failurePolicy` field in the webhook configuration.

Exam trap

The CKS exam often tests the default `failurePolicy` behavior, and the trap here is that candidates assume the API server will simply skip validation or crash, rather than understanding that the default `Fail` policy causes the request to be rejected.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfigurations are not automatically disabled when the webhook server is unavailable; the failure policy (`Fail` or `Ignore`) determines the behavior, not an automatic disable. Option B is wrong because the API server does not crash; it handles the webhook timeout or connection error gracefully by applying the configured failure policy, which may reject the request but does not cause a crash. Option D is wrong because the pod is not created without validation unless the failure policy is explicitly set to `Ignore`; by default, it is `Fail`, which rejects the request.

Full explanation →
45
MCQhard

You have enabled etcd encryption at rest using an EncryptionConfiguration with aescbc provider. After applying the configuration, you create a new Secret. Which of the following is true regarding the encrypted Secret?

A.All Secrets are encrypted because the EncryptionConfiguration applies to all resources.
B.All Secrets in the cluster, including existing ones, are immediately encrypted.
C.Only the new Secret is encrypted; existing Secrets remain in plaintext.
D.The new Secret is stored in plaintext because aescbc is not a valid provider.
AnswerC

A newly created Secret is passed through the encryption provider (here aescbc) before its bytes are stored in etcd, so only the new write is protected. Previously written Secrets are already at rest in plaintext and the API server does not proactively re-read and re-encrypt them. Without rotating, those old entries stay unencrypted until modified or deleted.

Why this answer

When you apply an EncryptionConfiguration with aescbc provider, only newly created Secrets are encrypted at rest. Existing Secrets remain in plaintext because encryption is applied at write time; the API server does not retroactively re-encrypt data already stored in etcd. This is why option C is correct.

Exam trap

The trap here is that candidates assume encryption is applied retroactively to all existing data, but Kubernetes only encrypts data at write time, so existing Secrets remain unencrypted until they are updated or re-created.

How to eliminate wrong answers

Option A is wrong because the EncryptionConfiguration applies only to the resources listed in its `resources` field, not to all resources by default. Option B is wrong because etcd encryption is not retroactive; existing Secrets are not automatically re-encrypted when the configuration is applied. Option D is wrong because aescbc is a valid provider in Kubernetes (AES-CBC with PKCS#7 padding) and is commonly used for encryption at rest.

Full explanation →
46
Multi-Selectmedium

Which TWO are best practices for Dockerfile security? (Select 2)

Select 2 answers
A.Use a non-root user
B.Use a minimal base image (distroless)
C.Store secrets in environment variables
D.Install SSH server for debugging
E.Run the container as root
AnswersA, B

Running as non-root limits the impact of a breach. Containers share the host kernel, so a root process escaping the container can gain root on the host. In the Dockerfile, use the USER directive to switch to an unprivileged user, and in Kubernetes set securityContext.runAsUser/runAsNonRoot. This ensures that even if the application is compromised, the attacker only has the privileges of that user, not root.

Why this answer

Running containers as a non-root user reduces the risk of privilege escalation attacks. If an attacker compromises the container, they will not have root privileges, limiting their ability to modify system files or escape the container. This is enforced by using the USER directive in the Dockerfile to specify a non-root UID (e.g., USER 1001).

Exam trap

The CKS exam often tests the misconception that environment variables are a safe way to pass secrets to containers, but in reality they are easily leaked through Docker metadata and runtime introspection.

Full explanation →
47
Multi-Selectmedium

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Select 2 answers
A.Kata Containers run containers in lightweight VMs, providing hardware-level isolation.
B.gVisor provides a kernel-level sandbox by implementing a user-space kernel.
C.Kata Containers use the host kernel for system calls.
D.gVisor runs containers in separate VMs for each pod.
E.Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.
AnswersA, B

Kata Containers provide hardware-level isolation by spawning each container or pod inside a lightweight VM that is booted with its own guest kernel, typically using KVM on Linux. The guest kernel handles system calls as if it were a real host, and the hypervisor enforces CPU and memory isolation at the hardware boundary. This design gives each container a full kernel of its own, which is a stronger isolation boundary than syscall interception because even a compromised guest kernel cannot directly access the host kernel.

Why this answer

Kata Containers provide hardware-level isolation by running each container or pod in a lightweight VM with its own guest kernel using KVM. Option B is correct because gVisor implements a user-space kernel (called Sentry) that intercepts system calls, providing a kernel-level sandbox without dedicated VMs. Option C is incorrect because Kata Containers use a guest kernel, not the host kernel.

Option D is incorrect because gVisor does not run containers in separate VMs; it runs as a kernel within the user space. Option E is incorrect because although RuntimeClass is commonly used to select non-default runtimes in Kubernetes, the statement is not universally required; it is a mechanism but not a strict requirement for using these technologies, making the claim that both 'require' RuntimeClass too absolute and thus false.

Exam trap

Candidates may be misled by the appealing combination of A, B, and E, but only A and B are correct. The statement in E is too absolute because RuntimeClass is not strictly required—it is an optional mechanism.

Full explanation →
48
MCQmedium

What is the purpose of the Kubernetes Dashboard?

A.To provide a command-line interface for cluster management
B.To provide a web-based user interface for deploying and managing applications
C.To monitor cluster performance metrics
D.To enforce security policies on the cluster
AnswerB

The Kubernetes Dashboard is a general-purpose web UI that enables users to deploy, manage, and inspect applications running on the cluster. Through a browser, users can create or edit Deployments, Services, ConfigMaps, and Secrets, view pod logs, exec into containers, and monitor basic status — all without using kubectl. Its explicit goal is to make day-to-day cluster operations accessible via a visual interface, which matches its role as a front-end for Kubernetes resource management.

Why this answer

The Kubernetes Dashboard is a web-based user interface that allows users to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster resources. It provides a graphical alternative to the kubectl command-line tool, enabling operations such as viewing workloads, scaling deployments, and editing resources through a browser.

Exam trap

CNCF often tests the misconception that the Dashboard is a monitoring or security tool, but the CKS exam emphasizes that its role is purely a web UI for cluster management, and that security enforcement is the job of admission controllers and RBAC, not the Dashboard itself.

How to eliminate wrong answers

Option A is wrong because the command-line interface for cluster management is provided by kubectl, not the Dashboard. Option C is wrong because while the Dashboard can display some basic metrics (like CPU/memory usage) via integrations like metrics-server, its primary purpose is not performance monitoring; dedicated tools like Prometheus and Grafana are used for comprehensive cluster monitoring. Option D is wrong because security policies (e.g., Pod Security Standards, RBAC, NetworkPolicies) are enforced by the Kubernetes API server and admission controllers, not by the Dashboard; the Dashboard itself is subject to those policies.

Full explanation →
49
MCQmedium

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

A.Use a sidecar container that watches for changes and reloads the application
B.Update the pod spec to reference a new Secret version
C.The mounted volume is automatically updated over time
D.Delete and recreate the pod
AnswerC

For a Secret mounted as a regular volume (not via subPath or as a projected volume), the kubelet periodically syncs the Secret from the API server to the volume directory, so the file contents are updated automatically. This triggers inotify events that a well-designed application can watch to reload configuration without restarting the Pod. The update is eventually consistent and typically occurs within a minute, but the application must be coded to re-read the file from disk after receiving a change notification.

Why this answer

When a Secret is mounted as a volume in Kubernetes, the kubelet periodically syncs the secret data from the API server and updates the files in the volume. This means the pod can consume the updated values without needing a restart, as the files are refreshed automatically (with a default sync period of around 60 seconds). Option C correctly identifies this behavior.

Exam trap

Candidates often think that updating a Secret requires a pod restart, but in Kubernetes, Secrets mounted as volumes are automatically updated by the kubelet without restart.

How to eliminate wrong answers

Option A is wrong because while a sidecar container can watch for changes and reload the application, it is not the default or automatic mechanism; the question asks how the pod can consume updated values without restarting, and the built-in volume update handles that without requiring a sidecar. Option B is wrong because Kubernetes Secrets do not have versioning; you cannot reference a 'new Secret version' in the pod spec — you must update the same Secret object or create a new one and update the pod spec to reference the new name, which would require a pod restart. Option D is wrong because deleting and recreating the pod is unnecessary; the mounted volume is automatically updated by the kubelet, so restarting is not required.

Full explanation →
50
MCQeasy

Which Kubernetes admission controller ensures that a pod only uses images from a specific registry?

A.NamespaceLifecycle
B.ImagePolicyWebhook
C.PodNodeSelector
D.AlwaysPullImages
AnswerB

ImagePolicyWebhook delegates admission decisions to an external HTTP service, which inspects each pod's image reference and rejects anything outside the permitted registry. Built-in controllers such as NodeRestriction or PodSecurityPolicy cannot enforce registry allow-lists, so this satisfies the stem's registry restriction.

Why this answer

The ImagePolicyWebhook admission controller allows you to define a webhook that validates container images against a policy, such as restricting them to a specific registry. When a pod is created, Kubernetes sends an admission review to the webhook, which can reject images not from the allowed registry. This is the correct choice because it directly enforces image source policies.

Exam trap

The CKS exam often tests the distinction between AlwaysPullImages (which only affects pull behavior, not source validation) and ImagePolicyWebhook (which enforces registry restrictions), leading candidates to confuse operational controls with policy enforcement.

How to eliminate wrong answers

Option A is wrong because NamespaceLifecycle ensures that objects are created only in existing namespaces and prevents deletion of system namespaces, not image registry restrictions. Option C is wrong because PodNodeSelector enforces namespace-level node selector constraints on pods, not image registry validation. Option D is wrong because AlwaysPullImages forces image pull policy to Always, ensuring images are pulled every time, but it does not restrict which registry images can come from.

Full explanation →
51
MCQmedium

You have configured an audit policy with level: Request. Which request information is logged?

A.Only metadata for the request
B.Nothing is logged because Request is not a valid level
C.Request metadata and request body
D.Request metadata, request body, and response body
AnswerC

When the audit policy level is set to Request, the Kubernetes API server logs a structured audit event containing the full request metadata and the raw request body. This level sits between Metadata, which omits the body, and RequestResponse, which additionally includes the response body. It is the correct behavior for a policy configured with the Request level, matching the official audit level specification.

Why this answer

In the Kubernetes audit policy, the Request level logs the request metadata (who, what, when, where) plus the request body, but not the response body. This is useful for capturing what was sent to the API server without the overhead of logging responses. The Response level would additionally log the response body.

Exam trap

CKS often tests the distinction between Request and RequestResponse audit levels — candidates must remember that Request includes the request body but not the response body.

How to eliminate wrong answers

Option A is wrong because 'Only metadata' describes the Metadata level, not Request. Option B is wrong because Request is a valid audit level in Kubernetes (levels: None, Metadata, Request, RequestResponse). Option D is wrong because including the response body corresponds to the RequestResponse level, not Request.

Full explanation →
52
MCQmedium

An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?

A.The webhook configuration's rules do not match the pod create operation
B.The webhook's failure policy is set to Ignore
C.The webhook is only applied to pods in a specific namespace
D.The webhook only applies to pods created with a specific service account
AnswerA

For a ValidatingWebhookConfiguration to be triggered, the incoming request must match the declared rules on apiGroups, apiVersions, resources, and operations. If the rules omit the 'pods' resource or the 'create' operation (or the pod's API version/group), the API server bypasses this webhook entirely. Thus, the observed absence of any admission response is fully explained by a rules mismatch, making this the correct answer.

Why this answer

A is correct because the ValidatingWebhookConfiguration's `rules` define which API operations (e.g., create, update) and resources (e.g., pods) trigger the webhook. If the rules do not include the `create` operation for pods, the webhook will not intercept the pod creation request, so the pod is created without validation. The pod's security context (missing `runAsNonRoot`) is irrelevant if the webhook never fires.

Exam trap

The CKS exam often tests the misconception that a webhook's failure policy (Ignore/Fail) controls whether it denies requests, when in fact the `rules` matching is the primary gate for webhook invocation.

How to eliminate wrong answers

Option B is wrong because the failure policy (Ignore or Fail) only determines behavior when the webhook itself is unreachable or returns an error, not when the webhook is not triggered by the request. Option C is wrong because the question states the pod was created successfully, implying no namespace restriction was in effect; even if a namespaceSelector existed, the pod would have been denied if the webhook matched. Option D is wrong because service account filtering is configured via `matchConditions` or `objectSelector`, not by default, and the question provides no evidence of such a filter.

Full explanation →
53
MCQmedium

Which kubectl command creates a Role named 'pod-reader' that allows only 'get', 'list', and 'watch' on pods in namespace 'ns1'?

A.kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
B.kubectl create role pod-reader --verb=get,list,watch --resource=pods --namespace=ns1
C.kubectl create role pod-reader --verb=* --resource=pods --namespace=ns1
D.kubectl create rolebinding pod-reader --role=pod-reader --serviceaccount=ns1:default
AnswerB

This is the correct command because `kubectl create role` creates a namespaced Role, and the `--namespace=ns1` flag scopes it to the namespace ns1. The `--verb=get,list,watch` precisely defines the allowed actions, and `--resource=pods` targets the Pods resource. This matches exactly the requirement to create a role named `pod-reader` with read-only access to pods in namespace ns1.

Why this answer

The `kubectl create role` command creates a Role (namespaced resource) with the specified verbs and resources in the given namespace. The `--verb=get,list,watch` and `--resource=pods` flags define the exact permissions, and `--namespace=ns1` scopes the Role to that namespace, which matches the requirement.

Exam trap

The trap here is that candidates often confuse `kubectl create role` with `kubectl create clusterrole` (option A) or mistakenly use `--verb=*` (option C) thinking it means 'only these verbs', when in fact it grants all verbs, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because `kubectl create clusterrole` creates a ClusterRole, which is cluster-scoped, not namespaced; it would grant permissions across all namespaces, not just 'ns1'. Option C is wrong because `--verb=*` grants all verbs (including create, update, delete, etc.), not just 'get', 'list', and 'watch'. Option D is wrong because `kubectl create rolebinding` creates a RoleBinding (binding a role to a subject), not a Role; it also references a role named 'pod-reader' that does not exist yet, and the command does not create the Role itself.

Full explanation →
54
MCQmedium

Which tool can be used to perform static analysis of Kubernetes manifests for security issues?

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

Kubesec is a static analysis tool that evaluates Kubernetes resource manifests against a set of security best practice rules, scoring them and flagging risks such as running as root, privilege escalation, and insecure capabilities. It returns a risk score and provides remediation advice directly from the manifest, making it suitable for CI/CD integration. This is exactly the capability needed for static analysis of Kubernetes manifests, unlike the other tools listed.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes resource manifests against a set of built-in security best practices. It scans YAML or JSON manifests for common misconfigurations such as running containers as root, missing resource limits, or insecure capability assignments, and returns a risk score. This makes it the correct choice for static analysis of Kubernetes manifests for security issues.

Exam trap

The trap here is that candidates often confuse general vulnerability scanners (like Trivy) or image signing tools (like Cosign) with dedicated Kubernetes manifest static analysis tools, leading them to pick a tool that is not specifically designed for scanning YAML security configurations.

How to eliminate wrong answers

Option A is wrong because Syft is a software bill of materials (SBOM) generator that analyzes container images and filesystems to list packages and dependencies, not a static analyzer of Kubernetes manifests. Option B is wrong because Cosign is a tool for signing and verifying container image signatures and attestations, not for scanning Kubernetes manifest files for security misconfigurations. Option D is wrong because Trivy is a comprehensive vulnerability scanner that primarily scans container images, filesystems, and Git repositories for known CVEs, and while it can scan IaC files including Kubernetes manifests, its core focus is vulnerability detection rather than dedicated static analysis of Kubernetes security configurations; Kubesec is the more specialized and direct tool for this purpose.

Full explanation →
55
MCQhard

You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?

A.Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem
B.Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace
C.Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext
D.Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding
AnswerB

OPA/Gatekeeper is the appropriate choice because it provides a flexible, declarative policy engine that can enforce arbitrary constraints via ConstraintTemplates. A dedicated template can validate that every pod in acme-corp sets securityContext.readOnlyRootFilesystem to true and that any added Linux capabilities are limited to exactly NET_BIND_SERVICE. This approach is more precise than Pod Security Standards, is actively maintained, and can be scoped to a namespace with a Constraint resource, while also supporting dry-run and audit modes for safe rollout.

Why this answer

OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.

Exam trap

The trap here is that candidates may choose Pod Security Admission (PSA) because it is the newer, recommended replacement for PSP, but PSA lacks the granularity to enforce readOnlyRootFilesystem or restrict capabilities to a single capability like NET_BIND_SERVICE, leading to an incorrect choice like Option A or C.

How to eliminate wrong answers

Option A is wrong because Pod Security Admission (PSA) with the 'baseline' policy does not enforce readOnlyRootFilesystem or allow fine-grained capability control like only NET_BIND_SERVICE; it only restricts privileged containers and host namespaces, and a mutating webhook would be an additional, non-standard workaround. Option C is wrong because the 'privileged' policy in PSA allows all capabilities and privilege escalation, directly violating the requirement to prevent privilege escalation and enforce a read-only root filesystem. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.24 and will be removed in v1.25, making it a non-compliant choice for new configurations; additionally, PSPs are cluster-scoped and binding them via RoleBinding to a namespace is not the intended mechanism (they require PSP-specific RBAC bindings).

Full explanation →
56
MCQmedium

A cluster administrator wants to enforce that containers run with a read-only root filesystem. Which security context field should be set?

A.privileged: false
B.readOnlyRootFilesystem: true
C.readOnly: true
D.allowPrivilegeEscalation: false
AnswerB

`readOnlyRootFilesystem: true` is a container securityContext field that instructs the container runtime to mount the container's root filesystem as read-only (typically using a read-only overlay). Any attempt to write to the root filesystem will fail with an error unless a writable volume is mounted at a specific path, such as an `emptyDir` for temporary data. This directly satisfies the requirement to make the container's filesystem immutable, and it is the standard Kubernetes‑native way to achieve that guarantee.

Why this answer

The `readOnlyRootFilesystem: true` field in the Pod or container security context explicitly mounts the container's root filesystem as read-only, preventing any writes to the filesystem. This is a key runtime security control to mitigate malware or unauthorized modifications, as required by the CIS Kubernetes Benchmark and common security policies.

Exam trap

The CKS exam often tests the distinction between `readOnlyRootFilesystem` and the non-existent `readOnly` field, exploiting the common misconception that a simple `readOnly` boolean exists in the security context.

How to eliminate wrong answers

Option A is wrong because `privileged: false` only disables privileged mode (which grants all capabilities), but does not enforce a read-only root filesystem; a non-privileged container can still write to its filesystem. Option C is wrong because `readOnly: true` is not a valid field in the Kubernetes security context; the correct field is `readOnlyRootFilesystem`. Option D is wrong because `allowPrivilegeEscalation: false` prevents processes from gaining more privileges than their parent, but does not restrict filesystem writes.

Full explanation →
57
Multi-Selecthard

Which three of the following are valid methods to restrict access to etcd? (Choose three.)

Select 3 answers
A.Enable RBAC authorization on etcd
B.Disable the etcd API and use only the embedded etcd in control plane
C.Use firewall rules to limit access to etcd port 2379
D.Use TLS client certificates to authenticate clients
E.Encrypt etcd data at rest using EncryptionConfiguration
AnswersA, C, D

etcd ships with a built-in RBAC system that authenticates client identities and authorizes operations according to roles bound to users. You can define users and roles, and grant read or write access to specific key prefixes (for example, /registry/) so only kube-apiserver's credentials can modify cluster state. This is a direct, API-level control that restricts which authenticated principal can execute etcd operations, making it a valid access-control method.

Why this answer

Etcd supports Role-Based Access Control (RBAC) natively since version 3.0. By enabling RBAC on etcd, you can define roles and permissions to restrict which users or processes can read or write to specific keys or prefixes. This is a direct method to secure the etcd datastore against unauthorized access.

Exam trap

CNCF often tests the distinction between access control (who can connect to etcd) and data protection (encryption at rest), leading candidates to incorrectly select encryption as a method to restrict access.

Full explanation →
58
Multi-Selecthard

Which ONE of the following is a valid Rego policy construct used in OPA Gatekeeper ConstraintTemplates to enforce security policies?

Select 1 answer
A.violation[{"msg": msg}] { condition }
B.allow { condition }
C.deny[{"msg": msg}] { condition }
D.audit { condition }
E.warn[{"msg": msg}] { condition }
AnswersA

The `violation[{"msg": msg}] { condition }` construct is the canonical rule format for Gatekeeper ConstraintTemplates. Gatekeeper's admission and audit controllers compile the template's Rego and expect a partial set rule named `violation`; whenever the `condition` evaluates to true, the set is non-empty and the constraint's enforcement action (deny, warn, or dryrun) is applied. The `msg` variable binds to a human-readable message that is surfaced in the audit results or admission response. This construct directly fulfills Gatekeeper's internal policy enforcement contract.

Why this answer

In OPA Gatekeeper ConstraintTemplates, the only Rego construct that directly triggers a constraint violation is `violation[{"msg": msg}] { condition }`. When the condition evaluates to true, Gatekeeper generates a violation message. The `allow` and `deny` rules are not standard constructs for enforcing constraints in Gatekeeper; they are general Rego rules used in other OPA contexts but not within ConstraintTemplates to report violations.

Options D (`audit`) and E (`warn`) are also not valid Rego constructs for Gatekeeper constraints.

Exam trap

Candidates may mistakenly think that `allow` and `deny` are valid constructs within Gatekeeper ConstraintTemplates. In reality, only the `violation` rule is used to trigger constraint violations. `allow` and `deny` are general Rego rules used in other OPA contexts, but not for defining Gatekeeper constraints.

Full explanation →
59
MCQmedium

A security team wants to ensure that all container images in a cluster are scanned for critical CVEs before they are run. They decide to use an admission controller. Which Kubernetes built-in admission controller should they configure?

A.MutatingAdmissionWebhook
B.ValidatingAdmissionPolicy
C.ImagePolicyWebhook
D.PodSecurity
AnswerC

ImagePolicyWebhook satisfies the requirement by calling an external HTTPS endpoint during admission, letting the team's scanner reject pods whose images contain critical CVEs before they run. It is the only built-in admission controller that inspects image metadata at admission time, so scanning gates deployment rather than merely reporting afterwards.

Why this answer

The ImagePolicyWebhook admission controller is the correct choice because it allows an external webhook to validate container images against a policy (e.g., scanning for critical CVEs) before they are admitted into the cluster. It intercepts Pod creation requests and queries an external service to decide whether the image is allowed, making it ideal for enforcing image security scanning at admission time.

Exam trap

The CKS exam often tests the distinction between admission controllers that enforce security contexts (PodSecurity) versus those that integrate with external scanning services (ImagePolicyWebhook), leading candidates to mistakenly choose PodSecurity because it sounds security-related.

How to eliminate wrong answers

Option A is wrong because MutatingAdmissionWebhook is used to mutate (modify) objects during admission, not to validate image security policies; it can be used for injecting sidecars or annotations but does not natively enforce image scanning. Option B is wrong because ValidatingAdmissionPolicy (using CEL expressions) is a declarative validation mechanism that cannot call external scanning services; it is limited to simple in-cluster checks and cannot integrate with external CVE databases. Option D is wrong because PodSecurity is a built-in admission controller that enforces Pod Security Standards (e.g., restricted, baseline) but does not scan container images for CVEs; it only checks pod-level security contexts and capabilities.

Full explanation →
60
MCQhard

Developer A runs 'cosign verify --key cosign.pub myregistry/myimage:tag' and receives an error: 'No signatures found'. Developer B previously ran 'cosign sign --key cosign.key myregistry/myimage:tag'. What is the most likely cause of the verification failure?

A.The image tag does not exist in the registry
B.The signing command failed to push the signature to the registry
C.Developer B used a different private key to sign than the public key used for verification
D.Developer A used the public key instead of the private key
AnswerB

Cosign signing computes a signature over the image digest and pushes it as a separate OCI artifact (typically under a tag like 'sha256-<digest>.sig') to the same registry. If the `cosign sign` command fails during that push—due to missing write permissions, expired credentials, or a network interruption—no signature object is persisted. When verification later queries the registry for that signature tag and finds nothing, it reports 'No signatures found', even though the image itself is perfectly valid. This directly matches the scenario, so it is the correct explanation.

Why this answer

The error 'No signatures found' indicates that the verification process could not locate any signature associated with the image in the registry. Since Developer B attempted to sign the image with 'cosign sign', the most likely cause is that the signing command failed to push the signature artifact (typically stored as a separate tag like 'myimage:sha256-<digest>.sig' in the same registry) to the registry. Without the signature being successfully uploaded, the 'cosign verify' command finds nothing to validate against the provided public key.

Exam trap

The CKS exam often tests the distinction between signature absence (no signatures found) and signature mismatch (invalid signature), where candidates mistakenly think a key mismatch would cause a 'no signatures' error instead of a validation failure.

How to eliminate wrong answers

Option A is wrong because if the image tag did not exist, the error would typically be 'manifest unknown' or a 404 from the registry, not 'No signatures found'. Option C is wrong because if a different private key was used, the verification would fail with a signature mismatch error (e.g., 'invalid signature') rather than a missing signature error. Option D is wrong because 'cosign verify' expects a public key (--key cosign.pub) to verify the signature; using a private key would be a command syntax error, not a 'No signatures found' error.

Full explanation →
61
MCQhard

A cluster administrator wants to run some workloads in a sandboxed environment using gVisor. Which Kubernetes resource must be created first to allow pods to request the gVisor runtime?

A.Create a new PodSecurityPolicy that allows the gVisor runtime
B.Create a custom resource definition for the runtime
C.Create a RuntimeClass resource that specifies the gVisor runtime handler
D.Add a `runtimeClass` field to the pod spec
AnswerC

A RuntimeClass is a cluster-scoped, built-in object whose handler field names the runtime configuration registered on each node, for example ',runsc,' for gVisor. When a pod's spec sets runtimeClassName to reference this object, the kubelet passes the handler to the container runtime (like containerd), which then launches the pod under the gVisor sandbox. Creating this RuntimeClass resource is the mandatory administrative step, as it establishes the mapping between a simple name and the actual OCI runtime handler that workloads will use.

Why this answer

C is correct because in Kubernetes, a RuntimeClass resource must be created to define a container runtime configuration, such as gVisor. This resource specifies a runtime handler (e.g., 'runsc') that the container runtime uses to run pods in a sandboxed environment. Pods can then reference this RuntimeClass via the `runtimeClassName` field in their spec to request the gVisor runtime.

Exam trap

Kubernetes often tests the distinction between creating a resource (RuntimeClass) versus referencing it in a pod spec, so candidates mistakenly think adding the `runtimeClass` field directly to the pod is sufficient without first creating the RuntimeClass object.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in v1.21 and removed in v1.25) controls security context constraints, not runtime selection; it cannot specify which container runtime to use. Option B is wrong because a custom resource definition (CRD) is used to extend the Kubernetes API with new resource types, but RuntimeClass is a built-in API resource (node.k8s.io/v1) that does not require a CRD. Option D is wrong because the `runtimeClass` field in the pod spec is a reference to an existing RuntimeClass object; the RuntimeClass resource must be created first before any pod can use it.

Full explanation →
62
MCQmedium

A pod is scheduled on a node that has AppArmor enabled, and the pod has the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write'. The profile 'deny-write' is loaded. However, the nginx container is able to write to the filesystem. What is the most likely issue?

A.The container is privileged
B.The profile was loaded in complain mode using apparmor_parser with the -C flag
C.The pod's securityContext sets allowPrivilegeEscalation to true
D.The annotation is incorrectly formatted
AnswerB

AppArmor profiles have two modes: enforce and complain. The `apparmor_parser` with `-C` (or `--complain`) loads the profile into complain mode, where violations are logged via audit but not blocked. If a pod's profile was loaded in complain mode, the kernel allows the denied operations while recording them, so the pod appears to run without AppArmor enforcement even though the profile is actively attached. This precisely matches the symptom: the profile is loaded but not enforcing.

Why this answer

The most likely issue is that the AppArmor profile 'deny-write' was loaded in complain mode using the `apparmor_parser` with the `-C` flag. In complain mode, AppArmor logs policy violations but does not enforce them, allowing the container to write to the filesystem despite the profile being applied. The annotation is correctly formatted, and the profile is loaded, so enforcement depends on the mode.

Exam trap

CNCF often tests the distinction between enforce and complain modes in AppArmor, where candidates assume a loaded profile is always enforced, but the `-C` flag changes behavior to logging-only.

How to eliminate wrong answers

Option A is wrong because a privileged container would bypass AppArmor entirely, but the question states the profile is loaded and the annotation is set, so the issue is about enforcement mode, not privilege. Option C is wrong because `allowPrivilegeEscalation` controls whether processes can gain more privileges than their parent, but it does not affect AppArmor profile enforcement; AppArmor enforces regardless of privilege escalation settings. Option D is wrong because the annotation 'container.apparmor.security.beta.kubernetes.io/nginx: localhost/deny-write' is correctly formatted per Kubernetes conventions, using the profile name prefixed with 'localhost/'.

Full explanation →
63
MCQmedium

You run 'kubectl auth can-i --list --as=system:serviceaccount:kube-system:my-sa' and see that my-sa has cluster-admin access. What is the BEST way to reduce privileges?

A.Delete the service account and create a new one
B.Delete the ClusterRoleBinding that grants cluster-admin to the service account
C.Create a new RoleBinding with fewer privileges in the kube-system namespace
D.Modify the ClusterRole 'cluster-admin' to have fewer permissions
AnswerB

This is the correct remediation because it directly removes the ClusterRoleBinding that links the service account subject to the cluster-admin ClusterRole, thereby revoking all cluster-wide administrative permissions. You should first confirm the exact binding with `kubectl get clusterrolebinding -o yaml | grep <serviceaccount-name>` and then delete it; afterwards, `kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<name>` should show no dangerous permissions.

Why this answer

The service account 'my-sa' has cluster-admin privileges due to a ClusterRoleBinding that binds it to the 'cluster-admin' ClusterRole. Deleting that specific ClusterRoleBinding removes the excessive permissions without affecting other subjects or the underlying ClusterRole, which is shared and may be needed by other users or components. This is the most targeted and least disruptive approach to reduce privileges.

Exam trap

CNCF often tests the misconception that modifying a ClusterRole or recreating a service account is sufficient to revoke privileges, when in reality the binding is the source of the permission grant and must be removed directly.

How to eliminate wrong answers

Option A is wrong because deleting and recreating the service account does not remove the existing ClusterRoleBinding; the new service account would still be bound to the same ClusterRoleBinding and retain cluster-admin access. Option C is wrong because creating a new RoleBinding with fewer privileges in the kube-system namespace does not revoke the existing ClusterRoleBinding; the service account would still have cluster-admin access from the binding, and RoleBindings are namespace-scoped and cannot override a ClusterRoleBinding. Option D is wrong because modifying the 'cluster-admin' ClusterRole would affect all subjects bound to it, including other service accounts and users, potentially breaking critical system components that rely on its permissions.

Full explanation →
64
MCQeasy

To disable service account token automount for a pod, which field should be set to false in the pod spec?

A.automountServiceAccountToken
B.serviceAccountToken
C.automountToken
D.enableServiceAccountToken
AnswerA

This boolean field in a Pod spec controls whether the kubelet automatically injects the service account token into the pod. Setting it to false disables the default automounting behavior, which is a recommended security practice for workloads that don't need to call the Kubernetes API. This field can also be set on a ServiceAccount to apply cluster-wide, but the pod-level setting takes precedence.

Why this answer

In Kubernetes, the `automountServiceAccountToken` field in the Pod spec, when set to `false`, prevents the automatic mounting of the service account token (a JWT) into the pod's containers. This is a security hardening measure to reduce the attack surface, as the token could be used to authenticate to the Kubernetes API server if compromised. The default behavior is `true`, meaning the token is automatically mounted unless explicitly disabled.

Exam trap

The trap here is that candidates confuse the Pod spec field name with the ServiceAccount-level field or invent plausible-sounding names like `automountToken` or `enableServiceAccountToken`, while the exact API field is `automountServiceAccountToken`.

How to eliminate wrong answers

Option B is wrong because `serviceAccountToken` is not a valid field in the Pod spec; the correct field is `automountServiceAccountToken`. Option C is wrong because `automountToken` is not a recognized Kubernetes field; the exact API field name is `automountServiceAccountToken`. Option D is wrong because `enableServiceAccountToken` does not exist in the Pod spec; the field to disable automount is `automountServiceAccountToken`, not an enable/disable toggle.

Full explanation →
65
MCQmedium

During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes?

A.kubectl logs <pod-name>
B.kubectl exec <pod-name> -- ps aux
C.kubectl top pod <pod-name>
D.kubectl describe pod <pod-name>
AnswerB

Correct. `kubectl exec <pod-name> -- ps aux` executes the `ps aux` command inside the container, displaying all active processes. This is the appropriate kubectl command to check for a reverse shell without requiring node-level access.

Why this answer

`kubectl exec <pod-name> -- ps aux` runs the `ps aux` command inside the container, which lists running processes. It is the only kubectl command that allows you to inspect container processes. Options A, C, and D do not provide process listings.

Exam trap

The exam may test that `kubectl exec` is the kubectl command used to run commands inside a container, enabling process inspection.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` only retrieves the container's stdout/stderr logs, not a list of running processes; it cannot reveal a reverse shell that may not produce log output. Option C is wrong because `kubectl top pod` shows CPU and memory usage metrics for the pod, not process listings; it cannot identify specific processes like a reverse shell. Option D is wrong because `kubectl describe pod` provides metadata, events, and configuration details about the pod, not the container's running processes; it cannot inspect runtime process activity.

Full explanation →
66
MCQmedium

A developer wants to create a Deployment that runs as a non-root user. Which YAML snippet correctly sets the security context to run the container with UID 1000?

A.spec.containers[].securityContext.runAsUser: 0
B.spec.containers[].securityContext.runAsNonRoot: true
C.spec.containers[].securityContext.runAsGroup: 1000
D.spec.containers[].securityContext.runAsUser: 1000
AnswerD

Setting spec.containers[].securityContext.runAsUser: 1000 explicitly forces the container's main process to run with UID 1000, which is a standard non-root user. This overrides any default user in the image and ensures the process is not run as root. It is the direct, concrete way to satisfy the developer's requirement, and it also works in conjunction with pod-level settings.

Why this answer

`securityContext.runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This is the direct way to enforce a specific UID in Kubernetes, meeting the developer's requirement to run as a non-root user.

Exam trap

Candidates often confuse `runAsUser` (sets the UID) with `runAsGroup` (sets the GID) or with `runAsNonRoot: true` (which only ensures the container does not run as root, but does not set a specific UID). The question explicitly asks to run with UID 1000, so `runAsUser: 1000` is required.

How to eliminate wrong answers

Option A is wrong because `runAsUser: 0` sets the container to run as root (UID 0), which is the opposite of the non-root requirement. Option B is wrong because `runAsNonRoot: true` only prevents the container from running as root but does not specify a particular UID; it relies on the container image's default user, which may not be UID 1000. Option C is wrong because `runAsGroup: 1000` sets the group ID, not the user ID, so it does not control which user runs the container process.

Full explanation →
67
MCQmedium

A node in your cluster is running unnecessary services that increase the attack surface. Which of the following is the BEST approach to reduce the attack surface on the node?

A.Use a firewall to block all ports except those required
B.Apply a NetworkPolicy to block traffic to the node
C.Identify and disable unnecessary system services using systemctl or similar tools
D.Use AppArmor to confine the services
AnswerC

Disabling and removing unnecessary services with systemctl --now disable and optionally masking their unit files stops the running process and prevents it from starting at boot, eliminating the attack vector at the source. This follows the least functionality principle, which is the correct remediation for unnecessary services. It also frees system resources and reduces the surface available to an attacker who has achieved code execution on the node. For a Kubernetes node, keep only required services such as containerd, kubelet, kube-proxy, and necessary system utilities.

Why this answer

The most direct way to reduce the attack surface on a node is to disable unnecessary services that are actively listening or running. Tools like `systemctl disable` or `systemctl stop` permanently turn off services such as `telnet`, `rpcbind`, or `cups`, which are common vectors for exploitation. Simply blocking ports with a firewall (A) leaves the service running and potentially exploitable via localhost or if the firewall is misconfigured, while AppArmor (D) confines but does not remove the service.

NetworkPolicies (B) operate at the Kubernetes network layer and cannot control host-level services.

Exam trap

A common mistake in the CKS exam is to focus on network-level controls (firewall, NetworkPolicy) or confinement (AppArmor) rather than disabling the unnecessary service directly. The key is that disabling the service removes the attack surface entirely, whereas blocking or confining still leaves the service running and potentially exploitable through other means.

How to eliminate wrong answers

Option A is wrong because a firewall only blocks network access to ports but does not stop the underlying service from running; the service remains active and could be exploited locally or if the firewall rule is bypassed. Option B is wrong because a NetworkPolicy is a Kubernetes resource that controls pod-to-pod traffic within the cluster and has no effect on host-level services running directly on the node. Option D is wrong because AppArmor provides mandatory access control to confine a service's capabilities, but it does not disable or remove the service, so the attack surface from the service's existence and potential vulnerabilities remains.

Full explanation →
68
Matchingmedium

Match each etcd security configuration to its description.

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

Concepts
Matches

Encrypts communication between etcd clients and the etcd server

Encrypts communication between etcd cluster members

Requires clients to present a valid certificate to access etcd

Encrypts etcd data stored on disk (requires manual configuration)

Limits which users or clients can perform operations on etcd keys

Why these pairings

In this matching exercise, each etcd security configuration should be paired with its correct description. Common confusions arise between client-to-server TLS and peer-to-peer TLS due to similar wording. Client-to-server TLS secures communication between clients and the cluster, while peer-to-peer TLS secures inter-member communication.

Client certificate authentication and RBAC are distinct security features.

Full explanation →
69
Multi-Selectmedium

Which TWO of the following are valid audit stages in Kubernetes? (Select 2)

Select 2 answers
A.RequestEvaluated
B.All of the above
C.ResponseStarted
D.RequestReceived
E.ResponseSent
AnswersC, D

ResponseStarted is a valid audit stage that is recorded when the HTTP response headers are sent by the kube-apiserver to the client. This stage fires before the response body is fully transmitted, making it useful for observing when a request has begun to be served, especially for long-running or streaming requests.

Why this answer

`ResponseStarted` is a valid Kubernetes audit stage that occurs when the audit handler starts sending the response to the client. This stage is part of the audit event lifecycle defined in the Kubernetes API server, capturing the moment the response headers are sent but before the body is fully transmitted.

Exam trap

The CKS exam often tests the exact naming of audit stages, and the trap here is that candidates confuse `ResponseStarted` with `ResponseSent` or invent stages like `RequestEvaluated`, which sound plausible but are not defined in the Kubernetes audit specification.

Full explanation →
70
MCQhard

After setting up etcd encryption at rest using EncryptionConfiguration with aescbc, which resource stores the encryption key?

A.A ConfigMap in the etcd namespace
B.A Secret in the kube-system namespace
C.The EncryptionConfiguration file itself
D.An annotation on the etcd pod
AnswerC

The correct answer is the EncryptionConfiguration file itself: this YAML file contains a 'keys' list, and each key entry includes a 'secret' field with the actual encryption key material. The file is passed to the kube-apiserver using the --encryption-provider-config flag, and the API server uses those keys to encrypt data written to etcd and decrypt data read from etcd. Because the file holds the keys in plaintext, it must be protected with restrictive filesystem permissions and is typically mounted from a secure location; any rotation requires editing this file and restarting the API server. This is the only mechanism Kubernetes uses for encryption-at-rest key delivery.

Why this answer

When etcd encryption at rest is configured via an EncryptionConfiguration file, the encryption key is defined within that file itself under the 'keys' field for the specified provider (e.g., aescbc). The EncryptionConfiguration file is passed to the kube-apiserver via the --encryption-provider-config flag, and the key material is read from this file at startup. No separate Secret or ConfigMap stores the key; the file is the authoritative source.

Exam trap

The trap here is that candidates assume encryption keys must be stored in a Kubernetes Secret (like other secrets in kube-system), but the EncryptionConfiguration file itself is the sole storage for the key material, and it is not managed as a Kubernetes resource.

How to eliminate wrong answers

Option A is wrong because there is no 'etcd' namespace in Kubernetes; etcd runs as a static pod or systemd service, and ConfigMaps are not used to store encryption keys for etcd. Option B is wrong because while Secrets in kube-system store sensitive data like service account tokens, the etcd encryption key is not stored as a Kubernetes Secret; it resides in the EncryptionConfiguration file. Option D is wrong because annotations on the etcd pod are metadata only and cannot store the encryption key; the key is not injected via annotations.

Full explanation →
71
MCQmedium

Which of the following is a static analysis tool for Kubernetes manifests that can be used to find misconfigurations?

A.Trivy
B.Kubesec
C.Syft
D.Cosign
AnswerB

Kubesec parses Kubernetes manifests statically and scores them against security checks such as privileged containers, host mounts and missing resource limits. This satisfies the stem's requirement for a static manifest analysis tool without needing a running cluster.

Why this answer

Kubesec is a static analysis tool specifically designed to evaluate Kubernetes manifests against a set of built-in security policies. It scans YAML or JSON resource definitions and assigns a risk score based on misconfigurations such as running containers as root, missing resource limits, or insecure capability assignments. This makes it the correct choice for identifying misconfigurations in Kubernetes manifests without executing them.

Exam trap

The CKS exam often tests the distinction between tools that scan container images (like Trivy) versus tools that scan Kubernetes manifest files (like Kubesec), causing candidates to confuse vulnerability scanning with static configuration analysis.

How to eliminate wrong answers

Option A is wrong because Trivy is primarily a vulnerability scanner for container images, filesystems, and Git repositories, not a static analysis tool for Kubernetes manifests. Option C is wrong because Syft is a software bill of materials (SBOM) generator that produces a list of packages and dependencies from container images or filesystems, not a Kubernetes manifest scanner. Option D is wrong because Cosign is a tool for signing and verifying container images and blobs using cryptographic signatures, not for static analysis of Kubernetes manifests.

Full explanation →
72
MCQmedium

What is the correct way to specify a container image using a SHA digest instead of a tag for immutable deployments?

A.image: myapp:latest
B.image: myapp:stable
C.image: myapp@sha256:abc123...
D.image: myapp:1.0.0
AnswerC

The digest (in the format sha256:...) is a cryptographic hash of the image manifest, making it a content-addressed identifier. Pulling by digest always fetches the exact same image, regardless of any tag changes, thereby ensuring reproducibility and supply-chain integrity. This is the correct way to specify an immutable container image reference.

Why this answer

Using the `@sha256:` syntax pins the container image to an immutable content digest, ensuring that every pull returns the exact same image regardless of tag updates. This eliminates the risk of tag mutability, where a tag like `latest` can be overwritten with a different image, breaking supply chain integrity and reproducibility.

Exam trap

The exam often tests the misconception that version tags (e.g., `1.0.0`) are immutable, but the trap here is that tags are mutable by default and only a digest reference provides cryptographic immutability for supply chain security.

How to eliminate wrong answers

Option A is wrong because `myapp:latest` is a mutable tag that can be overwritten at any time, violating the principle of immutable deployments and introducing supply chain risks. Option B is wrong because `myapp:stable` is also a mutable tag, subject to the same overwrite risk as `latest`, and provides no cryptographic guarantee of image identity. Option D is wrong because `myapp:1.0.0` is a version tag that, while more stable than `latest`, can still be reassigned or deleted by a registry, and does not provide content-addressable immutability like a SHA digest does.

Full explanation →
73
MCQeasy

What is the purpose of using a non-root user in a container image?

A.To reduce the attack surface and limit potential damage if the container is compromised
B.To improve performance
C.To comply with Kubernetes requirements
D.To allow the container to bind to privileged ports
AnswerA

Running as non-root removes the container's default privileged UID 0, so a process escaping the application cannot write to root-owned paths or perform privileged kernel operations. This limits blast radius if compromised, satisfying the stem's damage-limitation requirement.

Why this answer

Running containers as a non-root user reduces the attack surface by ensuring that even if an attacker exploits a vulnerability in the application, they do not gain root privileges inside the container. This limits the potential damage, such as modifying system binaries, escaping the container via kernel exploits, or accessing host resources. In Kubernetes, this is enforced by setting `securityContext.runAsNonRoot: true` or specifying a non-root user in the Dockerfile with `USER` directive.

Exam trap

CKS often tests the misconception that Kubernetes mandates non-root containers, but the trap is that it is a security best practice, not a hard requirement, and the default behavior is to run as root unless explicitly configured.

How to eliminate wrong answers

Option B is wrong because using a non-root user does not improve performance; performance is primarily affected by resource limits, CPU/memory allocation, and kernel scheduling, not the user ID. Option C is wrong because Kubernetes does not require containers to run as non-root; it is a best practice for security, but the default is to run as root unless explicitly configured. Option D is wrong because binding to privileged ports (ports below 1024) requires the `CAP_NET_BIND_SERVICE` capability or root privileges, and a non-root user cannot bind to these ports without additional capabilities or host-level configuration.

Full explanation →
74
Multi-Selectmedium

Which TWO of the following are required to enable encryption of Kubernetes Secrets at rest?

Select 2 answers
A.Configure etcd encryption via etcdctl
B.Create an EncryptionConfiguration resource
C.Enable the --feature-gates=EncryptionAtRest=true flag on the API server
D.Pass the --encryption-provider-config flag to the kube-apiserver
AnswersB, D

The EncryptionConfiguration manifest defines which resources are encrypted and names the provider (for example aescbc or kms). The API server reads this file to know what to encrypt, making its creation a prerequisite before any flag can reference it.

Why this answer

Option B is correct because enabling encryption at rest for Kubernetes Secrets requires creating an EncryptionConfiguration resource, a YAML file that defines the encryption providers (such as aescbc, aesgcm, or secretbox) and their key material used to encrypt resources like secrets in etcd. Option D is correct because the kube-apiserver must be started with the --encryption-provider-config flag pointing to that EncryptionConfiguration file; without this flag the API server ignores the configuration and writes Secrets to etcd in plaintext. Option A is incorrect because etcdctl is only an administrative CLI for interacting with etcd (for example, verifying that stored values are prefixed with k8s:enc:), not a mechanism for configuring encryption.

Option C is incorrect because EncryptionAtRest is not a feature gate that must be enabled; the feature is controlled entirely by the --encryption-provider-config flag and the EncryptionConfiguration resource, so no such --feature-gates flag exists or is needed.

Exam trap

The CNCF CKS exam often tests the misconception that encryption at rest is enabled via a feature gate or etcdctl, when in fact it requires creating an EncryptionConfiguration resource and passing it via the --encryption-provider-config flag to the kube-apiserver.

Full explanation →
75
MCQmedium

An operator must upgrade a kubeadm cluster and wants to verify that the new control plane binaries are authentic before installing them. The team already has the Kubernetes release signing key. Which step confirms the integrity and origin of the downloaded binary?

A.Run openssl dgst -sha256 on the binary and confirm it matches the checksum file downloaded from the same server.
B.Import the release key into kubeadm's trust store and let kubeadm verify binaries automatically during upgrade.
C.Compare the SHA-512 hash of the binary against the value published in the release notes, then install it.
D.Verify the detached signature over the checksum file with the release signing key, then confirm the binary's hash matches the signed checksum.
AnswerD

Signing the checksum file and verifying that signature with the trusted release key establishes origin, and matching the binary's hash to the signed checksum establishes integrity. This two-step chain is exactly what the Kubernetes release process publishes and is the recommended verification for downloaded artifacts before installing them on control plane nodes.

Why this answer

The Kubernetes release process publishes a checksum file and a detached signature over that file. Verifying the signature with the trusted release key proves the checksum file is authentic, and matching the binary's hash to the signed checksum proves the binary itself is intact. Hash comparisons alone or checksums fetched from the same origin do not establish origin, and kubeadm does not verify binaries automatically.

Exam trap

The trap here is treating a SHA-512 hash comparison as sufficient provenance verification, when a signed checksum verified with the release key is what actually binds the artifact to the project.

Full explanation →

Page 1 of 12

Page 2

All pages

123456789101112

Practice CKS by domain

Target a specific domain to shore up weak areas.

Minimize Microservice VulnerabilitiesSupply Chain SecurityMonitoring, Logging and Runtime SecuritySystem HardeningCluster SetupCluster Hardening
See all domains with question counts →