KCSA — Cluster Component Security — Practice Questions
Test Your Knowledge
These 10 multiple-choice questions cover all five topics from Chapter 3 — Kubernetes Cluster Component Security. They’re modeled after the style and difficulty of the actual KCSA exam.
How to use this quiz:
- Read each question carefully — some have subtle wording
- Pick your answer before expanding the solution
- Check the explanation for every option — even the ones you got right
- Score yourself at the end using the assessment guide
This is the highest-weighted domain on the KCSA exam at 22%. Take your time with these questions — they represent the types of concepts most likely to appear on the real exam.
Question 1 — API Server Request Flow
What is the correct order of the three stages a request passes through when it reaches the Kubernetes API server?
- A) Authorization → Authentication → Admission Control
- B) Admission Control → Authentication → Authorization
- C) Authentication → Authorization → Admission Control
- D) Authentication → Admission Control → Authorization
Show Answer
Correct Answer: C) Authentication → Authorization → Admission Control
| Option | Explanation |
|---|---|
| A) Authorization → Authentication → Authorization | ❌ Authorization cannot happen first — the API server doesn’t know who the requester is yet. Identity must be established before permissions can be checked |
| B) Admission Control → Authentication → Authorization | ❌ Admission control is the last stage, not the first. It validates or mutates the request after identity and permission checks have passed |
| C) Authentication → Authorization → Admission Control | ✅ This is the correct order. First, “Who are you?” (authentication). Then, “Are you allowed?” (authorization). Finally, “Should this request be modified or rejected by policy?” (admission control) |
| D) Authentication → Admission Control → Authorization | ❌ Admission control runs after authorization, not before. There’s no point in running admission webhook logic if the user doesn’t have permission |
This is one of the most important concepts in the cluster security domain. The three stages are always in this order: AuthN → AuthZ → Admission.
Question 2 — Authentication Methods
A security team wants to integrate their Kubernetes cluster with their corporate single sign-on (SSO) identity provider (Okta). Which authentication method should they configure on the API server?
- A) X.509 client certificates
- B) Static token file
- C) OpenID Connect (OIDC)
- D) Service account tokens
Show Answer
Correct Answer: C) OpenID Connect (OIDC)
| Option | Explanation |
|---|---|
| A) X.509 client certificates | ❌ Client certificates are tied to the cluster’s CA, not to an external identity provider. They can’t integrate with SSO systems like Okta |
| B) Static token file | ❌ Static tokens are stored in a file on the API server. They don’t support SSO, have no expiry mechanism, and require an API server restart to update. Avoid in production |
| C) OpenID Connect (OIDC) | ✅ OIDC is the standard method for integrating Kubernetes with external identity providers. It uses JWT tokens issued by providers like Okta, Azure AD, or Google. Users authenticate via SSO and receive a token that Kubernetes validates |
| D) Service account tokens | ❌ Service account tokens are for workloads (Pods) to authenticate to the API server, not for human users or SSO integration |
OIDC is the recommended authentication method for human users in enterprise environments. It supports SSO, multi-factor authentication, token expiry, and centralized identity management.
Question 3 — Admission Controllers
What is the difference between mutating and validating admission controllers, and in what order do they execute?
- A) Validating runs first and modifies requests; mutating runs second and accepts/rejects
- B) Mutating runs first and modifies requests; validating runs second and accepts/rejects
- C) Both run simultaneously and can both modify and reject requests
- D) Mutating runs only for create operations; validating runs for all operations
Show Answer
Correct Answer: B) Mutating runs first and modifies requests; validating runs second and accepts/rejects
| Option | Explanation |
|---|---|
| A) Validating first, mutating second | ❌ This is backwards. If validating ran first, it would validate the original request, not the final version after mutations. That would defeat the purpose |
| B) Mutating first, validating second | ✅ Mutating controllers run first — they can add defaults, inject sidecars, modify fields. Then validating controllers run on the final object and decide whether to accept or reject. This ensures validation always sees the complete, mutated version |
| C) Both run simultaneously | ❌ They are sequential, not concurrent. The order is critical for correctness |
| D) Mutating for create only | ❌ Both types run for all relevant API operations (create, update, delete, connect), not just create |
Remember: M before V — Mutating before Validating. This is a commonly tested concept.
Question 4 — etcd Encryption Providers
An organization needs to encrypt Secrets at rest in their Kubernetes cluster. They want the encryption keys to be managed by an external service and never stored on the cluster nodes. Which EncryptionConfiguration provider should they use?
- A) identity
- B) aescbc
- C) secretbox
- D) kms
Show Answer
Correct Answer: D) kms
| Option | Explanation |
|---|---|
| A) identity | ❌ The identity provider means no encryption — data is stored in plaintext. This is the default and should never be used for sensitive data |
| B) aescbc | ❌ aescbc encrypts data using AES-CBC, but the encryption keys are stored in the EncryptionConfiguration file on the node’s filesystem. If the node is compromised, the keys are exposed |
| C) secretbox | ❌ secretbox uses XSalsa20+Poly1305 for authenticated encryption, but like aescbc, the keys are stored on disk. Better algorithm, but same key management limitation |
| D) kms | ✅ The kms provider uses envelope encryption with an external Key Management Service (AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault). The master key (KEK) never leaves the KMS. Only encrypted data encryption keys (DEKs) are stored locally. This is the recommended approach for production |
The key distinction: with aescbc and secretbox, you’re protecting the data but the keys are on disk. With kms, the keys are in an external, hardened system purpose-built for key management.
Question 5 — Kubelet Authentication
A security auditor finds that the kubelet on a production node has --anonymous-auth=true and --authorization-mode=AlwaysAllow. What is the primary risk of this configuration?
- A) The kubelet will not be able to register with the API server
- B) Pods on the node will not be able to pull container images
- C) Any network-reachable client can execute commands inside containers on that node without authentication
- D) The kubelet will consume excessive CPU and memory resources
Show Answer
Correct Answer: C) Any network-reachable client can execute commands inside containers on that node without authentication
| Option | Explanation |
|---|---|
| A) Cannot register with API server | ❌ These flags affect how the kubelet receives requests, not how it connects to the API server. Node registration is unaffected |
| B) Cannot pull images | ❌ Image pulling is handled by the container runtime and doesn’t depend on kubelet authentication settings |
| C) Anyone can execute commands | ✅ With --anonymous-auth=true, no credentials are required. With --authorization-mode=AlwaysAllow, every request is permitted. This means anyone on the network can access the kubelet’s /exec, /run, and /logs endpoints to run arbitrary commands in any container on the node |
| D) Excessive resource consumption | ❌ These flags don’t directly affect resource usage. The risk is unauthorized access, not performance |
This is a critical misconfiguration. The correct settings are --anonymous-auth=false and --authorization-mode=Webhook. This has been exploited in real-world Kubernetes attacks.
Question 6 — Container Runtimes
A platform team is running a multi-tenant Kubernetes cluster where different teams deploy workloads that cannot be fully trusted. They need stronger isolation than standard Linux namespaces and cgroups provide. Which container runtime should they consider?
- A) containerd
- B) CRI-O
- C) gVisor or Kata Containers
- D) Docker Engine
Show Answer
Correct Answer: C) gVisor or Kata Containers
| Option | Explanation |
|---|---|
| A) containerd | ❌ containerd uses standard Linux namespaces and cgroups for isolation. Containers share the host kernel, which means a kernel vulnerability could allow container escape. Good for trusted workloads, insufficient for untrusted multi-tenant scenarios |
| B) CRI-O | ❌ CRI-O provides the same level of isolation as containerd — Linux namespaces and cgroups with a shared kernel. It’s lightweight and Kubernetes-optimized, but not designed for strong multi-tenant isolation |
| C) gVisor or Kata Containers | ✅ gVisor provides a user-space kernel that intercepts system calls, reducing the kernel attack surface. Kata Containers runs each Pod in a lightweight VM with its own kernel. Both provide significantly stronger isolation than standard runtimes |
| D) Docker Engine | ❌ Docker Engine (dockershim) was removed from Kubernetes in v1.24. Even when it was supported, it used the same namespace/cgroup isolation as containerd |
For multi-tenant clusters: use RuntimeClass to assign sandboxed runtimes (gVisor/Kata) to untrusted workloads while running trusted workloads on the standard runtime.
Question 7 — Secrets Management
A developer encodes a password using base64 and stores it in a Kubernetes Secret. They believe the password is now encrypted and secure. What is wrong with this assumption?
- A) base64 encoding uses a weak encryption algorithm
- B) base64 is an encoding scheme, not encryption — anyone can decode it, and Secrets are stored in plaintext in etcd by default
- C) Kubernetes automatically decrypts base64 Secrets, making them insecure
- D) base64 encoding is only secure when combined with TLS
Show Answer
Correct Answer: B) base64 is an encoding scheme, not encryption — anyone can decode it, and Secrets are stored in plaintext in etcd by default
| Option | Explanation |
|---|---|
| A) Weak encryption algorithm | ❌ base64 is not an encryption algorithm at all. It’s an encoding scheme designed for representing binary data in ASCII text. It has no key, no security mechanism, and is trivially reversible |
| B) Encoding, not encryption | ✅ echo "password" | base64 → cGFzc3dvcmQ=. echo "cGFzc3dvcmQ=" | base64 -d → password. There is no secret key involved. Moreover, without EncryptionConfiguration, this base64 value is stored as-is in etcd. Anyone with etcd access can read it |
| C) Automatically decrypts | ❌ This statement doesn’t make logical sense. Kubernetes decodes base64 when presenting the Secret to a Pod, but that’s by design — it’s not a security flaw in itself. The issue is that base64 provides zero confidentiality |
| D) Secure with TLS | ❌ TLS protects data in transit (between the API server and etcd, or between kubectl and the API server). It doesn’t protect data at rest in etcd. The base64 value is still in plaintext on disk |
This is probably the most important misconception to correct: base64 ≠ encryption. To actually protect Secrets, enable encryption at rest with EncryptionConfiguration.
Question 8 — Audit Levels
A security team configures an audit policy with level: Metadata for a particular resource. Which of the following will be included in the audit log?
- A) The full request body and response body
- B) Only the request body, not the response
- C) Request metadata (user, timestamp, resource, verb, response code) but NOT the request or response body
- D) No information is logged — Metadata means the event is skipped
Show Answer
Correct Answer: C) Request metadata (user, timestamp, resource, verb, response code) but NOT the request or response body
| Option | Explanation |
|---|---|
| A) Full request and response body | ❌ That’s the RequestResponse level — the most verbose. It includes everything: metadata + request body + response body |
| B) Only the request body | ❌ That’s the Request level — it includes metadata + the request body, but not the response body |
| C) Metadata only | ✅ The Metadata level records: who made the request, when, what resource/verb, and the response status code — but not the request body or response body. It’s a good balance between visibility and log volume |
| D) Nothing is logged | ❌ That’s the None level. Metadata explicitly means “log the metadata.” The four levels in order of verbosity: None → Metadata → Request → RequestResponse |
Remember the hierarchy: None < Metadata < Request < RequestResponse. Each level includes everything from the level below it plus additional data.
Question 9 — RBAC for Secrets
A Kubernetes administrator creates a ClusterRole with verbs: ["*"] and resources: ["*"], then binds it to a developer group. What is the security concern regarding Secrets?
- A) Developers cannot read Secrets because ClusterRoles don’t apply to Secrets
- B) Developers can read, list, and modify ALL Secrets in EVERY namespace in the cluster
- C) Developers can only read Secrets in their own namespace
- D) The ClusterRole is invalid because wildcards are not supported
Show Answer
Correct Answer: B) Developers can read, list, and modify ALL Secrets in EVERY namespace in the cluster
| Option | Explanation |
|---|---|
| A) ClusterRoles don’t apply to Secrets | ❌ ClusterRoles apply to all resources in the API, including Secrets. When bound via a ClusterRoleBinding, they apply across all namespaces |
| B) ALL Secrets in EVERY namespace | ✅ verbs: ["*"] means all verbs (get, list, watch, create, update, patch, delete). resources: ["*"] means all resources — including Secrets. Combined with a ClusterRoleBinding, this grants unrestricted access to Secrets in every namespace. A massive over-privilege |
| C) Only their own namespace | ❌ If this were a Role + RoleBinding (namespace-scoped), it would be limited to one namespace. But a ClusterRole + ClusterRoleBinding is cluster-wide |
| D) Wildcards not supported | ❌ Wildcards (*) are fully supported in RBAC rules. They match everything in the specified field |
This is a common RBAC mistake: granting * on * at cluster scope. Always follow the principle of least privilege — grant only the specific verbs and resources needed, scoped to specific namespaces where possible.
Question 10 — NodeRestriction
The NodeRestriction admission controller is enabled on a Kubernetes cluster. A compromised kubelet on Node A attempts to modify the labels on Node B. What happens?
- A) The modification succeeds because kubelets have full access to all Node objects
- B) The modification is rejected because NodeRestriction limits kubelets to modifying only their own Node object
- C) The modification succeeds but triggers an audit log entry
- D) The modification is queued and requires manual approval from an admin
Show Answer
Correct Answer: B) The modification is rejected because NodeRestriction limits kubelets to modifying only their own Node object
| Option | Explanation |
|---|---|
| A) Modification succeeds | ❌ Without NodeRestriction, this might be true (depending on RBAC). But the whole point of NodeRestriction is to prevent exactly this scenario |
| B) Rejected — own node only | ✅ The NodeRestriction admission controller ensures that a kubelet can only modify its own Node object (labels, status, taints) and Pods that are scheduled on its node. It explicitly blocks modifications to other nodes’ objects. This limits the blast radius of a compromised node |
| C) Succeeds with audit | ❌ NodeRestriction rejects the request — it’s an admission controller, not just a logging mechanism. The request never reaches etcd |
| D) Queued for approval | ❌ Kubernetes doesn’t have a built-in approval queue for API requests. Admission controllers make immediate accept/reject decisions |
NodeRestriction works alongside the Node authorization mode to create a defense-in-depth approach: the Node authorizer limits what scope of resources kubelets can access, and NodeRestriction further limits modifications to their own resources.
Self-Assessment Scoring Guide
Count the number of questions you answered correctly before viewing the solution.
| Score | Rating | What to Do |
|---|---|---|
| 9-10 | 🟢 Excellent | You have a strong grasp of Kubernetes cluster component security. Review any missed questions and move on to Chapter 4 |
| 7-8 | 🟡 Good | Solid foundation. Re-read the topics for any questions you missed and retry those questions in a day or two |
| 5-6 | 🟠 Needs Work | Review all five topics in this chapter, focusing on the Key Takeaways sections. Retake this quiz after review |
| Below 5 | 🔴 Review Required | This is the highest-weighted domain at 22%. Go back through each topic carefully, study the tables, and retake the quiz. Don’t move forward until you score at least 7/10 |
This domain represents 22% of the KCSA exam — more than any other. If you’re scoring below 7, invest the extra time here before moving on. It will pay off significantly on exam day.
What’s Next?
If you’re scoring 7 or above, you’re ready for the next chapter.
Want to review specific topics?
