KCSA — Authentication & Authorization — Practice Questions
Practice Questions — Authentication & Authorization
Test your understanding of the concepts covered in Chapter 4. These questions mirror the multiple-choice format of the KCSA exam — one correct answer per question, with conceptual reasoning required.
Try to answer each question before expanding the solution. Understanding why each option is correct or incorrect is more valuable than memorizing answers.
Question 1 — Authentication vs Authorization
What is the primary difference between authentication and authorization in Kubernetes?
A. Authentication determines what a user can do; authorization verifies the user’s identity.
B. Authentication verifies the user’s identity; authorization determines what the user is allowed to do.
C. Authentication and authorization are the same thing — both verify identity.
D. Authentication is handled by RBAC; authorization is handled by X.509 certificates.
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — this reverses the definitions. Authentication is about identity; authorization is about permissions. |
| B | Correct — Authentication (authn) answers “Who are you?” by verifying identity. Authorization (authz) answers “What can you do?” by checking permissions. |
| C | Incorrect — they are distinct steps in the API server request pipeline. Authentication happens first, followed by authorization. |
| D | Incorrect — RBAC is an authorization mechanism, not authentication. X.509 certificates are an authentication mechanism. This option has them reversed. |
Question 2 — RBAC Resources
Which Kubernetes RBAC resource would you use to grant a user read-only access to pods in a single namespace?
A. ClusterRole + ClusterRoleBinding
B. Role + RoleBinding
C. ClusterRole + RoleBinding
D. Both B and C are correct
Show Answer
Correct Answer: D
| Option | Explanation |
|---|---|
| A | Incorrect — a ClusterRoleBinding grants permissions across the entire cluster, not a single namespace. |
| B | Correct — a Role defines namespace-scoped permissions, and a RoleBinding binds it to a user within that namespace. This is the most straightforward approach. |
| C | Correct — a ClusterRole can be referenced by a RoleBinding to grant its permissions within a single namespace. This is a common pattern for reusing ClusterRole definitions. |
| D | Correct — both B and C achieve the goal of granting read-only pod access in a single namespace. Option B uses a namespace-scoped Role; option C reuses a cluster-scoped ClusterRole but limits it to one namespace via the RoleBinding. |
Question 3 — OIDC Authentication Flow
In the OIDC authentication flow for Kubernetes, how does the API server validate an OIDC token?
A. The API server contacts the Identity Provider (IdP) for every request to validate the token.
B. The API server validates the JWT signature using the IdP’s public keys, without contacting the IdP for each request.
C. The API server stores a copy of all valid OIDC tokens in etcd.
D. The API server forwards the token to the kubelet for validation.
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — the API server does NOT contact the IdP for every request. It fetches the IdP’s public keys (from the OIDC discovery endpoint) and caches them. Contacting the IdP per request would create a single point of failure and latency. |
| B | Correct — the API server validates the JWT signature using the IdP’s cached public keys. It checks the signature, issuer, audience, and expiration locally. This is why OIDC tokens work even if the IdP is temporarily unavailable (as long as keys are cached). |
| C | Incorrect — OIDC tokens are never stored in etcd. They are stateless JWTs validated cryptographically. |
| D | Incorrect — the kubelet has no role in OIDC token validation. Authentication is handled entirely by the API server. |
Question 4 — Service Account Token Types
What is the key advantage of projected service account tokens over legacy (Secret-based) service account tokens?
A. Projected tokens are stored in etcd and can be backed up.
B. Projected tokens never expire and provide permanent access.
C. Projected tokens are time-bound, audience-bound, and automatically rotated.
D. Projected tokens can only be used by cluster-admin users.
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — projected tokens are mounted as volumes in the pod, not stored in etcd. Legacy tokens (stored in Secrets) are the ones in etcd. |
| B | Incorrect — this describes legacy tokens, which never expire. The fact that they never expire is a security risk, not an advantage. |
| C | Correct — projected tokens (default since Kubernetes 1.22) are time-bound (expire after a configurable period, default ~1 hour), audience-bound (valid only for a specific audience), pod-bound (invalidated when the pod is deleted), and automatically rotated by the kubelet. |
| D | Incorrect — projected tokens are used by service accounts for pod workloads, not limited to cluster-admin users. |
Question 5 — Default ClusterRoles
Which built-in ClusterRole provides read-only access to most resources but explicitly excludes Secrets?
A. cluster-admin
B. admin
C. edit
D. view
Show Answer
Correct Answer: D
| Option | Explanation |
|---|---|
| A | Incorrect — cluster-admin grants full access to everything, including Secrets and all cluster-scoped resources. |
| B | Incorrect — admin grants full read/write access within a namespace, including Secrets. It cannot manage resource quotas or the namespace itself. |
| C | Incorrect — edit grants read/write access to most resources, including Secrets. It cannot manage Roles or RoleBindings. |
| D | Correct — view grants read-only access to most namespace-scoped resources but explicitly excludes Secrets. This prevents accidental exposure of sensitive data to read-only users. |
Question 6 — Authorization Chain Order
A Kubernetes cluster is configured with --authorization-mode=Node,RBAC. A kubelet makes a request to read a Secret for a pod scheduled on its node. What happens?
A. The RBAC authorizer handles the request because it comes first in the chain.
B. The Node authorizer allows the request because the Secret is bound to a pod on that node, and RBAC is never consulted.
C. Both Node and RBAC must allow the request for it to succeed.
D. The request is denied because kubelets cannot read Secrets.
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect — the authorization modes are evaluated in the order specified. Node is listed before RBAC, so the Node authorizer is consulted first. |
| B | Correct — the Node authorizer is evaluated first (as configured). It recognizes the kubelet identity (system:node:<name>) and allows it to read Secrets for pods scheduled on its node. Since the first authorizer allowed the request, RBAC is never consulted. This is the “first-allow wins” behavior. |
| C | Incorrect — the authorization chain does not require all authorizers to agree. The first authorizer to allow wins. Only if an authorizer has no opinion or denies does the chain continue. |
| D | Incorrect — kubelets are explicitly allowed to read Secrets, ConfigMaps, and PVCs that are referenced by pods on their node, via the Node authorizer. |
Question 7 — Groups in Kubernetes
Which of the following is a built-in Kubernetes group that grants superuser access and bypasses all RBAC checks?
A. system:authenticated
B. system:serviceaccounts
C. system:masters
D. system:nodes
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — system:authenticated is assigned to all authenticated users. It does not grant special privileges by itself — RBAC still applies normally. |
| B | Incorrect — system:serviceaccounts is the group for all service accounts across all namespaces. It has no inherent superuser privileges. |
| C | Correct — system:masters is hard-coded into the Kubernetes API server to bypass all authorization checks. Members of this group effectively have unrestricted access, regardless of RBAC policies. It should be reserved for emergency break-glass scenarios. |
| D | Incorrect — system:nodes is the group for kubelet identities. It is used by the Node authorizer to scope kubelet permissions, not to grant superuser access. |
Question 8 — RBAC Verbs
A Role grants the verbs ["get", "list", "watch"] on a resource. Which HTTP operations does this allow?
A. GET (single), GET (collection), GET (with watch parameter) — read-only access
B. GET, POST, PUT — read and create access
C. GET, DELETE — read and delete access
D. All HTTP methods — full access
Show Answer
Correct Answer: A
| Option | Explanation |
|---|---|
| A | Correct — get maps to GET for a single resource, list maps to GET on a collection endpoint, and watch maps to GET with the ?watch=true parameter. Together, these three verbs provide complete read-only access without any ability to modify or delete resources. |
| B | Incorrect — POST maps to the create verb, and PUT maps to the update verb. Neither create nor update is included in the granted verbs. |
| C | Incorrect — DELETE maps to the delete verb, which is not included. |
| D | Incorrect — full access would require the wildcard * or explicitly listing all verbs including create, update, patch, delete, and deletecollection. |
Question 9 — Least Privilege
An operations team needs to view pod logs and exec into pods in the staging namespace for debugging. Which approach best follows the principle of least privilege?
A. Bind the cluster-admin ClusterRole to the team’s group with a ClusterRoleBinding.
B. Bind the admin ClusterRole to the team’s group with a RoleBinding in the staging namespace.
C. Create a custom Role in the staging namespace with only pods/log and pods/exec subresources, plus get and list on pods, and bind it with a RoleBinding.
D. Bind the edit ClusterRole to the team’s group with a ClusterRoleBinding.
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — cluster-admin with a ClusterRoleBinding gives full access to every resource in every namespace. This massively violates least privilege. |
| B | Incorrect — while the RoleBinding limits scope to staging, the admin ClusterRole grants full read/write access to most resources in the namespace, far exceeding the requirement to view logs and exec into pods. |
| C | Correct — a custom Role with only the required permissions (get and list on pods, create on pods/log and pods/exec) scoped to the staging namespace via a RoleBinding. This grants exactly what the team needs and nothing more. |
| D | Incorrect — edit with a ClusterRoleBinding grants read/write access across all namespaces. Both the scope (cluster-wide) and the permissions (full edit) exceed the requirement. |
Example of the least-privilege Role:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: staging
name: pod-debugger
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create"]
Question 10 — automountServiceAccountToken
A security team wants to harden a pod that serves static web pages and never needs to communicate with the Kubernetes API. What should they set?
A. serviceAccountName: cluster-admin
B. automountServiceAccountToken: true
C. automountServiceAccountToken: false
D. hostNetwork: true
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Incorrect — cluster-admin is a ClusterRole, not a service account name. Even if a SA with that name existed, granting it would violate least privilege. This option increases risk, not reduces it. |
| B | Incorrect — true is the default behavior. This explicitly mounts a service account token, which is the opposite of what the security team wants. A compromised pod with a mounted token could use it to call the API server. |
| C | Correct — automountServiceAccountToken: false prevents Kubernetes from mounting a service account token into the pod. Since the pod never needs API access, there is no reason to expose a credential. This reduces the attack surface if the pod is compromised. |
| D | Incorrect — hostNetwork: true gives the pod access to the host’s network namespace, which is a privilege escalation, not a hardening measure. This is completely unrelated to service account tokens. |
Self-Assessment Scoring Guide
| Score | Rating | Recommendation |
|---|---|---|
| 10/10 | Excellent | You’ve mastered authentication & authorization concepts. Move to the next chapter. |
| 8-9/10 | Strong | Review the topics for the questions you missed, then proceed. |
| 6-7/10 | Adequate | Revisit the specific topics where gaps exist — especially RBAC and token types. |
| 4-5/10 | Needs Work | Re-read the chapter topics, focusing on the comparison tables and key takeaways. |
| 0-3/10 | Start Over | Go through each topic in order, taking notes on key concepts before retrying. |
Topics to Revisit Based on Missed Questions
| Question | Topic to Review |
|---|---|
| Q1 | Authentication Methods — authn vs authz fundamentals |
| Q2 | RBAC Deep Dive — four RBAC resources and binding patterns |
| Q3 | Authentication Methods — OIDC flow and validation |
| Q4 | Service Accounts & Token Security — legacy vs projected tokens |
| Q5 | RBAC Deep Dive — default ClusterRoles |
| Q6 | Authorization Modes & Best Practices — authorization chain |
| Q7 | User & Group Management — built-in groups |
| Q8 | RBAC Deep Dive — verbs and HTTP methods |
| Q9 | RBAC Deep Dive — least privilege principle |
| Q10 | Service Accounts & Token Security — automountServiceAccountToken |
What’s Next?
If you scored 8 or above, you’re ready to move on to the next chapter:
