Linux Foundation CKS Actual Free Exam Questions & Community Discussion
SIMULATION
Documentation Upgrading kubeadm clusters
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000034
Context
The kubeadm provisioned cluster was recently upgraded, leaving one node on a slightly older version due to workload compatibility concerns.
Task
Upgrade the cluster node compute-0 to match the version of the control plane node.
Use a command like the following to connect to the compute node:
[candidate@cks000034] $ ssh compute-0
Do not modify any running workloads in the cluster.
Do not forget to exit from the compute node once you have completed your tasks:
[candidate@icompute-e] $ exit
Documentation Upgrading kubeadm clusters
You must connect to the correct host . Failure to do so may result in a zero score.
[candidate@base] $ ssh cks000034
Context
The kubeadm provisioned cluster was recently upgraded, leaving one node on a slightly older version due to workload compatibility concerns.
Task
Upgrade the cluster node compute-0 to match the version of the control plane node.
Use a command like the following to connect to the compute node:
[candidate@cks000034] $ ssh compute-0
Do not modify any running workloads in the cluster.
Do not forget to exit from the compute node once you have completed your tasks:
[candidate@icompute-e] $ exit
Correct Answer:
See the Explanation below for complete solution
Explanation:
Below is the CKS / CKA exam-style, exact step-by-step solution for Upgrading a kubeadm worker node.
Follow in order, type exact commands, no extra actions.
QUESTION - Upgrade node compute-0 (EXAM MODE)
1) Connect to the correct host (control plane)
ssh cks000034
sudo -i
export KUBECONFIG=/etc/kubernetes/admin.conf
2) Identify the control plane Kubernetes version
This is the target version for compute-0.
kubectl get nodes
Example output:
NAME STATUS ROLES VERSION
control-plane Ready control-plane v1.27.4
compute-0 Ready <none> v1.26.6
Note the control-plane version
Example: v1.27.4
3) Drain the compute node (do NOT modify workloads manually)
kubectl drain compute-0 --ignore-daemonsets --delete-emptydir-data
Wait until drain completes successfully.
4) SSH into the compute node
ssh compute-0
sudo -i
5) Check current kubeadm version on compute node
kubeadm version
6) Upgrade kubeadm to match control plane version
Replace 1.27.4 with the exact control-plane version you observed.
apt-get update
apt-get install -y kubeadm=1.27.4-00
Verify:
kubeadm version
7) Run kubeadm upgrade for the node
kubeadm upgrade node
✅ This updates node-specific configs (NO workloads touched).
8) Upgrade kubelet and kubectl to the same version
apt-get install -y kubelet=1.27.4-00 kubectl=1.27.4-00
9) Restart kubelet
systemctl daemon-reload
systemctl restart kubelet
systemctl status kubelet --no-pager
10) Exit the compute node (IMPORTANT)
exit
11) Uncordon the compute node (back on control plane)
kubectl uncordon compute-0
12) Final verification
kubectl get nodes
Expected:
NAME STATUS VERSION
compute-0 Ready v1.27.4
Explanation:
Below is the CKS / CKA exam-style, exact step-by-step solution for Upgrading a kubeadm worker node.
Follow in order, type exact commands, no extra actions.
QUESTION - Upgrade node compute-0 (EXAM MODE)
1) Connect to the correct host (control plane)
ssh cks000034
sudo -i
export KUBECONFIG=/etc/kubernetes/admin.conf
2) Identify the control plane Kubernetes version
This is the target version for compute-0.
kubectl get nodes
Example output:
NAME STATUS ROLES VERSION
control-plane Ready control-plane v1.27.4
compute-0 Ready <none> v1.26.6
Note the control-plane version
Example: v1.27.4
3) Drain the compute node (do NOT modify workloads manually)
kubectl drain compute-0 --ignore-daemonsets --delete-emptydir-data
Wait until drain completes successfully.
4) SSH into the compute node
ssh compute-0
sudo -i
5) Check current kubeadm version on compute node
kubeadm version
6) Upgrade kubeadm to match control plane version
Replace 1.27.4 with the exact control-plane version you observed.
apt-get update
apt-get install -y kubeadm=1.27.4-00
Verify:
kubeadm version
7) Run kubeadm upgrade for the node
kubeadm upgrade node
✅ This updates node-specific configs (NO workloads touched).
8) Upgrade kubelet and kubectl to the same version
apt-get install -y kubelet=1.27.4-00 kubectl=1.27.4-00
9) Restart kubelet
systemctl daemon-reload
systemctl restart kubelet
systemctl status kubelet --no-pager
10) Exit the compute node (IMPORTANT)
exit
11) Uncordon the compute node (back on control plane)
kubectl uncordon compute-0
12) Final verification
kubectl get nodes
Expected:
NAME STATUS VERSION
compute-0 Ready v1.27.4
SIMULATION
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.
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.
Correct Answer:
See the Explanation belowExplanation:
SIMULATION
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.
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.
Correct Answer:
See explanation below
Explanation:
se kubectl to create a CSR and approve it.
Get the list of CSRs:
kubectl get csr
Approve the CSR:
kubectl certificate approve myuser
Get the certificate
Retrieve the certificate from the CSR:
kubectl get csr/myuser -o yaml
here are the role and role-binding to give john permission to create NEW_CRD resource:
kubectl apply -f roleBindingJohn.yaml --as=john
rolebinding.rbac.authorization.k8s.io/john_external-rosource-rb created kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:
name: john_crd
namespace: development-john
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: crd-creation
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: crd-creation
rules:
- apiGroups: ["kubernetes-client.io/v1"]
resources: ["NEW_CRD"]
verbs: ["create, list, get"]
Explanation:
se kubectl to create a CSR and approve it.
Get the list of CSRs:
kubectl get csr
Approve the CSR:
kubectl certificate approve myuser
Get the certificate
Retrieve the certificate from the CSR:
kubectl get csr/myuser -o yaml
here are the role and role-binding to give john permission to create NEW_CRD resource:
kubectl apply -f roleBindingJohn.yaml --as=john
rolebinding.rbac.authorization.k8s.io/john_external-rosource-rb created kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata:
name: john_crd
namespace: development-john
subjects:
- kind: User
name: john
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: crd-creation
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: crd-creation
rules:
- apiGroups: ["kubernetes-client.io/v1"]
resources: ["NEW_CRD"]
verbs: ["create, list, get"]
SIMULATION
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.
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.
Correct Answer:
See the Explanation below
Explanation:
Explanation:
SIMULATION
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.
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.
Correct Answer:
SIMULATION
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 12 days.
3. at maximum, a number of 8 old audit logs files are retained.
4. set the maximum size before getting rotated to 200MB
Edit and extend the basic policy to log:
1. namespaces changes at RequestResponse
2. Log the request body of secrets changes in the namespace kube-system.
3. Log all other resources in core and extensions at the Request level.
4. Log "pods/portforward", "services/proxy" at Metadata level.
5. Omit the Stage RequestReceived All other requests at the Metadata level
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 12 days.
3. at maximum, a number of 8 old audit logs files are retained.
4. set the maximum size before getting rotated to 200MB
Edit and extend the basic policy to log:
1. namespaces changes at RequestResponse
2. Log the request body of secrets changes in the namespace kube-system.
3. Log all other resources in core and extensions at the Request level.
4. Log "pods/portforward", "services/proxy" at Metadata level.
5. Omit the Stage RequestReceived All other requests at the Metadata level
Correct Answer:
Kubernetes auditing provides a security-relevant chronological set of records about a cluster. Kube-apiserver performs auditing. Each request on each stage of its execution generates an event, which is then pre-processed according to a certain policy and written to a backend. The policy determines what's recorded and the backends persist the records.
You might want to configure the audit log as part of compliance with the CIS (Center for Internet Security) Kubernetes Benchmark controls.
The audit log can be enabled by default using the following configuration in cluster.yml:
services:
kube-api:
audit_log:
enabled: true
When the audit log is enabled, you should be able to see the default values at /etc/kubernetes/audit-policy.yaml The log backend writes audit events to a file in JSONlines format. You can configure the log audit backend using the following kube-apiserver flags:
--audit-log-path specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. - means standard out
--audit-log-maxage defined the maximum number of days to retain old audit log files
--audit-log-maxbackup defines the maximum number of audit log files to retain
--audit-log-maxsize defines the maximum size in megabytes of the audit log file before it gets rotated If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the hostPath to the location of the policy file and log file, so that audit records are persisted. For example:
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
--audit-log-path=/var/log/audit.log
You might want to configure the audit log as part of compliance with the CIS (Center for Internet Security) Kubernetes Benchmark controls.
The audit log can be enabled by default using the following configuration in cluster.yml:
services:
kube-api:
audit_log:
enabled: true
When the audit log is enabled, you should be able to see the default values at /etc/kubernetes/audit-policy.yaml The log backend writes audit events to a file in JSONlines format. You can configure the log audit backend using the following kube-apiserver flags:
--audit-log-path specifies the log file path that log backend uses to write audit events. Not specifying this flag disables log backend. - means standard out
--audit-log-maxage defined the maximum number of days to retain old audit log files
--audit-log-maxbackup defines the maximum number of audit log files to retain
--audit-log-maxsize defines the maximum size in megabytes of the audit log file before it gets rotated If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the hostPath to the location of the policy file and log file, so that audit records are persisted. For example:
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
--audit-log-path=/var/log/audit.log
SIMULATION
Context
The kubeadm-created cluster's Kubernetes API server was, for testing purposes, temporarily configured to allow unauthenticated and unauthorized access granting the anonymous user duster-admin access.
Task
Reconfigure the cluster's Kubernetes API server to ensure that only authenticated and authorized REST requests are allowed.
Use authorization mode Node,RBAC and admission controller NodeRestriction.
Cleaning up, remove the ClusterRoleBinding for user system:anonymous.
Context
The kubeadm-created cluster's Kubernetes API server was, for testing purposes, temporarily configured to allow unauthenticated and unauthorized access granting the anonymous user duster-admin access.
Task
Reconfigure the cluster's Kubernetes API server to ensure that only authenticated and authorized REST requests are allowed.
Use authorization mode Node,RBAC and admission controller NodeRestriction.
Cleaning up, remove the ClusterRoleBinding for user system:anonymous.
Correct Answer:
See the Explanation below
Explanation:
Explanation:
0
0
0
10