CKS Practice Test 19 — 15 Questions

Question 1

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

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

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

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.file: audit.json

Answer

securityContext.seccompProfile.type: Localhost and securityContext.seccompProfile.profile: audit.json

Answer

seccomp.security.alpha.kubernetes.io/pod: localhost/audit.json

Question 2

A Falco rule is triggered when a shell is spawned inside a container. Which syscall is typically used to detect shell execution?

Accepted Answer

execve. Falco detects shell execution by monitoring the `execve` syscall, which is the standard Linux system call used to execute a new program. When a shell like `/bin/bash` or `/sh` is spawned inside a container, the kernel invokes `execve` to replace the current process image with the shell binary. Falco's rule engine matches this syscall against its default rule set (e.g., `run_shell_untrusted`) to trigger an alert.

Answer

clone

Answer

open

Answer

read

Question 3

An administrator wants to enforce a policy that all containers must drop ALL capabilities and not allow privilege escalation. Which YAML snippet correctly implements this requirement in a PodSecurityPolicy-like manner using a security context? (Note: PodSecurityPolicy is deprecated; consider using a ValidatingAdmissionPolicy or OPA/Gatekeeper, but for this question choose the correct security context fields.)

Accepted Answer

securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }. It sets `allowPrivilegeEscalation: false` to prevent privilege escalation (e.g., via setuid binaries) and `capabilities: { drop: ["ALL"] }` to remove all Linux capabilities from the container. This combination enforces the requirement that containers start with no extra privileges and cannot gain more, aligning with the principle of least privilege in PodSecurityPolicy-like enforcement.

Answer

securityContext: { privileged: false, capabilities: { drop: ["ALL"] } }

Answer

securityContext: { allowPrivilegeEscalation: false, capabilities: { add: ["ALL"] } }

Answer

spec: { allowPrivilegeEscalation: false, capabilities: { drop: ["ALL"] } }

Question 4

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

Accepted Answer

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

Answer

spec.readOnlyRootFilesystem

Answer

securityContext.privileged: false

Answer

container.readOnly

Question 5

Order the steps to perform a Kubernetes cluster upgrade from version 1.24 to 1.25.

Accepted Answer

Upgrade kubeadm, then Drain the node, then Upgrade kubelet and kubectl, then Uncordon the node. Upgrade involves upgrading kubeadm, draining, applying upgrade, upgrading worker nodes, and verifying.

Answer

Drain the node, then Upgrade kubeadm, then Upgrade kubelet and kubectl, then Uncordon the node

Answer

Upgrade kubeadm, then Upgrade kubelet and kubectl, then Drain the node, then Uncordon the node

Answer

Upgrade kubeadm, then Drain the node, then Uncordon the node, then Upgrade kubelet and kubectl

Question 6

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

Accepted Answer

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

Answer

Configure kubelet with --pod-manifest-path pointing to a whitelist

Answer

Enable PodSecurity with restricted profile

Answer

Use NetworkPolicy to block traffic to untrusted registries

Question 7

Which of the following is the correct way to drop all capabilities in a container's security context?

Accepted Answer

securityContext: capabilities: drop: ['ALL']. In Kubernetes, the `securityContext.capabilities.drop` field is used to explicitly remove Linux capabilities from a container. Setting `drop: ['ALL']` removes all capabilities, ensuring the container runs with the least privilege. This is the standard and recommended way to harden container security.

Answer

securityContext: capabilities: remove: ['ALL']

Answer

securityContext: capabilities: []

Answer

securityContext: capabilities: add: []

Question 8

An AppArmor profile is loaded in 'complain' mode. What happens when a pod with that profile attempts an action that violates the profile?

Accepted Answer

The action is allowed but a log entry is created.. In AppArmor, 'complain' mode (also known as 'learning' mode) allows all actions, including those that violate the profile, but logs the violation to the system audit log (typically via auditd or syslog). This is distinct from 'enforce' mode, which blocks violating actions. Therefore, when a pod runs with a profile in complain mode, prohibited actions are permitted and recorded.

Answer

The pod is terminated.

Answer

The action is allowed and no log is generated.

Answer

The action is blocked and an audit log is generated.

Question 9

Which THREE of the following actions help reduce the attack surface of containers? (Select 3 correct answers)

Accepted Answer

Set securityContext.runAsNonRoot: true. Setting `securityContext.runAsNonRoot: true` forces the container to run with a user ID that is not 0 (root). This prevents an attacker who gains code execution inside the container from having root privileges, which would otherwise allow them to escape the container, modify system binaries, or perform privileged operations. It is a fundamental principle of least privilege and directly reduces the attack surface by limiting the damage a compromised container can do.

Answer

Set hostNetwork: true for better network performance

Answer

Enable audit logging for all API requests

Question 10

A cluster administrator wants to enforce Pod Security Standards at the namespace level using the built-in PodSecurity admission controller. The namespace 'test' should reject any pod that violates the 'baseline' level. Which command applies this correctly?

Accepted Answer

kubectl label ns test pod-security.kubernetes.io/enforce=baseline. The PodSecurity admission controller uses the label `pod-security.kubernetes.io/enforce` to enforce the specified Pod Security Standard (e.g., `baseline`) at the namespace level. Pods that violate the enforced level are rejected by the admission controller. The `enforce` label triggers the admission webhook to block non-compliant pods, which matches the requirement to reject violations.

Answer

kubectl annotate ns test pod-security.kubernetes.io/enforce-version=baseline

Answer

kubectl label ns test pod-security.kubernetes.io/warn=baseline

Answer

kubectl label ns test pod-security.kubernetes.io/audit=baseline

Question 11

Which kubectl command can be used to view the audit log policy currently in use by the API server?

Accepted Answer

kubectl get -n kube-system pods kube-apiserver- -o yaml | grep audit-policy-file. The audit policy file path is specified in the kube-apiserver manifest (usually a static pod YAML in /etc/kubernetes/manifests/). Running `kubectl get pod kube-apiserver- -n kube-system -o yaml` and grepping for `audit-policy-file` reveals the exact path to the policy file currently in use, which is the authoritative way to confirm which audit policy the API server is loading.

Answer

kubectl logs -n kube-system kube-apiserver-<node> | grep audit

Answer

kubectl describe clusterrolebinding audit

Answer

kubectl get auditpolicy

Question 12

A cluster administrator wants to allow only images from a specific registry (e.g., 'myregistry.io') to be deployed in the cluster. Which tool can be used to enforce this via admission control?

Accepted Answer

OPA/Gatekeeper. OPA/Gatekeeper is a Kubernetes admission controller that allows you to enforce custom policies, such as restricting container images to a specific registry. By defining a ConstraintTemplate and a Constraint that checks the image prefix (e.g., 'myregistry.io/'), Gatekeeper can reject any Pod creation that uses images from unauthorized registries. This directly addresses the requirement for registry-based admission control.

Answer

Helm

Answer

Calico

Answer

Prometheus

Question 13

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

Accepted Answer

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

Answer

AlwaysPullImages

Answer

NodeAffinity

Answer

PodSecurityPolicy

Question 14

You are creating a custom seccomp profile for a container that runs a binary requiring the 'write' syscall only. You place the profile JSON file at '/var/lib/kubelet/seccomp/profiles/write-only.json'. In the pod spec, which seccomp configuration correctly uses this profile?

Accepted Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/write-only.json. When using a custom seccomp profile with type 'Localhost', the 'localhostProfile' field must specify a path relative to the kubelet's seccomp root directory (default: /var/lib/kubelet/seccomp). The path 'profiles/write-only.json' is relative and resolves to /var/lib/kubelet/seccomp/profiles/write-only.json, matching the file location. The 'type' field must be 'Localhost' to reference a local profile file.

Answer

securityContext:
  seccompProfile:
    type: RuntimeDefault
    localhostProfile: profiles/write-only.json

Answer

securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: /var/lib/kubelet/seccomp/profiles/write-only.json

Answer

securityContext:
  seccompProfile:
    type: Localhost
    profile: write-only.json

Question 15

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

Accepted Answer

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

Answer

Role with 'list' on pods, RoleBinding in observability

Answer

ClusterRole with 'get' on pods, ClusterRoleBinding

Answer

ClusterRole with 'list' on pods, RoleBinding in observability