KCSA — Practice Questions
Practice Questions — Introduction Chapter
These 10 introductory practice questions cover topics from all six KCSA exam domains. They’re designed to give you a taste of the exam format and test the foundational concepts you should know before diving into the detailed chapters.
How to use these questions:
- Read each question carefully — watch for negative qualifiers like “NOT”
- Try to answer before expanding the answer section
- Use the elimination technique: cross off obviously wrong options first
- Read the full explanation for every question — even the ones you got right
- Track your score at the end
Questions
Q1: Which of the following is NOT one of the 4Cs of Cloud Native Security?
A) Cloud
B) Cluster
C) Compliance
D) Code
Show Answer
Correct Answer: C) Compliance
The 4Cs of Cloud Native Security are Cloud, Cluster, Container, and Code. They represent the four layers of security in a cloud-native environment, from the outermost (Cloud) to the innermost (Code). Compliance is an important concept in security, but it is not one of the 4Cs.
- A) Cloud — Incorrect. Cloud IS one of the 4Cs. It represents the outermost security layer, covering infrastructure and cloud provider security.
- B) Cluster — Incorrect. Cluster IS one of the 4Cs. It covers Kubernetes cluster-level security including the API server, RBAC, and network policies.
- C) Compliance — Correct. The missing C is Container, not Compliance. Compliance is a separate security concern related to frameworks and standards.
- D) Code — Incorrect. Code IS one of the 4Cs. It represents the innermost layer, covering application code security, dependency scanning, and secure coding practices.
Domain: Overview of Cloud Native Security (Domain 1)
Q2: What does STRIDE stand for in threat modeling?
A) Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
B) Security, Threat, Risk, Integrity, Detection, Encryption
C) Scanning, Testing, Remediation, Identification, Defense, Evaluation
D) Spoofing, Tracking, Repudiation, Injection, Denial of Service, Exploitation
Show Answer
Correct Answer: A) Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
STRIDE is a threat modeling framework developed by Microsoft that categorizes threats into six categories. It is widely used in security analysis, including Kubernetes security.
- A) Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege — Correct. This is the exact definition of STRIDE. Each letter represents a category of threat.
- B) Security, Threat, Risk, Integrity, Detection, Encryption — Incorrect. These are general security terms but not what STRIDE stands for.
- C) Scanning, Testing, Remediation, Identification, Defense, Evaluation — Incorrect. These describe security activities, not threat categories.
- D) Spoofing, Tracking, Repudiation, Injection, Denial of Service, Exploitation — Incorrect. While Spoofing, Repudiation, and Denial of Service are correct, the other terms are wrong. The correct terms are Tampering (not Tracking), Information Disclosure (not Injection), and Elevation of Privilege (not Exploitation).
Domain: Kubernetes Threat Model (Domain 3)
Q3: In Kubernetes RBAC, what is the difference between a Role and a ClusterRole?
A) A Role is for users, a ClusterRole is for service accounts
B) A Role is scoped to a namespace, a ClusterRole applies cluster-wide
C) A Role grants read access, a ClusterRole grants write access
D) A Role is created by admins, a ClusterRole is created by Kubernetes automatically
Show Answer
Correct Answer: B) A Role is scoped to a namespace, a ClusterRole applies cluster-wide
RBAC (Role-Based Access Control) in Kubernetes uses Roles and ClusterRoles to define permissions. The key difference is their scope.
- A) A Role is for users, a ClusterRole is for service accounts — Incorrect. Both Roles and ClusterRoles can be bound to users, groups, or service accounts. The difference is scope, not the type of subject they bind to.
- B) A Role is scoped to a namespace, a ClusterRole applies cluster-wide — Correct. A Role defines permissions within a specific namespace. A ClusterRole defines permissions across all namespaces or for cluster-scoped resources (like Nodes or PersistentVolumes).
- C) A Role grants read access, a ClusterRole grants write access — Incorrect. Both Roles and ClusterRoles can grant any combination of verbs (get, list, create, update, delete, etc.). Access type is defined by the rules, not the Role type.
- D) A Role is created by admins, a ClusterRole is created by Kubernetes automatically — Incorrect. While Kubernetes does create some default ClusterRoles (like
cluster-admin,edit,view), both Roles and ClusterRoles can be created by administrators.
Domain: Kubernetes Cluster Component Security (Domain 2)
Q4: Which of the following are the three Pod Security Standards (PSS) levels?
A) Low, Medium, High
B) Permissive, Standard, Strict
C) Privileged, Baseline, Restricted
D) Open, Default, Hardened
Show Answer
Correct Answer: C) Privileged, Baseline, Restricted
Pod Security Standards (PSS) define three levels of security restrictions for Pods. These are enforced by the Pod Security Admission (PSA) controller.
- A) Low, Medium, High — Incorrect. These are generic severity levels, not PSS level names.
- B) Permissive, Standard, Strict — Incorrect. While these words loosely describe the PSS levels, they are not the official names.
- C) Privileged, Baseline, Restricted — Correct. These are the three official PSS levels:
- Privileged — No restrictions. Allows all Pod configurations. Used for system-level workloads.
- Baseline — Minimally restrictive. Prevents known privilege escalations. Good default for most workloads.
- Restricted — Heavily restricted. Follows current Pod hardening best practices. Most secure level.
- D) Open, Default, Hardened — Incorrect. These are not official PSS level names.
Domain: Compliance and Security Frameworks (Domain 5)
Q5: What is the primary difference between authentication and authorization in Kubernetes?
A) Authentication encrypts data; authorization decrypts it
B) Authentication verifies who you are; authorization determines what you can do
C) Authentication is for external users; authorization is for internal services
D) Authentication uses RBAC; authorization uses certificates
Show Answer
Correct Answer: B) Authentication verifies who you are; authorization determines what you can do
Authentication and authorization are two distinct phases of every API request in Kubernetes. They happen in sequence: first authentication, then authorization.
- A) Authentication encrypts data; authorization decrypts it — Incorrect. Neither authentication nor authorization is about encryption/decryption. Encryption is a separate concept related to data confidentiality.
- B) Authentication verifies who you are; authorization determines what you can do — Correct. Authentication (authn) answers “Who are you?” via certificates, tokens, or OIDC. Authorization (authz) answers “What are you allowed to do?” via RBAC, ABAC, Node, or Webhook modes.
- C) Authentication is for external users; authorization is for internal services — Incorrect. Both authentication and authorization apply to all API requests, whether from external users, internal services, or service accounts.
- D) Authentication uses RBAC; authorization uses certificates — Incorrect. This is backwards. Certificates are commonly used for authentication. RBAC is an authorization mode.
Domain: Kubernetes Cluster Component Security (Domain 2)
Q6: What is the purpose of CIS Kubernetes Benchmarks?
A) To measure cluster performance under load
B) To provide security configuration guidelines and best practices for Kubernetes
C) To test Kubernetes applications for functional correctness
D) To benchmark different Kubernetes distributions against each other
Show Answer
Correct Answer: B) To provide security configuration guidelines and best practices for Kubernetes
CIS (Center for Internet Security) Kubernetes Benchmarks are a set of security best practices for configuring Kubernetes clusters. They provide specific, actionable recommendations for hardening cluster components.
- A) To measure cluster performance under load — Incorrect. Performance testing tools include kube-burner or k6, not CIS Benchmarks. CIS Benchmarks are about security, not performance.
- B) To provide security configuration guidelines and best practices for Kubernetes — Correct. CIS Benchmarks cover topics like API server configuration, etcd security, kubelet settings, and more. Tools like kube-bench automate checking compliance against these benchmarks.
- C) To test Kubernetes applications for functional correctness — Incorrect. Application testing is done with testing frameworks, not security benchmarks.
- D) To benchmark different Kubernetes distributions against each other — Incorrect. CIS Benchmarks don’t compare distributions. They provide a universal set of security recommendations applicable to any Kubernetes deployment.
Domain: Compliance and Security Frameworks (Domain 5)
Q7: Which tool is primarily used for runtime security monitoring and threat detection in Kubernetes?
A) Trivy
B) Falco
C) kube-bench
D) cosign
Show Answer
Correct Answer: B) Falco
Each of these tools serves a different security purpose. The key is knowing which tool addresses which concern.
- A) Trivy — Incorrect. Trivy is a vulnerability scanner for container images, file systems, and IaC configurations. It identifies known CVEs in images, not runtime threats.
- B) Falco — Correct. Falco is a runtime security tool created by Sysdig and now a CNCF incubating project. It monitors system calls in real time and alerts on suspicious behavior — like a container spawning a shell, accessing sensitive files, or making unexpected network connections.
- C) kube-bench — Incorrect. kube-bench checks whether your cluster configuration complies with CIS Kubernetes Benchmarks. It’s a compliance tool, not a runtime monitoring tool.
- D) cosign — Incorrect. cosign is used for signing and verifying container images. It’s a supply chain security tool that ensures image integrity.
Here’s a quick reference:
| Tool | Primary Function |
|---|---|
| Trivy | Image vulnerability scanning |
| Falco | Runtime threat detection |
| kube-bench | CIS benchmark compliance |
| cosign | Image signing & verification |
Domain: Cloud Native Security Tooling (Domain 6)
Q8: How are Kubernetes Secrets stored by default (without additional configuration)?
A) Encrypted with AES-256
B) Stored as plain text in the container file system
C) Base64 encoded in etcd (not encrypted)
D) Encrypted using the cluster’s TLS certificates
Show Answer
Correct Answer: C) Base64 encoded in etcd (not encrypted)
This is one of the most commonly misunderstood aspects of Kubernetes security and a frequent exam topic.
- A) Encrypted with AES-256 — Incorrect. Secrets are NOT encrypted by default. AES-256 encryption at rest must be explicitly configured via an
EncryptionConfigurationresource. - B) Stored as plain text in the container file system — Incorrect. Secrets are stored in etcd (the cluster’s data store), not directly in the container file system. When mounted into a Pod, they appear as files, but the question asks about storage, not consumption.
- C) Base64 encoded in etcd (not encrypted) — Correct. By default, Kubernetes Secrets are stored as base64 encoded values in etcd. Base64 is encoding, not encryption — it can be trivially decoded by anyone with access to etcd. This is why enabling encryption at rest for etcd is a critical security hardening step.
- D) Encrypted using the cluster’s TLS certificates — Incorrect. TLS certificates are used for encrypting data in transit between cluster components, not for encrypting data at rest in etcd.
Key takeaway: Base64 ≠ encryption. Anyone with access to etcd can decode base64 Secrets. Always enable encryption at rest.
Domain: Kubernetes Cluster Component Security (Domain 2)
Q9: What is the primary purpose of Kubernetes Network Policies?
A) To route traffic between clusters in different regions
B) To control ingress and egress traffic between Pods
C) To configure DNS resolution for Services
D) To load balance traffic across multiple replicas
Show Answer
Correct Answer: B) To control ingress and egress traffic between Pods
Network Policies are a key security feature in Kubernetes that allow you to define rules about which Pods can communicate with each other and with external endpoints.
- A) To route traffic between clusters in different regions — Incorrect. Multi-cluster routing is handled by service meshes, federation, or gateway APIs, not Network Policies.
- B) To control ingress and egress traffic between Pods — Correct. Network Policies define ingress (incoming) and egress (outgoing) rules for Pods. They act as firewalls at the Pod level. Without Network Policies, all Pods can communicate with all other Pods by default — which violates the zero trust principle.
- C) To configure DNS resolution for Services — Incorrect. DNS in Kubernetes is handled by CoreDNS, not Network Policies.
- D) To load balance traffic across multiple replicas — Incorrect. Load balancing is handled by Services (ClusterIP, NodePort, LoadBalancer) and kube-proxy, not Network Policies.
Important note: Network Policies are only enforced if the cluster’s CNI plugin supports them (e.g., Calico, Cilium, Weave Net). The default kubenet CNI does NOT support Network Policies.
Domain: Cloud Native Security Tooling (Domain 6)
Q10: What type of admission controller would you use to automatically add a sidecar container to every Pod in a namespace?
A) Validating admission controller
B) Mutating admission controller
C) Pod Security Admission controller
D) RBAC admission controller
Show Answer
Correct Answer: B) Mutating admission controller
Admission controllers intercept API requests after authentication and authorization but before the object is persisted in etcd. There are two main types: validating and mutating.
- A) Validating admission controller — Incorrect. Validating admission controllers check whether a resource meets certain criteria and either allow or reject it. They do NOT modify the resource. For example, a validating controller might reject a Pod that doesn’t have resource limits set.
- B) Mutating admission controller — Correct. Mutating admission controllers can modify the incoming resource before it’s persisted. Adding a sidecar container to a Pod is a modification — so it requires a mutating controller. This is exactly how Istio injects its Envoy sidecar proxy into Pods.
- C) Pod Security Admission controller — Incorrect. PSA is a specific built-in admission controller that enforces Pod Security Standards (Privileged, Baseline, Restricted). It validates Pods against these standards but doesn’t add sidecars.
- D) RBAC admission controller — Incorrect. There’s no such thing as an “RBAC admission controller.” RBAC is an authorization mode, not an admission controller. The RBAC authorizer runs during the authorization phase, which happens before admission control.
Key distinction:
| Type | What It Does | Example |
|---|---|---|
| Mutating | Modifies the resource | Add sidecar, inject default labels, set default resource limits |
| Validating | Approves or rejects the resource | Reject Pods without resource limits, reject privileged containers |
Mutating controllers run before validating controllers. This ensures that any modifications are also validated.
Domain: Cloud Native Security Tooling (Domain 6)
Self-Scoring Guide
Now that you’ve completed all 10 questions, calculate your score:
| Score | Result | Assessment |
|---|---|---|
| 9-10 | Excellent | You have a strong foundation. You’re well-prepared for the detailed chapters. |
| 7-8 | Good | Solid understanding with a few gaps. Pay attention to the topics you missed. |
| 5-6 | Fair | You have the basics but need focused study. Review the explanations carefully. |
| 3-4 | Needs Work | Important gaps exist. Study the Security Concepts Overview and Exam Overview before proceeding. |
| 0-2 | Starting Point | Don’t worry — this tutorial will teach you everything. Start from the beginning and study each chapter thoroughly. |
Questions by Domain
Here’s which domain each question tested, so you can identify your weak areas:
| Question | Domain | Topic |
|---|---|---|
| Q1 | Domain 1: Cloud Native Security | 4Cs of Cloud Native Security |
| Q2 | Domain 3: Threat Model | STRIDE threat modeling |
| Q3 | Domain 2: Cluster Components | RBAC (Role vs ClusterRole) |
| Q4 | Domain 5: Compliance | Pod Security Standards |
| Q5 | Domain 2: Cluster Components | Authentication vs Authorization |
| Q6 | Domain 5: Compliance | CIS Kubernetes Benchmarks |
| Q7 | Domain 6: Security Tooling | Cloud native security tools (Falco) |
| Q8 | Domain 2: Cluster Components | Secrets storage and encryption |
| Q9 | Domain 6: Security Tooling | Network Policies |
| Q10 | Domain 6: Security Tooling | Admission Controllers |
Domain Coverage
| Domain | Questions | Your Score |
|---|---|---|
| Domain 1: Cloud Native Security | Q1 | __ / 1 |
| Domain 2: Cluster Components | Q3, Q5, Q8 | __ / 3 |
| Domain 3: Threat Model | Q2 | __ / 1 |
| Domain 4: Platform Security | — | (Covered in later chapters) |
| Domain 5: Compliance | Q4, Q6 | __ / 2 |
| Domain 6: Security Tooling | Q7, Q9, Q10 | __ / 3 |
What to Do Next
Based on your score:
- Scored 8+: You’re ready to dive into the detailed chapters. Start with Chapter 2: Overview of Cloud Native Security.
- Scored 5-7: Review the Security Concepts Overview and the Exam Overview before proceeding.
- Scored below 5: Take your time with the Prerequisites & Study Plan and work through each chapter sequentially.
Remember — these practice questions are just the beginning. Every chapter in this tutorial includes practice questions at the end. By the time you finish the full tutorial, you’ll have answered dozens of exam-style questions and be ready for the real thing.
Chapter Complete!
You’ve finished the Introduction chapter. You now understand:
- What the KCSA exam is and who it’s for
- How the exam is structured (domains, weights, format)
- How KCSA compares to CKA and CKS
- The exam environment and rules
- Core security concepts (CIA Triad, defense in depth, least privilege, zero trust)
- How to plan your study time
- Strategies for tackling multiple-choice questions
- How to approach practice questions effectively
Next up: The detailed domain chapters, starting with Cloud Native Security.
