CKS Practice Exam 53 — 20 Questions

Question 1

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

Accepted Answer

crictl ps. The 'crictl ps' command is used to list all running containers managed by the container runtime. It provides a list of containers with their IDs, images, state, and other details. This is the standard command for viewing running containers when using CRI-compatible runtimes like containerd or CRI-O.

Answer

crictl images

Answer

crictl stats

Answer

crictl pods

Question 2

Refer to the exhibit. A cluster has the ClusterImagePolicy shown. A developer creates a pod with an image from registry.example.com/myapp:v1, which was built and signed by a GitHub Actions workflow that is NOT defined in the policy (different workflow). Which behavior will occur when the pod is created?

Accepted Answer

The pod is denied because the image's signer identity does not match the policy.. The ClusterImagePolicy enforces that images must be signed by a specific identity (the GitHub Actions workflow defined in the policy). The image from registry.example.com/myapp:v1 was signed by a different workflow, so the signer identity does not match the policy's required identity. Sigstore keyless signing verifies the OIDC identity embedded in the signature, and if the identity does not match the policy's `issuer` and `subject` patterns, the admission controller denies the pod.

Answer

The pod is admitted because keyless signing does not enforce identity matching.

Answer

The pod is admitted because the policy only applies to images with a tag 'v*'.

Answer

The pod is admitted because the image is from the allowed registry.

Question 3

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?

Accepted Answer

Any pod using the default service account in kube-system has cluster-admin privileges. The ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.

Answer

The risk is only if the service account is used by external users

Answer

The ClusterRoleBinding is invalid because it uses a namespace-scoped service account

Answer

No risk, as it is limited to kube-system namespace

Question 4

Which kubectl command can be used to view the live logs of a container in a pod named 'my-pod'?

Accepted Answer

kubectl logs -f my-pod. The command 'kubectl logs -f my-pod' streams the logs in real-time (follow mode), which is equivalent to viewing live logs. The -f flag stands for 'follow' and continuously outputs new log entries as they are generated.

Answer

kubectl attach my-pod

Answer

kubectl logs my-pod --tail 10

Answer

kubectl exec my-pod -- journalctl

Question 5

Which admission plugin should be used to enforce Pod Security Standards at the namespace level?

Accepted Answer

PodSecurity. The PodSecurity admission plugin is the successor to PodSecurityPolicy (PSP) and is designed specifically to enforce Pod Security Standards (PSS) at the namespace level. It evaluates pods against the three predefined PSS levels (privileged, baseline, restricted) based on labels set on the namespace, and can be configured in warn, audit, or enforce mode. This plugin is built into the kube-apiserver and is the recommended approach for pod security in Kubernetes v1.25 and later.

Answer

PodSecurityPolicy

Answer

NodeRestriction

Answer

SecurityContextDeny

Question 6

A container runs as non-root and needs to perform operations that require CAP_SYS_PTRACE. Which YAML snippet correctly adds only this capability while following the principle of least privilege?

Accepted Answer

securityContext:
  capabilities:
    drop: ['ALL']
    add: ['SYS_PTRACE']. It first drops all capabilities with `drop: ['ALL']` and then explicitly adds only `SYS_PTRACE`, ensuring the container runs with the minimum privileges required. This follows the principle of least privilege by removing any inherited or default capabilities before granting only the needed one. In Kubernetes, capabilities are Linux kernel capabilities; dropping all and adding only what is necessary is the recommended security practice.

Answer

securityContext:
  capabilities:
    add: ['SYS_PTRACE']

Answer

securityContext:
  capabilities:
    drop: ['ALL']

Answer

securityContext:
  privileged: true

Question 7

An administrator runs 'kube-bench master' and receives a warning that etcd has no client certificate authentication. What is the recommended remediation?

Accepted Answer

Set --client-cert-auth=true and --trusted-ca-file on the etcd process. The warning indicates that etcd is running without client certificate authentication, which means any client can communicate with etcd without verifying its identity. Setting `--client-cert-auth=true` enables TLS-based client certificate authentication, and `--trusted-ca-file` specifies the CA certificate used to validate client certificates. This is the recommended remediation because it ensures only clients with valid certificates signed by the trusted CA can access etcd, preventing unauthorized access to the cluster's key-value store.

Answer

Remove the --client-cert-auth flag

Answer

Set --anonymous-auth=true on etcd

Answer

Use etcdctl to enable authentication

Question 8

A developer creates a pod with the following YAML:
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: default
  automountServiceAccountToken: true
  containers:
  - name: app
    image: nginx

What is the security concern with this configuration?

Accepted Answer

The service account token is automatically mounted, potentially providing excessive permissions. Setting `automountServiceAccountToken: true` (or omitting it, as it defaults to true) causes the pod to automatically mount the service account token of the `default` service account into the container. This token can grant excessive permissions if the default service account has been bound to roles with broad access, such as cluster-admin or other privileged RBAC bindings, which is a common misconfiguration. An attacker who compromises the container can then use this token to authenticate to the Kubernetes API server and perform unauthorized actions within the cluster.

Answer

The pod does not specify resource limits

Answer

The container runs as root

Answer

The pod uses the 'default' namespace

Question 9

You have created a ValidatingWebhookConfiguration to reject pods without resource limits. When you try to create a pod without limits, it is created successfully. What is the most likely reason?

Accepted Answer

The webhook service is not running or is unreachable. The most likely reason a pod without resource limits is created successfully despite a ValidatingWebhookConfiguration is that the webhook service itself is not running or is unreachable. When the API server cannot contact the webhook endpoint, the default behavior (failurePolicy: Ignore) allows the request to proceed, so the pod is created without validation. If the webhook were functioning correctly, it would reject the pod; thus, the failure to reject indicates a connectivity or service issue.

Answer

The webhook is not matching the namespace labels

Answer

The webhook is configured with failurePolicy: Fail

Answer

The pod is being created by a controller like a Deployment

Question 10

You want to enable mutual TLS (mTLS) between services in a namespace using Istio. Which custom resource should you configure to enforce STRICT mTLS for all workloads in the namespace?

Accepted Answer

PeerAuthentication with mtls.mode: STRICT. PeerAuthentication is the Istio custom resource specifically designed to define traffic authentication policies between workloads. Setting `mtls.mode: STRICT` enforces that all traffic in the namespace must use mutual TLS (mTLS), rejecting any plain-text or non-mTLS connections. This is the standard way to enforce STRICT mTLS at the namespace level in Istio.

Answer

DestinationRule with trafficPolicy.tls.mode: ISTIO_MUTUAL

Answer

VirtualService with tls.mode: SIMPLE

Answer

ServiceEntry with resolution: NONE

Question 11

Which flag should you set on the kube-apiserver to disable anonymous authentication?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth` flag on the kube-apiserver controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous authentication, meaning requests without valid credentials will be rejected with a 401 Unauthorized response. This is the correct parameter to harden the API server against unauthenticated access.

Answer

--disable-anonymous=true

Answer

--enable-anonymous-auth=false

Answer

--auth-mode=RBAC

Question 12

Which kubectl command lists all MutatingWebhookConfigurations in the cluster?

Accepted Answer

kubectl get mutatingwebhookconfigurations. `kubectl get mutatingwebhookconfigurations` is the standard Kubernetes command to list all MutatingWebhookConfiguration resources. These resources are part of the admission webhook mechanism, which intercepts API requests to mutate objects before they are persisted. The resource name is case-sensitive and must match the exact API resource name `mutatingwebhookconfigurations` (or the short form `mutatingwebhookconfiguration`).

Answer

kubectl get webhooks

Answer

kubectl list webhooks

Answer

kubectl get mutating-webhooks

Question 13

A security engineer wants to scan a container image for vulnerabilities using Trivy. Which command should they use?

Accepted Answer

trivy image . Trivy uses the `image` subcommand to scan a container image for vulnerabilities. The correct syntax is `trivy image `, which pulls the image (if not already present) and scans its layers against known vulnerability databases (e.g., NVD, Red Hat, Debian). This is the standard command for container image scanning in Trivy.

Answer

trivy scan <image-name>

Answer

trivy repo <image-name>

Answer

trivy fs <image-name>

Question 14

During a security audit, a team discovers that their microservice application, deployed on Kubernetes, is vulnerable to container breakout attacks. The containers run as root and have many Linux capabilities. Which set of Pod Security Standards (PSS) enforcement modes and policies would best mitigate this risk?

Accepted Answer

Use 'restricted' PSS with Enforce mode. The 'restricted' Pod Security Standard with 'Enforce' mode is the correct choice because it mandates the most stringent security controls, including dropping all Linux capabilities and preventing containers from running as root. This directly mitigates container breakout attacks by eliminating the excessive privileges that enable such exploits. 'Enforce' mode actively blocks non-compliant pods, ensuring the policy is applied without relying on user awareness or audit logs.

Answer

Use 'privileged' PSS with Warn mode

Answer

Use 'baseline' PSS with Audit mode

Answer

Use 'baseline' PSS with Enforce mode

Question 15

A pod in namespace 'secure' has the following securityContext:
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  capabilities:
    drop: ["ALL"]
    add: ["NET_BIND_SERVICE"]
The pod fails to start. The namespace is enforced with the 'restricted' Pod Security Standard. What is the most likely reason?

Accepted Answer

The pod adds capabilities, which is not allowed by the restricted policy.. The 'restricted' Pod Security Standard (PSS) explicitly prohibits adding any capabilities beyond the default set, which is empty. Since the pod's securityContext adds the NET_BIND_SERVICE capability, it violates the restricted policy, causing the pod to fail to start.

Answer

The runAsUser is set to 1000, which is not allowed by the restricted policy.

Answer

The pod sets runAsNonRoot to true, which is not allowed by the restricted policy.

Answer

The pod drops all capabilities, which is not allowed by the restricted policy.

Question 16

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

Accepted Answer

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

Answer

Delete the service account and create a new one

Answer

Create a new RoleBinding with fewer privileges in the kube-system namespace

Answer

Modify the ClusterRole 'cluster-admin' to have fewer permissions

Question 17

Match each Kubernetes object or feature to its primary security purpose.

Accepted Answer

NetworkPolicy: Controls network traffic to and from pods. Correct matches: NetworkPolicy controls network traffic; RBAC controls permissions; SecurityContext defines security settings. Common confusions: ServiceAccount is for identity, not encryption; PodSecurityPolicy is for security constraints, not resource limits.

Answer

ServiceAccount: Encrypts secrets at rest

Answer

PodSecurityPolicy: Defines CPU and memory limits for pods

Question 18

Which THREE of the following are valid fields in an EncryptionConfiguration YAML to encrypt secrets at rest?

Accepted Answer

resources. `resources` is a valid field in an EncryptionConfiguration YAML that specifies which Kubernetes resources (e.g., secrets) should be encrypted. The EncryptionConfiguration object defines how to encrypt data at rest in etcd, and the `resources` field lists the resource types to encrypt, such as `secrets`. Without this field, the encryption configuration would not know which resources to apply encryption to.

Answer

providers

Answer

key

Question 19

Match each Kubernetes API server flag to its security function.

Accepted Answer

--authorization-mode=RBAC: Enables RBAC authorization. Correct matches: --authorization-mode=RBAC enables RBAC; --anonymous-auth=false disables anonymous auth; --profiling=false disables profiling. Common confusions involve mixing authorization and authentication flags.

Answer

--authorization-mode=RBAC: Enables anonymous authentication

Answer

--anonymous-auth=false: Enables RBAC

Answer

--profiling=false: Enables audit logging

Question 20

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

Accepted Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }. The AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Answer

annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }

Answer

annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }

Answer

annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }