A Deployment must meet common Pod Security restricted-level expectations for an ordinary app. Which checklist item belongs?
Select an answer to reveal the explanation.
Short Explanation
Restricted posture is a short packing list: non-root, no privilege escalation, capabilities dropped, no privileged flag. Host networking and UID 0 are the opposite of that packing list.
Full Explanation
Pod Security restricted-level expectations for ordinary city apps center on a short hardening checklist: runAsNonRoot true, allowPrivilegeEscalation false, drop ALL capabilities (then add only if justified), and avoid privileged containers—along with related constraints such as not sharing host namespaces. That checklist is what belongs when a Deployment must meet restricted posture for a routine municipal workload.
Requiring privileged: true and hostNetwork: true is the opposite of restricted. Mounting the host root read-write and running as UID 0 likewise violates restricted intent. Disabling all securityContext fields so admission “infers defaults from Services” is incorrect: Services do not define Pod security defaults, and restricted policies expect explicit compliant settings rather than empty hope.
Exam caveat: restricted is stricter than baseline/privileged profiles; know the difference when a question says “restricted-level.” Operational check: validate the Pod template against the city’s Pod Security restricted requirements (or kubectl label namespace ... pod-security.kubernetes.io/enforce=restricted in labs) and confirm the civic Deployment admits successfully only with non-root, no privilege escalation, dropped capabilities, and privileged absent. Fix failing fields rather than weakening the namespace policy.