Question 1

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_99_img_1.jpg Context A CIS Benchmark tool was run against the kubeadm-created cluster and found multiple issues that must be addressed immediately. Task Fix all issues via configuration and restart the affected components to ensure the new settings take effect. Fix all of the following violations that were found against the API server: https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_100_img_1.jpg Fix all of the following violations that were found against the Kubelet: https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_101_img_1.jpg https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_101_img_2.jpg Fix all of the following violations that were found against etcd: https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_102_img_1.jpg

Accepted Answer

1.  API SERVER: EDIT /ETC/KUBERNETES/MANIFESTS/KUBE-APISERVER.YAML AND ADD THE FOLLOWING FLAGS TO THE COMMAND LIST:
--AUTHORIZATION-MODE=NODE, RBAC
--ENCRYPTION-PROVIDER-CONFIG=/ETC/KUBERNETES/ENCRYPTION-CONFIG.YAML
--KUBELET-CLIENT-CERTIFICATE=/ETC/KUBERNETES/PKI/APISERVER-KUBELET-CLIENT.CRT
--KUBELET-CLIENT-KEY=/ETC/KUBERNETES/PKI/APISERVER-KUBELET-CLIENT.KEY
--PROFILING=FALSE
--SERVICE-ACCOUNT-LOOKUP=TRUE
--TLS-CIPHER-SUITES=TLSECDHEECDSAWITHAES128GCMSHA256, TLSECDHERSAWITHAES128GCMSHA256, TLSECDHEECDSAWITHCHACHA20POLY1305, TLSECDHERSAWITHCHACHA20POLY1305, TLSECDHEECDSAWITHAES256GCMSHA384, TLSECDHERSAWITHAES256GCMSHA384
CREATE THE ENCRYPTION FILE /ETC/KUBERNETES/ENCRYPTION-CONFIG.YAML WITH A VALID SECRET.
2.  KUBELET: EDIT /VAR/LIB/KUBELET/CONFIG.YAML TO SET:
AUTHORIZATION.MODE: WEBHOOK
AUTHENTICATION.X509.CLIENTCAFILE: /ETC/KUBERNETES/PKI/CA.CRT
PROTECTKERNELDEFAULTS: TRUE
READONLYPORT: 0
ROTATECERTIFICATES: TRUE
THEN, RESTART THE KUBELET: SYSTEMCTL RESTART KUBELET.
3.  ETCD: EDIT /ETC/KUBERNETES/MANIFESTS/ETCD.YAML AND ADD THE FOLLOWING FLAGS TO THE COMMAND LIST:
--AUTO-TLS=FALSE
--CLIENT-CERT-AUTH=TRUE
--PEER-AUTO-TLS=FALSE

Explanation: The specified modifications align the cluster's configuration with the Center for Internet Security (CIS) Kubernetes Benchmark security recommendations. For the API server, this involves enforcing strong authorization (Node,RBAC), enabling encryption at rest for secrets, disabling performance profiling, and restricting TLS to secure ciphers. For the Kubelet, the changes enforce webhook authorization, disable the insecure read-only port, and enable automatic certificate rotation. For etcd, the configuration ensures that client certificate authentication is mandatory and disables automatic, potentially insecure, TLS certificate generation. These adjustments harden the control plane and node components against identified security vulnerabilities. The static pod manifests and Kubelet configuration file are the correct locations for these changes in a kubeadm-managed cluster.

Question 2

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_31_img_1.jpg https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_31_img_2.jpg Two tools are pre-installed on the cluster's worker node: sysdig https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_1.jpg falco https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_2.jpg Using the tool of your choice (including any non pre-installed tool), analyze the container's behavior for at least 30 seconds, using filters that detect newly spawning and executing processes. Store an incident file at /opt/KSRS00101/alerts/details, containing the detected incidents, one per line, in the following format: https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_3.jpg The following example shows a properly formatted incident file: https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_4.jpg https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_5.jpg https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_32_img_6.jpg

Accepted Answer

BASH
MKDIR -P /OPT/KSRS00101/ALERTS && SYSDIG -P "%EVT.TIME %USER.NAME %PROC.CMDLINE" "CONTAINER.NAME=TERMINAL-APP AND EVT.TYPE=EXECVE" > /OPT/KSRS00101/ALERTS/DETAILS

Explanation: This command first ensures the target directory exists. It then uses sysdig to capture system call events. The filter container.name=terminal-app and evt.type=execve isolates events to the specified container and captures only execve system calls, which indicate a new process is being executed. The -p flag formats the output to match the required [time] [user] [command] structure using the fields %evt.time, %user.name, and %proc.cmdline. Finally, the output is redirected to the specified file. This command should be run on the worker node hosting the pod and stopped after at least 30 seconds of monitoring.

Question 3

use the Trivy to scan the following images,
1. amazonlinux:1
2. k8s.gcr.io/kube-controller-manager:v1.18.6
Look for images with HIGH or CRITICAL severity vulnerabilities and store the output of the same in
/opt/trivy-vulnerable.txt

Accepted Answer

BASH
TRIVY IMAGE --SEVERITY HIGH, CRITICAL AMAZONLINUX:1 > /OPT/TRIVY-VULNERABLE.TXT
TRIVY IMAGE --SEVERITY HIGH, CRITICAL K8S.GCR.IO/KUBE-CONTROLLER-MANAGER:V1.18.6 >> /OPT/TRIVY-VULNERABLE.TXT

Explanation: The task requires scanning two specified container images for vulnerabilities of HIGH or CRITICAL severity and saving the results. The trivy image command is used for this purpose. The --severity flag filters the output to show only vulnerabilities matching the provided comma-separated list (HIGH,CRITICAL). The first command scans amazonlinux:1 and redirects its output to /opt/trivy-vulnerable.txt using the > operator, which creates or overwrites the file. The second command scans k8s.gcr.io/kube-controller-manager:v1.18.6 and appends its output to the same file using the >> operator, ensuring that results from both scans are saved if both images contain matching vulnerabilities.

Question 4

You can switch the cluster/configuration context using the following command:
[desk@cli] $ kubectl config use-context test-account
Task: Enable audit logs in the cluster.
To do so, enable the log backend, and ensure that:
1. logs are stored at /var/log/Kubernetes/logs.txt
2. log files are retained for 5 days
3. at maximum, a number of 10 old audit log files are retained
A basic policy is provided at /etc/Kubernetes/logpolicy/audit-policy.yaml. It only specifies what not
to log.
Note: The base policy is located on the cluster's master node.
Edit and extend the basic policy to log:
1. Nodes changes at RequestResponse level
2. The request body of persistentvolumes changes in the namespace frontend
3. ConfigMap and Secret changes in all namespaces at the Metadata level
Also, add a catch-all rule to log all other requests at the Metadata level
Note: Don't forget to apply the modified policy.

Accepted Answer

THE FOLLOWING CONTENT SHOULD BE PLACED IN THE AUDIT POLICY FILE LOCATED AT /ETC/KUBERNETES/LOGPOLICY/AUDIT-POLICY.YAML:
YAML
APIVERSION: AUDIT.K8S.IO/V1
KIND: POLICY
RULES:
1. NODES CHANGES AT REQUESTRESPONSE LEVEL
- LEVEL: REQUESTRESPONSE
RESOURCES:
- GROUP: ""
RESOURCES: ["NODES"]
2. THE REQUEST BODY OF PERSISTENTVOLUMES CHANGES IN THE NAMESPACE FRONTEND
- LEVEL: REQUESTRESPONSE
RESOURCES:
- GROUP: ""
RESOURCES: ["PERSISTENTVOLUMES"]
NAMESPACES: ["FRONTEND"]
3. CONFIGMAP AND SECRET CHANGES IN ALL NAMESPACES AT THE METADATA LEVEL
- LEVEL: METADATA
RESOURCES:
- GROUP: ""
RESOURCES: ["SECRETS", "CONFIGMAPS"]
4. CATCH-ALL RULE TO LOG ALL OTHER REQUESTS AT THE METADATA LEVEL
- LEVEL: METADATA

Explanation: To enable and configure auditing, the Kubernetes API server's static pod manifest (/etc/kubernetes/manifests/kube-apiserver.yaml) must be modified. Add the following command-line arguments: --audit-policy-file=/etc/Kubernetes/logpolicy/audit-policy.yaml, --audit-log-path=/var/log/Kubernetes/logs.txt, --audit-log-maxage=5, and --audit-log-maxbackup=10. Additionally, ensure volumeMounts and corresponding hostPath volumes are configured for the policy file's directory (/etc/Kubernetes/logpolicy) and the log output directory (/var/log/Kubernetes). The provided YAML policy file implements the specific logging requirements. The rules are evaluated in order, with the final rule acting as a catch-all for any requests not matched by the preceding, more specific rules. The kubelet will automatically apply these changes by restarting the API server pod.

Question 5

a. Retrieve the content of the existing secret named default-token-xxxxx in the testing namespace. Store the value of the token in the token.txt b. Create a new secret named test-db-secret in the DB namespace with the following content: username: mysql password: password@123 Create the Pod name test-db-pod of image nginx in the namespace db that can access test-db-secret via a volume at path /etc/mysql-credentials

Accepted Answer

1. EXTRACT SERVICE-ACCOUNT TOKEN
KUBECTL -N TESTING GET SECRET $(KUBECTL -N TESTING GET SA DEFAULT -O JSONPATH='{.SECRETS0.NAME}') \
-O JSONPATH='{.DATA.TOKEN}' | BASE64 -D > TOKEN.TXT
2. CREATE THE SECRET IN NAMESPACE DB
KUBECTL -N DB CREATE SECRET GENERIC TEST-DB-SECRET \
--FROM-LITERAL=USERNAME=MYSQL \
--FROM-LITERAL=PASSWORD=PASSWORD@123
3. POD MANIFEST (SAVE AS TEST-DB-POD.YAML AND APPLY)
YAML
APIVERSION: V1
KIND: POD
METADATA:
NAME: TEST-DB-POD
NAMESPACE: DB
SPEC:
CONTAINERS:
- NAME: NGINX
IMAGE: NGINX
VOLUMEMOUNTS:
- NAME: MYSQL-CREDS
MOUNTPATH: /ETC/MYSQL-CREDENTIALS
READONLY: TRUE
VOLUMES:
- NAME: MYSQL-CREDS
SECRET:
SECRETNAME: TEST-DB-SECRET

KUBECTL APPLY -F TEST-DB-POD.YAML

Explanation: The first command fetches the name of the default service-account secret in the testing namespace, selects its base-64-encoded token field, decodes it, and saves it to token.txt. The create secret command places the required key/value pairs into a namespaced secret called test-db-secret. The Pod manifest mounts that secret as a volume, ensuring the nginx container can read the credentials from /etc/mysql-credentials as individual files (username, password) with default permissions. All steps follow Kubernetes’ documented methods for reading existing secrets, creating new secrets from literals, and consuming them as volumes inside Pods.

Question 6

Fix all issues via configuration and restart the affected components to ensure the new setting takes effect. Fix all of the following violations that were found against the API server:- a. Ensure that the RotateKubeletServerCertificate argument is set to true. b. Ensure that the admission control plugin PodSecurityPolicy is set. c. Ensure that the --kubelet-certificate-authority argument is set as appropriate. Fix all of the following violations that were found against the Kubelet:- a. Ensure the --anonymous-auth argument is set to false. b. Ensure that the --authorization-mode argument is set to Webhook. Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true b. Ensure that the --peer-auto-tls argument is not set to true Hint: Take the use of Tool Kube-Bench

Accepted Answer

[TRUE]

Explanation: The series of configuration changes listed in the prompt are standard security hardening practices for a Kubernetes cluster. Each specified argument and its recommended value directly corresponds to security controls designed to mitigate specific risks. These controls are outlined in authoritative security guides, such as the CIS (Center for Internet Security) Kubernetes Benchmark. API Server: Enabling RotateKubeletServerCertificate, setting a --kubelet-certificate-authority, and using appropriate admission controllers like PodSecurityPolicy (or its modern successor, Pod Security Admission) are critical for securing communication and enforcing workload policies. Kubelet: Disabling anonymous authentication (--anonymous-auth=false) and delegating authorization decisions to the API server (--authorization-mode=Webhook) are fundamental steps to ensure that only authenticated and authorized entities can interact with the Kubelet API. ETCD: Disabling automatic TLS (--auto-tls=false and --peer-auto-tls=false) prevents the use of insecure, automatically generated self-signed certificates, enforcing the use of a properly configured and trusted Public Key Infrastructure (PKI) for securing etcd communication.

Question 7

Create a new ServiceAccount named backend-sa in the existing namespace default, which has the
capability to list the pods inside the namespace default.
Create a new Pod named backend-pod in the namespace default, mount the newly created sa
backend-sa to the pod, and Verify that the pod is able to list pods.
Ensure that the Pod is running.

Accepted Answer

1. BACKEND-SA.YAML
---
APIVERSION: V1
KIND: SERVICEACCOUNT
METADATA:
NAME: BACKEND-SA
NAMESPACE: DEFAULT
---
APIVERSION: RBAC.AUTHORIZATION.K8S.IO/V1
KIND: ROLE
METADATA:
NAME: POD-LIST
NAMESPACE: DEFAULT
RULES:
- APIGROUPS: ""
RESOURCES: "PODS"
VERBS: "LIST"
---
APIVERSION: RBAC.AUTHORIZATION.K8S.IO/V1
KIND: ROLEBINDING
METADATA:
NAME: POD-LIST-BACKEND
NAMESPACE: DEFAULT
SUBJECTS:
- KIND: SERVICEACCOUNT
NAME: BACKEND-SA
NAMESPACE: DEFAULT
ROLEREF:
APIGROUP: RBAC.AUTHORIZATION.K8S.IO
KIND: ROLE
NAME: POD-LIST
---
APIVERSION: V1
KIND: POD
METADATA:
NAME: BACKEND-POD
NAMESPACE: DEFAULT
SPEC:
SERVICEACCOUNTNAME: BACKEND-SA
CONTAINERS:
- NAME: CLI
IMAGE: BITNAMI/KUBECTL:1.28
COMMAND: "SLEEP", "3600"
KUBECTL APPLY -F BACKEND-SA.YAML
VERIFY:
KUBECTL WAIT --FOR=CONDITION=READY POD/BACKEND-POD
KUBECTL EXEC BACKEND-POD -- KUBECTL GET PODS -N DEFAULT

Explanation: A ServiceAccount alone has no API permissions, so an in-namespace Role granting verb list on resource pods is created, then bound to backend-sa with a RoleBinding. The Pod specifies serviceAccountName: backend-sa; when the Pod starts, kube-api-server mounts the SA token automatically, enabling the container to authenticate. Using an image that already contains kubectl shows the SA can successfully call “kubectl get pods” within default, proving the Role works. Waiting for Ready ensures the Pod is running.

Question 8

Fix all issues via configuration and restart the affected components to ensure the new setting takes effect. Fix all of the following violations that were found against the API server:- a. Ensure the --authorization-mode argument includes RBAC b. Ensure the --authorization-mode argument includes Node c. Ensure that the --profiling argument is set to false Fix all of the following violations that were found against the Kubelet:- a. Ensure the --anonymous-auth argument is set to false. b. Ensure that the --authorization-mode argument is set to Webhook. Fix all of the following violations that were found against the ETCD:- a. Ensure that the --auto-tls argument is not set to true Hint: Take the use of Tool Kube-Bench

Accepted Answer

1. API-SERVER:
• EDIT /ETC/KUBERNETES/MANIFESTS/KUBE-APISERVER.YAML
--AUTHORIZATION-MODE=NODE, RBAC
--PROFILING=FALSE
2. KUBELET:
• EDIT /VAR/LIB/KUBELET/CONFIG.YAML
ANONYMOUS-AUTH: FALSE
AUTHORIZATION-MODE: WEBHOOK
• SYSTEMCTL RESTART KUBELET
3. ETCD:
• EDIT /ETC/KUBERNETES/MANIFESTS/ETCD.YAML
(DELETE --AUTO-TLS=TRUE OR SET --AUTO-TLS=FALSE)

Explanation: The API server must authorise requests with both the Node and RBAC plug-ins and disable performance profiling to comply with CIS 1.2 benchmarks. Kubelet should reject unauthenticated requests and delegate authorisation to the API-server via the Webhook mode. ETCD must not automatically generate server certificates because CIS 2.1.4 forbids --auto-tls=true; certificates should be supplied explicitly. Modifying the static-pod manifests under /etc/kubernetes/manifests/ triggers an automatic restart of those control-plane pods by kubelet, while a manual systemctl restart kubelet reloads its new configuration.

Question 9

https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_89_img_1.jpg Context This cluster uses containerd as CRI runtime. Containerd's default runtime handler is runc. Containerd has been prepared to support an additional runtime handler, runsc (gVisor). Task Create a RuntimeClass named sandboxed using the prepared runtime handler named runsc. Update all Pods in the namespace server to run on gVisor. https://kxbjsyuhceggsyvxdkof.supabase.co/storage/v1/object/public/file-images/Linux_CKS/page_90_img_1.jpg

Accepted Answer

1.  CREATE AND APPLY THE RUNTIMECLASS MANIFEST:
YAML
FILE: SANDBOXED-RC.YAML
APIVERSION: NODE.K8S.IO/V1
KIND: RUNTIMECLASS
METADATA:
NAME: SANDBOXED
HANDLER: RUNSC

BASH
KUBECTL APPLY -F SANDBOXED-RC.YAML

2.  PATCH THE EXISTING DEPLOYMENT TO USE THE NEW RUNTIMECLASS:
BASH
KUBECTL PATCH DEPLOYMENT NGINX-DEPLOYMENT -N SERVER --PATCH '{"SPEC":{"TEMPLATE":{"SPEC":{"RUNTIMECLASSNAME":"SANDBOXED"}}}}'

Explanation: The solution involves two main steps. First, a RuntimeClass object named sandboxed is created. This object acts as a cluster-level resource that maps a name (sandboxed) to a specific CRI handler (runsc), which is pre-configured in containerd. Second, the nginx-deployment in the server namespace is patched. The patch adds the runtimeClassName: sandboxed field to the Pod template spec (spec.template.spec). This instructs the Kubernetes scheduler and kubelet to use the runsc handler for all new Pods created by this Deployment, effectively running them in the gVisor sandbox. This triggers a rolling update of the Deployment, replacing the old Pods with new, sandboxed ones.

Question 10

Create a Pod name Nginx-pod inside the namespace testing, Create a service for the Nginx-pod named nginx-svc, using the ingress of your choice, run the ingress on tls, secure port.

Accepted Answer

FIRST, CREATE A TLS SECRET. THE INGRESS RESOURCE REQUIRES THIS FOR TLS TERMINATION.
BASH
CREATE A SELF-SIGNED CERTIFICATE AND PRIVATE KEY
OPENSSL REQ -X509 -NODES -DAYS 365 -NEWKEY RSA:2048 \
-KEYOUT TLS.KEY -OUT TLS.CRT -SUBJ "/CN=NGINX.EXAMPLE.COM"
CREATE THE KUBERNETES SECRET IN THE 'TESTING' NAMESPACE (AFTER CREATING IT)
KUBECTL CREATE SECRET TLS NGINX-TLS-SECRET --KEY TLS.KEY --CERT TLS.CRT -N TESTING

APPLY THE FOLLOWING KUBERNETES MANIFESTS:
YAML
1-NAMESPACE.YAML
APIVERSION: V1
KIND: NAMESPACE
METADATA:
NAME: TESTING
---
2-POD.YAML
APIVERSION: V1
KIND: POD
METADATA:
NAME: NGINX-POD
NAMESPACE: TESTING
LABELS:
APP: NGINX
SPEC:
CONTAINERS:
- NAME: NGINX
IMAGE: NGINX:1.25
PORTS:
- CONTAINERPORT: 80
---
3-SERVICE.YAML
APIVERSION: V1
KIND: SERVICE
METADATA:
NAME: NGINX-SVC
NAMESPACE: TESTING
SPEC:
SELECTOR:
APP: NGINX
PORTS:
- PROTOCOL: TCP
PORT: 80
TARGETPORT: 80
---
4-INGRESS.YAML
APIVERSION: NETWORKING.K8S.IO/V1
KIND: INGRESS
METADATA:
NAME: NGINX-INGRESS
NAMESPACE: TESTING
SPEC:
TLS:
- HOSTS:
- NGINX.EXAMPLE.COM
SECRETNAME: NGINX-TLS-SECRET
RULES:
- HOST: NGINX.EXAMPLE.COM
HTTP:
PATHS:
- PATH: /
PATHTYPE: PREFIX
BACKEND:
SERVICE:
NAME: NGINX-SVC
PORT:
NUMBER: 80

Explanation: The solution creates the required resources in a logical sequence. First, a Namespace isolates the components. A Pod running Nginx is created with a label app: nginx. A Service then targets this pod using the label selector, providing a stable internal endpoint. For TLS, a Kubernetes Secret of type kubernetes.io/tls is created from a pre-generated certificate and key. Finally, the Ingress resource is defined. Its tls section references the secret to secure traffic for the specified host (nginx.example.com), and its rules section routes external traffic from that host to the internal nginx-svc. This configuration ensures traffic is served over a secure port (HTTPS/443).

Free Linux CKS Actual Exam Questions