KCSA — Mock Exam — Part 1

22 minute read

Mock Exam — Part 1

This is the first of two mock exams. It contains 15 multiple-choice questions distributed across all six KCSA exam domains, weighted proportionally to the real exam.

Instructions

  1. Set a timer for 22 minutes (proportional to 90 min / 60 questions × 15 questions)
  2. Do not look at the answers until you have selected your choice
  3. Read each question carefully — pay attention to qualifiers like “BEST”, “PRIMARY”, “NOT”, and “TRUE”
  4. Use elimination — cross off obviously wrong options before choosing
  5. Record your answers on paper before checking
  6. After finishing, expand every answer — read all four explanations even for questions you got right

Treat this like a real exam. No notes, no searching, no second-guessing after you move on.

Domain Distribution

Domain Weight Questions in This Mock
Overview of Cloud Native Security 14% 2 (Q1, Q2)
Kubernetes Cluster Security 22% 3 (Q3, Q5, Q6)
Kubernetes Cluster Component Security 22% 3 (Q4, Q11, Q14)
Kubernetes Security Fundamentals 16% 3 (Q7, Q8, Q12)
Kubernetes Threat Model 16% 2 (Q9, Q10)
Compliance and Security Frameworks 10% 2 (Q13, Q15)

Questions

Q1: 4Cs of Cloud Native Security

Domain: Overview of Cloud Native Security

A security architect is designing a defense-in-depth strategy for a Kubernetes-based application. They want to apply security controls at every layer using the Cloud Native Security model.

Which of the following correctly lists the 4Cs of Cloud Native Security from the outermost to the innermost layer?

A) Cloud → Container → Cluster → Code
B) Cloud → Cluster → Container → Code
C) Code → Container → Cluster → Cloud
D) Cluster → Cloud → Container → Code

Show Answer

Correct Answer: B) Cloud → Cluster → Container → Code

The 4Cs of Cloud Native Security represent concentric layers of defense, starting from the broadest infrastructure layer and moving inward to the application code.

  • A) Cloud → Container → Cluster → Code — Incorrect. Container and Cluster are swapped. The cluster layer (Kubernetes control plane, RBAC, network policies) wraps around individual containers.
  • B) Cloud → Cluster → Container → Code — Correct. This is the official order. Cloud (infrastructure) → Cluster (Kubernetes) → Container (runtime) → Code (application). Each inner layer depends on the security of the outer layers.
  • C) Code → Container → Cluster → Cloud — Incorrect. This is the reverse order. The 4Cs go from outermost to innermost, not innermost to outermost.
  • D) Cluster → Cloud → Container → Code — Incorrect. Cloud is the outermost layer, not Cluster. The cloud provider’s security forms the foundation.

Q2: SLSA Framework Levels

Domain: Overview of Cloud Native Security

Your organization is working toward improving the integrity of their software supply chain. They want to ensure that builds are reproducible and that the build platform cannot be tampered with by individual developers.

Which SLSA (Supply-chain Levels for Software Artifacts) level requires a hosted, tamper-resistant build platform?

A) SLSA Level 1
B) SLSA Level 2
C) SLSA Level 3
D) SLSA Level 4

Show Answer

Correct Answer: C) SLSA Level 3

SLSA defines increasing levels of supply chain integrity:

  • A) SLSA Level 1 — Incorrect. Level 1 only requires that the build process is documented and produces provenance metadata. There is no requirement for a hosted build platform.
  • B) SLSA Level 2 — Incorrect. Level 2 requires a hosted build service and authenticated provenance, but does not require the build platform to be tamper-resistant.
  • C) SLSA Level 3 — Correct. Level 3 requires that the build platform is hardened and tamper-resistant. Builds must be isolated from one another, and the platform must resist insider threats. This means individual developers cannot influence the build environment.
  • D) SLSA Level 4 — Incorrect. While SLSA originally described Level 4 (requiring hermetic and reproducible builds), the current SLSA specification (v1.0) defines three levels, with Level 3 being the highest. Earlier drafts had four levels, but the framework has been simplified.

Q3: API Server Admission Control Pipeline

Domain: Kubernetes Cluster Security

A Kubernetes administrator is troubleshooting why a Pod creation request was rejected. The request passed authentication and authorization but was still denied.

What is the correct order of the API server request processing pipeline?

A) Authentication → Admission Control → Authorization → Persist to etcd
B) Authorization → Authentication → Admission Control → Persist to etcd
C) Authentication → Authorization → Admission Control → Persist to etcd
D) Admission Control → Authentication → Authorization → Persist to etcd

Show Answer

Correct Answer: C) Authentication → Authorization → Admission Control → Persist to etcd

The API server processes every request through a strict pipeline:

  • A) Authentication → Admission Control → Authorization → Persist to etcd — Incorrect. Admission control runs after authorization, not before. The API server must first determine who the requester is (AuthN) and whether they are allowed (AuthZ) before the request reaches admission controllers.
  • B) Authorization → Authentication → Admission Control → Persist to etcd — Incorrect. Authentication always comes before authorization. The system must know who you are before it can decide what you are allowed to do.
  • C) Authentication → Authorization → Admission Control → Persist to etcd — Correct. This is the exact order: (1) Authenticate the request (who are you?), (2) Authorize the request (are you allowed?), (3) Run admission controllers (mutating then validating — should this be modified or rejected based on policy?), (4) Persist the resource to etcd.
  • D) Admission Control → Authentication → Authorization → Persist to etcd — Incorrect. Admission control is the last check before persistence, not the first step.

Q4: etcd Encryption Providers

Domain: Kubernetes Cluster Component Security

A security team is configuring encryption at rest for Kubernetes Secrets stored in etcd. They need to choose an encryption provider.

Which encryption provider stores data in plaintext without any encryption?

A) aescbc
B) aesgcm
C) secretbox
D) identity

Show Answer

Correct Answer: D) identity

The Kubernetes EncryptionConfiguration supports multiple providers:

  • A) aescbc — Incorrect. aescbc uses AES-CBC encryption with PKCS#7 padding. It is a strong encryption provider, though it does not provide authenticated encryption (no built-in integrity check).
  • B) aesgcm — Incorrect. aesgcm uses AES-GCM which provides both encryption and authenticated encryption (integrity). However, the key must be rotated frequently because AES-GCM is vulnerable if nonces are reused.
  • C) secretbox — Incorrect. secretbox uses XSalsa20 and Poly1305 for encryption and authentication. It is a strong, modern choice.
  • D) identity — Correct. The identity provider performs no encryption. Data is stored as-is in etcd. This is the default behavior when no EncryptionConfiguration is applied. It is listed as a provider so that administrators can explicitly configure a fallback for reading unencrypted data during migration.

Q5: RBAC — Role vs ClusterRole

Domain: Kubernetes Cluster Security

A Kubernetes administrator needs to grant a developer read access to Pods in the staging namespace only. The developer should not be able to access Pods in any other namespace.

Which combination of RBAC resources should the administrator use?

A) ClusterRole + ClusterRoleBinding
B) Role + ClusterRoleBinding
C) ClusterRole + RoleBinding
D) Role + RoleBinding

Show Answer

Correct Answer: D) Role + RoleBinding

RBAC resources have specific scoping rules:

  • A) ClusterRole + ClusterRoleBinding — Incorrect. A ClusterRoleBinding grants permissions cluster-wide across all namespaces. This would give the developer access to Pods in every namespace, not just staging.
  • B) Role + ClusterRoleBinding — Incorrect. A Role is namespaced but a ClusterRoleBinding is cluster-wide. You cannot bind a namespace-scoped Role with a ClusterRoleBinding — this is not a valid combination for namespace-specific access.
  • C) ClusterRole + RoleBinding — Partially correct but not the best choice. A ClusterRole bound with a RoleBinding in the staging namespace would technically work — it scopes the ClusterRole permissions to that namespace. However, this pattern is used when you want to reuse a ClusterRole across multiple namespaces. Since the requirement is access to a single namespace, a simple Role is more appropriate and follows the principle of least privilege.
  • D) Role + RoleBinding — Correct. A Role defines permissions within a specific namespace (staging). A RoleBinding in that same namespace binds the Role to the developer. This is the simplest, most restrictive, and most correct approach for single-namespace access.

Q6: Service Account Token Projection

Domain: Kubernetes Cluster Security

A security engineer is reviewing the Kubernetes configuration and notices that some Pods are using legacy service account tokens while others use projected (bound) tokens.

What is the PRIMARY security advantage of projected service account tokens over legacy tokens?

A) Projected tokens are encrypted with AES-256, while legacy tokens are stored in plaintext
B) Projected tokens have a bounded lifetime and audience, while legacy tokens never expire
C) Projected tokens are stored in etcd, while legacy tokens are stored in the Pod filesystem
D) Projected tokens use mutual TLS, while legacy tokens use bearer authentication

Show Answer

Correct Answer: B) Projected tokens have a bounded lifetime and audience, while legacy tokens never expire

  • A) Projected tokens are encrypted with AES-256, while legacy tokens are stored in plaintext — Incorrect. Neither type is encrypted with AES-256. Legacy tokens are stored as Kubernetes Secrets (base64-encoded), and projected tokens are issued as JWTs by the TokenRequest API. Encryption is a separate concern (etcd encryption at rest).
  • B) Projected tokens have a bounded lifetime and audience, while legacy tokens never expire — Correct. This is the primary difference. Legacy service account tokens are long-lived Secrets that never expire and have no audience binding. Projected tokens are time-bound (default 1 hour, auto-rotated by the kubelet), audience-bound (valid only for a specific API server), and object-bound (invalidated when the Pod is deleted). These properties significantly reduce the blast radius of a token compromise.
  • C) Projected tokens are stored in etcd, while legacy tokens are stored in the Pod filesystem — Incorrect. It is actually the reverse — legacy tokens are stored as Secrets in etcd and mounted into the Pod. Projected tokens are issued dynamically and mounted via the projected volume, they are not persisted as Secret objects in etcd.
  • D) Projected tokens use mutual TLS, while legacy tokens use bearer authentication — Incorrect. Both token types are used as bearer tokens in the Authorization header. mTLS (mutual TLS) is a separate authentication mechanism used by components like the kubelet or by service meshes.

Q7: Pod Security Standards Levels

Domain: Kubernetes Security Fundamentals

A cluster administrator wants to enforce the most restrictive Pod Security Standard to prevent any privileged operations in a production namespace.

Which Pod Security Standard level should be applied?

A) Privileged
B) Baseline
C) Restricted
D) Enforced

Show Answer

Correct Answer: C) Restricted

  • A) Privileged — Incorrect. The Privileged level is completely unrestricted — it allows everything, including privileged containers, host namespaces, and all capabilities. It provides no security and is intended only for system-level workloads like CNI plugins or log collectors that need full access.
  • B) Baseline — Incorrect. Baseline prevents known privilege escalation vectors (e.g., privileged containers, hostPID, hostNetwork) but still allows running as root, adding non-default capabilities, and writable root filesystems. It is a reasonable default but not the most restrictive.
  • C) Restricted — Correct. Restricted is the most hardened Pod Security Standard. It requires: running as non-root, dropping ALL capabilities, read-only root filesystem recommended, no privilege escalation (allowPrivilegeEscalation: false), Seccomp profile set to RuntimeDefault or Localhost. This is the recommended level for production workloads.
  • D) Enforced — Incorrect. “Enforced” is not a Pod Security Standard level — it is a Pod Security Admission mode. The three levels are Privileged, Baseline, and Restricted. The three modes are enforce, audit, and warn.

Q8: Network Policy AND vs OR Logic

Domain: Kubernetes Security Fundamentals

An administrator creates the following NetworkPolicy:

spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
          namespaceSelector:
            matchLabels:
              env: production

Which Pods can send traffic to the app: web Pods?

A) Any Pod with role: frontend label OR any Pod in a namespace with env: production label
B) Any Pod with role: frontend label in a namespace with env: production label
C) Any Pod in any namespace
D) No Pods — the policy syntax is invalid

Show Answer

Correct Answer: B) Any Pod with role: frontend label in a namespace with env: production label

This question tests the critical difference between AND and OR logic in NetworkPolicy:

  • A) Any Pod with role: frontend OR any Pod in a namespace with env: production — Incorrect. This would be OR logic, which happens when podSelector and namespaceSelector are separate items in the from array (two separate - entries). In the YAML above, both selectors are under the same array element (single -), making them AND logic.
  • B) Any Pod with role: frontend in a namespace with env: production — Correct. When podSelector and namespaceSelector appear in the same from entry (same - list item), they are combined with AND logic. The Pod must match BOTH conditions: it must have the role: frontend label AND reside in a namespace with the env: production label.
  • C) Any Pod in any namespace — Incorrect. The policy has specific selector rules that restrict traffic to matching Pods only. An empty ingress with no from field would allow all traffic, but that is not what this policy specifies.
  • D) No Pods — the policy syntax is invalid — Incorrect. The syntax is perfectly valid. Both podSelector and namespaceSelector can appear in the same from entry to create an AND condition.

The rule to remember: Same array item = AND. Separate array items = OR.

Q9: STRIDE Model Category

Domain: Kubernetes Threat Model

An attacker gains access to a Kubernetes cluster and creates a CronJob that periodically exfiltrates Secrets from all namespaces. The CronJob runs under a service account with excessive permissions.

Which STRIDE threat category BEST describes this attack?

A) Spoofing
B) Tampering
C) Elevation of Privilege
D) Information Disclosure

Show Answer

Correct Answer: D) Information Disclosure

  • A) Spoofing — Incorrect. Spoofing involves impersonating another identity (e.g., using stolen certificates or tokens to pretend to be another user). While the attacker may have used spoofing to gain initial access, the described action (exfiltrating Secrets) is about data exposure, not identity impersonation.
  • B) Tampering — Incorrect. Tampering involves unauthorized modification of data or code (e.g., altering ConfigMaps, injecting malicious containers). The attacker is reading and exfiltrating Secrets, not modifying them.
  • C) Elevation of Privilege — Incorrect. Elevation of privilege involves gaining higher permissions than authorized (e.g., escaping a container to the host). While the overly permissive service account is a contributing factor, the attack itself — exfiltrating Secrets — is an information disclosure action. The excessive permissions are the vulnerability, not the attack category.
  • D) Information Disclosure — Correct. The attacker’s goal is to read and exfiltrate sensitive data (Secrets). Information Disclosure in STRIDE covers any scenario where confidential information is exposed to unauthorized parties. Kubernetes Secrets (database passwords, API keys, TLS certificates) are the target, and the CronJob is the mechanism for ongoing exfiltration.

Q10: Container Escape Prevention

Domain: Kubernetes Threat Model

A security team is hardening a Kubernetes cluster to prevent container escape attacks. They want to ensure that even if an attacker compromises a container, they cannot break out to the host.

Which of the following configurations MOST directly prevents container escape?

A) Enabling NetworkPolicies to restrict Pod-to-Pod traffic
B) Setting hostPID: false, hostNetwork: false, and privileged: false in the security context
C) Configuring resource limits (CPU and memory) on all Pods
D) Enabling audit logging at the RequestResponse level

Show Answer

Correct Answer: B) Setting hostPID: false, hostNetwork: false, and privileged: false in the security context

  • A) Enabling NetworkPolicies to restrict Pod-to-Pod traffic — Incorrect. NetworkPolicies control network traffic between Pods and external endpoints. They operate at the network layer (L3/L4) and do nothing to prevent a container from escaping to the host kernel. A container escape is about breaking out of the container’s isolation boundary, not about network communication.
  • B) Setting hostPID: false, hostNetwork: false, and privileged: false — Correct. These three settings directly address the most common container escape vectors: privileged: true gives the container full access to the host’s devices and kernel capabilities. hostPID: true allows the container to see and interact with host processes. hostNetwork: true gives the container access to the host’s network stack. Setting all three to false (and enforcing via Pod Security Standards) eliminates the primary escape paths.
  • C) Configuring resource limits (CPU and memory) on all Pods — Incorrect. Resource limits prevent denial-of-service (resource exhaustion) but do not prevent container escape. A container can escape to the host regardless of its CPU and memory allocation.
  • D) Enabling audit logging at the RequestResponse level — Incorrect. Audit logging is a detective control — it records what happened for investigation purposes. It does not prevent container escape. Prevention requires restrictive security contexts and admission control policies.

Q11: gVisor vs Kata Containers

Domain: Kubernetes Cluster Component Security

A security architect is evaluating container runtime sandboxing options for running untrusted workloads. They need to choose between gVisor and Kata Containers.

Which statement is TRUE about how gVisor provides container isolation?

A) gVisor runs each container inside a lightweight virtual machine with its own kernel
B) gVisor intercepts system calls from the container and services them in a user-space kernel
C) gVisor uses Linux namespaces and cgroups with additional SELinux policies
D) gVisor encrypts all container filesystem operations using hardware-based encryption

Show Answer

Correct Answer: B) gVisor intercepts system calls from the container and services them in a user-space kernel

  • A) gVisor runs each container inside a lightweight virtual machine with its own kernel — Incorrect. This describes Kata Containers, not gVisor. Kata Containers uses lightweight VMs (with QEMU or Firecracker) where each container gets its own guest kernel, providing strong hardware-based isolation.
  • B) gVisor intercepts system calls from the container and services them in a user-space kernel — Correct. gVisor (developed by Google) interposes a user-space kernel called Sentry between the container and the host kernel. The Sentry intercepts system calls from the application and re-implements them in user space. Only a small subset of system calls are passed to the actual host kernel through Gofer. This dramatically reduces the attack surface of the host kernel.
  • C) gVisor uses Linux namespaces and cgroups with additional SELinux policies — Incorrect. Namespaces and cgroups are the standard container isolation mechanisms used by runc (the default container runtime). gVisor goes beyond these by adding a user-space kernel layer. While gVisor does use namespaces internally, the key differentiator is the system call interception.
  • D) gVisor encrypts all container filesystem operations using hardware-based encryption — Incorrect. gVisor does not provide filesystem encryption. It provides system call isolation. Filesystem encryption is a separate concern handled by tools like dm-crypt or encrypted volumes.

Q12: OPA Gatekeeper vs Kyverno

Domain: Kubernetes Security Fundamentals

A Kubernetes administrator wants to implement policy-as-code to enforce that all container images must come from an approved registry (registry.company.com).

What is a key architectural difference between OPA Gatekeeper and Kyverno?

A) Gatekeeper uses Rego language for policies, while Kyverno uses native Kubernetes YAML
B) Gatekeeper can only validate resources, while Kyverno can only mutate resources
C) Gatekeeper runs as a DaemonSet on every node, while Kyverno runs as a CronJob
D) Gatekeeper requires etcd access, while Kyverno uses the Kubernetes API

Show Answer

Correct Answer: A) Gatekeeper uses Rego language for policies, while Kyverno uses native Kubernetes YAML

  • A) Gatekeeper uses Rego language for policies, while Kyverno uses native Kubernetes YAML — Correct. This is the most significant architectural difference. OPA Gatekeeper policies are written in Rego, a purpose-built policy language from the Open Policy Agent project. Kyverno policies are defined as native Kubernetes custom resources using standard YAML, making them more accessible to Kubernetes administrators who may not know Rego. Both tools function as admission controllers.
  • B) Gatekeeper can only validate, while Kyverno can only mutate — Incorrect. Both tools support both mutation and validation. Gatekeeper added mutation support (in beta/stable), and Kyverno has supported both validate and mutate rules since its inception. Kyverno also supports generate rules for creating resources automatically.
  • C) Gatekeeper runs as a DaemonSet, while Kyverno runs as a CronJob — Incorrect. Both Gatekeeper and Kyverno run as Deployments (webhook servers) in the cluster, not as DaemonSets or CronJobs. They register as admission webhooks with the API server.
  • D) Gatekeeper requires etcd access, while Kyverno uses the Kubernetes API — Incorrect. Neither tool accesses etcd directly. Both interact with the Kubernetes API server through admission webhook callbacks. They receive admission review requests from the API server and return allow/deny decisions.

Q13: Falco Data Source

Domain: Compliance and Security Frameworks

A security engineer is deploying Falco for runtime threat detection in a Kubernetes cluster. They want to understand what data Falco uses to detect threats.

What is the PRIMARY data source that Falco uses to detect runtime security threats in containers?

A) Container image vulnerability scan results from Trivy
B) Kubernetes audit log events from the API server
C) Linux kernel system calls captured via eBPF or a kernel module
D) Network packet captures from the container network interface

Show Answer

Correct Answer: C) Linux kernel system calls captured via eBPF or a kernel module

  • A) Container image vulnerability scan results from Trivy — Incorrect. Trivy is a separate tool for static vulnerability scanning. Falco operates at runtime, not at image scan time. Falco does not consume Trivy output as a data source.
  • B) Kubernetes audit log events from the API server — Partially correct but not the primary source. Falco can ingest Kubernetes audit logs as a secondary data source (via the k8s_audit plugin), but this is not its primary detection mechanism. Audit logs capture API server events, not container-level behavior.
  • C) Linux kernel system calls captured via eBPF or a kernel module — Correct. Falco’s primary data source is system calls from the Linux kernel. It uses either an eBPF probe or a kernel module to intercept syscalls in real time. This allows Falco to detect behaviors like file access, process execution, network connections, and privilege changes inside containers as they happen. This is what makes Falco a runtime threat detection tool.
  • D) Network packet captures from the container network interface — Incorrect. Falco does not perform packet capture (pcap). While Falco can detect network-related events through syscalls (e.g., connect, accept), it does not analyze network packets at the protocol level. Tools like Cilium Hubble or service mesh proxies handle network-layer observability.

Q14: CIS Benchmark Tool

Domain: Kubernetes Cluster Component Security

A cluster administrator needs to verify that their Kubernetes cluster meets the CIS Kubernetes Benchmark recommendations.

Which open-source tool is specifically designed to run CIS Kubernetes Benchmark checks automatically?

A) Trivy
B) kube-bench
C) Falco
D) kubeaudit

Show Answer

Correct Answer: B) kube-bench

  • A) Trivy — Incorrect. Trivy is primarily a vulnerability scanner for container images, filesystems, IaC configurations, and SBOMs. While Trivy has some misconfiguration scanning capabilities, it is not specifically designed for running CIS Kubernetes Benchmark checks against cluster components.
  • B) kube-bench — Correct. kube-bench (by Aqua Security) is an open-source tool specifically built to check whether a Kubernetes cluster is deployed according to the CIS Kubernetes Benchmark. It runs checks against control plane components (API server, etcd, scheduler, controller-manager), worker nodes (kubelet, proxy), and policies. It outputs pass/fail/warn results for each CIS recommendation.
  • C) Falco — Incorrect. Falco is a runtime threat detection tool that monitors system calls. It does not assess cluster configuration against CIS Benchmark recommendations. Falco detects threats at runtime; kube-bench checks configuration at rest.
  • D) kubeaudit — Incorrect. kubeaudit (by Shopify) audits Kubernetes cluster configurations for security best practices, but it focuses on workload-level checks (security contexts, capabilities, resource limits) rather than the full CIS Kubernetes Benchmark. It is complementary but not a direct CIS Benchmark tool.

Q15: NIST SP 800-190 Focus

Domain: Compliance and Security Frameworks

A compliance officer asks the Kubernetes team to align their security practices with NIST SP 800-190.

What is the PRIMARY focus of NIST SP 800-190?

A) General cybersecurity risk management framework for all IT systems
B) Application container security — risks and countermeasures for container technologies
C) Kubernetes-specific network segmentation and firewall requirements
D) Cloud service provider compliance and shared responsibility requirements

Show Answer

Correct Answer: B) Application container security — risks and countermeasures for container technologies

  • A) General cybersecurity risk management framework for all IT systems — Incorrect. This describes the NIST Cybersecurity Framework (CSF) or NIST SP 800-53, not SP 800-190. SP 800-190 is specifically focused on container security.
  • B) Application container security — risks and countermeasures for container technologies — Correct. NIST SP 800-190, titled “Application Container Security Guide,” focuses specifically on the security concerns associated with container technologies. It covers risks in five areas: images, registries, orchestrators, containers, and host OS. It provides countermeasures and recommendations for each area. This is a key document for the KCSA exam.
  • C) Kubernetes-specific network segmentation and firewall requirements — Incorrect. NIST SP 800-190 is container-focused, not Kubernetes-specific. It does not prescribe specific network segmentation or firewall rules. Network Policies and segmentation are Kubernetes-native concepts not covered in detail by this NIST publication.
  • D) Cloud service provider compliance and shared responsibility requirements — Incorrect. Shared responsibility is a cloud provider concept (addressed by frameworks like CSA STAR or cloud-specific compliance standards). NIST SP 800-190 focuses on the container technology layer regardless of whether it runs on-premises or in the cloud.

Score Card

Record your answers and calculate your score:

Question Your Answer Correct Answer Result
Q1 ___ B ⬜
Q2 ___ C ⬜
Q3 ___ C ⬜
Q4 ___ D ⬜
Q5 ___ D ⬜
Q6 ___ B ⬜
Q7 ___ C ⬜
Q8 ___ B ⬜
Q9 ___ D ⬜
Q10 ___ B ⬜
Q11 ___ B ⬜
Q12 ___ A ⬜
Q13 ___ C ⬜
Q14 ___ B ⬜
Q15 ___ B ⬜

Your Score: ___ / 15

Passing Threshold

Score Percentage Result
12–15 80–100% ✅ Pass — You are well-prepared
11 73% ⚠️ Borderline — Review weak areas
8–10 53–67% ❌ Needs work — Review relevant chapters
Below 8 Below 53% ❌ Significant gaps — Revisit the tutorial from the beginning

The KCSA passing score is 75%. On a 15-question mock, that means you need at least 11 correct to be on track.

Missed Questions? Review These Chapters

Question Domain Review Chapter
Q1, Q2 Cloud Native Security Chapter 2
Q3, Q5, Q6 Cluster Security Chapter 4
Q4, Q11, Q14 Component Security Chapters 3, 7
Q7, Q8, Q12 Security Fundamentals Chapters 5, 9
Q9, Q10 Threat Model Chapter 6
Q13, Q15 Compliance & Frameworks Chapters 8, 9

Next: Mock Exam — Part 2

Updated:

You may also enjoy