CKS Practice Exam 2 — 20 Questions

Question 1

Which TWO of the following are recommended practices for securing the Kubernetes Dashboard? (Select TWO)

Accepted Answer

Restrict Dashboard access using RBAC with minimal privileges. The Kubernetes Dashboard should be secured using Role-Based Access Control (RBAC) with minimal privileges. This follows the principle of least privilege, ensuring that users or service accounts accessing the Dashboard have only the permissions necessary for their tasks, reducing the attack surface and potential blast radius in case of compromise.

Answer

Use HTTP instead of HTTPS for Dashboard traffic

Answer

Disable authentication for the Dashboard

Answer

Use the default cluster-admin ServiceAccount for Dashboard access

Question 2

An administrator wants to ensure that a Deployment uses a specific image digest (SHA256) instead of a tag. Which field in the Deployment YAML should be modified?

Accepted Answer

spec.template.spec.containers[].image. The `image` field under `spec.template.spec.containers[]` is where you specify the container image, and to enforce immutable deployment, you replace the tag with the SHA256 digest (e.g., `nginx@sha256:abc123...`). This ensures the exact image content is used, preventing tag mutation or accidental updates.

Answer

spec.replicas

Answer

spec.template.spec.containers[].imagePullPolicy

Answer

spec.template.metadata.annotations

Question 3

Which TWO of the following are best practices for securing container images?

Accepted Answer

Use minimal base images like distroless. Minimal base images like distroless reduce the attack surface by eliminating unnecessary packages, libraries, and shell access. This aligns with the principle of least functionality, making it harder for attackers to exploit vulnerabilities or execute arbitrary commands within the container. Distroless images typically contain only the application and its runtime dependencies, significantly lowering the risk of privilege escalation or lateral movement.

Answer

Always use the latest tag

Answer

Run containers as root

Answer

Run containers in privileged mode

Question 4

You run 'kube-bench' and see a failure: '1.2.7 Ensure that the --kubelet-client-certificate and --kubelet-client-key arguments are set as appropriate'. What is the impact of this misconfiguration?

Accepted Answer

The apiserver will use anonymous authentication when connecting to kubelets. When the API server lacks a properly configured client certificate and key for kubelet communication, it falls back to anonymous authentication when making requests to kubelets. This means the kubelet cannot verify the API server's identity, allowing any unauthenticated request to be processed, which violates the principle of mutual TLS (mTLS) and weakens cluster security.

Answer

The apiserver will use the kubelet's own certificate

Answer

The kubelet will refuse to register with the cluster

Answer

The apiserver will reject all requests to kubelets

Question 5

Which flag disables anonymous authentication on the API server?

Accepted Answer

--anonymous-auth=false. The `--anonymous-auth=false` flag explicitly disables anonymous authentication on the Kubernetes API server. When set to false, the API server will reject requests from unauthenticated users (those not presenting valid credentials), enforcing that all requests must be authenticated. This is a critical security hardening step to prevent anonymous access to the cluster's control plane.

Answer

--enable-admission-plugins=NodeRestriction

Answer

--authorization-mode=RBAC

Answer

--client-ca-file=<path>

Question 6

An administrator wants to secure etcd communication. Which of the following is required to enable TLS for client-to-etcd communication?

Accepted Answer

--cert-file= and --key-file=. To enable TLS for client-to-etcd communication, the etcd server must present a certificate to clients. The `--cert-file` and `--key-file` flags specify the server's TLS certificate and private key, which are required for the TLS handshake. Without these, etcd cannot serve HTTPS to clients.

Answer

Set ETCD_TLS_ENABLE=true environment variable

Answer

--client-cert-auth=true and --trusted-ca-file=<CA-file>

Answer

--tls-cert-file and --tls-key-file

Question 7

Which of the following is a recommended CIS benchmark setting for the kubelet?

Accepted Answer

--anonymous-auth=false. The CIS benchmark for Kubernetes recommends disabling anonymous authentication on the kubelet to ensure that all requests to the kubelet API are authenticated. Setting `--anonymous-auth=false` forces the kubelet to reject requests from unauthenticated users, preventing potential unauthorized access to node-level operations such as pod logs, exec, and port-forwarding.

Answer

--anonymous-auth=true

Answer

--protect-kernel-defaults=false

Answer

--read-only-port=10255

Question 8

A ClusterRole named 'secret-reader' is defined with rules to get, list, and watch secrets. A RoleBinding in namespace 'app' binds this ClusterRole to a service account. Which of the following best describes the permissions of the service account?

Accepted Answer

The service account can get, list, and watch secrets only in the 'app' namespace.. A RoleBinding in a specific namespace grants the permissions defined in the referenced ClusterRole, but only within that namespace. Since the RoleBinding is in the 'app' namespace, the service account receives the get, list, and watch permissions for secrets only within the 'app' namespace, not cluster-wide. This is the standard behavior of RoleBinding when binding to a ClusterRole.

Answer

The service account has no permissions because ClusterRole cannot be used with RoleBinding.

Answer

The service account can only get secrets in the 'app' namespace.

Answer

The service account can get, list, and watch secrets in all namespaces.

Question 9

An administrator runs `kube-bench` and sees that the check 'Ensure that the --protect-kernel-defaults flag is set to true' has failed. Which component does this check apply to?

Accepted Answer

Kubelet. The `--protect-kernel-defaults` flag is a kubelet-specific security option that ensures the kubelet does not modify kernel parameters that could weaken node security. When set to true, it enforces that the kubelet respects kernel defaults, preventing privilege escalation via sysctl overrides. This check is part of the CIS Benchmark for the kubelet component, not for etcd, the API server, or the controller manager.

Answer

etcd

Answer

API server

Answer

Controller manager

Question 10

Which TWO actions are recommended by the CIS Kubernetes Benchmark to secure the API server?

Accepted Answer

Set --authorization-mode=RBAC. The CIS Kubernetes Benchmark recommends setting `--authorization-mode=RBAC` to enforce role-based access control, which restricts API server access based on user roles and permissions. This ensures that only authorized users and service accounts can perform specific actions, aligning with the principle of least privilege.

Answer

Set --enable-admission-plugins=NodeRestriction

Answer

Set --authorization-mode=AlwaysAllow

Answer

Set --insecure-port=8080

Question 11

Given the following PodSecurityPolicy (PSP) snippet, which statement about the allowed containers is correct?

Accepted Answer

Containers cannot add any Linux capabilities. The PodSecurityPolicy snippet does not include `allowedCapabilities` or sets it to an empty list, and the `defaultAddCapabilities` is not specified, meaning no Linux capabilities are added by default. Additionally, the `requiredDropCapabilities` field is not present, but the absence of any allowed capabilities effectively prevents containers from adding any Linux capabilities beyond the default set, which is restricted by the PSP's `allowedCapabilities: []` or lack thereof. This enforces a strict security posture where containers cannot gain extra privileges via capabilities.

Answer

Containers can run in privileged mode

Answer

Containers cannot use ConfigMap volumes

Answer

Containers must run as the root user

Question 12

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

Accepted Answer

hostNetwork: false. 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.

Answer

hostIPC: false

Answer

hostNetwork: true

Answer

hostPID: false

Question 13

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 14

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 15

Which TWO of the following are true about AppArmor profiles in Kubernetes?

Accepted Answer

AppArmor profiles can be loaded in 'enforce' or 'complain' mode. AppArmor profiles operate in two modes: 'enforce' (where violations are blocked and logged) and 'complain' (where violations are only logged without blocking). This is a fundamental characteristic of AppArmor, and Kubernetes supports both modes when referencing profiles via annotations.

Answer

The profile name in the annotation should be just the profile name without the 'localhost/' prefix

Answer

The annotation key for a container is 'container.apparmor.security.beta.kubernetes.io/<profile_name>'

Answer

AppArmor profiles are automatically loaded from a ConfigMap

Question 16

Order the steps to configure and apply a NetworkPolicy to restrict pod-to-pod traffic.

Accepted Answer

Create the NetworkPolicy YAML manifest, then apply it using kubectl apply, then deploy test pods with appropriate labels, then verify connectivity using kubectl exec.. NetworkPolicy must be created and applied, then tested by deploying pods and checking connectivity. The policy is enforced immediately.

Answer

Apply the NetworkPolicy using kubectl apply, then create the YAML manifest, then deploy test pods, then verify connectivity.

Answer

Create the NetworkPolicy YAML, then deploy test pods, then apply the policy, then verify connectivity.

Answer

Deploy test pods, then create and apply the NetworkPolicy, then verify connectivity.

Question 17

A cluster has both ImagePolicyWebhook and a mutating webhook that adds a sidecar. The admin notices that even when ImagePolicyWebhook rejects an image, the mutating webhook has already added the sidecar. What admission ordering issue is occurring?

Accepted Answer

Validating webhooks should run before mutating webhooks. In Kubernetes, admission controllers are invoked in a fixed order: mutating admission controllers (including MutatingAdmissionWebhook) run before validating ones (including ImagePolicyWebhook and ValidatingAdmissionWebhook). Therefore, the mutating webhook that adds the sidecar runs before ImagePolicyWebhook validates the image. This means even if ImagePolicyWebhook rejects the image, the sidecar has already been added. The issue is that validating webhooks should run before mutating webhooks to prevent such problems, but the fixed order prevents this. Option B is wrong because using a validating webhook still runs after mutating webhooks. Option C is a workaround but not related to the ordering issue. Option D is incorrect because you cannot change the order of built-in admission controllers; the order is fixed.

Answer

Use a validating webhook instead of ImagePolicyWebhook

Answer

The mutating webhook should be configured to skip pods with certain images

Answer

The ImagePolicyWebhook should be placed before the mutating webhook in the webhook configuration

Question 18

Which tool can generate an SBOM for a container image?

Accepted Answer

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

Answer

Trivy

Answer

Cosign

Answer

Kubescape

Question 19

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

Accepted Answer

kubectl get pods -n kube-system kube-apiserver- -o yaml | grep anonymous-auth. The kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver- -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Answer

kubectl get --raw /api/v1

Answer

kubectl describe node | grep anonymous

Answer

kubectl cluster-info dump | grep -i anonymous

Question 20

Which kubectl command can be used to check the CIS benchmark compliance of a Kubernetes cluster?

Accepted Answer

kube-bench run --targets=master,worker. `kube-bench` is the official open-source tool from Aqua Security that runs CIS Kubernetes Benchmark checks against a cluster. It scans nodes by targeting specific roles (master, worker) and compares the cluster configuration against the CIS Benchmark controls, reporting pass/fail for each check.

Answer

kubectl security-check

Answer

kubectl cis-benchmark

Answer

kubectl audit cluster