Free Linux Foundation CKS Practice Exam with Questions & Answers | Set: 2

1) Connect to the correct host

ssh cks000036

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Confirm the failing Pods + see the PSA error (fast)

kubectl -n confidential get deploy

kubectl -n confidential get pods

kubectl -n confidential describe deploy | sed -n '/Events/,$p'

(You’ll usually see “violates PodSecurity ‘restricted’ …” with the exact missing fields.)

3) Edit the provided manifest

vi /home/candidate/nginx-unprivileged.yaml

You must ensure the Pod template becomes compliant. Add/ensure the following exact blocks:

4) Add Pod-level securityContext (under spec.template.spec)

Find:

spec:

template:

spec:

Add this block under it (or merge if securityContext: already exists):

securityContext:

runAsNonRoot: true

runAsUser: 65535

seccompProfile:

type: RuntimeDefault

5) Add Container-level securityContext (under the nginx container)

Find:

containers:

- name: ...

image: ...

Under that container, add (or adjust) this exact block:

securityContext:

allowPrivilegeEscalation: false

readOnlyRootFilesystem: true

capabilities:

drop:

- ALL

If there are multiple containers, apply the same container securityContext to each one.

Save and exit:

wq

6) Apply the manifest to the confidential namespace

kubectl -n confidential apply -f /home/candidate/nginx-unprivileged.yaml

Wait rollout:

kubectl -n confidential rollout status deployment/

If you don’t know the deployment name from the file, list:

kubectl -n confidential get deploy

7) Verify Pods are running

kubectl -n confidential get pods -o wide

If still failing, show the exact PSA violation (this tells you what else to fix):

kubectl -n confidential describe pod | sed -n '/Events/,$p'

Quick “if it still fails” fixes (common restricted blockers)

Open the manifest again and ensure these are NOT set (or are removed/false):

hostNetwork: true

hostPID: true

hostIPC: true

any hostPort:

privileged: true

capabilities.add:

seccompProfile: Unconfined

runAsUser: 0 or runAsNonRoot: false

Then re-apply.

Minimal compliant result (what the grader expects)

Your Pod template should include:

seccompProfile: RuntimeDefault

runAsNonRoot: true (and a non-root UID like 65535)

container: allowPrivilegeEscalation: false

container: capabilities.drop: [ALL]

container: readOnlyRootFilesystem: true

Explanation[desk@cli] $vim runtime.yaml

apiVersion: node.k8s.io/v1

kind: RuntimeClass

metadata:

 name: not-trusted

handler: runsc

[desk@cli] $ k apply -f runtime.yaml

[desk@cli] $ k get pods

NAME READY STATUS RESTARTS AGE

nginx-6798fc88e8-chp6r 1/1 Running 0 11m

nginx-6798fc88e8-fs53n 1/1 Running 0 11m

nginx-6798fc88e8-ndved 1/1 Running 0 11m

[desk@cli] $ k get deploy

NAME READY UP-TO-DATE AVAILABLE AGE

nginx 3/3 11 3 5m

[desk@cli] $ k edit deploy nginx

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

1) Connect to the correct host

ssh cks000032

sudo -i

2) Use admin kubeconfig

export KUBECONFIG=/etc/kubernetes/admin.conf

3) Verify prerequisites (quick check)

These should already exist per task.

kubectl -n prod get svc web

kubectl -n prod get secret web-cert

kubectl get pods -n ingress-nginx

(If the ingress controller pods exist, you’re good.)

4) Create the Ingress resource

Create Ingress named web in namespace prod with:

host: web.k8s.local

all paths → Service web

TLS using Secret web-cert

HTTP → HTTPS redirect (NGINX)

cat <

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web

namespace: prod

annotations:

nginx.ingress.kubernetes.io/ssl-redirect: "true"

nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

spec:

ingressClassName: nginx

tls:

- hosts:

- web.k8s.local

secretName: web-cert

rules:

- host: web.k8s.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web

port:

number: 80

EOF

5) Verify Ingress creation

kubectl -n prod get ingress web

kubectl -n prod describe ingress web

Confirm:

Host = web.k8s.local

TLS Secret = web-cert

Backend Service = web

6) Test HTTP → HTTPS redirect

curl -L http://web.k8s.local

Expected:

Redirects to https://web.k8s.local

Returns application response over HTTPS

master1 $ k get pods -n test --show-labels

NAME READY STATUS RESTARTS AGE LABELS

test-pod 1/1 Running 0 34s role=test,run=test-pod

testing 1/1 Running 0 17d run=testing

$ vim netpol.yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-network

namespace: test

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

master1 $ k apply -f netpol.yaml

Explanationcontrolplane $ k get pods -n test --show-labels

NAME READY STATUS RESTARTS AGE LABELS

test-pod 1/1 Running 0 34s role=test,run=test-pod

testing 1/1 Running 0 17d run=testing

master1 $ vim netpol1.yaml

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: deny-network

namespace: test

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

master1 $ k apply -f netpol1.yaml

You can create a "default" isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any ingress traffic to those pods.

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-ingress

spec:

podSelector: {}

policyTypes:

- Ingress

You can create a "default" egress isolation policy for a namespace by creating a NetworkPolicy that selects all pods but does not allow any egress traffic from those pods.

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: allow-all-egress

spec:

podSelector: {}

egress:

- {}

policyTypes:

- Egress

You can create a "default" policy for a namespace which prevents all ingress AND egress traffic by creating the following NetworkPolicy in that namespace.

---

apiVersion: networking.k8s.io/v1

kind: NetworkPolicy

metadata:

name: default-deny-all

spec:

podSelector: {}

policyTypes:

- Ingress

- Egress

This ensures that even pods that aren't selected by any other NetworkPolicy will not be allowed ingress or egress traffic.

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