Courseiva

Certified Kubernetes Administrator CKA (CKA) — Questions 301302

302 questions total · 5pages · All types, answers revealed

Page 4

Page 5 of 5

301
Multi-Selectmedium

You need to create a Kubernetes ServiceAccount named 'build-bot' and ensure that pods using this ServiceAccount can authenticate to the Kubernetes API using a long-lived token. Which TWO steps are necessary? (Choose TWO.)

Select 2 answers
A.Create a Secret of type 'Opaque' with the token data
B.Run 'kubectl create token build-bot'
C.Use the TokenRequest API to generate a token
D.Create a ServiceAccount object named 'build-bot'
E.Create a Secret with type 'kubernetes.io/service-account-token' and reference the ServiceAccount via annotation
AnswersD, E

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.

Why this answer

Creating a ServiceAccount named 'build-bot' is the foundational step; without the ServiceAccount object, no pods can be assigned a service account identity. Option E is correct because a Secret of type 'kubernetes.io/service-account-token' with an annotation referencing the ServiceAccount causes the Kubernetes controller manager to automatically generate and populate a long-lived token, which pods can mount and use to authenticate to the API server.

Exam trap

CNCF often tests the distinction between long-lived tokens (created via the legacy Secret-based mechanism) and short-lived tokens (generated via the TokenRequest API or 'kubectl create token'), leading candidates to incorrectly select options that produce ephemeral credentials.

302
Multi-Selecthard

Which THREE statements about NetworkPolicy are correct?

Select 3 answers
A.To allow traffic from a specific namespace, you can use a namespaceSelector in the ingress rule.
B.If no NetworkPolicy exists, all traffic is denied by default.
C.A NetworkPolicy with podSelector: {} selects all pods in the namespace.
D.The field 'podSelector.matchLabels' is used to select pods based on labels.
E.NetworkPolicy is a cluster-scoped resource.
AnswersA, C, D

Correct. The namespaceSelector in the ingress rule allows traffic from pods in namespaces matching the selector, enabling cross-namespace traffic control.

Why this answer

A NetworkPolicy ingress rule can use a `namespaceSelector` to allow traffic from pods in a specific namespace. Option C is correct because an empty `podSelector: {}` selects all pods in the namespace. Option D is correct because `podSelector.matchLabels` is used to select pods based on specific labels.

Options B and E are incorrect: B is false because without any NetworkPolicy, all traffic is allowed; E is false because NetworkPolicy is namespaced, not cluster-scoped.

Exam trap

A common misconception is that NetworkPolicy defaults to deny-all when no policy exists, but the actual default is allow-all; the trap is that candidates confuse the 'default deny' behavior that occurs once a policy selects a pod (if no rule allows traffic) with the cluster-wide default.

Page 4

Page 5 of 5

All pages