An open-data portal needs an opaque Secret from literal values in a demo Namespace so the app is not baked with passwords in the image. What is the admin's responsibility?
Select an answer to reveal the explanation.
Short Explanation
Images should stay password-free—like shipping a safe without writing the combination on the cardboard. Admins create Secrets (often opaque from literals) and point the app at them.
Full Explanation
An open-data portal that needs an opaque Secret from literal values in a demo Namespace so the app is not baked with passwords in the image places responsibility on the admin to create a Secret the workload references instead of embedding passwords in the container image. Opaque Secrets from literals (kubectl create secret generic … --from-literal) are a standard CKA skill: produce the object, reference it from the Pod or Deployment, and keep demo credentials out of image layers and public registries while the portal runs.
Disabling the API server so Secrets cannot be read during demos breaks the cluster control plane and is not a configuration practice. Replacing kubelet with a cron job that prints passwords on the node console increases exposure rather than managing Secrets. Storing only the password in a ClusterRole rule verb list misunderstands RBAC—ClusterRoles authorize API verbs and resources; they are not secret stores.
Exam caveat: know --from-literal and --from-file creation paths, plus consuming via env or volume; remember base64 in manifests is encoding, not encryption. Operational check: create the Secret in the demo Namespace, mount or env-inject it, confirm the open-data app authenticates without image-embedded passwords, and delete demo secrets after the exercise per policy.