A background worker needs an API token stored as an Opaque Secret named worker-token in namespace billing. Which command creates it from a literal value?
Select an answer to reveal the explanation.
Short Explanation
Opaque Secrets are labeled envelopes for app credentials—generic is the everyday type. kubectl create secret generic with --from-literal drops the token into billing without pretending it's a registry login. ConfigMaps aren't for secret tokens.
Full Explanation
A background worker that needs an API token stored as an Opaque Secret named worker-token in namespace billing should be created with kubectl create secret generic worker-token --from-literal=token=s3cret -n billing. generic creates an Opaque Secret from literals or files, which is the standard CKAD path for application tokens consumed by municipal workers.
kubectl create configmap worker-token --from-literal=... stores non-secret configuration and is the wrong object type for an API token. kubectl apply -f worker-token --type=ServiceAccount is not how ServiceAccounts or Secrets are created and misuses flags. kubectl create docker-registry worker-token creates a registry pull Secret, not a generic Opaque token Secret for application API auth.
Exam caveat: avoid committing the literal token into git; prefer sealed secrets or CI injection in real civic pipelines even when the exam uses --from-literal. Operational check: create the Secret in billing, confirm type Opaque and key token exists, reference it from the worker Pod, and verify the process receives the token without exposing it in image layers. In CKAD scenarios involving q211, prefer verifying the live object with kubectl get and describe before changing cluster-wide settings.