KCSA — Platform Security — Practice Questions
Practice Questions — Platform Security
These 10 questions cover the key topics from the Platform Security chapter: CIS benchmarks, kube-bench, sandboxed runtimes, RuntimeClass, admission controllers, policy engines, image signing, SLSA framework, multi-tenancy models, and namespace isolation.
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: What is the primary purpose of the CIS Kubernetes Benchmark?
A) To provide a container image scanning standard for Kubernetes workloads
B) To define a set of best practices and configuration recommendations for hardening Kubernetes clusters
C) To specify the minimum hardware requirements for running Kubernetes in production
D) To create a compliance certification that cloud providers must pass
Show Answer
Correct Answer: B) To define a set of best practices and configuration recommendations for hardening Kubernetes clusters
The CIS (Center for Internet Security) Kubernetes Benchmark is an industry-standard guide that provides prescriptive configuration recommendations for hardening Kubernetes components — including the API server, etcd, kubelet, and policies like RBAC and Pod Security.
- A) To provide a container image scanning standard for Kubernetes workloads — Incorrect. The CIS Benchmark focuses on cluster configuration hardening, not image scanning. Image scanning is handled by tools like Trivy, Grype, and Snyk.
- B) To define a set of best practices and configuration recommendations for hardening Kubernetes clusters — Correct. The CIS Benchmark covers control plane configuration, worker node settings, policies, and more — all organized into Level 1 (basic) and Level 2 (defense-in-depth) recommendations.
- C) To specify the minimum hardware requirements for running Kubernetes in production — Incorrect. The CIS Benchmark is about security configuration, not hardware specifications. Hardware requirements are documented in the Kubernetes official documentation.
- D) To create a compliance certification that cloud providers must pass — Incorrect. While the CIS Benchmark is used in compliance assessments, it is not a certification that providers must pass. It is a voluntary best-practice guide that organizations can adopt.
Topic: Node & OS Hardening
Q2: Which tool automates checking a Kubernetes cluster against the CIS Benchmark?
A) Trivy
B) Falco
C) kube-bench
D) cosign
Show Answer
Correct Answer: C) kube-bench
kube-bench is an open-source tool by Aqua Security that runs automated checks against the CIS Kubernetes Benchmark on control plane and worker nodes, reporting PASS, FAIL, WARN, and INFO results with remediation guidance.
- A) Trivy — Incorrect. Trivy is a vulnerability scanner for container images, filesystems, and IaC configurations. It does not check cluster configuration against CIS Benchmarks.
- B) Falco — Incorrect. Falco is a runtime security monitoring tool that detects anomalous behavior using eBPF or kernel modules. It monitors running workloads, not static cluster configuration.
- C) kube-bench — Correct. kube-bench is specifically designed to check whether Kubernetes is deployed according to CIS Benchmark recommendations. It can run on both master and worker nodes and provides actionable remediation steps.
- D) cosign — Incorrect. cosign is an image signing and verification tool from the Sigstore project. It has nothing to do with CIS Benchmark checking.
Topic: Node & OS Hardening
Q3: How does gVisor (runsc) provide container isolation differently from standard runc?
A) gVisor runs each container inside a lightweight virtual machine with its own kernel
B) gVisor intercepts system calls in a user-space kernel, preventing containers from directly accessing the host kernel
C) gVisor encrypts all container filesystem operations to prevent data leakage
D) gVisor replaces Linux namespaces with a custom isolation mechanism based on hardware enclaves
Show Answer
Correct Answer: B) gVisor intercepts system calls in a user-space kernel, preventing containers from directly accessing the host kernel
gVisor provides a user-space kernel called Sentry that intercepts system calls from the container application. Instead of passing syscalls directly to the host kernel (as runc does), Sentry handles them in user space, dramatically reducing the host kernel attack surface.
- A) gVisor runs each container inside a lightweight virtual machine with its own kernel — Incorrect. This describes Kata Containers, not gVisor. gVisor does not use virtual machines. It uses a user-space kernel (Sentry) to intercept syscalls.
- B) gVisor intercepts system calls in a user-space kernel, preventing containers from directly accessing the host kernel — Correct. gVisor’s Sentry component implements approximately 200 Linux syscalls in user space. The container application never directly interacts with the host kernel, reducing the attack surface significantly.
- C) gVisor encrypts all container filesystem operations to prevent data leakage — Incorrect. gVisor does not provide filesystem encryption. Its isolation mechanism is syscall interception, not encryption.
- D) gVisor replaces Linux namespaces with a custom isolation mechanism based on hardware enclaves — Incorrect. gVisor still uses Linux namespaces and seccomp as part of its security model. It does not use hardware enclaves. Hardware enclave technology (like Intel SGX) is a separate concept.
Topic: Runtime Security & Sandboxing
Q4: When would you choose Kata Containers over gVisor for workload isolation?
A) When you need the fastest possible cold start time for serverless functions
B) When you need the strongest possible isolation with hardware-level separation and full syscall compatibility
C) When you want to reduce memory overhead to the minimum possible
D) When you need to run containers on nodes without hardware virtualization support
Show Answer
Correct Answer: B) When you need the strongest possible isolation with hardware-level separation and full syscall compatibility
Kata Containers runs each pod inside a lightweight virtual machine with a dedicated guest kernel, providing hardware-level isolation. This is the strongest isolation available and maintains full Linux syscall compatibility because the guest runs a real kernel.
- A) When you need the fastest possible cold start time for serverless functions — Incorrect. Kata Containers has a slower cold start than both gVisor and standard runc because it needs to boot a VM. For fast cold starts, gVisor or standard runc is better.
- B) When you need the strongest possible isolation with hardware-level separation and full syscall compatibility — Correct. Kata Containers provides the highest isolation level (hardware VM boundary) and full syscall compatibility (real Linux kernel in the VM). This is ideal for strict compliance requirements or running completely untrusted code.
- C) When you want to reduce memory overhead to the minimum possible — Incorrect. Kata Containers has higher memory overhead than gVisor because each pod gets its own kernel and VM. For lower overhead, gVisor is more appropriate.
- D) When you need to run containers on nodes without hardware virtualization support — Incorrect. Kata Containers requires hardware virtualization extensions (Intel VT-x or AMD-V). Without them, Kata cannot run. gVisor, on the other hand, does not require hardware virtualization.
Topic: Runtime Security & Sandboxing
Q5: In the Kubernetes API request flow, what is the correct order of the admission control stages?
A) Validating Admission → Mutating Admission → Schema Validation → Persist to etcd
B) Authentication → Authorization → Schema Validation → Mutating Admission → Validating Admission
C) Authentication → Authorization → Mutating Admission → Schema Validation → Validating Admission → Persist to etcd
D) Authorization → Authentication → Mutating Admission → Validating Admission → Persist to etcd
Show Answer
Correct Answer: C) Authentication → Authorization → Mutating Admission → Schema Validation → Validating Admission → Persist to etcd
The Kubernetes API server processes requests in a specific pipeline order. Authentication verifies identity, authorization checks permissions, mutating admission modifies the request, schema validation ensures the resource conforms to the API schema, validating admission applies policy checks, and finally the object is persisted to etcd.
- A) Validating Admission → Mutating Admission → Schema Validation → Persist to etcd — Incorrect. The order is reversed — mutating admission runs before validating admission. Additionally, this option omits authentication and authorization, which are the first two stages.
- B) Authentication → Authorization → Schema Validation → Mutating Admission → Validating Admission — Incorrect. Schema validation occurs after mutating admission, not before it. This ensures the schema check validates the mutated object.
- C) Authentication → Authorization → Mutating Admission → Schema Validation → Validating Admission → Persist to etcd — Correct. This is the exact order. Mutating webhooks can modify the resource first, then the schema is validated, then validating webhooks accept or reject the final result.
- D) Authorization → Authentication → Mutating Admission → Validating Admission → Persist to etcd — Incorrect. Authentication must happen before authorization — you cannot check permissions until you know who is making the request.
Topic: Admission Controllers & Policy Engines
Q6: What is a key advantage of Kyverno over OPA/Gatekeeper?
A) Kyverno uses the Rego language, which is more expressive than YAML
B) Kyverno can natively generate resources and mutate requests using YAML-based policies
C) Kyverno is a CNCF Graduated project while Gatekeeper is still in Sandbox
D) Kyverno does not require any webhook configuration to function
Show Answer
Correct Answer: B) Kyverno can natively generate resources and mutate requests using YAML-based policies
Kyverno’s key differentiators are its YAML-based policy language (no Rego needed), native mutation support, and the ability to automatically generate companion resources (like creating a default NetworkPolicy when a new namespace is created).
- A) Kyverno uses the Rego language, which is more expressive than YAML — Incorrect. Kyverno uses YAML, not Rego. Rego is the policy language used by OPA/Gatekeeper. Kyverno’s appeal is specifically that it avoids Rego in favor of familiar YAML syntax.
- B) Kyverno can natively generate resources and mutate requests using YAML-based policies — Correct. Kyverno has three policy types: validate, mutate, and generate. The generate capability is unique — neither Gatekeeper nor ValidatingAdmissionPolicy can auto-create resources. Combined with YAML syntax, this makes Kyverno accessible and powerful.
- C) Kyverno is a CNCF Graduated project while Gatekeeper is still in Sandbox — Incorrect. Both are mature CNCF projects. OPA (which Gatekeeper is based on) is actually a CNCF Graduated project, while Kyverno is CNCF Incubating — the reverse of what this option states.
- D) Kyverno does not require any webhook configuration to function — Incorrect. Kyverno operates as a webhook-based admission controller, just like Gatekeeper. It registers itself as both a mutating and validating admission webhook with the API server.
Topic: Admission Controllers & Policy Engines
Q7: What does cosign do in a secure CI/CD pipeline?
A) Scans container images for known CVE vulnerabilities
B) Signs container images cryptographically and verifies signatures to ensure image authenticity
C) Generates SBOM (Software Bill of Materials) for container images
D) Monitors running containers for anomalous behavior at runtime
Show Answer
Correct Answer: B) Signs container images cryptographically and verifies signatures to ensure image authenticity
cosign (part of the Sigstore project) is the standard tool for signing and verifying container images. It supports key-based signing and keyless signing (using OIDC identity), ensuring that only authentic, untampered images are deployed.
- A) Scans container images for known CVE vulnerabilities — Incorrect. Image scanning is done by tools like Trivy, Grype, and Snyk. cosign handles signing and verification, not vulnerability scanning.
- B) Signs container images cryptographically and verifies signatures to ensure image authenticity — Correct. cosign creates a cryptographic signature for an image and can verify that signature at deployment time. This ensures the image was built by a trusted entity and has not been tampered with since signing.
- C) Generates SBOM (Software Bill of Materials) for container images — Incorrect. SBOM generation is done by tools like Syft or Trivy. While cosign can attach SBOMs to images as attestations, it does not generate them.
- D) Monitors running containers for anomalous behavior at runtime — Incorrect. Runtime monitoring is done by tools like Falco and Tetragon. cosign operates in the build and deploy phases, not at runtime.
Topic: Image Assurance & Pipeline Security
Q8: In the SLSA framework, what does Level 3 primarily guarantee?
A) That the build process is documented somewhere in the repository
B) That the build platform is hardened and provenance is non-falsifiable
C) That all container images are scanned for vulnerabilities before deployment
D) That the application passes all unit tests before being signed
Show Answer
Correct Answer: B) That the build platform is hardened and provenance is non-falsifiable
SLSA (Supply-chain Levels for Software Artifacts) Level 3 requires a hardened build platform and non-falsifiable provenance. This means the build system itself is secured against tampering, and the metadata about how the artifact was built cannot be forged.
- A) That the build process is documented somewhere in the repository — Incorrect. This describes SLSA Level 1 at best, which requires the build process to be documented and automated. Level 3 goes far beyond documentation.
- B) That the build platform is hardened and provenance is non-falsifiable — Correct. SLSA Level 3 ensures that the build platform is resistant to compromise, build provenance (metadata about source, builder, and build steps) is generated automatically and cannot be falsified by anyone, including the build system administrators.
- C) That all container images are scanned for vulnerabilities before deployment — Incorrect. SLSA does not address vulnerability scanning. It focuses on supply chain integrity — ensuring artifacts are built from the intended source by a trusted builder.
- D) That the application passes all unit tests before being signed — Incorrect. SLSA does not define testing requirements. It focuses on provenance and build integrity, not functional testing.
Topic: Image Assurance & Pipeline Security
Q9: Which multi-tenancy model would be most appropriate for a healthcare company that must comply with strict data isolation regulations?
A) Namespace per tenant with RBAC and NetworkPolicy
B) Virtual clusters using vCluster
C) Cluster per tenant with dedicated infrastructure
D) A single namespace shared by all tenants with ResourceQuota
Show Answer
Correct Answer: C) Cluster per tenant with dedicated infrastructure
For strict regulatory compliance (such as healthcare, finance, or government), cluster-per-tenant provides the strongest isolation. Each tenant gets completely separate infrastructure — no shared kernel, no shared API server, no shared etcd. This eliminates the risk of cross-tenant data leakage at the infrastructure level.
- A) Namespace per tenant with RBAC and NetworkPolicy — Incorrect. While namespace isolation with RBAC and NetworkPolicy provides reasonable separation for internal teams, it is soft tenancy. Pods still share nodes (and the kernel), cluster-scoped resources are shared, and a kernel exploit could break isolation. This is insufficient for strict compliance requirements.
- B) Virtual clusters using vCluster — Incorrect. vCluster provides better isolation than namespaces (separate API server, CRDs, RBAC), but pods still run on shared host nodes. The underlying kernel is shared, which may not meet strict data isolation regulations.
- C) Cluster per tenant with dedicated infrastructure — Correct. This is the only model that provides complete infrastructure isolation. Each tenant has their own nodes, control plane, and data store. There is no shared kernel, no shared etcd, and no possibility of cross-tenant data access at the infrastructure level. This is the appropriate choice when regulations mandate strict data isolation.
- D) A single namespace shared by all tenants with ResourceQuota — Incorrect. This provides the weakest isolation possible — tenants share the same namespace, and ResourceQuota only limits resource consumption, not access to each other’s data.
Topic: Multi-Tenancy & Isolation
Q10: Which of the following is NOT a namespace-level isolation mechanism in Kubernetes?
A) NetworkPolicy
B) ResourceQuota
C) CustomResourceDefinition (CRD)
D) Pod Security Admission (PSA) labels
Show Answer
Correct Answer: C) CustomResourceDefinition (CRD)
CustomResourceDefinitions are cluster-scoped resources — they are shared across all namespaces. You cannot have different CRD versions or schemas per namespace. This is one of the key limitations of the namespace-per-tenant isolation model.
- A) NetworkPolicy — Incorrect (it IS a namespace-level mechanism). NetworkPolicies are namespaced resources that control pod-to-pod traffic within and between namespaces. They are a core isolation mechanism for multi-tenancy.
- B) ResourceQuota — Incorrect (it IS a namespace-level mechanism). ResourceQuotas are namespaced resources that limit the total resource consumption (CPU, memory, pod count) within a namespace.
- C) CustomResourceDefinition (CRD) — Correct. CRDs are cluster-scoped — when you create a CRD, it defines a new API resource type available across all namespaces. This means all tenants in a namespace-per-tenant model share the same CRDs, which can cause version conflicts and is a limitation of soft tenancy.
- D) Pod Security Admission (PSA) labels — Incorrect (it IS a namespace-level mechanism). PSA labels are applied to namespaces to enforce Pod Security Standards (privileged, baseline, restricted) at the namespace level.
Topic: Multi-Tenancy & Isolation
Self-Assessment
Score Tracker
| Question | Topic | Your Answer | Correct? |
|---|---|---|---|
| Q1 | CIS Kubernetes Benchmark | ||
| Q2 | kube-bench | ||
| Q3 | gVisor vs runc | ||
| Q4 | Kata Containers vs gVisor | ||
| Q5 | Admission controller pipeline | ||
| Q6 | OPA/Gatekeeper vs Kyverno | ||
| Q7 | Image signing (cosign) | ||
| Q8 | SLSA compliance levels | ||
| Q9 | Multi-tenancy models | ||
| Q10 | Namespace isolation |
Your Score: __ / 10
Topic Coverage
| Topic | Questions | Your Score |
|---|---|---|
| Node & OS Hardening | Q1, Q2 | __ / 2 |
| Runtime Security & Sandboxing | Q3, Q4 | __ / 2 |
| Admission Controllers & Policy Engines | Q5, Q6 | __ / 2 |
| Image Assurance & Pipeline Security | Q7, Q8 | __ / 2 |
| Multi-Tenancy & Isolation | Q9, Q10 | __ / 2 |
What to Do Next
Based on your score:
- Scored 8–10: Excellent! You have a strong grasp of Platform Security concepts. Move on to the next chapter.
- Scored 5–7: Review the topics where you got questions wrong. Re-read the relevant sections and pay attention to the comparison tables.
- Scored below 5: Go back through the entire chapter. Focus on the Key Takeaways sections and the comparison tables — they capture the most exam-relevant information.
Topic-Specific Review
| If You Missed | Review This Section |
|---|---|
| Q1, Q2 | Node & OS Hardening — CIS Benchmarks and kube-bench |
| Q3, Q4 | Runtime Security & Sandboxing — gVisor vs Kata comparison |
| Q5, Q6 | Admission Controllers & Policy Engines — Pipeline order and policy engine comparison |
| Q7, Q8 | Image Assurance & Pipeline Security — cosign and SLSA framework |
| Q9, Q10 | Multi-Tenancy & Isolation — Tenancy models and namespace isolation |
Chapter Complete!
You have finished the Platform Security chapter. You now understand:
- How to harden Kubernetes nodes and choose minimal OS distributions
- The role of CIS Benchmarks and kube-bench in security assessment
- How sandboxed runtimes (gVisor, Kata Containers) provide stronger isolation
- The Kubernetes admission controller pipeline and how policy engines enforce rules
- Image scanning, signing, and verification in secure CI/CD pipelines
- Multi-tenancy models and the isolation mechanisms required at each level
Platform Security accounts for 16% of the KCSA exam — the concepts in this chapter are heavily tested.
