CKS Practice Test 50 — 15 Questions

Question 1

A security team wants to detect attempts to read /etc/shadow inside containers. Which Falco rule condition would trigger on a container reading that file?

Accepted Answer

evt.type=open and fd.name=/etc/shadow. Falco uses system call events to monitor file access. The condition `evt.type=open` captures file open operations, and `fd.name=/etc/shadow` filters for the specific file path. This triggers when any process inside a container opens /etc/shadow for reading, which is a classic indicator of an attempt to access sensitive host data.

Answer

evt.type=connect and fd.name=/etc/shadow

Answer

evt.type=execve and proc.name=cat

Answer

evt.type=open and container.id exists

Question 2

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

Accepted Answer

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

Answer

Helm

Answer

Kube-bench

Answer

Prometheus

Question 3

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

Accepted Answer

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

Answer

cosign sign --key mykey.pub myimage

Answer

cosign download myimage

Answer

cosign attest --predicate mypredicate myimage

Question 4

A developer created a ClusterRole 'pod-reader' with rules to get, list, and watch pods, and bound it to a user. The user reports they cannot list pods in namespace 'test', although the same commands work in the 'default' namespace. What is the most likely cause?

Accepted Answer

The ClusterRole was bound with a namespace-scoped RoleBinding in 'default' instead of a ClusterRoleBinding. The ClusterRole was bound with a namespace-scoped RoleBinding (created in the 'default' namespace) rather than a cluster-scoped ClusterRoleBinding. A RoleBinding can reference a ClusterRole, but it only grants those permissions inside the RoleBinding's own namespace — which is why access works in 'default' but not in 'test'. Binding the ClusterRole with a ClusterRoleBinding would grant pod access in every namespace. Option A is wrong because a ClusterRoleBinding (not a RoleBinding) is what grants cluster-wide access. Option B is wrong because human users do not need ServiceAccounts. Option D is wrong because the scenario states the ClusterRole includes the 'list' verb.

Answer

The ClusterRole must be bound with a RoleBinding

Answer

The user needs a ServiceAccount

Answer

The pod-reader ClusterRole is missing 'list' verb

Question 5

An administrator deploys a Gatekeeper ConstraintTemplate with the following Rego policy:

package k8srequiredlabels
deny[{"msg": msg}] {
  input.request.kind.kind == "Pod"
  not input.request.object.metadata.labels["security-tier"]
  msg := "Pod must have label 'security-tier'"
}

After creating the Constraint, a user creates a Pod without the 'security-tier' label. What is the expected behavior?

Accepted Answer

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

Answer

The pod is created and the label is automatically added

Answer

Only the first pod without the label is denied; subsequent ones are allowed

Answer

The pod is created but logged as a violation

Question 6

Which of the following is a BEST practice for container images to reduce the attack surface?

Accepted Answer

Use minimal base images like distroless. Distroless images contain only the application and its runtime dependencies, omitting package managers, shells, and other utilities that could be exploited. This drastically reduces the number of CVEs present in the image and limits the tools available to an attacker who gains code execution inside the container.

Answer

Use the 'latest' tag

Answer

Include debugging tools in the image

Answer

Run containers as root user

Question 7

A pod named 'compromised-pod' is suspected of making unauthorized outbound connections. You want to isolate the pod using a NetworkPolicy. Which policy correctly denies all egress traffic from the pod?

Accepted Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and egress: []. A NetworkPolicy with podSelector matching 'compromised-pod' (via label app=compromised) and an empty egress list (egress: []) explicitly denies all egress traffic from the pod. This is the standard Kubernetes pattern to isolate a pod by default-deny egress. Option A allows egress to 0.0.0.0/0, which permits all outbound traffic. Option B only restricts ingress, not egress. Option D allows egress to pods matching an empty podSelector (all pods), thus permitting traffic to other pods in the namespace. Therefore, only option C achieves complete egress isolation.

Answer

NetworkPolicy with podSelector: {} and egress: [{to: [{ipBlock: {cidr: 0.0.0.0/0}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and policyTypes: ["Ingress"]

Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and egress: [{to: [{podSelector: {}}]}]

Question 8

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

Accepted Answer

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

Answer

The DaemonSet has a nodeSelector that doesn't match any nodes

Answer

The DaemonSet uses hostNetwork which conflicts with existing pods

Answer

The nodes are cordoned

Question 9

Which two of the following are best practices for securing a CI/CD pipeline that builds and deploys container images? (Select TWO.)

Accepted Answer

Scan container images for vulnerabilities in the pipeline. Option A is correct because integrating automated image vulnerability scanning (e.g., Trivy, Clair, or Grype) into the pipeline catches known CVEs in base images and dependencies before the image is pushed or deployed, enabling fail-fast remediation. Option C is correct because signing images after building them (e.g., with Cosign/Notation using Sigstore or Docker Content Trust) establishes provenance and integrity, allowing admission controllers to verify signatures before deployment and preventing tampered or unauthorized images from running. Option B is not a best practice because secrets stored as plaintext environment variables in pipeline configuration can leak through logs, build artifacts, or repository access; a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) or OIDC-based short-lived credentials should be used instead. Option D is wrong because running builds as root violates least privilege and increases the blast radius of a compromised build step; rootless builds (e.g., Buildah, Kaniko, or Docker rootless mode) are preferred. Option E is wrong because granting the pipeline service account all permissions violates least privilege and dramatically expands the impact of a supply-chain compromise; scoped, minimal RBAC roles should be assigned per stage.

Answer

Store secrets as environment variables in the pipeline configuration

Answer

Run the build process as root to avoid permission issues

Answer

Grant all permissions to the pipeline service account to avoid failures

Question 10

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

Accepted Answer

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

Answer

runAsUser: RunAsAny

Answer

runAsGroup: MustRunAsNonRoot

Answer

seLinuxContext: MustRunAsNonRoot

Question 11

A developer runs 'trivy image myapp:latest' and gets a report with several CRITICAL CVEs. Which action would BEST address the supply chain security risk?

Accepted Answer

Rebuild the image using a minimal base image like distroless or alpine with no CVEs. Rebuilding the image using a minimal base image like distroless or Alpine directly eliminates the vulnerable packages that cause the CRITICAL CVEs. This addresses the root cause of the supply chain risk by ensuring the container image contains only the necessary runtime dependencies, reducing the attack surface and removing known vulnerabilities at the source.

Answer

Ignore the report because the container is running in a sandboxed environment

Answer

Run 'trivy image myapp:latest --severity CRITICAL' to filter out lower severity findings

Answer

Add a network policy to block outbound traffic from the container

Question 12

An organization uses a GitOps workflow with Argo CD to deploy applications to Kubernetes. The security team wants to ensure that container images are immutable and signed. They currently use a private container registry (Harbor) with vulnerability scanning and Cosign for signing. Which combination of controls best enforces that only signed and scanned images are deployed?

Accepted Answer

Enable Harbor's content trust feature to reject unsigned images, and use a Kyverno admission rule to verify Cosign signatures at deploy time.. It enforces a two-layer defense: Harbor's content trust rejects unsigned images at the registry level, and a Kyverno admission rule verifies Cosign signatures at deploy time. This ensures that even if an unsigned image bypasses the registry, it will be blocked by Kubernetes admission control, providing defense in depth for supply chain security.

Answer

Configure Argo CD to verify Cosign signatures before syncing the application.

Answer

Use imagePullSecrets in Kubernetes to ensure only Harbor images are used.

Answer

Add a Cosign verification step in the CI pipeline before pushing images to Harbor, and rely on that guarantee.

Question 13

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

Accepted Answer

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

Answer

--disable-anonymous=true

Answer

--auth-mode=RBAC

Answer

--enable-anonymous-auth=false

Question 14

A security engineer needs to ensure that all containers in a cluster run as non-root users. Which Pod Security Context field should be set to enforce this requirement?

Accepted Answer

runAsNonRoot: true. Setting `runAsNonRoot: true` in the Pod Security Context explicitly instructs the container runtime to verify that the container's user ID is non-zero (i.e., not root). If the container image is configured to run as root (UID 0), the Pod will fail to start, enforcing the requirement that all containers run as non-root users.

Answer

runAsUser: 1000

Answer

privileged: false

Answer

allowPrivilegeEscalation: false

Question 15

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

Accepted Answer

setuid. The setuid syscall is used to change the effective user ID of a process, and it is the mechanism by which setuid binaries elevate privileges. Falco rules that detect privilege escalation via setuid binaries monitor this syscall (often combined with execve of a setuid binary) to flag unauthorized elevation attempts.

Answer

connect

Answer

open

Answer

execve