An application needs a time-bound, audience-scoped ServiceAccount token rather than the legacy long-lived secret-based token. Which pattern should the developer use?
Select an answer to reveal the explanation.
Short Explanation
Projected SA tokens are temporary guest passes with an expiration time and audience. Mount a projected volume that asks for that token shape instead of clinging to old everlasting secrets. ca.crt alone is not your bearer credential.
Full Explanation
An application that needs a time-bound, audience-scoped ServiceAccount token rather than a legacy long-lived secret-based token should mount a projected ServiceAccount token volume that requests a token with bounded lifetime and audience. Projected tokens support expiration and audience claims appropriate for modern municipal workload identity to the apiserver or integrated services.
Copying ca.crt from /var/run/secrets into a ConfigMap and treating it as the bearer token fails—ca.crt is trust material, not a bearer token. Requesting a ClusterRole named system:projected-token with no volume mounts does not mint projected tokens by itself. Disabling ServiceAccounts cluster-wide and embedding static kubeconfig files in the image is insecure and operationally brittle.
Exam caveat: projected token path and refresh behavior differ from the legacy secret-backed token; configure the volume audience to match the API you call. Operational check: add a projected serviceAccountToken volume with expirationSeconds and audience, mount it, and confirm the app uses that path rather than a long-lived secret token. In CKAD scenarios involving q223, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.