CKS Exam Preparation with Solutions: Pass the CKS Exam in 2023

One thought on “CKS Exam Preparation with Solutions: Pass the CKS Exam in 2023”

• Example questions (from various online resources):
  1.
  
  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).

  2.

  Create a new ServiceAccount named frontend-sa in the existing namespace dev. Ensure the ServiceAccount does not automount API credentials.
  
  Using the manifest file at /home/candidate/KSCH00301/app.yaml, create the Pod.
  
  Finally, clean up any unused ServiceAccounts in namespace dev.
  
  Using the manifest file at /home/candidate/KSCH00301/app.yaml, create the Pod.

  3.
  
  Fix all issues via configuration and restart the affected components to ensure the new setting effect.
  
  Fix the following violations that were found against the API server:

  – Ensure that the –authorization-mode argument is not set to AlwaysAllow
  
  – Ensure that the authorization-mode argument includes Node
  
  – Ensure that the –authorization-mode argument includes RBAC

  Use Webhook authentication/authorization where possible.

  4.
  
  "Create a default-deny NetworkPolicy named denypolicy in the namespace development traffic of type Egress.

  The new NetworkPolicy must deny all Egress traffic in the namespace development.

  Apply the newly created default-deny NetworkPolicy to all Pods running in namespace development"

  5.
  
  Create a new PodSecurityPolicy named deny-policy, which prevents the creation of privileged

  Create a new ClusterRole named deny-access-role, which uses the newly created PodSecurity deny-policy.

  Create a new ServiceAccount named psp-restrict-sa in the existing namespace staging.

  Finally, create a new ClusterRoleBinding named deny-access-bind, which binds the newly created ClusterRole deny-access-role to the newly created ServiceAccount psp-restrict-sa.

  6.
  
  Create a new ServiceAccount named frontend-sa in the existing namespace dev. Ensure the ServiceAccount does not automount API credentials.
  
  Using the manifest file at /home/candidate/KSCH00301/app.yaml, create the Pod.
  
  Finally, clean up any unused ServiceAccounts in namespace dev.
  
  Using the manifest file at /home/candidate/KSCH00301/app.yaml, create the Pod.

  7.
  
  Given an existing Pod named web-pod running in the namespace security.

  Edit the existing Role bound to the Pod's ServiceAccount sa-dev-1 to only allow performing watch operations, only on resources of type services.

  Create a new Role named role-2 in the namespace security, which only allows performing update

  operations, only on resources of type namespaces.

  Create a new RoleBinding named role-2-binding binding the newly created Role to the Pod's ServiceAccount.

  8.
  
  Enable audit logs in the cluster, To Do so, enable the log backend, and ensure that

  logs are stored at /var/log/kubernetes-logs.txt.
  
  Log files are retained for 12 days.
  
  at maximum, a number of 8 old audit logs files are retained.
  
  set the maximum size before getting rotated to 200MB
  
  Edit and extend the basic policy to log:

  namespaces changes at RequestResponse
  
  Log the request body of secrets changes in the namespace kube-system.
  
  Log all other resources in core and extensions at the Request level.
  
  Log "pods/portforward", "services/proxy" at Metadata level.
  
  Omit the Stage RequestReceived
  
  All other requests at the Metadata level

  9.

  Cluster: dev

  Master node:master1 Worker node:worker1

  You can switch the cluster/configuration context using the following command: [desk@cli] $kubectl config use-context dev

  Task: Retrieve the content of the existing secret namedadamin thesafenamespace.

  Store the username field in a file names/home/cert-masters/username.txt, and the password field in a file named/home/cert-masters/password.txt.

  1. You must create both files; they don't exist yet. 2. Do not use/modify the created files in the following steps, create new temporary files if needed.

  Create a new secret namesnewsecretin thesafenamespace, with the following content: Username:dbadmin Password:moresecurepas

  Finally, create a new Pod that has access to the secretnewsecretvia a volume:

  Namespace: safe

  Pod name: mysecret-pod

  Container name: db-container

  Image: redis

  Volume name: secret-vol

  Mount path: /etc/mysecret

  10)
  
  Analyze and edit the given Dockerfile /home/candidate/KSSC00301/Docker file (based on the ubuntu:16.04 image), fixing two instructions present in the file that are prominent security/best-practice issues.

  Analyze and edit the given manifest file /home/candidate/KSSC00301/deployment.yaml, fixing two fields present in the file that are prominent security/best-practice issues.

  11.
  
  Use detection tools to detect anomalies like processes spawning and executing something weird frequently in the single container belonging to Podtomcat.

  Two tools are available to use:

  1. falco

  2. sysdig

  Tools are pre-installed on the worker1 node only.

  Analyse the container's behaviour for at least 40 seconds, using filters that detect newly spawning and executing processes.

  Store an incident file at/home/cert_masters/report, in the following format:

  [timestamp],[uid],[processName]

  Note:Make sure to store incident file on the cluster's worker node, don't move it to master node.

  12.

  A container image scanner is set up on the cluster, but it's not yet fully integrated into the cluster s configuration. When complete, the container image scanner shall scan for and reject the use of vulnerable images.

  Task

  Given an incomplete configuration in directory /etc/kubernetes/epconfig and a functional container image scanner with HTTPS endpoint https://wakanda.local:8081 /image_policy :

  1. Enable the necessary plugins to create an image policy
  
  2. Validate the control configuration and change it to an implicit deny
  
  3. Edit the configuration to point to the provided HTTPS endpoint correctly
  
  Finally, test if the configuration is working by trying to deploy the vulnerable resource /root/KSSC00202/vulnerable-resource.yml.

  13.
  
  Use the Trivy open-source container scanner to detect images with severe vulnerabilities used by Pods in the namespace nato.
  
  Look for images with High or Critical severity vulnerabilities and delete the Pods that use those images.
  
  Trivy is pre-installed on the cluster's master node. Use cluster's master node to use Trivy.

  14.
  
  On the worker1 node,
  
  1. Enforce the prepared AppArmor profile located at:/etc/apparmor.d/nginx
  
  2. Edit the prepared manifest file located at/home/cert_masters/nginx.yamlto apply the apparmor profile
  
  3. Create the Pod using this manifest

Comments are closed.