CKS Timed Practice Test 4 — 10 Questions

Question 1

An administrator runs 'kube-bench run --targets=master' and sees a failing check for 'Ensure that the --audit-log-path argument is set'. What is the correct remediation?

Accepted Answer

Add '--audit-log-path=/var/log/audit.log' to the kube-apiserver. The kube-bench check for 'Ensure that the --audit-log-path argument is set' specifically targets the kube-apiserver component, as it is the primary component that handles API requests and should log them for audit purposes. The correct remediation is to add '--audit-log-path=/var/log/audit.log' to the kube-apiserver's startup arguments, which enables writing audit logs to a specified file path. This ensures that all API server requests are recorded for security monitoring and compliance.

Answer

Add '--audit-policy-file=/etc/kubernetes/audit-policy.yaml' to the API server

Answer

Add '--audit-log-path=/var/log/audit.log' to the kube-controller-manager

Answer

Add '--audit-log-maxsize=100' to the API server

Question 2

What is the recommended way to provide TLS certificates to the API server?

Accepted Answer

Use --tls-cert-file and --tls-private-key-file flags. The recommended way to provide TLS certificates to the API server is by using the `--tls-cert-file` and `--tls-private-key-file` flags. These flags explicitly point the kube-apiserver to the certificate and key files, ensuring the server presents a valid TLS certificate for encrypted HTTPS communication. This is the standard, documented method for configuring TLS on the API server, as it allows the server to authenticate itself to clients.

Answer

Store certificates in a ConfigMap and mount them

Answer

Place certificates in /etc/kubernetes/pki/ without additional flags

Answer

Use --client-ca-file only

Question 3

A cluster administrator wants to ensure that pods cannot modify node objects. Which admission plugin should be enabled?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the kubelet's ability to modify node and pod objects to only those nodes it is authorized to manage. This prevents a compromised or misconfigured kubelet from modifying arbitrary node objects, enforcing the principle of least privilege. Option D is correct because it directly addresses the requirement to restrict node object modifications.

Answer

PodSecurityPolicy

Answer

NodeAffinity

Answer

PodNodeSelector

Question 4

You are asked to ensure that a specific Kubernetes dashboard (e.g., kubernetes-dashboard) is not publicly accessible. The dashboard is deployed in the 'kube-system' namespace. Which NetworkPolicy should you apply?

Accepted Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: []. Option B is correct because a NetworkPolicy with an empty `ingress` array (i.e., `ingress: []`) explicitly denies all inbound traffic to the selected pods. This ensures that the kubernetes-dashboard pod in the kube-system namespace is not publicly accessible, as no ingress rules are defined to allow any source. By default, if no NetworkPolicy selects a pod, all traffic is allowed; applying this policy changes the default to deny for ingress.

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{namespaceSelector: {matchLabels: {}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Ingress], ingress: [{from: [{podSelector: {matchLabels: {app: kubernetes-dashboard}}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: kubernetes-dashboard, policyTypes: [Egress], egress: [{to: [{podSelector: {}}]}]

Question 5

You want to ensure that kubelets only serve pods that have been scheduled by the API server. Which admission plugin should be enabled?

Accepted Answer

NodeRestriction. The NodeRestriction admission plugin limits the Node and Pod objects a kubelet can modify. When enabled, each kubelet can only create/modify pods bound to its own node, and only pods that have been scheduled by the API server (i.e., have a non-empty `spec.nodeName` set by the scheduler). This prevents a compromised kubelet from creating arbitrary pods or modifying pods on other nodes, enforcing that only the API server schedules pods.

Answer

ServiceAccount

Answer

AlwaysPullImages

Answer

PodNodeSelector

Question 6

Which THREE of the following are valid methods to restrict access to etcd in a Kubernetes cluster? (Select THREE)

Accepted Answer

Use TLS certificates for client and server authentication. Option A is correct because etcd supports mutual TLS (mTLS) authentication, where both the client (e.g., kube-apiserver) and the etcd server present TLS certificates to verify each other's identity. This is the standard and recommended method for securing communication between the API server and etcd, as it prevents unauthorized clients from accessing the key-value store and ensures data-in-transit encryption.

Answer

Use simple username and password authentication

Answer

Put etcd on the same network as the API server without firewall

Question 7

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. Option C is correct because 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 8

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

Accepted Answer

Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config. Option B is correct because etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

Answer

Use etcdctl to encrypt the data directory

Answer

Set --encryption-provider=secretbox on etcd

Answer

Set ETCD_ENABLE_ENCRYPTION=true environment variable

Question 9

Which THREE of the following are valid ways to restrict access to etcd? (Select 3)

Accepted Answer

Enable etcd RBAC to restrict read/write access. Option A is correct because etcd supports Role-Based Access Control (RBAC) that allows you to define roles and permissions to restrict read and write access to keys. By enabling etcd RBAC, you can enforce fine-grained authorization, ensuring that only authenticated and authorized clients (e.g., the Kubernetes API server) can perform specific operations on etcd data.

Answer

Use HTTP instead of HTTPS

Answer

Disable client authentication for simplicity

Question 10

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?

Accepted Answer

--anonymous-auth=false and --authorization-mode=Webhook. Option D is correct because 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.

Answer

--anonymous-auth=false and --authorization-mode=RBAC

Answer

--anonymous-auth=true and --authorization-mode=ABAC

Answer

--anonymous-auth=false and --authorization-mode=AlwaysAllow