Question: 52 SIMULATION You must connect to the correct host. Failure to do so may result in a zero score. Analyze and edit the Dockerfile located at /home/candidate/subtle-bee/build/Dockerfile, fixin

This CKS-style simulation tests your ability to identify and fix container security misconfigurations in both a Dockerfile and a Kubernetes deployment manifest, specifically around running workloads as privileged/root users.

Submitted by fernanda_arg· May 4, 2026Minimize Microservice Vulnerabilities

Question

Question: 52 SIMULATION You must connect to the correct host. Failure to do so may result in a zero score. Analyze and edit the Dockerfile located at /home/candidate/subtle-bee/build/Dockerfile, fixing one instruction present in the file that is a prominent security/best-practice issue. Do not add or remove instructions; only modify the one existing instruction with a security/best-practice concern. Do not build the Dockerfile, Failure to do so may result in running out of storage and a zero score. Analyze and edit the given manifest file /home/candidate/subtle-bee/deployment.yaml, fixing one fields present in the file that is a prominent security/best-practice issue. Do not add or remove fields; only modify the one existing field with a security/best-practice concern. Should you need an unprivileged user for any of the tasks, use user nobody with user ID 65535.

Explanation

Approach. For the Dockerfile: the most prominent single-instruction security issue is a 'USER root' (or implicitly running as root without a USER directive). Since you cannot add instructions, the file already contains a USER instruction - change 'USER root' to 'USER nobody' or 'USER 65535' to ensure the container process runs as an unprivileged user. For the deployment.yaml: the most prominent single-field fix is changing 'runAsUser: 0' to 'runAsUser: 65535' inside the pod's securityContext (or container-level securityContext), which maps to the 'nobody' user. Alternatively, if the field is 'privileged: true', change it to 'privileged: false', or if 'allowPrivilegeEscalation: true', flip it to 'false'. The hint about UID 65535 (nobody) points toward the runAsUser field being the target. In both cases, the fix is a one-field/one-instruction modification - never build the image, as the task explicitly forbids it.

Concept tested. Container and Kubernetes security hardening: running workloads as non-root unprivileged users (Dockerfile USER instruction and Kubernetes securityContext.runAsUser), which is a core CKS domain - minimizing host OS footprint and applying the principle of least privilege to containerized workloads.

Reference. CKS Exam Domain: System Hardening / Minimize Microservice Vulnerabilities - Dockerfile USER best practices (Docker docs) and Kubernetes Pod Security Standards / securityContext.runAsUser (kubernetes.io/docs/tasks/configure-pod-container/security-context)

Topics

#Dockerfile Security#Kubernetes Manifest Security#Least Privilege#Container Hardening

Community Discussion

No community discussion yet for this question.

Full CKS Practice