Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 76150

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

Page 1

Page 2 of 12

Page 3
76
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.

77
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 runAsUser at the container level ensures the container runs with that UID.

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.

78
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 reduces the attack surface directly.

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.

79
MCQeasy

Which of the following is the correct way to drop all capabilities from a container in a pod specification?

A.securityContext: dropCapabilities: ALL
B.securityContext: capabilities: drop: ALL
C.securityContext: capabilities: drop: ["all"]
D.securityContext: capabilities: remove: ALL
AnswerB

Correct: 'drop: ALL' drops all capabilities.

Why this answer

In Kubernetes, to drop all capabilities from a container, you must set `capabilities.drop` to `ALL` under the `securityContext`. The `capabilities` field is a standard part of the container's security context, and `drop` is the correct key to specify capabilities to remove. Using `ALL` (uppercase) ensures all capabilities defined by the Linux kernel (e.g., CAP_NET_RAW, CAP_SYS_ADMIN) are dropped, which is a best practice for minimizing privilege escalation risks.

Exam trap

CNCF often tests the distinction between the correct `capabilities.drop` field and common misspellings like `dropCapabilities` or `remove`, and the requirement for uppercase `ALL` versus lowercase `all`.

How to eliminate wrong answers

Option A is wrong because `dropCapabilities` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option C is wrong because it uses lowercase `"all"` instead of uppercase `ALL`; Kubernetes expects the string `ALL` in uppercase to match the Linux capability naming convention. Option D is wrong because `remove` is not a valid key under `capabilities`; the correct key is `drop`.

80
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.

81
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, logged when the response headers are sent.

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.

82
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 encryption key is defined in the EncryptionConfiguration YAML file under the 'keys' section. This file is passed to the API server via --encryption-provider-config.

Why this answer

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

Exam trap

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

How to eliminate wrong answers

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

83
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 scans Kubernetes manifests for security issues.

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.

84
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 uniquely identifies the image content.

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.

85
MCQhard

You are tasked with reducing the attack surface on a Kubernetes node. Which of the following actions is LEAST effective for hardening the node itself?

A.Restrict SSH access to the node using firewall rules
B.Disable unnecessary system services (e.g., telnet, rsh) on the node
C.Drop the NET_RAW capability from all containers running on the node
D.Apply the latest security patches to the host kernel
AnswerC

This is a container-level hardening measure. While beneficial, it does not directly harden the node itself.

Why this answer

The least effective for hardening the node itself because dropping NET_RAW from containers is a container-level security control (e.g., via Pod Security Standards or seccomp), not a node-level hardening measure. Node hardening focuses on the host OS and Kubernetes components, not container capabilities. While it reduces attack surface for containers, it does not directly secure the node's kernel, services, or network access.

Exam trap

The trap here is that candidates confuse container-level security controls (like dropping capabilities) with node-level hardening, assuming any security measure applied to containers also hardens the underlying node, when in fact node hardening requires direct OS and infrastructure changes.

How to eliminate wrong answers

Option A is wrong because restricting SSH access via firewall rules directly reduces the node's network attack surface by limiting administrative access, which is a fundamental node hardening practice. Option B is wrong because disabling unnecessary services like telnet and rsh eliminates legacy, unencrypted protocols that could be exploited to compromise the node, making it a critical hardening step. Option D is wrong because applying the latest security patches to the host kernel addresses known vulnerabilities in the node's core operating system, which is essential for node-level security.

86
MCQmedium

You are implementing supply chain security for container images. Which tool would you use to scan a local directory of Dockerfiles and Kubernetes manifests for known vulnerabilities?

A.kubectl scan
B.syft
C.cosign sign
D.trivy fs
AnswerD

`trivy fs` scans a local directory for vulnerabilities, including those in Dockerfiles (via base image references) and Kubernetes manifests (via configuration analysis). It is the correct tool for this task.

Why this answer

D is correct because `trivy fs` scans a local filesystem (including directories containing Dockerfiles and Kubernetes manifests) for known vulnerabilities. It parses these files, checks base images against vulnerability databases, and detects misconfigurations or CVEs. This tool is designed for supply chain security, covering both package vulnerabilities and infrastructure-as-code issues.

The `fs` subcommand of trivy combines filesystem scanning with configuration analysis, making it suitable for the stated task.

Exam trap

The trap is that candidates might think `trivy fs` only scans packages, but it can also scan configuration files like Dockerfiles and Kubernetes manifests for vulnerabilities. The exam tests the understanding that `trivy` is a multi-purpose tool, and `fs` is the appropriate subcommand for local directory scanning, not just `trivy image`.

How to eliminate wrong answers

Option A is wrong because `kubectl scan` is not a valid kubectl subcommand; kubectl does not have a built-in vulnerability scanning feature. Option B is wrong because `syft` generates a Software Bill of Materials (SBOM) from container images or filesystems but does not scan for known vulnerabilities; it catalogs packages but lacks a vulnerability database. Option C is wrong because `cosign sign` is used for signing container images to ensure integrity and provenance, not for scanning local directories for vulnerabilities.

87
MCQeasy

Which admission controller is responsible for validating and mutating requests based on webhooks?

A.ServiceAccount
B.PodSecurityPolicy
C.NodeRestriction
D.ValidatingAdmissionWebhook and MutatingAdmissionWebhook
AnswerD

These admission controllers enable custom webhooks for validation and mutation.

Why this answer

The ValidatingAdmissionWebhook and MutatingAdmissionWebhook admission controllers are specifically designed to intercept admission requests and call external webhooks to validate or mutate the request. MutatingAdmissionWebhook can modify the object (e.g., inject sidecar containers) before it is persisted, while ValidatingAdmissionWebhook only validates and can reject the request. These controllers are the only ones that delegate admission decisions to external HTTP callbacks.

Exam trap

The exam often tests the distinction between built-in admission controllers (like PodSecurityPolicy or ServiceAccount) and webhook-based controllers, expecting candidates to know that only ValidatingAdmissionWebhook and MutatingAdmissionWebhook rely on external HTTP callbacks.

How to eliminate wrong answers

Option A is wrong because the ServiceAccount admission controller is responsible for automating the creation and binding of service accounts to pods, not for webhook-based validation or mutation. Option B is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforced security constraints on pod specifications via an internal admission plugin, not via external webhooks. Option C is wrong because the NodeRestriction admission controller limits the Node API access of kubelets, preventing them from modifying other nodes or secrets; it does not involve webhooks.

88
MCQmedium

Which etcd security measure should be implemented to ensure only authorized clients can access the etcd cluster?

A.Enable anonymous authentication on etcd
B.Configure etcd to listen on localhost only
C.Enable TLS client-to-server authentication
D.Use etcd RBAC with role-based access control
AnswerC

TLS ensures that only clients presenting valid certificates can connect to etcd.

Why this answer

Enabling TLS client-to-server authentication (mutual TLS) ensures that only clients presenting a valid certificate signed by a trusted Certificate Authority (CA) can communicate with the etcd cluster. This cryptographically verifies the client's identity, preventing unauthorized access and man-in-the-middle attacks. Without client certificate validation, any client with network access could potentially interact with etcd, compromising the Kubernetes control plane.

Exam trap

CNCF often tests the distinction between authentication (verifying identity) and authorization (controlling actions), so candidates may mistakenly choose RBAC (Option D) thinking it controls access, when in fact TLS client authentication is the prerequisite for ensuring only authorized clients can connect.

How to eliminate wrong answers

Option A is wrong because enabling anonymous authentication on etcd would allow unauthenticated clients to access the cluster, directly contradicting the requirement to restrict access to authorized clients only. Option B is wrong because configuring etcd to listen on localhost only restricts network access to the local machine, which is impractical for a multi-node etcd cluster and does not provide authentication or authorization for clients that do have access. Option D is wrong because etcd RBAC (role-based access control) controls what operations an authenticated user can perform, but it does not authenticate the client itself; without TLS client authentication, an attacker could still connect and attempt to exploit RBAC misconfigurations.

89
Multi-Selectmedium

Which TWO of the following are recommended CIS benchmark practices for securing etcd? (Choose two.)

Select 2 answers
A.Use TLS certificates for client-to-server communication
B.Run etcd as root user
C.Disable authentication for etcd to reduce latency
D.Enable encryption at rest
E.Expose etcd to the public internet for easier management
AnswersA, D

CIS recommends using TLS to secure communication between the API server and etcd.

Why this answer

The CIS benchmark for etcd recommends using TLS certificates for client-to-server communication to ensure data in transit is encrypted and authenticated. This prevents man-in-the-middle attacks and unauthorized access to the etcd cluster, which stores critical cluster state and secrets.

Exam trap

CNCF often tests the misconception that disabling authentication reduces latency and is acceptable for performance, but the CIS benchmark explicitly requires authentication and encryption for all etcd communication, and candidates may overlook the security implications of running etcd as root or exposing it publicly.

90
MCQhard

An administrator needs to encrypt secrets at rest in etcd. Which of the following steps is required?

A.Use kubectl encrypt secrets command.
B.Modify the etcd configuration to enable encryption.
C.Create an EncryptionConfiguration resource and pass it to the kube-apiserver via the --encryption-provider-config flag.
D.Set the environment variable ENCRYPT_SECRETS=true on all nodes.
AnswerC

EncryptionConfiguration is a resource that defines how to encrypt data at rest. The kube-apiserver reads it via the flag.

Why this answer

Kubernetes does not have a native `kubectl encrypt secrets` command, and etcd itself does not handle encryption configuration directly. Instead, encryption at rest is configured by creating an `EncryptionConfiguration` YAML resource that defines providers (e.g., `aescbc`, `secretbox`) and passing it to the `kube-apiserver` via the `--encryption-provider-config` flag. The API server then transparently encrypts secrets before writing them to etcd and decrypts them on read.

Exam trap

The CKS exam often tests the misconception that encryption at rest is configured directly on etcd or via an environment variable, when in fact it is a kube-apiserver configuration that intercepts writes to etcd.

How to eliminate wrong answers

Option A is wrong because `kubectl encrypt secrets` is not a valid kubectl command; encryption is handled server-side by the API server, not by the client. Option B is wrong because etcd does not have a configuration option to encrypt secrets at rest; encryption is enforced by the API server, which writes encrypted data to etcd. Option D is wrong because there is no `ENCRYPT_SECRETS` environment variable in Kubernetes; encryption is configured declaratively via the `EncryptionConfiguration` resource and the API server flag.

91
MCQmedium

To enforce Pod Security Standards at the namespace level, which admission plugin must be enabled on the API server?

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

This plugin enforces Pod Security Standards.

Why this answer

Pod Security Standards (PSS) are enforced at the namespace level using the PodSecurity admission plugin, which was introduced in Kubernetes v1.23 and graduated to stable in v1.25. This plugin evaluates pods against the predefined security levels (privileged, baseline, restricted) based on labels on the namespace, replacing the deprecated PodSecurityPolicy.

Exam trap

CNCF often tests the distinction between the deprecated PodSecurityPolicy (PSP) and the current PodSecurity admission plugin, leading candidates to mistakenly select PSP because they recall 'Pod Security' in the name, but PSP is no longer available in recent Kubernetes versions.

How to eliminate wrong answers

Option A is wrong because SecurityContextDeny is a deprecated admission plugin that only rejects pods with specific security context settings (like privileged containers) but does not implement the three-tier Pod Security Standards. Option B is wrong because NodeRestriction is an admission plugin that limits the kubelet's ability to modify node and pod objects, not related to enforcing pod security policies. Option C is wrong because PodSecurityPolicy (PSP) is a deprecated admission plugin that was removed in Kubernetes v1.25; it enforced security policies at the cluster level via PSP resources, not at the namespace level using Pod Security Standards.

92
MCQmedium

A security policy requires that all containers in the 'staging' namespace drop all Linux capabilities and only add the necessary ones. Which pod security context configuration achieves this?

A.capabilities.drop: ["ALL"] capabilities.add: ["NET_BIND_SERVICE"]
B.cap_drop: ["NET_RAW"]
C.cap_add: ["ALL"]
D.cap_add: ["NET_BIND_SERVICE"]
AnswerA

Correct. It drops all capabilities and adds only the needed one.

Why this answer

It drops all Linux capabilities using `capabilities.drop: ["ALL"]` and then explicitly adds only the necessary `NET_BIND_SERVICE` capability via `capabilities.add: ["NET_BIND_SERVICE"]`. This adheres to the principle of least privilege by starting from a clean slate and granting only the required capability. In Kubernetes security contexts, the correct keys are `capabilities.drop` and `capabilities.add` under the `securityContext` field.

Options B and D partially meet the requirement but do not drop all capabilities; Option C adds all capabilities, violating the policy.

Exam trap

CNCF often tests the misconception that simply adding a capability is sufficient, without realizing that the default capability set includes many capabilities (e.g., `CHOWN`, `DAC_OVERRIDE`, `FOWNER`, `FSETID`, `KILL`, `SETGID`, `SETUID`, `SETPCAP`, `NET_BIND_SERVICE`, `NET_RAW`, `SYS_CHROOT`, `MKNOD`, `AUDIT_WRITE`, `SETFCAP`) and that dropping all first is mandatory to enforce least privilege.

How to eliminate wrong answers

Option B is wrong because `cap_drop: ["NET_RAW"]` only drops the `CAP_NET_RAW` capability, leaving all other capabilities intact, which violates the requirement to drop all capabilities first. Option C is wrong because `cap_add: ["ALL"]` adds every capability, which is the opposite of dropping all capabilities and contradicts the security policy. Option D is wrong because `cap_add: ["NET_BIND_SERVICE"]` without a preceding `cap_drop: ["ALL"]` only adds the capability on top of the default set, which still includes many unnecessary capabilities, failing to meet the 'drop all' requirement.

93
Multi-Selectmedium

Which THREE of the following are recommended practices for securing container images in a Kubernetes environment?

Select 3 answers
A.Scan images for vulnerabilities before deployment
B.Store sensitive configuration data directly in the image
C.Use imagePullSecrets to authenticate to private container registries
D.Use minimal base images like distroless or scratch
E.Run containers as root to avoid permission issues
AnswersA, C, D

Identifies known CVEs.

Why this answer

Scanning container images for vulnerabilities before deployment is a fundamental security practice in Kubernetes environments. Tools like Trivy, Clair, or Anchore Grype can identify known CVEs in the base image and application dependencies, allowing teams to remediate issues before the image is run. This aligns with the principle of shifting security left and is a key requirement for compliance with standards like the NIST Application Container Security Guide.

Option C is correct because using imagePullSecrets is a recommended practice to authenticate to private container registries. While imagePullSecrets do not enforce access control policies on which images can be pulled, they securely store credentials and enable pods to pull images from private registries, which is essential for using images that are not publicly accessible. This prevents unauthorized access to private images and reduces the risk of using compromised public images.

Option D is correct because using minimal base images such as distroless or scratch reduces the attack surface by eliminating unnecessary packages, libraries, and utilities. This aligns with the principle of least functionality and minimizes the number of potential vulnerabilities that could be exploited.

Exam trap

CNCF often tests the misconception that imagePullSecrets (Option C) are used to restrict which images can be pulled from registries, but in reality, imagePullSecrets only authenticate to private registries and do not enforce any access control or policy on which images are allowed to be pulled; for restriction, you need an admission controller like OPA/Gatekeeper or a registry firewall.

94
Multi-Selecthard

Which TWO of the following are correct ways to apply a seccomp profile named 'audit.json' located on each node? (Select two.)

Select 2 answers
A.Add annotation: seccomp.security.alpha.kubernetes.io/pod: audit.json
B.Add annotation per container: container.seccomp.security.alpha.kubernetes.io/<name>: localhost/audit.json
C.Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.localhostProfile: audit.json
D.Add annotation: seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json
E.Set securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json
AnswersC, D

This is the current recommended way.

Why this answer

In Kubernetes v1.19+, the `securityContext.seccompProfile` field is the stable API for configuring seccomp profiles. Setting `type: Localhost` and `localhostProfile: audit.json` instructs the kubelet to load the profile from the node's local seccomp directory (typically `/var/lib/kubelet/seccomp/audit.json`). This is the recommended approach for applying a node-local seccomp profile to a pod or container.

Exam trap

CNCF often tests the distinction between the deprecated alpha annotation format (which requires the `localhost/` prefix in the value) and the stable `securityContext.seccompProfile` API, and candidates mistakenly omit the `localhost/` prefix in the annotation value or confuse the field names `localhostProfile` vs `profile`.

95
MCQmedium

A development team uses a custom container image for their application, built from a base image that includes multiple CVEs. The security team requires that no container runs with known critical vulnerabilities. Which approach best ensures that only images with no critical vulnerabilities are deployed in production?

A.Configure a Kubernetes admission controller (e.g., Kyverno) to reject pods using images with critical vulnerabilities.
B.Scan the base image before building the application image.
C.Integrate an image scanner (e.g., Trivy) into the CI/CD pipeline to block builds with critical vulnerabilities.
D.Manually review vulnerability reports after the image is deployed.
AnswerC

Scans the final image and prevents vulnerable images from being pushed to the registry.

Why this answer

Integrating an image scanner like Trivy into the CI/CD pipeline ensures that any image with critical vulnerabilities is blocked before it is even built or pushed to a registry. This shift-left approach prevents vulnerable images from ever reaching the production environment, aligning with the security team's requirement to deploy only images with no critical vulnerabilities.

Exam trap

CNCF often tests the distinction between shift-left security (preventing vulnerabilities at build time) versus runtime enforcement (admission controllers), and the trap here is that candidates choose admission controllers (Option A) because they seem to block vulnerable images, but they fail to realize that the image must already exist in the registry and may have been built with vulnerabilities, whereas CI/CD scanning prevents the image from being created in the first place.

How to eliminate wrong answers

Option A is wrong because a Kubernetes admission controller like Kyverno can only reject pods at deployment time, but the image may already be in the registry with known CVEs, and the admission controller relies on metadata or external scans that may not be up-to-date; it also does not prevent the image from being built or stored. Option B is wrong because scanning only the base image before building the application image does not account for vulnerabilities introduced by the application layer or dependencies added during the build process, leaving the final image potentially vulnerable. Option D is wrong because manually reviewing vulnerability reports after deployment is reactive and does not prevent vulnerable images from running in production, violating the requirement to ensure no container runs with critical vulnerabilities.

96
MCQhard

A pod is using a custom seccomp profile stored at /var/lib/kubelet/seccomp/custom-profile.json. Which securityContext configuration correctly references this profile?

A.seccompProfile: type: Unconfined localhostProfile: "custom-profile.json"
B.seccompProfile: type: RuntimeDefault localhostProfile: "custom-profile.json"
C.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/custom-profile.json"
D.seccompProfile: type: Localhost localhostProfile: "custom-profile.json"
AnswerD

Correct. The profile is assumed to be in /var/lib/kubelet/seccomp/.

Why this answer

When using a custom seccomp profile stored in the default kubelet seccomp directory (`/var/lib/kubelet/seccomp/`), the `type` must be `Localhost` and the `localhostProfile` must be a relative path (just the filename). Kubernetes automatically prepends the default seccomp root path, so `custom-profile.json` resolves to `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the misconception that `localhostProfile` requires an absolute path, but the correct syntax is a relative path (just the filename) when the profile resides in the default kubelet seccomp directory.

How to eliminate wrong answers

Option A is wrong because `type: Unconfined` disables seccomp entirely and ignores any `localhostProfile` value. Option B is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile, not a custom one, and `localhostProfile` is ignored when type is not `Localhost`. Option C is wrong because `localhostProfile` must be a relative path (just the filename) when the profile is in the default kubelet seccomp directory; an absolute path like `/var/lib/kubelet/seccomp/custom-profile.json` is not valid in this context.

97
Multi-Selectmedium

Which TWO of the following are valid ways to enforce that a container runs as a non-root user?

Select 2 answers
A.Set the container image to use a root user
B.Set runAsNonRoot: true in the pod securityContext
C.Use a PodSecurityPolicy (PSP)
D.Use a Kyverno policy to validate runAsNonRoot
E.Set runAsUser: 0 in the container securityContext
AnswersB, D

This enforces that the container cannot run as root.

Why this answer

Setting `runAsNonRoot: true` in the pod's `securityContext` explicitly instructs the kubelet to validate that the container's user ID is not 0 (root) before starting the container. If the container attempts to run as root, the kubelet will refuse to start it, providing a strong enforcement mechanism at the Kubernetes level.

Exam trap

The CKS exam often tests the misconception that PodSecurityPolicy (PSP) is still a valid option, but it has been removed since Kubernetes v1.25, so candidates must know that Kyverno or OPA/Gatekeeper policies are the modern replacements for enforcing non-root execution.

98
MCQmedium

You have a requirement to encrypt secrets at rest in etcd. Which resource and apiVersion should be used?

A.EtcdEncryption with apiVersion apiserver.config.k8s.io/v1beta1
B.EncryptionConfig with apiVersion v1
C.SecretEncryption with apiVersion v1
D.EncryptionConfiguration with apiVersion apiserver.config.k8s.io/v1
AnswerD

This is the correct resource for configuring encryption at rest.

Why this answer

The Kubernetes API server uses an `EncryptionConfiguration` resource with `apiVersion apiserver.config.k8s.io/v1` to define how secrets and other resources are encrypted at rest in etcd. This resource specifies providers (e.g., `aescbc`, `secretbox`) and keys, and is loaded via the `--encryption-provider-config` flag on the API server. The `v1` version is the stable, production-ready API version for this configuration.

Exam trap

CNCF often tests the exact resource name and API group, and the trap here is that candidates confuse `EncryptionConfiguration` with made-up names like `EtcdEncryption` or `SecretEncryption`, or incorrectly assume it belongs to the core `v1` API group instead of `apiserver.config.k8s.io`.

How to eliminate wrong answers

Option A is wrong because `EtcdEncryption` is not a valid Kubernetes resource; the correct resource is `EncryptionConfiguration`. Option B is wrong because `EncryptionConfig` with `apiVersion v1` does not exist; the resource is `EncryptionConfiguration` under `apiserver.config.k8s.io`, not core `v1`. Option C is wrong because `SecretEncryption` is not a real resource; Kubernetes uses `EncryptionConfiguration` to configure encryption at rest, not a resource named after the object type.

99
MCQhard

You are tasked with securing a Kubernetes cluster. You want to ensure that the kubelet only serves APIs that are explicitly allowed and that it does not allow anonymous requests. Which kubelet configuration flags should you set?

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

Disables anonymous auth and uses webhook authorization.

Why this answer

Setting `--anonymous-auth=false` disables anonymous requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server), allowing fine-grained control over which APIs the kubelet serves. This combination ensures that only authenticated, authorized requests are processed, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates confuse kubelet authorization modes with API server authorization modes, mistakenly selecting `RBAC` (Option A) which is not a valid kubelet flag, while overlooking that `Webhook` is the correct mode to enforce RBAC-like policies on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=RBAC` is not a valid kubelet flag; the kubelet supports `AlwaysAllow`, `Webhook`, and `ABAC` modes, but RBAC is an API server authorization mode, not a kubelet one. Option B is wrong because `--anonymous-auth=true` allows anonymous requests, which contradicts the requirement to disallow them, and `--authorization-mode=ABAC` is deprecated and less secure than Webhook for dynamic authorization. Option C is wrong because `--authorization-mode=AlwaysAllow` permits all authenticated requests without any authorization checks, failing to restrict APIs to only those explicitly allowed.

100
MCQeasy

An admin wants to check which AppArmor profiles are loaded. Which command should they run?

A.apparmor list
B.aa-status
C.seccomp-status
D.ls /sys/kernel/security/apparmor/profiles
AnswerB

aa-status displays loaded profiles and their modes.

Why this answer

The `aa-status` command is the standard tool for displaying the status of AppArmor, including which profiles are loaded, their enforcement mode (enforce/complain), and process confinement. It queries the AppArmor security module directly via the kernel interface, making it the correct and most comprehensive command for this task.

Exam trap

A common trap is that candidates may think the profiles are listed via a filesystem path or confuse AppArmor with seccomp, which is another Linux security module used in Kubernetes for restricting syscalls. However, `aa-status` is the proper command for AppArmor profile status, and it is often used on Kubernetes nodes to verify profile loading.

How to eliminate wrong answers

Option A is wrong because `apparmor list` is not a valid command; AppArmor does not provide a `list` subcommand. Option C is wrong because `seccomp-status` is not a real command; seccomp (secure computing mode) is a separate Linux kernel feature for syscall filtering, and its status is checked via `/proc/sys/kernel/seccomp/` or `seccomp-tools`, not this command. Option D is wrong because while `ls /sys/kernel/security/apparmor/profiles` does list the profile names as files, it only shows the names and not the full status (e.g., mode, process association), and is not the standard admin command; `aa-status` is the intended tool.

101
MCQhard

A security team wants to enforce that no container in the 'restricted' namespace runs with added Linux capabilities beyond the default set (according to the restricted Pod Security Standard). Which PodSecurityConfiguration should be applied to the namespace?

A.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "restricted" enforce-version: "latest"
B.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: warn: "restricted" warn-version: "latest"
C.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "privileged" enforce-version: "latest"
D.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "baseline" enforce-version: "latest"
AnswerA

This configuration enforces the restricted profile, which drops all capabilities except the minimal default set.

Why this answer

The 'restricted' Pod Security Standard (PSS) is the most stringent profile, which enforces that no container runs with added Linux capabilities beyond the default set (e.g., dropping all capabilities except those required by the runtime). The 'enforce' mode blocks non-compliant pods from being created, and 'enforce-version: latest' applies the most current version of the restricted profile, ensuring that any new restrictions are automatically enforced.

Exam trap

The trap here is that candidates often confuse the 'baseline' profile with 'restricted', thinking baseline is sufficient to block added capabilities, but baseline explicitly allows a set of capabilities (e.g., CHOWN, DAC_OVERRIDE) that are not permitted under the restricted standard.

How to eliminate wrong answers

Option B is wrong because it uses 'warn' mode, which only generates a warning but does not block non-compliant pods; the question requires enforcement (blocking) of the restricted profile. Option C is wrong because it uses the 'privileged' profile, which allows all capabilities and is the opposite of the required restriction. Option D is wrong because it uses the 'baseline' profile, which allows a minimal set of capabilities beyond the default (e.g., NET_RAW, CHOWN) and does not enforce the stricter 'restricted' standard that drops all non-default capabilities.

102
MCQmedium

Which command can be used to check if the API server has anonymous authentication enabled?

A.kubectl get clusterrole cluster-admin -o yaml
B.kubectl describe pod kube-apiserver -n kube-system | grep anonymous-auth
C.kubectl get node -o yaml
D.kubectl auth can-i --list --as=system:anonymous
AnswerB

This shows the kube-apiserver's flags including anonymous-auth.

Why this answer

The kube-apiserver pod's manifest (or its runtime configuration) contains the `--anonymous-auth` flag. By inspecting the pod's YAML with `kubectl describe pod kube-apiserver -n kube-system` and grepping for `anonymous-auth`, you can see whether the flag is set to `true` (enabled) or `false` (disabled). This is the direct way to check the API server's runtime configuration for anonymous authentication.

Exam trap

CNCF often tests the misconception that RBAC commands (like `kubectl auth can-i`) can detect server-level flags, when in fact they only test authorization after authentication has already succeeded, making them useless for checking if anonymous auth is enabled.

How to eliminate wrong answers

Option A is wrong because `kubectl get clusterrole cluster-admin -o yaml` shows the permissions of the `cluster-admin` ClusterRole, which has no bearing on whether the API server accepts anonymous requests; anonymous authentication is a server-level flag, not a RBAC setting. Option C is wrong because `kubectl get node -o yaml` displays node metadata and status, which contains no information about the API server's authentication configuration. Option D is wrong because `kubectl auth can-i --list --as=system:anonymous` checks what actions the `system:anonymous` user can perform *after* authentication, but it does not reveal whether anonymous authentication is enabled; if anonymous auth is disabled, the command would fail with an authentication error, but the command itself does not inspect the server's flag.

103
MCQmedium

An administrator runs 'kubectl describe nodes' and notices that the node status shows 'Ready,SchedulingDisabled'. What is the most likely cause?

A.The kubelet is not running
B.The node was cordoned using 'kubectl cordon <node>'
C.The node has insufficient resources
D.The node is tainted with NoSchedule
AnswerB

Cordoning a node marks it as unschedulable, resulting in SchedulingDisabled.

Why this answer

The 'Ready,SchedulingDisabled' status indicates that the node is marked as unschedulable for new pods while remaining fully operational. This is exactly what happens when an administrator runs 'kubectl cordon <node>', which sets the node's 'spec.unschedulable' field to true. The kubelet continues to run and report readiness, but the scheduler will skip the node when placing new pods.

Exam trap

CNCF often tests the distinction between taints (which affect scheduling based on tolerations) and cordoning (which makes the node completely unschedulable), leading candidates to confuse taint-based scheduling restrictions with the explicit unschedulable flag.

How to eliminate wrong answers

Option A is wrong because if the kubelet were not running, the node status would be 'NotReady' or 'Unknown', not 'Ready,SchedulingDisabled'. Option C is wrong because insufficient resources would cause the node to report conditions like 'MemoryPressure' or 'DiskPressure', not the specific 'SchedulingDisabled' marker. Option D is wrong because a NoSchedule taint prevents pod scheduling via the scheduler's taint-toleration mechanism, but the node status would still show 'Ready' without the 'SchedulingDisabled' suffix; the node remains schedulable for pods that tolerate the taint.

104
MCQmedium

A security team wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?

A.Configure CRI-O to log all container process starts to syslog.
B.Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.
C.Enable Kubernetes audit logging and parse the logs for process events.
D.Use OPA Gatekeeper to enforce allowed process lists in pod specs.
AnswerB

Falco on the host can detect container process anomalies without modifying images.

Why this answer

Falco, deployed as a DaemonSet with an eBPF probe, can monitor system calls at the kernel level without modifying container images or requiring agents inside containers. This allows it to detect anomalous process executions in real time by analyzing syscall events from the host, which is the most suitable approach for runtime security monitoring in Kubernetes.

Exam trap

CNCF often tests the distinction between admission control (e.g., OPA Gatekeeper) and runtime monitoring (e.g., Falco), where candidates mistakenly choose a policy enforcement tool for detection tasks.

How to eliminate wrong answers

Option A is wrong because CRI-O does not natively log all container process starts to syslog; it manages container runtime operations but lacks built-in process-level auditing. Option C is wrong because Kubernetes audit logging captures API server requests (e.g., pod creation), not process executions within containers, so it cannot detect anomalous process starts. Option D is wrong because OPA Gatekeeper enforces admission control policies on pod specs (e.g., allowed process lists) but does not monitor runtime behavior or detect anomalies after a container is running.

105
MCQeasy

Which admission plugin should be enabled on the kubelet to ensure it only registers nodes and sets labels as allowed by the Node REST API?

A.PodSecurity
B.NodeRestriction
C.DenyEscalatingExec
D.AlwaysPullImages
AnswerB

NodeRestriction limits the kubelet's self-modification capabilities, enhancing security.

Why this answer

The NodeRestriction admission plugin is the correct choice because it limits the kubelet's ability to modify node and pod labels, ensuring that nodes can only register themselves and set labels that are explicitly allowed by the Node REST API. This plugin enforces a whitelist of labels that the kubelet can set, preventing privilege escalation through label manipulation.

Exam trap

CNCF often tests the NodeRestriction plugin by pairing it with other admission controllers like PodSecurity or AlwaysPullImages, leading candidates to confuse node-level restrictions with pod-level security policies.

How to eliminate wrong answers

Option A is wrong because PodSecurity is an admission plugin that enforces Pod Security Standards (e.g., privileged, baseline, restricted) on pods, not node registration or label restrictions. Option C is wrong because DenyEscalatingExec is a deprecated admission plugin that prevents exec and attach commands to pods with escalated privileges, unrelated to node registration. Option D is wrong because AlwaysPullImages forces every pod to pull container images with the specified pull policy, which does not control node registration or label setting.

106
MCQhard

A pod has been compromised. You want to isolate it from other pods while preserving its network state for forensics. Which NetworkPolicy rule achieves this?

A.Deny all ingress and egress traffic to/from the pod's namespace
B.Create a NetworkPolicy with podSelector matching the compromised pod and empty ingress/egress rules (deny all)
C.Add a label to the pod and create a NetworkPolicy allowing only traffic from a forensic pod
D.Delete the pod
AnswerB

This denies all traffic to/from that specific pod.

Why this answer

A NetworkPolicy with a `podSelector` matching the compromised pod and empty `ingress` and `egress` rules (i.e., no rules specified) defaults to denying all traffic to and from that pod. This isolates the pod from all other pods in the cluster while preserving its network state for forensics, as the pod remains running and its network interfaces are untouched.

Exam trap

The trap here is that candidates often think a NetworkPolicy must explicitly specify `deny all` rules, but Kubernetes uses an implicit deny when the `ingress` or `egress` arrays are empty, which is a subtle but critical distinction tested in the CKS exam.

How to eliminate wrong answers

Option A is wrong because denying all ingress and egress traffic to/from the pod's namespace would affect all pods in that namespace, not just the compromised one, and does not isolate the specific pod while preserving its network state. Option C is wrong because adding a label and creating a NetworkPolicy that allows only traffic from a forensic pod would still permit egress traffic from the compromised pod unless explicitly denied, and it does not achieve full isolation. Option D is wrong because deleting the pod destroys its network state and prevents forensic analysis of its runtime behavior.

107
Multi-Selecthard

Which THREE of the following are correct statements about seccomp in Kubernetes? (Select 3)

Select 3 answers
A.Seccomp can be configured using the securityContext.seccompProfile field
B.Seccomp profiles can only be applied to privileged containers
C.The RuntimeDefault seccomp profile uses the container runtime's default profile
D.Seccomp can only restrict system calls, not allow them
E.Custom seccomp profiles must be placed in /var/lib/kubelet/seccomp/ on the node
AnswersA, C, E

Correct. seccompProfile is used in the security context.

Why this answer

The `securityContext.seccompProfile` field in a Pod or container spec allows you to configure seccomp profiles directly in the Kubernetes API. This field supports values like `RuntimeDefault`, `Localhost`, and `Unconfined`, enabling fine-grained control over system call filtering without requiring manual profile loading on the node.

Exam trap

CNCF often tests the misconception that seccomp only applies to privileged containers or that it can only deny syscalls, when in fact it is a general-purpose syscall filter for all containers and supports both allow and deny actions.

108
Multi-Selectmedium

Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)

Select 2 answers
A.evt.type
B.k8s.ns.name
C.proc.pname
D.container.id
E.proc.name
AnswersC, E

Parent process name; shell often spawned by another process.

Why this answer

Falco's 'proc.name' matches the process name (e.g., bash, sh). 'container.id' identifies the container. 'evt.type' is for syscall type, not process name. 'k8s.ns.name' is namespace, not shell detection. 'fd.name' is file path.

109
MCQmedium

Which tool can generate an SBOM for a container image?

A.Trivy
B.Cosign
C.Kubescape
D.Syft
AnswerD

Syft generates SBOMs from container images.

Why this answer

Syft is a CLI tool specifically designed to generate a Software Bill of Materials (SBOM) for container images and filesystems. It scans the image layers and package managers (e.g., APT, RPM, pip, npm) to produce an SBOM in formats like CycloneDX or SPDX, directly addressing the question's requirement.

Exam trap

The trap here is that candidates confuse Trivy (a vulnerability scanner that can also output SBOMs) with Syft (a dedicated SBOM generator), but the CKS exam expects you to know the primary purpose of each tool in the CNCF supply chain security toolkit.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability scanner that can output SBOMs as a secondary feature, but its primary purpose is security scanning, not SBOM generation; the question asks for a tool that 'can generate an SBOM', and while Trivy can, Syft is the dedicated SBOM tool. Option B is wrong because Cosign is used for signing and verifying container images and attestations, not for generating SBOMs. Option C is wrong because Kubescape is a Kubernetes security scanner that checks cluster configurations and compliance, not a tool for generating SBOMs from container images.

110
MCQeasy

Which of the following is a BEST practice for securing container images in a Dockerfile?

A.Use the USER directive to specify a non-root user
B.Store secrets in environment variables in the image
C.Run the container as root to simplify permission management
D.Use the 'latest' tag to always get the newest base image
AnswerA

This follows the principle of least privilege.

Why this answer

The USER directive in a Dockerfile sets the user for the container process, and using a non-root user (e.g., USER 1000) follows the principle of least privilege. This reduces the attack surface by preventing an attacker who gains code execution from having root access to the host or container, which is a critical security requirement for containerized workloads.

Exam trap

The CKS exam often tests the misconception that running as root is acceptable if you drop capabilities or use a read-only filesystem, but it emphasizes that a non-root user is a fundamental defense-in-depth layer that must be explicitly set in the Dockerfile.

How to eliminate wrong answers

Option B is wrong because storing secrets in environment variables in the image embeds them in the image layers, making them accessible via `docker history` or image inspection, and they persist even if the container is restarted — this violates secret management best practices (use secrets mounts or external vaults instead). Option C is wrong because running as root inside the container grants unnecessary privileges; if the container is compromised, the attacker gains root access to the container and potentially to the host via kernel vulnerabilities or misconfigured capabilities. Option D is wrong because using the 'latest' tag introduces unpredictability and breaks reproducibility; the base image can change without notice, potentially introducing vulnerabilities or breaking changes — always pin to a specific digest or version tag.

111
MCQmedium

An administrator wants to enforce mTLS between all services in the 'mesh' namespace using Istio. Which resource should be applied to require mutual TLS for all workloads in that namespace?

A.PeerAuthentication with mtls.mode: STRICT in the namespace
B.VirtualService with tls mode
C.DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL
D.ServiceEntry for external services
AnswerA

PeerAuthentication with mtls.mode: STRICT enforces mTLS for all services in the namespace.

Why this answer

PeerAuthentication defines the authentication policy for workloads within a namespace. Setting `mtls.mode: STRICT` in a PeerAuthentication resource for the 'mesh' namespace enforces that all services in that namespace require mutual TLS for incoming traffic, ensuring that only authenticated and encrypted connections are accepted. This is the correct Istio resource to enforce mTLS at the namespace level.

Exam trap

The CKS exam often tests the distinction between PeerAuthentication (server-side enforcement) and DestinationRule (client-side configuration), leading candidates to incorrectly choose DestinationRule for namespace-wide mTLS enforcement.

How to eliminate wrong answers

Option B is wrong because VirtualService is used for traffic routing and management (e.g., canary deployments, A/B testing), not for enforcing mTLS authentication policies. Option C is wrong because DestinationRule with `trafficPolicy.tls.mode: ISTIO_MUTUAL` configures the client side to use mTLS when sending traffic to a specific service, but it does not enforce mTLS on the server side for all workloads in the namespace; it is a per-service or per-host policy, not a namespace-wide enforcement. Option D is wrong because ServiceEntry is used to register external services (outside the mesh) into the Istio service registry, enabling traffic management and mTLS to those external endpoints, but it does not enforce mTLS for internal services within the namespace.

112
MCQeasy

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

A.cosign verify <image>
B.cosign attest <image>
C.cosign sign <image>
D.cosign generate <image>
AnswerC

Correct command to sign an image.

Why this answer

The `cosign sign <image>` command is used to sign a container image by attaching a digital signature to the image manifest in the container registry. This signature, typically stored as a separate tag or in an OCI artifact, allows verification of the image's origin and integrity using the corresponding public key.

Exam trap

The trap for CKS candidates is confusing the `cosign sign` command with `cosign attest` or `cosign verify`. Signing creates a signature artifact attached to the image, attestation adds a signed in-toto statement, and verification validates signatures. In the context of container supply chain security as tested on the CKS exam, understanding this distinction is key.

How to eliminate wrong answers

Option A is wrong because `cosign verify <image>` is used to verify an existing signature on an image, not to create one. Option B is wrong because `cosign attest <image>` creates an in-toto attestation (a signed statement about the image's build process or metadata), not a simple signature on the image itself. Option D is wrong because `cosign generate <image>` is not a valid command; the correct command for generating a key pair is `cosign generate-key-pair`, and `cosign generate` does not exist.

113
MCQmedium

An administrator wants to enforce that all pods in a namespace use the restricted Pod Security Standard. Which of the following commands correctly enables this enforcement?

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

Correct. This label enforces the restricted Pod Security Standard at the namespace level.

Why this answer

The Pod Security Standards are enforced via labels on the namespace, and the `pod-security.kubernetes.io/enforce` label with value `restricted` tells the Pod Security Admission controller to reject any pod that violates the restricted policy. This is the only way to actively block non-compliant pods from being created in the namespace.

Exam trap

CNCF often tests the distinction between labels and annotations, and the trap here is that candidates confuse `kubectl annotate` with `kubectl label` for setting Pod Security Standard enforcement, or they pick `audit` or `warn` thinking they enforce the policy.

How to eliminate wrong answers

Option A is wrong because `pod-security.kubernetes.io/audit` only logs violations without blocking them, so it does not enforce the policy. Option B is wrong because Pod Security Standards use labels, not annotations; the `pod-security.kubernetes.io/enforce` key must be applied as a label for the admission controller to recognize it. Option D is wrong because `pod-security.kubernetes.io/warn` only generates a warning message for the user but still allows the pod to be created, so it does not enforce the restricted standard.

114
Multi-Selectmedium

Which TWO of the following are valid methods to apply a seccomp profile to a container? (Select 2 correct answers)

Select 2 answers
A.Setting securityContext.seLinuxOptions.type
B.Using the seccomp.security.alpha.kubernetes.io/pod annotation
C.Using the container.apparmor.security.beta.kubernetes.io annotation
D.Using the seccomp.security.beta.kubernetes.io/pod annotation
E.Setting securityContext.seccompProfile.type
AnswersB, E

This is a deprecated method but still valid in older clusters.

Why this answer

The `seccomp.security.alpha.kubernetes.io/pod` annotation was the original method to apply a seccomp profile to a pod in Kubernetes versions prior to v1.19. This annotation allows you to specify a seccomp profile path (e.g., 'localhost/my-profile') or a runtime default ('runtime/default') directly on the pod, which then applies to all containers in the pod. Option E is correct because `securityContext.seccompProfile.type` is the current, stable API field (GA since v1.19) that sets the seccomp profile at the container or pod level, accepting values like 'RuntimeDefault', 'Localhost', or 'Unconfined'.

Exam trap

Kubernetes often tests the distinction between alpha (`seccomp.security.alpha.kubernetes.io/pod`) and beta (`seccomp.security.beta.kubernetes.io/pod`) annotations, where the beta version never existed for seccomp, causing candidates to confuse it with the AppArmor beta annotation pattern.

115
MCQhard

You need to encrypt Kubernetes secrets at rest using aescbc. Which YAML snippet defines the EncryptionConfiguration correctly?

A.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw== - identity: {}
B.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: my-plain-text-key
C.apiVersion: v1 kind: EncryptionConfig resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==
D.apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration resources: - resources: - secrets providers: - secretbox: keys: - name: key1 secret: c2VjcmV0LWtleS0zMi1ieXRlcw==
AnswerA

Correct structure with aescbc and identity fallback.

Why this answer

It defines an EncryptionConfiguration with the correct apiVersion (apiserver.config.k8s.io/v1), kind (EncryptionConfiguration), and a valid provider list. It uses the aescbc provider with a base64-encoded key (c2VjcmV0LWtleS0zMi1ieXRlcw==) for encrypting secrets, and includes the identity provider as a fallback to allow reading existing unencrypted data. This configuration ensures that secrets are encrypted at rest using AES-CBC with a properly encoded 32-byte key.

Exam trap

CNCF often tests the requirement that the aescbc provider's secret must be base64-encoded (not plain text) and that the correct apiVersion/kind must be used, leading candidates to pick options with plain-text keys or wrong resource types.

How to eliminate wrong answers

Option B is wrong because the secret value for the aescbc provider must be base64-encoded, not a plain-text key like 'my-plain-text-key'; Kubernetes expects the key to be base64-decoded to obtain the raw 32-byte key for AES-CBC. Option C is wrong because it uses an incorrect apiVersion 'v1' and kind 'EncryptionConfig' — the correct apiVersion is 'apiserver.config.k8s.io/v1' and kind is 'EncryptionConfiguration'. Option D is wrong because it uses the 'secretbox' provider, which implements XSalsa20-Poly1305 encryption, not AES-CBC; the question specifically requires aescbc.

116
MCQhard

An administrator runs 'kubectl describe pod secure-pod' and sees that the pod is in a Pending state with the event 'Error: ImagePullBackOff' and the message 'unauthorized: authentication required'. The image is stored in a private registry. What is the most likely cause?

A.Missing imagePullSecret in the pod spec or in the namespace's default service account
B.The registry requires TLS 1.3 but the kubelet uses TLS 1.2
C.The image tag is misspelled
D.The registry hostname is not resolvable
AnswerA

The error indicates authentication failure. Creating an imagePullSecret with valid registry credentials and adding it to the pod spec resolves the issue.

Why this answer

The error 'unauthorized: authentication required' indicates that the kubelet cannot authenticate to the private registry. Kubernetes requires an imagePullSecret, which contains registry credentials (typically a Docker config JSON), to be attached either directly to the pod spec or to the namespace's default service account. Without this secret, the kubelet cannot pull the image, resulting in the ImagePullBackOff state.

Exam trap

The CKS exam often tests the distinction between authentication failures (ImagePullBackOff with 'unauthorized') and other pull errors (e.g., DNS, TLS, or image name issues), so candidates must recognize that 'authentication required' points specifically to missing or invalid registry credentials.

How to eliminate wrong answers

Option B is wrong because TLS version mismatch (e.g., kubelet using TLS 1.2 vs registry requiring TLS 1.3) would cause a TLS handshake failure, not an 'unauthorized: authentication required' message; the error would be something like 'tls: protocol version not supported'. Option C is wrong because a misspelled image tag would produce an 'ImagePullBackOff' with a 'manifest unknown' or 'not found' error, not an authentication error. Option D is wrong because an unresolvable registry hostname would cause a 'dial tcp: lookup' or 'no such host' error, not an authentication failure.

117
MCQhard

A security team wants to ensure that no pod runs with privileged access. They have created a PodSecurityPolicy (PSP) that sets 'privileged: false'. However, a pod with privileged: true still gets created. What is the most likely cause?

A.The user creating the pod does not have a RoleBinding that grants use of the PSP
B.The pod has a higher priority than the PSP
C.The PodSecurityPolicy admission controller is not enabled
D.The PodSecurityPolicy is defined after the pod creation
AnswerA

Without authorization, the PSP does not apply; the user may be using a default PSP that allows privileged.

Why this answer

A is correct because PodSecurityPolicy (PSP) requires the user or service account creating the pod to have a RoleBinding or ClusterRoleBinding that grants the `use` verb on the PSP resource. Without this RBAC authorization, the PSP is not enforced for that user, even if the PSP exists and the admission controller is enabled. The pod with `privileged: true` bypasses the PSP because the creating identity lacks the necessary RBAC permissions to trigger the PSP's validation.

Exam trap

CNCF often tests the misconception that simply creating a PSP is enough to enforce restrictions, but the trap here is that PSP enforcement requires explicit RBAC binding—without it, the PSP is effectively ignored for the pod's creator.

How to eliminate wrong answers

Option B is wrong because pod priority does not override PSP enforcement; PSP is an admission controller that evaluates all pods regardless of priority class. Option C is wrong because if the PodSecurityPolicy admission controller were not enabled, no PSP would be enforced at all, but the question states a PSP was created and the pod still gets created, implying the controller is active (otherwise the PSP would be irrelevant). Option D is wrong because PSPs are cluster-scoped resources evaluated at pod creation time; the order of creation does not affect enforcement—if the PSP exists before the pod creation attempt, it applies.

118
Multi-Selectmedium

Which TWO of the following are valid ways to enforce that containers run with a read-only root filesystem?

Select 2 answers
A.Setting `runAsNonRoot: true` in the pod's securityContext
B.Using an emptyDir volume mounted at /
C.Setting `fsGroup: 1000` in the pod's securityContext
D.Using a MutatingWebhookConfiguration that adds `readOnlyRootFilesystem: true` to all containers
E.Setting `readOnlyRootFilesystem: true` in the container's securityContext
AnswersD, E

A mutating webhook can automatically inject the setting.

Why this answer

A MutatingWebhookConfiguration can intercept Pod creation requests and automatically add the `readOnlyRootFilesystem: true` field to every container's securityContext, enforcing a read-only root filesystem without requiring manual changes to Pod specs. Option E is correct because setting `readOnlyRootFilesystem: true` directly in the container's securityContext is the explicit Kubernetes API field that makes the container's root filesystem read-only, preventing writes to the filesystem layer.

Exam trap

The CKS exam often tests the distinction between Pod-level and container-level securityContext fields, and candidates may incorrectly assume that Pod-level settings like `runAsNonRoot` or `fsGroup` affect the root filesystem's write permissions, when only the container-level `readOnlyRootFilesystem` field (or a mutating webhook) actually enforces that behavior.

119
MCQmedium

An administrator runs 'kubectl run test-pod --image=nginx --dry-run=client -o yaml > pod.yaml', then adds 'hostPID: true' and 'hostNetwork: true' to the pod's spec. After applying with 'kubectl apply -f pod.yaml', the pod is created but immediately goes into 'CrashLoopBackOff'. What is the likely cause?

A.The container is missing a memory limit and gets OOMKilled
B.The namespace has a PodSecurity enforce level that restricts hostPID and hostNetwork
C.The 'hostPID' and 'hostNetwork' fields cannot be combined
D.The pod lacks the necessary Linux capabilities
AnswerD

When using hostNetwork, the container must have the necessary Linux capabilities (such as NET_BIND_SERVICE) to bind to privileged ports like 80. Without these capabilities, nginx fails to start, leading to CrashLoopBackOff.

Why this answer

The pod is created but enters CrashLoopBackOff because nginx requires certain Linux capabilities (e.g., NET_BIND_SERVICE) to bind to port 80 on the host network, which are not granted by default. The combination of hostPID and hostNetwork does not cause immediate rejection, but the container fails at runtime due to insufficient privileges.

Exam trap

A common misconception is that hostPID and hostNetwork cause the pod to be rejected by admission controllers. In reality, without specific PodSecurity policies restricting their usage, the pod is created successfully, but the nginx container crashes when it cannot bind to privileged ports without the proper capabilities.

How to eliminate wrong answers

Option A is wrong because OOMKilled occurs when a container exceeds its memory limit, but the question states the pod goes into CrashLoopBackOff immediately, and no memory limit was set; the default behavior without limits is to allow unlimited memory unless a LimitRange exists, which is not mentioned. Option C is wrong because `hostPID` and `hostNetwork` can be combined in a pod spec; there is no Kubernetes restriction preventing their simultaneous use, and they are independent fields. Option D is wrong because Linux capabilities are not required for `hostPID` or `hostNetwork`; these settings grant host-level access directly, and the pod fails due to security policy enforcement, not missing capabilities.

120
MCQmedium

You need to create a NetworkPolicy that allows only ingress traffic from pods with label 'app: frontend' in the same namespace. Which policyType and ingress rule should you use?

A.policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: app: frontend
B.policyTypes: [Ingress] ingress: - from: - podSelector: {}
C.policyTypes: [Ingress] ingress: - from: - namespaceSelector: {}
D.policyTypes: [Egress]
AnswerA

Correct: This restricts ingress to pods with label app: frontend.

Why this answer

A NetworkPolicy that restricts ingress traffic to only pods with the label 'app: frontend' in the same namespace must use `policyTypes: [Ingress]` and an `ingress` rule with a `podSelector` that matches that label. The `podSelector` without a `namespaceSelector` implicitly selects pods only within the same namespace as the NetworkPolicy, which satisfies the requirement.

Exam trap

The trap here is that candidates often confuse `podSelector: {}` (which allows all pods in the namespace) with `podSelector` with specific labels, or they incorrectly add a `namespaceSelector` when the requirement explicitly says 'same namespace'.

How to eliminate wrong answers

Option B is wrong because `podSelector: {}` selects all pods in the namespace, which would allow ingress from any pod, not just those with label 'app: frontend'. Option C is wrong because `namespaceSelector: {}` selects all namespaces, allowing ingress from pods in any namespace, which violates the requirement to restrict to the same namespace. Option D is wrong because `policyTypes: [Egress]` only controls outbound traffic, not ingress traffic, so it cannot satisfy the requirement to allow only ingress traffic.

121
MCQmedium

A security policy requires that all container images must have a signed attestation. Which Cosign command would an admin add to the CI pipeline to create this attestation?

A.cosign verify-attestation <image>
B.cosign sign --key <key> <image>
C.cosign download attestation <image>
D.cosign attest --type custom --predicate <file> <image>
AnswerD

Creates a signed attestation with a predicate.

Why this answer

The `cosign attest` command is specifically designed to create an in-toto attestation for a container image, attaching a signed predicate (e.g., a SLSA provenance file) that satisfies the policy requirement for a signed attestation. The `--type custom` flag allows specifying a custom predicate type, and `--predicate <file>` provides the attestation payload, which is then signed and stored in the image's OCI manifest as an attached attestation.

Exam trap

The CNCF CKS exam often tests the distinction between a simple image signature (`cosign sign`) and an attestation (`cosign attest`), where candidates mistakenly choose `cosign sign` because they think signing alone creates an attestation, but attestation requires a structured predicate and the `--type` flag.

How to eliminate wrong answers

Option A is wrong because `cosign verify-attestation` is used to verify an existing attestation, not to create one. Option B is wrong because `cosign sign --key <key> <image>` creates a simple signature on the image digest, not an attestation (which is a signed statement about the image's provenance or metadata). Option C is wrong because `cosign download attestation` retrieves an existing attestation from the registry, it does not create a new one.

122
MCQhard

An audit policy is configured with the following rule: - level: RequestResponse users: ["system:serviceaccount:kube-system:admin"] verbs: ["get", "list"] resources: - group: "" resources: ["secrets"] What will be logged when the service account 'admin' in kube-system performs a GET request on a Secret?

A.Only the request metadata will be logged
B.Only the response will be logged
C.The request and response metadata and body will be logged
D.Nothing will be logged because the rule uses an empty api group
AnswerC

RequestResponse level logs both the request and the response objects.

Why this answer

The audit rule specifies `level: RequestResponse`, which instructs the API server to log both the request metadata and body, as well as the response metadata and body, for matching events. The rule matches the service account `system:serviceaccount:kube-system:admin` performing a GET on secrets (empty API group matches core API group), so the full request and response payloads are captured.

Exam trap

A common misconception is that an empty API group means 'no group' or 'invalid', but in Kubernetes audit policy, `group: ""` explicitly matches the core API group (e.g., pods, secrets, services), so the rule is valid and will log the event.

How to eliminate wrong answers

Option A is wrong because `RequestResponse` level logs both request and response metadata and body, not just request metadata (that would be `Request` level). Option B is wrong because `RequestResponse` logs both request and response, not only the response (no level logs only response). Option D is wrong because an empty `group: ""` in the resources section matches the core API group (e.g., `/api/v1`), which includes secrets, so the rule applies correctly.

123
MCQhard

A custom seccomp profile is created at /var/lib/kubelet/seccomp/custom-profile.json. Which YAML snippet applies this profile to a container?

A.securityContext: seccompProfile: type: Localhost localhostProfile: custom-profile.json
B.securityContext: seccompProfile: type: Unconfined
C.securityContext: seccompProfile: type: RuntimeDefault localhostProfile: custom-profile.json
D.securityContext: seccomp: profile: custom-profile.json
AnswerA

This correctly references the custom profile.

Why this answer

When using a custom seccomp profile stored on the node, the `type: Localhost` field must be set, and the `localhostProfile` field specifies the filename (relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`). This configuration tells the container runtime to load the profile from the node's filesystem at the path `/var/lib/kubelet/seccomp/custom-profile.json`.

Exam trap

The CKS exam often tests the distinction between the `seccompProfile` field (correct in Kubernetes 1.19+) and the older `seccomp` annotation-based syntax, and candidates mistakenly choose option D because they remember the old annotation format or confuse `profile` with `localhostProfile`.

How to eliminate wrong answers

Option B is wrong because `type: Unconfined` disables seccomp entirely, which does not apply any custom profile and is the opposite of what the question asks. Option C is wrong because `type: RuntimeDefault` uses the container runtime's default seccomp profile, and specifying `localhostProfile` alongside `RuntimeDefault` is invalid; the `localhostProfile` field is only used when `type: Localhost` is set. Option D is wrong because the correct API field is `seccompProfile` (not `seccomp`), and the subfield for the profile name is `localhostProfile` (not `profile`); this syntax is from an older, deprecated API version.

124
MCQhard

A compromised pod is making unexpected outbound connections. You want to isolate the pod by blocking all egress traffic while keeping it running for forensic analysis. Which action is correct?

A.Use kubectl exec to kill the outbound processes inside the container
B.Apply a NetworkPolicy that selects the pod and has no egress rules, effectively blocking all outbound traffic
C.Modify the pod's /etc/hosts to block external IPs
D.Delete the pod and recreate it with a restrictive NetworkPolicy
AnswerB

Correct. A NetworkPolicy with an empty egress list (or egress: []) will deny all egress traffic by default. This isolates the pod while keeping it running.

Why this answer

Applying a NetworkPolicy that denies all egress traffic (with no egress rules specified) while targeting the specific pod via podSelector will isolate the pod by blocking all outbound connections. This allows the pod to remain running for forensic analysis. Option B correctly describes this approach.

125
MCQmedium

You need to enforce that all images deployed in the cluster are signed by a trusted key. Which Kubernetes admission control mechanism would you use?

A.ResourceQuota
B.NetworkPolicy
C.PodSecurityPolicy
D.ImagePolicyWebhook
AnswerD

ImagePolicyWebhook can be configured to verify image signatures by calling an external service.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to enforce that container images are signed by a trusted key. It intercepts Pod creation requests and validates the image signatures against a configured webhook endpoint, rejecting unsigned or untrusted images. This directly addresses the requirement for supply chain security by ensuring only cryptographically verified images are deployed.

Exam trap

The trap here is that candidates may confuse PodSecurityPolicy (which deals with pod security contexts) with image trust enforcement, but PodSecurityPolicy never validates image signatures—it only controls runtime security attributes.

How to eliminate wrong answers

Option A is wrong because ResourceQuota is used to limit resource consumption (CPU, memory, storage) per namespace, not to validate image signatures. Option B is wrong because NetworkPolicy controls pod-to-pod and pod-to-service network traffic using labels and ports, not image signing or trust. Option C is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints like privileged containers, host namespaces, and volume types, but does not validate image signatures or trust.

126
MCQhard

You need to configure a NetworkPolicy that allows egress traffic only to an external database at IP 10.0.0.5 on port 5432, and denies all other egress. Which policy BEST achieves this?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 ports: - port: 5432
B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - podSelector: matchLabels: app: db
C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: []
D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: db-egress spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.0.5/32 ports: - port: 5432
AnswerD

This policy allows egress only to the specified IP and port, and denies all other egress due to default deny.

Why this answer

The correct policy has an egress rule that allows traffic to 10.0.0.5 on port 5432, and no other egress rules, so all other egress is denied by default.

127
Multi-Selecthard

Which THREE of the following are valid methods to disable automount of service account tokens for a pod?

Select 3 answers
A.Set --service-account-issuer flag on API server
B.Set env: - name: KUBERNETES_SERVICE_ACCOUNT_TOKEN to false
C.Set automountServiceAccountToken: false in the ServiceAccount YAML
D.Set spec.automountServiceAccountToken: false in the Pod spec
E.Use the 'default' service account with automount disabled
AnswersC, D, E

Correct service account level setting.

Why this answer

Setting `automountServiceAccountToken: false` in the ServiceAccount YAML disables automatic mounting of the service account token for all pods that use that ServiceAccount. This is a declarative way to prevent the Kubernetes API server from injecting the token volume into pods, which is a key security hardening step to reduce the attack surface from compromised pods.

Exam trap

CNCF often tests the distinction between the Pod spec field (`spec.automountServiceAccountToken`) and the ServiceAccount field, and candidates may incorrectly think that environment variables or API server flags can disable token mounting, when only the `automountServiceAccountToken` boolean field in the Pod or ServiceAccount spec is valid.

128
Multi-Selectmedium

Which TWO of the following are best practices for securing secrets in Kubernetes? (Select 2)

Select 2 answers
A.Use external secret management systems like HashiCorp Vault
B.Mount secrets as volumes instead of environment variables
C.Enable encryption at rest for etcd
D.Set secrets with kubectl create secret generic --from-literal
E.Store secrets in ConfigMaps for easier rotation
AnswersA, B

External secret managers provide better security, auditing, and rotation capabilities.

Why this answer

External secret management systems like HashiCorp Vault decouple secrets from the cluster, providing centralized access control, audit logging, and dynamic secret rotation without storing plaintext secrets in etcd. This aligns with the principle of least privilege and reduces the attack surface by avoiding direct Kubernetes secret storage.

Exam trap

A common pitfall in the CKS exam is confusing 'best practices' with 'acceptable practices' — candidates may incorrectly select encryption at rest (Option C) as a top-two choice because it is a strong security measure, but the question specifically targets microservice vulnerability minimization, where external secret management and secure mounting directly reduce exposure at the application layer.

129
Multi-Selecthard

Which THREE of the following are best practices for Dockerfile security? (Select THREE)

Select 3 answers
A.Install debugging tools like curl and vim in the final image
B.Pin base image versions using SHA256 digests
C.Specify a non-root user with the USER directive
D.Use COPY instead of ADD for copying files
E.Use multi-stage builds to reduce image size
AnswersB, C, E

Pinning base image versions using SHA256 digests ensures that the exact same image is used across builds, preventing unintended changes or vulnerabilities from updated tags.

Why this answer

Pinning base image versions using SHA256 digests ensures immutability and prevents the image from being silently updated to a potentially vulnerable version. Docker image tags (e.g., `ubuntu:latest`) are mutable and can point to different images over time, but a digest (e.g., `ubuntu@sha256:abc123...`) uniquely identifies a specific image manifest, guaranteeing that every build uses the exact same base image. This practice is a key supply chain security control to avoid dependency confusion or accidental inclusion of compromised base images.

Exam trap

The CKS exam often tests the distinction between 'best practices for security' and 'general best practices' — candidates may incorrectly select D (COPY vs ADD) because it is a common recommendation, but the CKS exam specifically focuses on security controls like image integrity (digest pinning), privilege reduction (non-root user), and attack surface minimization (multi-stage builds), not merely build hygiene.

130
MCQmedium

A pod is created with the following security context: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json Where must the 'audit.json' file be placed on the node?

A./etc/kubernetes/seccomp/profiles/audit.json
B./var/lib/kubelet/audit.json
C./var/lib/kubelet/seccomp/profiles/audit.json
D./var/lib/containerd/seccomp/audit.json
AnswerC

This is the default directory for seccomp profiles.

Why this answer

When a pod uses a `seccompProfile` of type `Localhost` with `localhostProfile: profiles/audit.json`, the file path is relative to the kubelet's seccomp root directory, which defaults to `/var/lib/kubelet/seccomp`. Therefore, the complete path on the node must be `/var/lib/kubelet/seccomp/profiles/audit.json`. This is the only location where the kubelet will look for the seccomp profile when `type: Localhost` is specified.

Exam trap

The CNCF CKS exam often tests the default seccomp profile root path (`/var/lib/kubelet/seccomp`) and the fact that `localhostProfile` is relative to that root, not an absolute path or a path under `/etc/kubernetes` or containerd directories.

How to eliminate wrong answers

Option A is wrong because `/etc/kubernetes/seccomp/profiles/audit.json` is not the default root for seccomp profiles; the kubelet uses `/var/lib/kubelet/seccomp` as its base directory. Option B is wrong because `/var/lib/kubelet/audit.json` places the file directly under the kubelet directory, but the seccomp profile must be inside the `seccomp/profiles/` subdirectory relative to the kubelet's seccomp root. Option D is wrong because `/var/lib/containerd/seccomp/audit.json` is a containerd-specific path, not the kubelet's seccomp profile directory; the kubelet does not look for seccomp profiles in containerd's data directory.

131
MCQeasy

Which of the following securityContext settings prevents a container from using host network namespace?

A.hostIPC: false
B.hostNetwork: true
C.hostNetwork: false
D.hostPID: false
AnswerC

Correct. Setting hostNetwork to false (default) prevents use of host network.

Why this answer

Setting `hostNetwork: false` in the Pod's securityContext explicitly prevents the container from using the host's network namespace. When `hostNetwork` is `false` (the default), the container gets its own network stack with its own loopback interface and IP address, isolating it from the host's network interfaces and routing table. This is a fundamental Pod-level security setting to enforce network isolation.

Exam trap

CNCF often tests the distinction between the three namespace-related securityContext fields (`hostNetwork`, `hostIPC`, `hostPID`), and the trap here is that candidates confuse `hostIPC` or `hostPID` with network isolation, assuming any `false` setting prevents host network access.

How to eliminate wrong answers

Option A is wrong because `hostIPC: false` controls access to the host's Inter-Process Communication (IPC) namespace (e.g., shared memory segments), not the network namespace. Option B is wrong because `hostNetwork: true` would actually allow the container to share the host's network namespace, which is the opposite of preventing it. Option D is wrong because `hostPID: false` controls whether the container can see host processes via the PID namespace, not the network namespace.

132
Multi-Selecthard

Which THREE of the following are best practices for securing a Kubernetes cluster using OPA Gatekeeper? (Choose three.)

Select 3 answers
A.Enforce that containers set runAsNonRoot: true.
B.Enforce that containers do not mount hostPath volumes with read-write access.
C.Allow privileged containers for system-critical workloads.
D.Allow containers to use hostNetwork for easier service discovery.
E.Enforce that containers set seccompProfile.type to RuntimeDefault or Localhost.
AnswersA, B, E

This is a common security best practice.

Why this answer

Enforcing `runAsNonRoot: true` via OPA Gatekeeper ensures that containers run with a non-root user ID, mitigating the risk of privilege escalation attacks. This aligns with the Kubernetes Pod Security Standards (PSS) 'restricted' profile and is a key control for minimizing microservice vulnerabilities.

Exam trap

The CKS exam often tests the misconception that privileged containers are acceptable for 'critical' workloads, but the CKS exam expects a zero-trust approach where no containers run privileged, and hostNetwork is restricted to only explicitly authorized system pods.

133
Multi-Selecthard

Which TWO of the following are valid methods to enforce mTLS in an Istio service mesh? (Select 2)

Select 2 answers
A.Create a ServiceEntry for internal services
B.Create a VirtualService with tls termination
C.Create a PeerAuthentication resource with mtls.mode: STRICT
D.Set global.mtls.enabled: true in IstioConfigMap
E.Create a DestinationRule with tls.mode: ISTIO_MUTUAL
AnswersC, E

PeerAuthentication enforces mTLS at the sidecar proxy level.

Why this answer

A PeerAuthentication resource with `mtls.mode: STRICT` enforces mutual TLS at the service-to-service communication level within the Istio mesh. This setting ensures that all traffic between sidecar proxies uses mTLS, rejecting any plaintext connections, which directly minimizes the risk of unauthorized access or eavesdropping.

Exam trap

Candidates often confuse the legacy global settings (like `global.mtls.enabled` in ConfigMap) with the modern, granular Istio security resources (PeerAuthentication and DestinationRule), leading them to mistakenly select the deprecated option D.

134
Drag & Dropmedium

Order the steps to configure and use Falco for runtime security in a Kubernetes cluster.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Falco installation, configuration, deployment as DaemonSet, monitoring alerts, and tuning are the key steps.

135
MCQmedium

A security audit reveals that a service account in the 'default' namespace has been granted cluster-admin privileges via a ClusterRoleBinding. What is the best mitigation?

A.Disable the service account token automount
B.Delete the service account
C.Modify the ClusterRoleBinding to use a less privileged role
D.Set --authorization-mode=AlwaysDeny
AnswerC

The best approach is to follow least-privilege: bind the service account to a role with only the necessary permissions.

Why this answer

The best practice is to apply the principle of least privilege: instead of deleting the service account or disabling its token, you should modify the ClusterRoleBinding to bind the service account to a ClusterRole with only the permissions it actually needs. This retains the service account's functionality while removing excessive cluster-admin privileges, which grant unrestricted access to all cluster resources.

Exam trap

The trap here is that candidates often think disabling the token automount or deleting the service account removes the RBAC permissions, but in reality, the ClusterRoleBinding itself must be updated or deleted to actually revoke the granted privileges.

How to eliminate wrong answers

Option A is wrong because disabling the service account token automount (e.g., via automountServiceAccountToken: false) prevents the token from being mounted into pods, but it does not revoke the already-granted cluster-admin privileges; the ClusterRoleBinding remains in effect. Option B is wrong because deleting the service account removes the identity, but any pods or workloads that depend on it will fail, and the ClusterRoleBinding would become orphaned (pointing to a non-existent subject), which is a disruptive and incomplete fix. Option D is wrong because setting --authorization-mode=AlwaysDeny on the API server would deny all requests cluster-wide, breaking all administrative and workload operations, and is not a targeted mitigation for an over-privileged binding.

136
MCQmedium

You are reviewing RBAC permissions and notice a ClusterRoleBinding that binds the cluster-admin role to a service account in the 'monitoring' namespace. What is the best practice recommendation?

A.Keep the binding as it is required for monitoring
B.Delete the service account
C.Replace cluster-admin with a custom Role granting only necessary permissions
D.Change the binding to a RoleBinding in the monitoring namespace
AnswerC

This follows least-privilege principle.

Why this answer

The principle of least privilege dictates that a service account should only have the permissions necessary for its function. The cluster-admin role grants superuser access across the entire cluster, which is excessive for a monitoring service account. Replacing it with a custom Role that includes only the required API operations (e.g., get, list, watch on pods and nodes) reduces the attack surface and aligns with Kubernetes security best practices.

Exam trap

CNCF often tests the misconception that a RoleBinding can replace a ClusterRoleBinding for cluster-scoped tasks, but a RoleBinding cannot grant access to cluster-scoped resources like nodes or persistent volumes, so candidates must recognize when a ClusterRoleBinding is necessary even after reducing permissions.

How to eliminate wrong answers

Option A is wrong because keeping a cluster-admin binding for a monitoring service account violates the principle of least privilege and unnecessarily exposes the cluster to privilege escalation if the service account is compromised. Option B is wrong because deleting the service account would break the monitoring functionality; the correct approach is to adjust its permissions, not remove it entirely. Option D is wrong because changing to a RoleBinding in the monitoring namespace would restrict permissions to that namespace only, but the monitoring service account likely needs cluster-scoped access (e.g., to read node metrics) and a RoleBinding cannot grant cluster-scoped permissions.

137
MCQmedium

A security admin runs 'trivy image --severity CRITICAL,HIGH myrepo/myapp:latest' and sees many CVEs. The admin wants to ensure that only images with no CRITICAL or HIGH severity vulnerabilities are deployed to the cluster. Which admission controller should be configured to enforce this policy?

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

ImagePolicyWebhook is specifically designed to check container images against an external policy service before admission.

Why this answer

The ImagePolicyWebhook admission controller is specifically designed to evaluate container images against an external policy backend before they are admitted into the cluster. By configuring it to reject images with CRITICAL or HIGH severity vulnerabilities (as reported by Trivy), the admin can enforce that only compliant images are deployed. This controller intercepts Pod creation requests and queries an external webhook to decide whether to allow or deny the image based on the policy.

Exam trap

The CKS exam often tests the distinction between generic admission webhooks (ValidatingAdmissionWebhook, MutatingAdmissionWebhook) and the purpose-built ImagePolicyWebhook, leading candidates to choose a generic webhook when the question explicitly asks for the controller designed for image policy enforcement.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) enforces security context constraints on Pods (e.g., privileged containers, host namespaces), not image vulnerability policies. Option B is wrong because ValidatingAdmissionWebhook can be used to validate arbitrary resources, but it is a generic mechanism that requires writing a custom webhook; the question specifically asks for the admission controller designed for image policy enforcement, which is ImagePolicyWebhook. Option C is wrong because MutatingAdmissionWebhook modifies resources during admission (e.g., injecting sidecars), but it does not perform image vulnerability checks or enforce image policies based on severity.

138
MCQeasy

Which of the following is the correct command to load an AppArmor profile from a file named 'my-profile'?

A.apparmor_load my-profile
B.apparmor_parser my-profile
C.apparmor_parser -R my-profile
D.systemctl start apparmor my-profile
AnswerB

Correct. apparmor_parser loads the profile.

Why this answer

The correct command to load an AppArmor profile from a file is `apparmor_parser my-profile`. The `apparmor_parser` tool is used to load, replace, or remove AppArmor profiles into the kernel. When invoked without flags, it loads the profile from the specified file into the kernel's AppArmor security module, enforcing the defined access controls.

Exam trap

The trap here is that candidates confuse `apparmor_parser` with a hypothetical `apparmor_load` command or misuse the `-R` flag, thinking it stands for 'run' or 'reload' instead of 'remove'.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; the correct tool is `apparmor_parser`. Option C is wrong because `apparmor_parser -R my-profile` removes (unloads) the profile from the kernel, not loads it. Option D is wrong because `systemctl start apparmor my-profile` is invalid syntax; `systemctl` manages the AppArmor service itself (e.g., `systemctl start apparmor`), not individual profiles, and passing a profile name as an argument is not supported.

139
Multi-Selecthard

Which THREE of the following are required to secure etcd in a Kubernetes cluster?

Select 3 answers
A.Configure RBAC for etcd
B.Allow anonymous access for monitoring
C.Require client certificate authentication
D.Enable encryption at rest for secrets
E.Use TLS for peer and client communication
AnswersC, D, E

Authenticates clients.

Why this answer

Etcd requires client certificate authentication to verify the identity of clients (such as kube-apiserver) connecting to it. Without mutual TLS (mTLS), an attacker could impersonate a legitimate client and read or modify cluster state, including secrets and configuration data.

Exam trap

CNCF often tests the misconception that etcd has its own RBAC or that anonymous access can be safely allowed for monitoring, when in fact etcd relies solely on TLS certificate authentication and encryption at rest is a separate mandatory control.

140
MCQhard

An administrator wants to use OPA Gatekeeper to enforce that all pods have a resource limits section defined. Which of the following is the correct combination to implement this policy?

A.Create a NetworkPolicy to block pods without limits.
B.Create a MutatingWebhookConfiguration to add resource limits automatically.
C.Create a ValidatingWebhookConfiguration that calls an external service to validate pod limits.
D.Create a ConstraintTemplate with a Rego policy that checks for 'spec.containers[*].resources.limits', then create a Constraint targeting pods.
AnswerD

Gatekeeper uses ConstraintTemplate (Rego) and Constraint to enforce policies. The Rego policy inspects the resource limits.

141
MCQmedium

A pod is running with AppArmor enabled using a profile named 'k8s-apparmor-profile'. You want to verify that the profile is loaded and set to enforce mode. Which command should you run on the node?

A.aa-status
B.aa-profile --status
C.aa-enabled
D.cat /sys/kernel/security/apparmor/profiles
AnswerA

'aa-status' lists all loaded AppArmor profiles and their modes (enforce/complain).

Why this answer

`aa-status` is the standard AppArmor utility that displays the status of AppArmor, including which profiles are loaded and their enforcement mode (enforce, complain, or unconfined). Running this command on the node will show whether 'k8s-apparmor-profile' is loaded and set to enforce mode, which directly answers the verification requirement.

Exam trap

The trap here is that candidates may confuse `aa-enabled` (which only checks if AppArmor is enabled) with `aa-status` (which shows loaded profiles and their modes), or they may think the raw kernel interface file is the correct answer, but the CKS exam expects knowledge of the standard user-space tool `aa-status` for verification.

How to eliminate wrong answers

Option B is wrong because `aa-profile --status` is not a valid AppArmor command; the correct command to check profile status is `aa-status` or `apparmor_status`. Option C is wrong because `aa-enabled` only checks if AppArmor is enabled on the system (returns 0 if enabled, 1 if not), but it does not list loaded profiles or their enforcement mode. Option D is wrong because while `cat /sys/kernel/security/apparmor/profiles` does list loaded profiles and their modes, it is a raw kernel interface that may not be available in all environments (e.g., containers or systems without securityfs mounted) and is less user-friendly than `aa-status`; the question asks for a command to run, and `aa-status` is the standard, reliable tool.

142
MCQmedium

You need to enable audit logging for the Kubernetes API server. Which two flags must be set?

A.--audit-log-path and --audit-log-maxage
B.--audit-policy-file and --audit-log-maxbackup
C.--audit-log-path and --audit-policy-file
D.--audit-log-path and --authorization-mode=RBAC
AnswerC

Correct. Both are required.

Why this answer

To enable audit logging in the Kubernetes API server, you must specify both an audit policy file (using --audit-policy-file) to define which events should be logged and at what level, and a log file path (using --audit-log-path) to specify where the audit logs should be written. Without the policy file, the API server does not know which requests to audit; without the log path, the audit events have no output destination.

Exam trap

CNCF often tests the distinction between mandatory flags (--audit-log-path and --audit-policy-file) and optional retention flags (--audit-log-maxage, --audit-log-maxbackup, --audit-log-maxsize), leading candidates to select options that include only retention flags or mix authorization flags with audit flags.

How to eliminate wrong answers

Option A is wrong because --audit-log-maxage is an optional flag that controls the maximum number of days to retain old audit log files, but it is not required to enable audit logging; the two mandatory flags are --audit-log-path and --audit-policy-file. Option B is wrong because --audit-log-maxbackup is also an optional flag that sets the maximum number of old audit log files to retain, and it does not replace the need for --audit-log-path or --audit-policy-file. Option D is wrong because --authorization-mode=RBAC is used to enable Role-Based Access Control for authorization, not for audit logging; audit logging requires the policy file and log path flags.

143
MCQmedium

You are implementing a policy to ensure all containers in a namespace run as non-root. Which of the following is the most appropriate approach to enforce this at the cluster level?

A.Create a PodSecurityPolicy that requires runAsNonRoot
B.Use OPA/Gatekeeper with a ConstraintTemplate that checks runAsNonRoot is set to true
C.Set runAsNonRoot in the securityContext of each Pod spec manually
D.Configure a ValidatingAdmissionPolicy with a CEL rule requiring runAsNonRoot
AnswerB

OPA/Gatekeeper can enforce policies via admission webhooks, and a ConstraintTemplate can validate that all containers have runAsNonRoot: true.

Why this answer

OPA/Gatekeeper allows you to enforce custom policies at the cluster level via ConstraintTemplates and Constraints. By creating a ConstraintTemplate that checks `runAsNonRoot: true` in the Pod securityContext, you can ensure all Pods in a namespace (or cluster-wide) run as non-root, without modifying individual Pod specs. This approach is native to Kubernetes admission control and provides a flexible, cluster-wide enforcement mechanism.

Exam trap

A common pitfall in the CKS exam is assuming that PodSecurityPolicy (PSP) is still a viable cluster-level enforcement mechanism. However, PSP was deprecated in Kubernetes v1.21 and removed in v1.25. The modern approach uses either OPA/Gatekeeper with ConstraintTemplates or Kubernetes Pod Security Standards (PSS) via labels or built-in admission controllers.

Candidates often choose PSP out of habit, but it is no longer available in recent clusters.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.21 and removed in v1.25, so it is not a viable cluster-level enforcement mechanism for current CKS exam contexts. Option C is wrong because manually setting `runAsNonRoot` in each Pod spec is not a cluster-level enforcement; it requires per-Pod changes and does not prevent non-compliant Pods from being created. Option D is wrong because ValidatingAdmissionPolicy with CEL is a newer feature (alpha in v1.26, beta in v1.28) and is not as mature or widely adopted as OPA/Gatekeeper for complex policy enforcement; it also lacks the rich constraint framework that OPA/Gatekeeper provides for this specific use case.

144
Multi-Selecthard

Which THREE of the following are recommended steps during incident response for a compromised pod? (Choose three.)

Select 3 answers
A.Take a memory dump of the container for analysis
B.Delete the entire namespace containing the pod
C.Use kubectl logs and kubectl exec to collect forensic data
D.Apply a NetworkPolicy to deny egress traffic from the pod
E.Immediately restart the pod to stop the attack
AnswersA, C, D

Preserves in-memory evidence.

Why this answer

Isolating via egress denial, collecting logs/exec output, and taking a memory dump for forensic analysis are appropriate. Restarting pods may destroy evidence, and deleting the namespace is too drastic.

145
MCQeasy

Which kubectl command checks the CIS Benchmark compliance of a cluster node using the kube-bench tool?

A.kubectl apply -f job.yaml
B.kubectl kube-bench
C.kubectl run kube-bench --image=aquasec/kube-bench
D.kube-bench run --targets=node
AnswerA

kube-bench is often deployed as a Kubernetes Job; applying the job YAML runs the benchmark.

Why this answer

Kube-bench runs as a Kubernetes Job, and the standard way to execute it against a cluster node is to apply a Job YAML manifest that runs the aquasec/kube-bench image. This Job performs CIS Benchmark checks on the node where it is scheduled, and the results are output to the Job's logs. The `kubectl apply -f job.yaml` command deploys the pre-configured Job, which is the recommended method for running kube-bench in a cluster context.

Exam trap

The trap here is that candidates confuse running a container directly with `kubectl run` versus deploying a proper Job manifest, or they assume `kubectl` has a native kube-bench subcommand, when in fact kube-bench must be run as a Kubernetes workload (typically a Job) to comply with the CIS Benchmark scanning methodology.

How to eliminate wrong answers

Option B is wrong because `kubectl kube-bench` is not a valid kubectl subcommand; kubectl does not have a built-in kube-bench plugin, and this command would fail. Option C is wrong because `kubectl run kube-bench --image=aquasec/kube-bench` creates a Pod, not a Job, and kube-bench is designed to run as a Job to properly handle completion and logging; a Pod may not terminate correctly or provide the expected output format. Option D is wrong because `kube-bench run --targets=node` is a direct command-line invocation of the kube-bench binary, not a kubectl command, and the question specifically asks for a kubectl command.

146
MCQmedium

A Falco rule triggers on 'Write below etc' and you see an alert about a process writing to /etc/shadow. Which syscall is Falco most likely using to detect this?

A.open
B.chmod
C.write
D.openat
AnswerC

Falco monitors write syscalls to detect modifications to sensitive files like /etc/shadow.

Why this answer

Falco uses system calls to monitor file writes. The 'write' syscall is used when a process writes data to a file. 'open' and 'openat' are used to open files, but the actual write event is captured by 'write'. 'chmod' changes permissions.

147
MCQmedium

A pod with the following annotation is created: 'container.apparmor.security.beta.kubernetes.io/webserver: localhost/k8s-apparmor-profile'. However, the pod remains in 'Pending' state and the node logs show 'AppArmor not available'. What is the most likely cause?

A.The annotation should be on the pod's securityContext, not as an annotation
B.AppArmor is not loaded or enabled on the node kernel
C.The AppArmor profile name is misspelled
D.The pod is using a privileged security context
AnswerB

The error indicates AppArmor is not available on the node. It needs to be enabled in the kernel and the apparmor_parser used to load profiles.

Why this answer

The node logs explicitly state 'AppArmor not available', which indicates that the AppArmor kernel security module is either not loaded or not enabled on the node's operating system. Without AppArmor support in the kernel, the kubelet cannot enforce the profile specified in the pod annotation, causing the pod to remain in 'Pending' state. This is a prerequisite condition for AppArmor profiles to work in Kubernetes.

Exam trap

CNCF often tests the distinction between a profile being misconfigured (e.g., wrong name) versus the underlying kernel module not being available; the trap here is that candidates may assume a spelling error (Option C) when the node logs clearly point to a missing kernel feature.

How to eliminate wrong answers

Option A is wrong because the AppArmor profile is correctly specified as a pod annotation per the Kubernetes beta API (container.apparmor.security.beta.kubernetes.io/<container_name>), not in the securityContext. Option C is wrong because the node logs do not indicate a profile name mismatch; they explicitly state 'AppArmor not available', which is a kernel-level issue, not a name misspelling. Option D is wrong because a privileged security context does not prevent AppArmor from being available; it may bypass AppArmor enforcement, but the error here is about the kernel module not being present, not about privilege escalation.

148
MCQhard

You want to configure an audit policy to log all requests to the 'secrets' resource with the body at the 'RequestResponse' level. Other resources should be logged at 'Metadata' level. Which audit policy YAML snippet is correct?

A.rules: - level: Body resources: ["secrets"] - level: Metadata resources: ["*"]
B.apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets"] - level: Metadata resources: - group: "" resources: ["*"]
C.policies: - level: RequestResponse resources: ["secrets"] - level: Metadata resources: ["*"]
D.rules: - level: RequestResponse resources: - group: "" resources: ["secrets"] - level: Metadata resources: - group: "" resources: ["*"]
AnswerB

Correct: Includes apiVersion and kind, and defines two rules with proper resource and level assignments.

Why this answer

It includes the required apiVersion and kind fields (audit.k8s.io/v1 and Policy) and correctly defines two rules: one for secrets at RequestResponse level with an empty group, and one for all other resources at Metadata level. Option D is incorrect because it omits the apiVersion and kind fields; while the rules structure is valid, a complete audit policy object must include those fields to be applied in Kubernetes. Option A uses 'Body' which is not a valid audit level (must be RequestResponse).

Option C uses 'policies' as the top-level key instead of 'rules', which is invalid.

149
MCQeasy

Which YAML field in a Deployment specifies the container user should not run as root?

A.spec.containers[].securityContext.readOnlyRootFilesystem
B.spec.containers[].securityContext.runAsUser: 0
C.spec.containers[].securityContext.runAsNonRoot
D.spec.containers[].securityContext.allowPrivilegeEscalation
AnswerC

Setting runAsNonRoot: true ensures the container runs with a non-root user.

Why this answer

`spec.containers[].securityContext.runAsNonRoot: true` explicitly enforces that the container's user ID is non-zero, preventing the container from running as root. This is a key Pod Security Standard (PSS) control for the 'Restricted' profile, ensuring compliance with the principle of least privilege. The field rejects the container if the user is set to root (UID 0) or if no user is specified and the image defaults to root.

Exam trap

The CKS exam often tests the distinction between `runAsNonRoot` (which enforces a non-root user) and `runAsUser: 0` (which explicitly sets root), and candidates mistakenly think setting `runAsUser` to a non-zero value is equivalent to `runAsNonRoot`, but `runAsNonRoot` is a boolean enforcement that rejects root regardless of the image's default user.

How to eliminate wrong answers

Option A is wrong because `readOnlyRootFilesystem` only makes the container's root filesystem read-only, which prevents writes to the filesystem but does not restrict the user ID; a root user can still run with UID 0. Option B is wrong because `runAsUser: 0` explicitly sets the container to run as root (UID 0), which is the opposite of preventing root execution. Option D is wrong because `allowPrivilegeEscalation` controls whether a process can gain more privileges than its parent (e.g., via setuid binaries), but it does not prevent the container from running as root initially.

150
MCQeasy

A DevOps team uses a CI/CD pipeline to build container images and push them to a private registry. To minimize the risk of supply chain attacks, which of the following is the most effective security control to implement?

A.Scan all images for vulnerabilities using Trivy before pushing to the registry.
B.Restrict access to the registry using Kubernetes RBAC and service accounts.
C.Implement network policies to restrict traffic to the registry endpoint.
D.Sign all container images using a private key and verify the signature before deployment.
AnswerD

Image signing provides cryptographic assurance of image integrity and origin, a core supply chain security control.

Why this answer

Signing container images with a private key and verifying the signature before deployment ensures image integrity and authenticity, directly mitigating supply chain attacks where an attacker could tamper with images in transit or at rest. This control, often implemented using tools like Notary or Cosign (part of the Sigstore project), provides cryptographic proof that the image was produced by a trusted source and has not been altered. Without signature verification, even a vulnerability-scanned image could be replaced with a malicious one, bypassing other controls.

Exam trap

The trap here is that candidates often confuse vulnerability scanning (which detects known flaws) with image signing (which ensures integrity and provenance), and mistakenly choose scanning as the primary defense against supply chain attacks, overlooking that a scanned image can still be replaced or tampered with.

How to eliminate wrong answers

Option A is wrong because vulnerability scanning (e.g., with Trivy) only identifies known CVEs in the image content; it does not prevent an attacker from replacing the image with a different, malicious one after scanning or during transit. Option B is wrong because restricting registry access via Kubernetes RBAC and service addresses only controls who can push or pull images, but does not verify the integrity or origin of the image itself—an authorized user could still push a tampered image. Option C is wrong because network policies limit traffic to the registry endpoint but do not protect against image tampering; an attacker who gains access to the registry or intercepts traffic could still modify images without detection.

Page 1

Page 2 of 12

Page 3