A review of a cloud container platform finds three issues: application containers run in privileged mode, images are built from public base images that are never scanned, and orchestrator secrets are readable from every namespace. Which remediation plan best addresses all three findings?

Container security spans the image, the runtime and the orchestrator. Image scanning in the build pipeline finds known vulnerabilities and malicious content before deployment, and an admission policy that accepts only approved, signed images stops unscanned images from reaching the cluster. Running containers as non-root and without privileged mode removes the direct path from a compromised container to the host kernel and devices. Role-based access control in the orchestrator, with secrets scoped to the namespaces and service accounts that need them, prevents one workload from reading every credential in the cluster. Moving containers onto dedicated virtual machines adds an isolation boundary but leaves vulnerable images, privileged execution and over-shared secrets exactly as they were, so all three findings remain. A web application firewall filters HTTP traffic at ingress; it does not inspect image contents, change runtime privileges or restrict secret access, and logging only records the problem. Pulling the latest public tags nightly replaces one unscanned image with another, and floating tags make builds less reproducible, not more trustworthy. Exam caveat: the outline names containers, Docker and Kubernetes, but questions test concepts, not syntax. Operational check: verify that the admission controller rejects an unsigned image, that no running pod is privileged or root, and that a service account in one namespace cannot read another namespace's secrets.