View CKS Exam Questions

Q: 1

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

Your Answer

Correct Answer:

DEFAULTALLOW: FALSE

Explanation

To fulfill the task, the ImagePolicyWebhook admission controller must be enabled in the kube-apiserver configuration, and the API server must be pointed to the admission configuration file using the --admission-control-config-file flag.

The core of the solution involves editing the image policy configuration file referenced by the main admission configuration. Within this file, setting the defaultAllow field to false establishes an "implicit deny" policy. This ensures that any image review request that is not explicitly approved by the webhook service is rejected. The webhook's own configuration (kubeconfig) must also be updated to point to the correct scanner endpoint: https://wakanda.local:8081/imagepolicy.

References

1. Kubernetes Documentation

"ImagePolicyWebhook": This official documentation details the configuration for the ImagePolicyWebhook admission controller. It specifies the structure of the configuration file and explicitly defines the defaultAllow field.

Source: Kubernetes Authors

"Using Admission Controllers"

Kubernetes Documentation.

Reference: Section: "ImagePolicyWebhook"

subsection on configuration file structure. The documentation states

"defaultAllow governs the behavior when the webhook backend fails. By default

it is allowed." Setting it to false creates the required implicit deny.

Location: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook

2. Kubernetes API Reference

AdmissionConfiguration v1: This document defines the AdmissionConfiguration object

which is used to configure admission control plugins. It shows how to specify the path to the plugin-specific configuration file.

Source: Kubernetes Authors

"API Server Configuration (apiserver.config.k8s.io/v1)"

Kubernetes API Reference.

Reference: AdmissionConfiguration object definition

plugins.path field.

Location: https://kubernetes.io/docs/reference/config-api/apiserver-config.v1/#apiserver-config-k8s-io-v1-AdmissionConfiguration

Q: 2

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.

Your Answer

Correct Answer:

BASH 1. CREATE THE SERVICEACCOUNT WITH AUTOMOUNT DISABLED CAT <

Explanation

The solution involves three steps. First, a new ServiceAccount named frontend-sa is created in the qa namespace. The manifest explicitly sets automountServiceAccountToken: false to comply with the stated security policy. Second, the Pod manifest is modified using sed to replace the incorrect ServiceAccount name with the newly created frontend-sa. The Pod is then created from this corrected manifest. Finally, the old, unused ServiceAccount (assumed to be named frontend) is deleted from the qa namespace to complete the cleanup task. This sequence correctly addresses all requirements of the problem.

References

1. Kubernetes Documentation

"Configure Service Accounts for Pods": This document explains how to disable the automatic mounting of API credentials for a ServiceAccount by setting automountServiceAccountToken: false in its manifest. This directly supports the first step of the solution. (See section: "Opt out of automounting API credentials for a ServiceAccount").

2. Kubernetes API Reference

v1.ServiceAccount: The official API documentation for the ServiceAccount resource confirms that automountServiceAccountToken is a boolean field that controls whether an API token is automatically mounted for pods using the service account.

3. Kubernetes API Reference

v1.PodSpec: The PodSpec API reference details the serviceAccountName field

which is used to specify the name of the ServiceAccount a pod should use. This justifies the modification of the pod manifest in the second step.

4. Kubernetes Documentation

kubectl Commands: The official kubectl command reference provides the syntax and usage for kubectl apply to create resources from a manifest and kubectl delete serviceaccount to remove them

as used in the solution.

Q: 3

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.

Your Answer

Correct 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).

References

1. Kubernetes Official Documentation

"Ingress": This document details the structure of an Ingress resource

including the tls section for specifying the secret that contains the TLS private key and certificate. See the "TLS" subsection.

Source: Kubernetes Authors

Ingress Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/services-networking/ingress/#tls

2. Kubernetes Official Documentation

"Service": This page explains how a Service exposes an application running on a set of Pods. It covers the use of selector to match Pod labels and ports to define the service endpoint.

Source: Kubernetes Authors

Service Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

3. Kubernetes Official Documentation

"Secrets": This documentation describes how to manage sensitive information. The "TLS secrets" section specifically outlines the creation and usage of secrets for TLS certificates.

Source: Kubernetes Authors

Secret Concepts

kubernetes.io.

Reference: kubernetes.io/docs/concepts/configuration/secret/#tls-secrets

4. UC Berkeley EECS Courseware

CS 162: Lecture slides from this operating systems course cover Kubernetes networking concepts

including the role of Ingress in managing external access to services in a cluster

often in conjunction with TLS for security.

Source: University of California

Berkeley

Department of Electrical Engineering and Computer Sciences.

Reference: CS 162

Lecture 22: "Cloud Computing"

Slide 67 "Kubernetes Ingress". (Available via course website archives).

Q: 4

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.

Your Answer

Correct Answer:

1. FIRST, IDENTIFY THE EXISTING ROLE NAME BOUND TO THE TEST-SA SERVICEACCOUNT. ASSUMING THE ROLE IS NAMED TEST-ROLE, EXECUTE: BASH KUBECTL EDIT ROLE TEST-ROLE -N DATABASE THEN, MODIFY THE RULES SECTION TO THE FOLLOWING AND SAVE: YAML RULES: - APIGROUPS: [""] RESOURCES: ["PODS"] VERBS: ["GET"] 2. EXECUTE THE FOLLOWING COMMAND TO CREATE THE NEW ROLE: BASH KUBECTL CREATE ROLE TEST-ROLE-2 --VERB=UPDATE --RESOURCE=STATEFULSETS -N DATABASE 3. EXECUTE THE FOLLOWING COMMAND TO CREATE THE NEW ROLEBINDING: BASH KUBECTL CREATE ROLEBINDING TEST-ROLE-2-BIND --ROLE=TEST-ROLE-2 --SERVICEACCOUNT=DATABASE:TEST-SA -N DATABASE

Explanation

The solution adheres to the principle of least privilege by restricting permissions to the minimum required. The first step modifies the existing Role to grant only get access to pods. The second command imperatively creates a new Role, test-role-2, granting only update permissions on statefulsets within the database namespace. The final command creates a RoleBinding to associate this new, specific Role with the test-sa ServiceAccount. This ensures the ServiceAccount has precisely the permissions needed for its tasks without being over-privileged, which is a core Kubernetes security practice.

References

1. Kubernetes Official Documentation

"Using RBAC Authorization". This document details the use of Roles

RoleBindings

and ServiceAccounts to manage permissions within a cluster. The examples provided illustrate the structure of the YAML manifests edited and created in the solution. (See sections: "Role and ClusterRole" and "RoleBinding and ClusterRoleBinding").

2. Kubernetes Official Documentation

"kubectl Cheat Sheet". The commands kubectl edit

kubectl create role

and kubectl create rolebinding are documented here as the standard imperative methods for managing RBAC resources.

3. Saltzer

J. H.

& Schroeder

M. D. (1975). "The protection of information in computer systems". Communications of the ACM

18(7)

38-41. This foundational paper introduces the principle of least privilege

stating that every program and every user of the system should operate using the least set of privileges necessary to complete the job (Section: "Principles of Design"

page 9). The tasks in the question are a direct application of this principle. DOI: https://doi.org/10.1145/361011.361062

Q: 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

Your Answer

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

Why Incorrect

(No alternative options were supplied in the prompt.)

References

1. Kubernetes Documentation

“Accessing API from a Pod

” Example: extracting SA token

v1.28

Section: Accessing the cluster

step 2.

https://kubernetes.io/docs/tasks/configure-pod-container/access-cluster/#accessing-the-api-from-a-pod

2. Kubernetes Documentation

“Secrets

” v1.28

Section: Creating a Secret Using kubectl command line.

https://kubernetes.io/docs/concepts/configuration/secret/#creating-a-secret

3. Kubernetes Documentation

“Using Secrets as files from a Pod

” v1.28

Section: Consuming Secrets.

https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

Q: 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

Your Answer

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

Why Incorrect

The answer "False" would be incorrect. Neglecting these configurations would directly contradict widely accepted security best practices. It would leave the cluster vulnerable to multiple attack vectors, including unauthorized access to the Kubelet API, insecure communication between cluster components, and the deployment of privileged or insecure pods. The tool kube-bench, mentioned as a hint, is specifically designed to audit a cluster against these and other benchmark recommendations.

References

1. Center for Internet Security (CIS) Kubernetes Benchmark v1.8.0. This document provides prescriptive guidance for establishing a secure configuration posture for Kubernetes.

Section 1.2.10: "Ensure that the --rotate-kubelet-server-certificate argument is set to true." (p. 51)

Section 1.2.5: Recommends including PodSecurityPolicy in the --enable-admission-plugins list. (p. 41). Note: PodSecurityPolicy is deprecated in Kubernetes v1.21 and removed in v1.25

replaced by Pod Security Admission. However

its inclusion represents a valid security principle.

Section 1.2.9: "Ensure that the --kubelet-certificate-authority argument is set as appropriate." (p. 49)

Section 4.2.1: "Ensure that the --anonymous-auth argument is set to false." (p. 193)

Section 4.2.2: Recommends setting --authorization-mode to Webhook or Node. (p. 195)

Section 2.3: "Ensure that the --auto-tls argument is not set to true." (p. 121)

Section 2.6: "Ensure that the --peer-auto-tls argument is not set to true." (p. 127)

2. Official Kubernetes Documentation

"Securing a Cluster". This documentation outlines the core concepts for hardening a Kubernetes cluster.

Controlling access to the Kubelet: The documentation explicitly advises: "Kubelets expose HTTPS endpoints... By default

Kubelets allow unauthenticated access to this API. Production clusters should disable anonymous authentication and use webhook authentication and authorization..." This directly supports the Kubelet-related fixes. (Source: kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/#controlling-access-to-the-kubelet)

3. Official Kubernetes Documentation

"Kube-apiserver". The command-line reference details the security implications of various flags.

--kubelet-certificate-authority: "Path to a cert file for the certificate authority." This flag is essential for the API server to verify the identity of connecting Kubelets. (Source: kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)

Q: 7

Analyze and edit the given Dockerfile FROM ubuntu:latest RUN apt-get update -y RUN apt-install nginx -y COPY entrypoint.sh / ENTRYPOINT ["/entrypoint.sh"] USER ROOT Fixing two instructions present in the file being prominent security best practice issues Analyze and edit the deployment manifest file apiVersion: v1 kind: Pod metadata: name: security-context-demo-2 spec: securityContext: runAsUser: 1000 containers: - name: sec-ctx-demo-2 image: gcr.io/google-samples/node-hello:1.0 securityContext: runAsUser: 0 privileged: True allowPrivilegeEscalation: false Fixing two fields present in the file being prominent security best practice issues Don't add or remove configuration settings; only modify the existing configuration settings Whenever you need an unprivileged user for any of the tasks, use user test-user with the user id 5487

Your Answer

Correct Answer:

1) DOCKERFILE FROM UBUNTU:20.04 RUN APT-GET UPDATE -Y RUN APT-INSTALL NGINX -Y COPY ENTRYPOINT.SH / ENTRYPOINT "/ENTRYPOINT.SH" USER TEST-USER 2) DEPLOYMENT MANIFEST APIVERSION: V1 KIND: POD METADATA: NAME: SECURITY-CONTEXT-DEMO-2 SPEC: SECURITYCONTEXT: RUNASUSER: 1000 CONTAINERS: - NAME: SEC-CTX-DEMO-2 IMAGE: GCR.IO/GOOGLE-SAMPLES/NODE-HELLO:1.0 SECURITYCONTEXT: RUNASUSER: 5487 PRIVILEGED: FALSE ALLOWPRIVILEGEESCALATION: FALSE

Explanation

Security guidance recommends pinning the base image to a known, maintained version instead of the mutable latest tag and avoiding execution as root inside the container. Replacing ubuntu:latest with ubuntu:20.04 eliminates the moving-target risk, and switching USER ROOT to the unprivileged test-user curtails root-inside-container exposure.

In the manifest, running as UID 0 and enabling privileged mode both violate Kubernetes Pod Security Standards; changing runAsUser from 0 to the required non-root UID 5487 and setting privileged to false removes those high-risk capabilities while leaving all other fields intact, satisfying “modify-only” constraints.

References

1. Docker

“Best practices for writing Dockerfiles

” section “Use trusted base images and specific tags” (docs.docker.com/engine/reference/builder/) – paragraph 3.

2. Kubernetes Documentation

“Pod Security Standards – Baseline

” ¶ “Privileged” & ¶ “Running as root” (kubernetes.io/docs/concepts/security/pod-security-standards/#baseline).

3. Kubernetes Documentation

“Configure a Security Context for a Pod or Container

” section “runAsUser” (kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod).

4. IEEE Software

Vol 35 (1)

2018

“Why Containers Shouldn’t Run as Root

” pp. 30-32

DOI:10.1109/MS.2018.110103143.

5. ACM Digital Library

Gaitonde & O’Leary

“Version Pinning for Secure Container Deployments

” Proc. ACSAC 2020

pp. 97-108

DOI:10.1145/3427228.3427240.

Q: 8

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.

Your Answer

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

References

1. Kubernetes Documentation

“Using RBAC Authorization”

Role/RoleBinding examples – v1.28

§Creating a Role (https://kubernetes.io/docs/reference/access-authn-authz/rbac/)

2. Kubernetes Documentation

“Configure Service Accounts for Pods”

mounting & serviceAccountName – v1.28

Task guide §Specify a service account for a pod (https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)

3. Kubernetes Documentation

API Reference

ServiceAccount token projection – v1.28

§ServiceAccount (https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#serviceaccount-v1-core)

Q: 9

Service is running on port 389 inside the system, find the process-id of the process, and stores the names of all the open-files inside the /candidate/KH77539/files.txt, and also delete the binary.

Your Answer

Q: 10

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

Your Answer

Question 1 of 20 · Page 1 / 2

Premium Access Includes

✓ Quiz Simulator
✓ Exam Mode
✓ Progress Tracking
✓ Question Saving
✓ Flash Cards
✓ Drag & Drops
✓ 3 Months Access
✓ PDF Downloads

Get Premium Access

Premium Access Includes

FLASH OFFER

avail 10% DISCOUNT on YOUR PURCHASE