A user authenticates to the API server using a bearer token obtained from an OIDC provider. The token contains a `groups` claim. How does the API server use this claim?

It stores the groups in etcd for future authorization decisions

It ignores the groups claim and uses only the username

It validates the groups against the local LDAP server

It maps the groups to RBAC roles via RoleBindings or ClusterRoleBindings

What is the correct order of security checks for an API request in Kubernetes?

Admission → Authentication → Authorization → Persistence

Authentication → Authorization → Admission → Persistence

Authorization → Authentication → Admission → Persistence

Authentication → Admission → Authorization → Persistence

A pod needs to access the Kubernetes API to list pods in its namespace. The pod uses the default service account. What must be configured to allow this?

Create a Role and RoleBinding that grants the `list` verb on pods to the default service account in that namespace

Create a Secret with a token and mount it into the pod

Create a ClusterRole and ClusterRoleBinding that grants the `list` verb on pods to the default service account

Set `automountServiceAccountToken: true` on the pod spec

What is the primary function of the RBAC authorization mode in Kubernetes?

It grants permissions to users based on roles defined in the cluster, which are bound to users or groups.

It allows the API server to call an external service for authorization decisions.

It authorizes requests from kubelets based on their node identity.

It uses attributes of the request (e.g., user, resource, action) to evaluate policies defined in JSON files.

A new administrator is tasked with securing the Kubernetes API server. They want to ensure that all requests are authenticated and authorized, and that sensitive data is encrypted in transit. Which set of configurations should they apply?

Use only client certificates for authentication and disable all other methods

Disable the insecure port and enable audit logging

Enable admission controllers and set `--authorization-mode=AlwaysAllow`

Enable TLS on the secure port, configure authentication, and set `--authorization-mode=RBAC`

Kubernetes and Cloud Native Security Associate (KCSA)

Domain 2Objective 1

API Server KCSA Practice Questions (Page 1)

Part of the Kubernetes Cluster Component Security domain, which accounts for 22% of the KCSA exam. Linux Foundation does not publish an official question count, but from its 90-minute exam (~35–60 total, ~8–13 in this domain), expect 1–2 from this objective — we provide 25 practice questions to prepare you well beyond it. (estimate)

25questions here

5free pages

9concepts

22%of the exam

Questions 1–5

1application · medium
A user authenticates to the API server using a bearer token obtained from an OIDC provider. The token contains a `groups` claim. How does the API server use this claim?
Select an answer first
2foundation · easy
What is the correct order of security checks for an API request in Kubernetes?
Select an answer first
3application · medium
A pod needs to access the Kubernetes API to list pods in its namespace. The pod uses the default service account. What must be configured to allow this?
Select an answer first
4foundation · easy
What is the primary function of the RBAC authorization mode in Kubernetes?
Select an answer first
5application · medium
A new administrator is tasked with securing the Kubernetes API server. They want to ensure that all requests are authenticated and authorized, and that sensitive data is encrypted in transit. Which set of configurations should they apply?
Select an answer first

Finished these 5 questions?

Review the revealed explanations, or continue through the curriculum.

Next 5 questions →Back to KCSA

Free Basic Practice is a study aid with revealable answers — not a scored exam. Examers.io is independent and not affiliated with or endorsed by Linux Foundation. “KCSA” is a trademark of its owner, used for identification only.