CKS Question #59: Real Exam Question with Answer & Explanation

Question

Question: 53 SIMULATION Context A Pod is misbehaving and poses a security threat to the system. Task One of the Pods belonging to the application ollama is misbehaving. It is directly accessing the system's memory reading from the sensitive file `/dev/mem`. First, identify the misbehaving Pod accessing `/dev/mem`. The cluster uses the Docker Engine as its container runtime. If needed, use the docker command to troubleshoot running containers. Next, identify the Deployment managing the misbehaving Pod and scale it to zero replicas. Do not modify the Deployment except for scaling it down. Do not modify any other Deployments. Do not delete any Deployments.

Explanation

CKS/CKA Exam Simulation: Isolating a Misbehaving Pod

Overall Goal

A Pod is reading /dev/mem - a raw interface to physical system memory. This is a critical security threat: a process with access to /dev/mem can read kernel data, credentials, encryption keys, and other sensitive data from any process on the host. The goal is to find the offending Pod and neutralize it by scaling its Deployment to zero, which terminates all its containers without deleting the Deployment itself.

Step-by-Step Breakdown

Step 1: Find the misbehaving Pod

The question tells you the Pod belongs to the ollama application. Start by listing Pods in that namespace:

kubectl get pods -n <namespace> -l app=ollama
# or search all namespaces
kubectl get pods -A | grep ollama

But the question specifically says to use docker if needed, because you need to inspect what the container is actually doing at runtime - not just what Kubernetes reports. List running containers and check which one has /dev/mem open:

# List containers with their names
docker ps | grep ollama

# For each container, check open file descriptors
docker exec <container-id> ls -la /proc/1/fd | grep mem
# or
docker exec <container-id> cat /proc/1/maps | grep /dev/mem

Alternatively, use nsenter or check from the host:

# Find process with /dev/mem open on the host
sudo lsof /dev/mem
# or
sudo fuser /dev/mem

Map the PID back to a container ID, then map the container ID back to a Pod name using:

docker inspect <container-id> --format '{{.Name}}'
# Pod name is embedded in the container name

Why this step matters: You cannot scale the right Deployment without first identifying which Pod is the culprit. There may be multiple ollama Pods; only one is misbehaving.

Step 2: Identify the Deployment managing that Pod

Once you have the Pod name, find its owner:

kubectl describe pod <pod-name> -n <namespace>
# Look for "Controlled By: ReplicaSet/<rs-name>"

Then trace the ReplicaSet to its Deployment:

kubectl get rs <rs-name> -n <namespace> -o yaml | grep -A5 ownerReferences

Or use a shortcut:

kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.metadata.ownerReferences[0].name}'
# That gives the ReplicaSet name, then:
kubectl get rs <rs-name> -n <namespace> \
  -o jsonpath='{.metadata.ownerReferences[0].name}'

Why this step matters: You need the exact Deployment name to scale it. Scaling the wrong Deployment would be a critical exam mistake.

Step 3: Scale the Deployment to zero

kubectl scale deployment <deployment-name> -n <namespace> --replicas=0

Verify:

kubectl get pods -n <namespace> | grep ollama
# Should show no running pods

Why scale to zero instead of delete? The question explicitly says do not delete Deployments. Scaling to zero is the correct operational response - it terminates all Pod instances immediately while preserving the Deployment spec for future investigation or recovery.

What Goes Wrong If You Skip Steps

Why Not Just Delete the Pod?

If you kubectl delete pod <pod>, the Deployment's ReplicaSet controller will immediately reschedule a new Pod. Scaling to zero tells the Deployment controller "desired state = 0 replicas," so no new Pods are created.

Memory Tip

"Find → Trace → Scale"

• Find the bad container with docker / lsof
• Trace the Pod → ReplicaSet → Deployment ownership chain
• Scale to zero with kubectl scale

Think of it like finding which faucet is leaking before you shut off the water - you need the right valve.

No community discussion yet for this question.