A school district discovers API tokens stored in a ConfigMap that was committed to git. What correction aligns with Kubernetes configuration practice?
Select an answer to reveal the explanation.
Short Explanation
If it is a password or token, it does not belong on the hallway bulletin board. Move it into a Secret—and better yet an external secret manager—not a ConfigMap living in git.
Full Explanation
When a school district discovers API tokens stored in a ConfigMap that was committed to git, the correction that aligns with Kubernetes configuration practice is to move sensitive tokens into Secrets—and preferably into external secret stores—not ConfigMaps. ConfigMaps are for non-confidential data; Secrets are the API type for confidential material. Tokens in git history remain a breach concern even after migration, so rotate the credentials as part of the remediation for the district's security posture.
Keeping tokens in ConfigMaps but renaming the keys so git scanners cannot match them is security theater and still misuses ConfigMaps for secrets. Converting the ConfigMap into a headless Service so tokens become Endpoints confuses discovery objects with secret storage. Storing the tokens only as Docker ENTRYPOINT strings inside public images bakes credentials into image layers and registries—another anti-pattern.
Exam caveat: Secret objects alone are not a complete secret-management program, but CKA expects clear separation of ConfigMap versus Secret responsibilities. Operational check: remove tokens from ConfigMaps, create/rotate Secrets, update Pod references, purge git history where required by policy, and verify workloads authenticate with the new secret material.