On the city’s Kubernetes cluster, a Catalyst Center sync pod needs an API token. Which store is appropriate for that credential?

On Kubernetes-style platforms, API tokens belong in a Secret or an external secret operator sync—not in a ConfigMap or a checked-in plaintext manifest. Secrets signal credential handling, support tighter RBAC, and integrate with encryption-at-rest features for cluster state that ConfigMaps typically lack. Placing the token in a ConfigMap because “all non-code settings share one object type” ignores that distinction and often leaves values more widely readable to workloads and users who only needed non-sensitive config. Checking the token into the deployment manifest in git as plain YAML fields puts production credentials into version control and every clone of the municipal repo. Writing the token into a Service annotation for easy kubectl describe maximizes casual exposure during routine debugging and support screenshares. Exam caveat: native Secrets are base64-encoded for transport in manifests, not encrypted by that encoding alone—enable etcd encryption at rest and prefer external managers when policy demands stronger custody. Operational check: inspect ConfigMap and Secret objects in staging and confirm the API token appears only in the Secret or external store, with RBAC limiting who can read the credential data.