Free Practice Questions for Linux Foundation CKS Exam

1) Connect to the correct host

ssh cks000m40

sudo -i

export KUBECONFIG=/etc/kubernetes/admin.conf

2) Verify namespace exists (quick check)

kubectl get ns clever-cactus

3) Verify certificate and key files exist

ls -l /home/candidate/clever-cactus/web.k8s.local.crt

ls -l /home/candidate/clever-cactus/web.k8s.local.key

Both files must exist.

4) Create the TLS Secret (THIS IS THE MAIN TASK)

Create a TLS Secret named clever-cactus in namespace clever-cactus:

kubectl -n clever-cactus create secret tls clever-cactus \

--cert=/home/candidate/clever-cactus/web.k8s.local.crt \

--key=/home/candidate/clever-cactus/web.k8s.local.key

⚠️ Do NOT use apply

⚠️ Do NOT edit the Deployment

5) Verify the Secret

kubectl -n clever-cactus get secret clever-cactus

Expected type:

kubernetes.io/tls

Optional detail check:

kubectl -n clever-cactus describe secret clever-cactus

You should see:

tls.crt

tls.key

6) (Optional) Confirm Pods are running

Since the Deployment is already configured to use the Secret, Pods should now work.

kubectl -n clever-cactus get pods

root# netstat -ltnup

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name

tcp 0 0 127.0.0.1:17600 0.0.0.0:* LISTEN 1293/dropbox

tcp 0 0 127.0.0.1:17603 0.0.0.0:* LISTEN 1293/dropbox

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd

tcp 0 0 127.0.0.1:9393 0.0.0.0:* LISTEN 900/perl

tcp 0 0 :::80 :::* LISTEN 9583/docker-proxy

tcp 0 0 :::443 :::* LISTEN 9571/docker-proxy

udp 0 0 0.0.0.0:68 0.0.0.0:* 8822/dhcpcd

root# netstat -ltnup | grep ':22'

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 575/sshd

The ss command is the replacement of the netstat command.

Now let’s see how to use the ss command to see which process is listening on port 22:

root# ss -ltnup 'sport = :22'

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port

tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:("sshd",pid=575,fd=3))

1) SSH to the right node

ssh cks000002

sudo -i

2) Fix kubelet CIS findings

2.1 Edit kubelet config (MAIN place in kubeadm clusters)

vi /var/lib/kubelet/config.yaml

A) Set anonymous-auth to false

Find (or add) this block exactly:

authentication:

anonymous:

enabled: false

B) Use Webhook authentication (recommended by task)

Ensure this exists under authentication:

webhook:

enabled: true

C) Use Webhook authorization and NOT AlwaysAllow

Find (or add) this block exactly:

authorization:

mode: Webhook

When done, your file should contain something like this (exact structure to aim for):

authentication:

anonymous:

enabled: false

webhook:

enabled: true

x509:

clientCAFile: /etc/kubernetes/pki/ca.crt

authorization:

mode: Webhook

If x509: section isn’t there, it’s usually already present in kubeadm; don’t panic. Only the task-required parts are: anonymous false + webhook enabled + authorization mode Webhook.

2.2 Restart kubelet (required for config.yaml changes)

systemctl daemon-reload

systemctl restart kubelet

systemctl status kubelet --no-pager

Quick confirm (optional but fast):

grep -nE "anonymous|webhook|authorization|mode" /var/lib/kubelet/config.yaml

3) Fix etcd CIS finding: --client-cert-auth=true

3.1 Edit etcd static pod manifest (kubeadm path)

vi /etc/kubernetes/manifests/etcd.yaml

Find the container command: args that look like:

- command:

- etcd

- --something=...

Ensure this line exists exactly in the list:

- --client-cert-auth=true

Also ensure this is present (usually already is, but add if missing):

- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

Example snippet (what you want the args area to include):

- command:

- etcd

- --client-cert-auth=true

- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt

3.2 Apply etcd change (auto-restart happens)

Just save the file. Kubelet will restart etcd automatically.

Watch it restart (pick one depending on runtime):

If Docker runtime (your task mentions Docker):

docker ps | grep etcd

If you don’t see it briefly, wait 2–5 seconds and rerun:

docker ps | grep etcd

(Alternative if available)

crictl ps | grep etcd

4) Final quick validation (fast exam check)

Kubelet config check

grep -n "enabled: false" -n /var/lib/kubelet/config.yaml | head

grep -n "webhook" /var/lib/kubelet/config.yaml

grep -n "authorization" /var/lib/kubelet/config.yaml

etcd arg check

grep -n "client-cert-auth" /etc/kubernetes/manifests/etcd.yaml

1) Connect to the correct host

ssh cks000037

sudo -i

2) Remove user developer from the docker group ONLY

2.1 Verify current groups (optional but fast)

id developer

2.2 Remove ONLY from docker group

gpasswd -d developer docker

2.3 Verify removal

id developer

✅ docker should not appear; other groups must remain.

3) Reconfigure Docker to secure the socket and disable TCP

Docker config file:

vi /etc/docker/daemon.json

3.1 Set socket group to root and disable TCP listeners

Ensure the file contains exactly these relevant settings (merge with existing JSON if present):

{

"group": "root",

"hosts": ["unix:///var/run/docker.sock"]

}

Important:

"group": "root" → docker.sock owned by group root

"hosts" includes ONLY the unix socket (no tcp://)

If the file already exists with other keys, add/adjust only these keys and keep valid JSON (commas!).

Save and exit:

wq

4) Restart Docker daemon

systemctl daemon-reload

systemctl restart docker

systemctl status docker --no-pager

5) Verify Docker socket ownership and permissions

ls -l /var/run/docker.sock

Expected:

srw-rw---- 1 root root ...

✅ Owner: root

✅ Group: root

6) Verify Docker is NOT listening on TCP

ss -lntp | grep docker

Expected:

No output (or nothing bound to TCP by dockerd)

Optional double-check:

ps aux | grep dockerd | grep -v grep

Ensure no -H tcp://... flags.

7) Ensure Kubernetes cluster is healthy

7.1 Check node and pods

export KUBECONFIG=/etc/kubernetes/admin.conf

kubectl get nodes

kubectl get pods -A

All nodes should be Ready, core pods Running.

0) Connect to the correct host

ssh cks000023

sudo -i

PART A — Fix ONE prominent Dockerfile security/best-practice issue

1) Open the Dockerfile

vi /home/candidate/subtle-bee/build/Dockerfile

2) Find the “most obvious” security/best-practice problem and modify ONLY THAT ONE instruction

Use / search in vi to quickly find candidates:

Candidate 1 (very common): USER root (or no USER but a USER 0)

Search:

/USER

If you see:

USER root

Change that single instruction to:

USER 65535

(or USER nobody if that exact word is already used in the file—but the task explicitly allows UID 65535, so USER 65535 is safest.)

✅ This is one-instruction change and is a top-tier best practice.

Candidate 2 (very common): FROM <image>:latest

Search:

/FROM

If you see something like:

FROM nginx:latest

Change ONLY that line to a pinned tag (example):

FROM nginx:1.25.5

(Any non-latest pinned version is the point. Don’t add a digest line; just modify the existing FROM line.)

Candidate 3: ADD http://... (remote URL download)

Search:

/ADD

If you see remote URL usage like:

ADD https://example.com/app.tar.gz /app/

Change that single instruction to COPY only if it’s copying local files.

If it’s a remote URL, the more “correct” fix would normally be using curl with verification, but that would require adding instructions (not allowed).

So in this exam constraint, do NOT pick this unless it’s actually a local add like:

ADD . /app

Then change just the word:

COPY . /app

3) Save and exit

wq

⚠️ Don’t run docker build (task forbids building).

PART B — Fix ONE prominent security/best-practice issue in the Deployment manifest

4) Open the manifest

vi /home/candidate/subtle-bee/deployment.yaml

5) Change ONLY ONE existing field that is a clear security issue

Use / search in vi for the usual “bad fields”:

Option 1 (most common): running as root

Search:

/runAsUser

If you see:

runAsUser: 0

Change that one existing field value to:

runAsUser: 65535

✅ This is a single-field change and matches the prompt hint.

Option 2: privileged container

Search:

/privileged

If you see:

privileged: true

Change only that value to:

privileged: false

Option 3: allow privilege escalation

Search:

/allowPrivilegeEscalation

If you see:

allowPrivilegeEscalation: true

Change only that value to:

allowPrivilegeEscalation: false

Option 4: writable root filesystem

Search:

/readOnlyRootFilesystem

If you see:

readOnlyRootFilesystem: false

Change only that value to:

readOnlyRootFilesystem: true

Option 5: image uses :latest

Search:

/image:

If you see:

image: something:latest

Change only that value to a pinned tag, e.g.:

image: something:1.2.3

6) Save and exit

wq

What to pick (fast decision rule)

If you see run as root in either file, that’s usually the highest scoring / most “prominent” security issue.

Dockerfile: USER root → USER 65535

Deployment: runAsUser: 0 → runAsUser: 65535

Those are perfect because you only modify one line/field and it matches the hint.