Home / Linux Foundation / CKS

Linux Foundation CKS Practice Test - Questions Answers, Page 4

Question list

List of questions

Question 31

(0)

You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context qa Context: A pod fails to run because of an incorrectly specified ServiceAcc

Question 32

(0)

You must complete this task on the following cluster/nodes: Cluster: trace Master node: master Worker node: worker1 You can switch the cluster/configuration context using the following command:

Question 33

(0)

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

Question 34

(0)

Cluster: scanner Master node: controlplane Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context scanner Giv

Question 35

(0)

Context: Cluster: gvisor Master node: master1 Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context gvisor

Question 36

(0)

You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context prod-account Context: A Role bound to a Pod's ServiceAccount grants overly pe

Question 37

(0)

You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context dev Context: A CIS Benchmark tool was run against the kubeadm created cluster

Question 38

(0)

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 C

Question 39

(0)

Context Your organization’s security policy includes: ServiceAccounts must not automount API credentials ServiceAccount names must end in "-sa" The Pod specified in the manifest file /home/can

Question 40

(0)

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 affe

Related questions

Context AppArmor is enabled on the cluster's worker node. An AppArmor profile is prepared, but not enforced yet. Task On the cluster's worker node, enforce the prepared AppArmor profile located at /etc/apparmor.d/nginx_apparmor. Edit the prepared manifest file located at /home/candidate/KSSH00401/nginx-pod.yaml to apply the AppArmor profile. Finally, apply the manifest file and create the Pod specified in it.

Use the kubesec docker images to scan the given YAML manifest, edit and apply the advised changes, and passed with a score of 4 points. kubesec-test.yaml apiVersion: v1 kind: Pod metadata: name: kubesec-demo spec: containers: - name: kubesec-demo image: gcr.io/google-samples/node-hello:1.0 securityContext: readOnlyRootFilesystem: true Hint: docker run -i kubesec/kubesec:512c5e0 scan /dev/stdin < kubesec-test.yaml

Create a User named john, create the CSR Request, fetch the certificate of the user after approving it. Create a Role name john-role to list secrets, pods in namespace john Finally, Create a RoleBinding named john-role-binding to attach the newly created role john-role to the user john in the namespace john. To Verify: Use the kubectl auth CLI command to verify the permissions.

Cluster: scanner Master node: controlplane Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context scanner Given: You may use Trivy's documentation. Task: 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.

You must complete this task on the following cluster/nodes: Cluster: immutable-cluster Master node: master1 Worker node: worker1 You can switch the cluster/configuration context using the following command: [desk@cli] $ kubectl config use-context immutable-cluster Context: It is best practice to design containers to be stateless and immutable. Task: Inspect Pods running in namespace prod and delete any Pod that is either not stateless or not immutable. Use the following strict interpretation of stateless and immutable: 1. Pods being able to store data inside containers must be treated as not stateless. Note: You don't have to worry whether data is actually stored inside containers or not already. 2. Pods being configured to be privileged in any way must be treated as potentially not stateless or not immutable.

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.

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

Context 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 correctlyFinally, test if the configuration is working by trying to deploy the vulnerable resource /root/KSSC00202/vulnerable-resource.yml.

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

On the Cluster worker node, enforce the prepared AppArmor profile #include <tunables/global> profile nginx-deny flags=(attach_disconnected) { #include <abstractions/base> file, # Deny all file writes. deny /** w, } EOF' Edit the prepared manifest file to include the AppArmor profile. apiVersion: v1 kind: Pod metadata: name: apparmor-pod spec: containers: - name: apparmor-pod image: nginx Finally, apply the manifests files and create the Pod specified on it. Verify: Try to make a file inside the directory which is restricted. Answer: See explanation below.

Question 31

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context qa

Context:

A pod fails to run because of an incorrectly specified ServiceAccount Task:

Create a new service account named backend-qa in an existing namespace qa, which must not have access to any secret.

Edit the frontend pod yaml to use backend-qa service account

Note: You can find the frontend pod yaml at /home/cert_masters/frontend-pod.yaml

See the explanation

Show Answer Comment (0)

Question 32

You must complete this task on the following cluster/nodes:

Cluster: trace

Master node: master

Worker node: worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context trace

Given: You may use Sysdig or Falco documentation.

Task:

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

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.

See the explanation

Show Answer Comment (0)

Question 33

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 named adam in the safe namespace.

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 names newsecret in the safe namespace, with the following content:

Username: dbadmin

Password: moresecurepas

Finally, create a new Pod that has access to the secret newsecret via a volume:

Namespace: safe

Pod name: mysecret-pod

Container name: db-container

Image: redis

Volume name: secret-vol

Mount path: /etc/mysecret

See the explanation

Show Answer Comment (0)

Question 34

Cluster: scanner

Master node: controlplane

Worker node: worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context scanner

Given:

You may use Trivy's documentation.

Task:

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.

See the explanation

Show Answer Comment (0)

Question 35

Context:

Cluster: gvisor

Master node: master1

Worker node: worker1

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context gvisor

Context: This cluster has been prepared to support runtime handler, runsc as well as traditional one.

Task:

Create a RuntimeClass named not-trusted using the prepared runtime handler names runsc.

Update all Pods in the namespace server to run on newruntime.

See the explanation

Show Answer Comment (0)

Question 36

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context prod-account

Context:

A Role bound to a Pod's ServiceAccount grants overly permissive permissions. Complete the following tasks to reduce the set of permissions.

Task:

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

1. Edit the existing Role bound to the Pod's ServiceAccount test-sa to only allow performing get operations, only on resources of type Pods.

2. Create a new Role named test-role-2 in the namespace database, which only allows performing update operations, only on resources of type statuefulsets.

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

Note: Don't delete the existing RoleBinding.

See the explanation

Show Answer Comment (0)

Question 37

You can switch the cluster/configuration context using the following command:

[desk@cli] $ kubectl config use-context dev

Context:

A CIS Benchmark tool was run against the kubeadm created cluster and found multiple issues that must be addressed.

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:

1.2.7 authorization-mode argument is not set to AlwaysAllow FAIL

1.2.8 authorization-mode argument includes Node FAIL

1.2.7 authorization-mode argument includes RBAC FAIL

Fix all of the following violations that were found against the Kubelet:

4.2.1 Ensure that the anonymous-auth argument is set to false FAIL

4.2.2 authorization-mode argument is not set to AlwaysAllow FAIL (Use Webhook autumn/authz where possible) Fix all of the following violations that were found against etcd:

2.2 Ensure that the client-cert-auth argument is set to true

See the explanation

Show Answer Comment (0)

Question 38

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.

See the explanation

Show Answer Comment (0)

Question 39

Context

Your organization’s security policy includes:

ServiceAccounts must not automount API credentials

ServiceAccount names must end in "-sa"

The Pod specified in the manifest file /home/candidate/KSCH00301 /pod-m nifest.yaml fails to schedule because of an incorrectly specified ServiceAccount.

Complete the following tasks:

Task

1. Create a new ServiceAccount named frontend-sa in the existing namespace q a. Ensure the ServiceAccount does not automount API credentials.

2. Using the manifest file at /home/candidate/KSCH00301 /pod-manifest.yaml, create the Pod.

3. Finally, clean up any unused ServiceAccounts in namespace qa.

See the explanation

Show Answer Comment (0)