A housing lottery service image runs as root by default, and the platform requires non-root containers. What should the image build include?
Select an answer to reveal the explanation.
Short Explanation
Running as root in a container is like leaving the master key under the doormat. Create a non-root user in the image, chown what the app needs, and set USER so Kubernetes SecurityContext policies can happily refuse root.
Full Explanation
Housing lottery services that run as root by default conflict with restricted Pod Security standards many cities enforce. The image build should create a non-root user, chown application directories the process must write, and set a USER instruction so the container process starts non-root. Pair that with a Pod securityContext (runAsNonRoot, runAsUser) so admission and runtime agree. This reduces blast radius if the lottery app is compromised.
A privileged SecurityContext fails the requirement: it expands privileges instead of removing root. hostNetwork does not remap image USER to a safer identity and increases network exposure. A ClusterRoleBinding mapping root to a ServiceAccount confuses RBAC identities with Linux UIDs inside the container; API permissions do not change the process user.
Exam caveat: USER in the image and securityContext in the Pod must be consistent; numeric UIDs are clearer than names across distroless images. CKAD tests non-root application design, not cluster-wide policy authoring.
Operational check: kubectl get pod -o jsonpath for securityContext fields; attempt a deploy under a restricted namespace and confirm it passes; verify the process user is non-root via ephemeral debug or application-reported UID metrics.