KCSA: Kubernetes and Cloud Native Security Associate Practice Exam

What the KCSA exam covers

• Overview of Cloud Native Security96 questions
• Kubernetes Cluster Component Security194 questions
• Kubernetes Security Fundamentals221 questions
• Kubernetes Threat Model141 questions
• Platform Security166 questions
• Compliance and Security Frameworks71 questions

Free KCSA sample questions

A sample of 10 questions with answers and explanations. Sign up free to practice all 889.

1. Question 1Overview of Cloud Native Security

   The '4Cs of Cloud Native Security' model describes defense in depth across which layers?

   • AControl, Compute, Cache, Code
   • BCloud, CDN, Cache, Cluster
   • CContainer, CNI, CSI, CRI
   • DCloud, Cluster, Container, CodeCorrect
   ✓ Correct answer: D

   The 4Cs of Cloud Native Security model provides hierarchical defense-in-depth across four layers: Cloud (the outermost infrastructure and account controls), Cluster (the Kubernetes control-plane and its configuration), Container (the image, runtime, and container settings), and Code (the application logic and its dependencies). Each layer protects the one inside it, ensuring that multiple independent security boundaries must be breached before a full compromise can occur.

   Why the other options are wrong

   • AControl, Compute, Cache, Code are not part of any established cloud-native security framework; these terms do not map to the 4Cs defense-in-depth layers defined by the Kubernetes security documentation.
   • BCloud, CDN, Cache, Cluster replaces the legitimate Container and Code layers with CDN and Cache, which are networking and caching concerns rather than independent security tiers in the 4Cs model.
   • CContainer, CNI, CSI, CRI conflates the single Container layer with three Kubernetes plugin interfaces (CNI for networking, CSI for storage, CRI for container runtimes), none of which represent the four hierarchical defense layers of the 4Cs model.
2. Question 2Kubernetes Security FundamentalsSelect all that apply

   Two NetworkPolicies select the same pod: policy X allows ingress from namespace 'a', policy Y allows ingress from namespace 'b'. Which TWO statements are correct? (Choose TWO)

   • AThere is no 'deny' rule in NetworkPolicy; you cannot write a policy that subtracts an allowCorrect
   • BThe pod becomes fully open because two policies conflict
   • CPolicy Y overrides policy X, so only namespace 'b' is allowed
   • DNetworkPolicies are additive: traffic from either namespace 'a' or 'b' is allowedCorrect
   ✓ Correct answer: A, D

   Kubernetes NetworkPolicy uses an additive allow model: when multiple policies select the same pod, the effective ingress or egress rules are the union of all matching rules. Traffic is permitted if any policy allows it. There is no deny rule type in NetworkPolicy, so it is impossible to use a second policy to revoke an allow granted by a first policy. The only way to block traffic is to ensure no policy permits it.

   Why the other options are wrong

   • BMultiple NetworkPolicies selecting the same pod do not cause the pod to become fully open. The pod is only open to traffic that at least one policy explicitly allows. Conflicting policies do not default to allow-all; the additive model simply unions the allowed sources.
   • CNetworkPolicies do not have override or precedence ordering. Policy Y does not override policy X; both apply simultaneously and their rules are combined. The result is that both namespace 'a' and namespace 'b' are allowed, not just 'b'.
3. Question 3Platform Security

   A team automates enforcement so every namespace must run pods with a RuntimeDefault seccomp profile. Which component best enforces this at admission?

   • AA PersistentVolumeClaim template mounted into every pod to record its seccomp profile setting
   • BA policy engine (Kyverno/OPA Gatekeeper) rule requiring seccompProfile.type RuntimeDefaultCorrect
   • CA CoreDNS rewrite rule injected into the Corefile to require the RuntimeDefault seccomp profile
   • DA kube-proxy iptables rule that matches seccomp annotations and drops the non-conforming pods
   ✓ Correct answer: B

   Policy engines like Kyverno and OPA Gatekeeper integrate as validating admission webhooks. By defining a policy that requires every pod's securityContext.seccompProfile.type to equal RuntimeDefault (or Localhost), the engine intercepts every pod creation or update request and rejects any that omit or override the seccomp profile - providing automated, consistent enforcement across all namespaces without relying on developers to set the field manually.

   Why the other options are wrong

   • AA PersistentVolumeClaim requests storage for a pod; it has no ability to inspect or require a pod's seccomp profile at admission.
   • CCoreDNS rewrite rules manipulate DNS queries and are unrelated to pod security fields; they cannot enforce a seccomp requirement on workloads.
   • Dkube-proxy programs Service networking with iptables and does not evaluate pod securityContext; it cannot gate admission on seccomp settings.
4. Question 4Platform SecuritySelect all that apply

   A pod must be hardened so a compromise cannot write to the container filesystem or gain new privileges. Which TWO securityContext settings directly achieve these goals? (Choose TWO)

   • APrivileged: true
   • BallowPrivilegeEscalation: falseCorrect
   • ChostPID: true
   • DreadOnlyRootFilesystem: trueCorrect
   ✓ Correct answer: B, D

   Two securityContext settings directly address the two hardening goals stated. readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, preventing any process in the container from writing to the filesystem, dropping files, modifying binaries, or persisting malicious payloads after a compromise. allowPrivilegeEscalation: false sets the no_new_privs bit on the process, preventing it from using setuid binaries, sudo, or Linux capabilities to gain higher privileges than those it started with. Together they implement two key controls from the restricted Pod Security Standard.

   Why the other options are wrong

   • APrivileged: true is a privilege escalation vector, not a hardening control. It removes namespace isolation and gives the container broad host device and kernel access, which is directly contrary to the goal of preventing privilege gain.
   • ChostPID: true shares the host's process namespace with the container, allowing it to see and potentially signal all host processes. This is an attack-enabling configuration that increases the blast radius of a compromise and does not contribute to filesystem or privilege hardening.
5. Question 5Kubernetes Security FundamentalsSelect all that apply

   Select TWO statements that are true about Kubernetes Role-Based Access Control (RBAC) aggregation.

   • AAn aggregated ClusterRole automatically inherits rules from any ClusterRole whose labels match its aggregationRule selectorsCorrect
   • BRoleBindings can aggregate permissions from multiple Roles in the same namespace
   • CThe built-in view, edit, and admin ClusterRoles use aggregation so extensions can add rules without modifying the originalsCorrect
   • DAggregated rules are evaluated only when there is no matching direct rule, acting as a fallback
   ✓ Correct answer: A, C

   ClusterRole aggregation uses aggregationRule.clusterRoleSelectors to union rules from any ClusterRole matching those label selectors. The built-in view, edit, and admin ClusterRoles declare aggregation labels (e.g., rbac.authorization.k8s.io/aggregate-to-view: 'true') so that CRD operators can extend those roles by creating a new ClusterRole with the matching label, without touching the built-in definition. This is a common and safe extensibility pattern.

   Why the other options are wrong

   • BRoleBindings grant permissions defined in a Role or ClusterRole but do not themselves aggregate multiple Roles - only ClusterRoles support aggregationRule.
   • DAggregated rules are merged (unioned) with direct rules and all apply simultaneously; there is no fallback ordering.
6. Question 6Overview of Cloud Native Security

   In the 4Cs of Cloud Native Security, which layer is considered the innermost and most foundational, meaning weaknesses in the layers surrounding it can still be partially compensated for, but a flaw at this layer is the hardest to contain?

   • ACloud
   • BCluster
   • CContainer
   • DCodeCorrect
   ✓ Correct answer: D

   The 4Cs are layered outermost-to-innermost as Cloud, Cluster, Container, and Code. Because Code runs inside everything else, a vulnerability such as an injection flaw or insecure dependency executes within the application itself, and the outer layers can only limit blast radius rather than prevent exploitation. This is why secure coding and dependency scanning are emphasized as the deepest line of defense.

   Why the other options are wrong

   • ACloud is the outermost layer, not the innermost foundational one.
   • BCluster sits between Cloud and Container and is not the innermost layer.
   • CContainer surrounds Code but is one layer out from the innermost.
7. Question 7Kubernetes Security Fundamentals

   During a review, you find a ClusterRoleBinding granting the 'cluster-admin' ClusterRole to the group 'system:authenticated'. Why is this dangerous?

   • AIt gives full administrative control of the cluster to every successfully authenticated identityCorrect
   • BIt only affects anonymous (unauthenticated) requests, so the impact is minimal
   • CIt restricts cluster-admin to a single namespace, breaking legitimate admins
   • DIt disables RBAC entirely until the binding is removed
   ✓ Correct answer: A

   The system:authenticated group includes all identities that pass authentication, including every user and ServiceAccount token holder. Granting them cluster-admin effectively removes least-privilege boundaries and lets anyone with valid credentials do anything, including deleting resources or reading all Secrets.

   Why the other options are wrong

   • Bsystem:authenticated is the opposite of anonymous; it covers all logged-in identities, maximizing exposure.
   • CA ClusterRoleBinding applies cluster-wide, not to one namespace.
   • DRBAC remains active; the problem is an overly broad grant, not a disabled authorizer.
8. Question 8Platform SecuritySelect all that apply

   A pod must be hardened to the PSS 'restricted' standard. Which TWO securityContext settings are required by that profile? (Choose TWO)

   • AallowPrivilegeEscalation: falseCorrect
   • Bcapabilities.drop includes "ALL"Correct
   • ChostNetwork: true
   • Dprivileged: true
   ✓ Correct answer: A, B

   PSS 'restricted' mandates disabling privilege escalation and dropping all capabilities (only NET_BIND_SERVICE may be added back), among other constraints like running as non-root and a RuntimeDefault/Localhost seccomp profile. hostNetwork and privileged are explicitly disallowed.

   Why the other options are wrong

   • ChostNetwork: true is forbidden under the restricted profile.
   • Dprivileged: true is forbidden under the restricted profile.
9. Question 9Kubernetes Cluster Component Security

   You apply a NetworkPolicy that should deny all ingress to a sensitive pod, but traffic is still getting through. After ruling out policy syntax, what is the MOST likely root cause specific to the networking component?

   • AThe installed CNI plugin does not implement NetworkPolicy enforcement, so the policy object is accepted but ineffectiveCorrect
   • BThe NetworkPolicy requires a matching egress rule on the source pod before its ingress deny rule is allowed to take effect
   • Ckube-proxy must be restarted so that it can compile the new NetworkPolicy into the node's iptables rule set
   • DNetworkPolicies only ever apply to traffic that crosses namespace boundaries and never to traffic within a single namespace
   ✓ Correct answer: A

   Kubernetes accepts and stores NetworkPolicy objects regardless of whether anything enforces them. Enforcement is the job of the CNI plugin (for example Calico or Cilium); a plugin that lacks NetworkPolicy support will silently allow the traffic. Verifying that the deployed CNI supports and enforces policy is a key part of validating network segmentation.

   Why the other options are wrong

   • BIngress and egress rules are independent, so a deny-all-ingress policy on the target pod takes effect on its own and does not require a corresponding egress rule on the source pod.
   • Ckube-proxy programs Service rules rather than NetworkPolicy, whose enforcement is the CNI's responsibility, so restarting kube-proxy would not make the ingress policy effective.
   • DNetworkPolicy applies to traffic destined for selected pods regardless of the source's namespace, so it is not limited to cross-namespace traffic as this option claims.
10. Question 10Kubernetes Threat ModelSelect all that apply

    An incident shows pods consuming maximum CPU running an unknown binary mining cryptocurrency, scheduled via the compromised credentials of an exposed Dashboard. Which two ATT&CK-style categories does this single incident span? (Choose two.)

    • AImpact, in the form of resource hijacking for cryptominingCorrect
    • BInitial Access through the exposed Kubernetes DashboardCorrect
    • CDefense Evasion by rotating etcd encryption keys
    • DExfiltration of the cluster CA private key
    ✓ Correct answer: A, B

    Resource hijacking, including cryptomining, falls under the Impact tactic because it abuses compute the victim pays for. An exposed Kubernetes Dashboard with usable credentials is a documented Initial Access vector that has led to real cryptomining campaigns. Nothing in the scenario indicates etcd key rotation or theft of the cluster CA private key.

    Why the other options are wrong

    • CNothing in the incident describes rotating etcd encryption keys, and that is not how this attack evades defenses.
    • DThere is no indication the cluster CA private key was exfiltrated; the activity is compute abuse.

Related Cloud Native resources

• KCSA study guideKey concepts
• Cloud Native practice examsAll Cloud Native
• Certification pathWhere this fits
• Certification exam guides & tipsBlog
• Plans & pricingFree & paid
• CKS practice examRelated
• CKA practice examRelated
• KCNA practice examRelated

KCSA practice exam FAQ