CKA Practice Question: Cluster Architecture, Installation and Configuration

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Create a Secret of type 'Opaque' with the token data

  Why it's wrong here

  An Opaque secret stores arbitrary key/value data and has no special meaning to the Kubernetes authentication layer. It is not automatically associated with any ServiceAccount, and a token placed inside it is simply a string—Kubernetes will not issue or sign it as a ServiceAccount credential. The controller-manager only populates secrets with type `kubernetes.io/service-account-token`, and an Opaque secret cannot be referenced by a workload as a projected service account token. Thus, this option neither creates the ServiceAccount nor provides a functional token.

• ✗

  Run 'kubectl create token build-bot'

  Why it's wrong here

  The `kubectl create token` command is a convenience wrapper around the TokenRequest API. It produces a short-lived, time-limited token (typically valid for an hour by default) intended for one-time or temporary authentication. It does not create a ServiceAccount, and in fact requires the target ServiceAccount to already exist in the cluster. Running this command when the ServiceAccount does not exist would fail, and even after the ServiceAccount is present, it would generate an ephemeral token rather than the persistent secret you might need for automated workloads.

• ✗

  Use the TokenRequest API to generate a token

  Why it's wrong here

  The TokenRequest API can mint a signed ServiceAccount token with a configurable expiration. However, these tokens are designed to be short-lived and are typically used for direct authentication by an application or a kubeconfig, not as a stored long-lived credential in a Secret. The API requires the ServiceAccount to exist before a token can be requested, so it cannot be used to create a ServiceAccount in the first place. Additionally, the token is not persisted anywhere in the cluster, so it does not fulfill the common requirement of creating a durable token tied to the ServiceAccount.

• ✓

  Create a ServiceAccount object named 'build-bot'

  Why this is correct

  The foundational step is to create a ServiceAccount object, which you can do with `kubectl create serviceaccount build-bot` or by applying a YAML manifest with `kind: ServiceAccount` and the desired name. Kubernetes does not automatically carve out a ServiceAccount for you—it must be explicitly created before any pod or process can assume that identity. Once the ServiceAccount exists, the controller-manager automatically provisions a long-lived token secret for it (unless you explicitly opt out), so the ServiceAccount immediately has a usable credential. Without this object, all other claims about generating or attaching tokens are invalid because there is no identity to bind them to.

• ✓

  Create a Secret with type 'kubernetes.io/service-account-token' and reference the ServiceAccount via annotation

  Why this is correct

  When you create a Secret with type `kubernetes.io/service-account-token` and include the annotation `kubernetes.io/service-account-name`, the token controller in kube-controller-manager detects the Secret and fills its `data.token` field with a signed token issued by the API server. This is a legitimate way to create a long-lived token that pods can mount when `automountServiceAccountToken` or a projected volume requests it. However, the annotation must reference an existing ServiceAccount—if the ServiceAccount named in the annotation is not yet present, the controller will log an error and the Secret will remain empty. Therefore, although this is a valid secondary step, it presupposes that the ServiceAccount object has already been created, which is the actual requirement in the question.

Go deeper

Related to this question