KCSA — Cloud Native Security — Practice Questions
Test Your Knowledge
These 10 multiple-choice questions cover all five topics from Chapter 2 — Cloud Native Security Overview. 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
Question 1 — The 4Cs Layers
In the 4Cs of Cloud Native Security, which layer represents the outermost boundary?
- A) Code
- B) Container
- C) Cluster
- D) Cloud
Show Answer
Correct Answer: D) Cloud
| Option | Explanation |
|---|---|
| A) Code | ❌ Code is the innermost layer — your application logic and dependencies |
| B) Container | ❌ Container is the third layer from the outside — between Cluster and Code |
| C) Cluster | ❌ Cluster is the second layer — the Kubernetes cluster itself |
| D) Cloud | ✅ Cloud is the outermost layer — the infrastructure, network, and cloud provider. The 4Cs from outside to inside are: Cloud → Cluster → Container → Code |
The 4Cs are a concentric model where each inner layer depends on the security of the layer below (outside) it. If the Cloud layer is compromised, all inner layers are at risk.
Question 2 — Shared Responsibility Model
In a managed Kubernetes service like Amazon EKS, which of the following is the customer’s responsibility?
- A) Patching the Kubernetes API server
- B) Physical security of the data center
- C) Configuring RBAC policies for the cluster
- D) Managing the etcd database for the control plane
Show Answer
Correct Answer: C) Configuring RBAC policies for the cluster
| Option | Explanation |
|---|---|
| A) Patching the Kubernetes API server | ❌ In managed Kubernetes, the cloud provider handles control plane patching. You initiate upgrades, but they manage the infrastructure |
| B) Physical security of the data center | ❌ Physical security is always the cloud provider’s responsibility |
| C) Configuring RBAC policies | ✅ RBAC configuration is always the customer’s responsibility — the provider doesn’t know what access your users and services need |
| D) Managing the etcd database | ❌ In managed Kubernetes, etcd is managed by the provider — you don’t have direct access to it |
The shared responsibility model means: the provider secures the infrastructure of the cloud; you secure what you put in the cloud. RBAC, network policies, and workload security are always yours.
Question 3 — Image Scanning Tools
Which of the following is an open-source container image vulnerability scanner that is widely used in the cloud native ecosystem?
- A) Terraform
- B) Trivy
- C) Prometheus
- D) Falco
Show Answer
Correct Answer: B) Trivy
| Option | Explanation |
|---|---|
| A) Terraform | ❌ Terraform is an Infrastructure as Code (IaC) tool by HashiCorp — it provisions infrastructure, not scans images |
| B) Trivy | ✅ Trivy (by Aqua Security) is the most popular open-source vulnerability scanner for container images. It can also scan IaC files, filesystems, and generate SBOMs |
| C) Prometheus | ❌ Prometheus is a monitoring and alerting system — it collects metrics, not vulnerability data |
| D) Falco | ❌ Falco is a runtime security tool that detects unexpected behavior in running containers — it’s not an image scanner. (Good to know the difference!) |
Other image scanners include Grype (Anchore), Clair (Red Hat/Quay), and Snyk. But Trivy is the most commonly referenced in KCSA context.
Question 4 — SBOM Formats
A security team needs to generate a Software Bill of Materials (SBOM) for their container images. Which two formats are the industry standard for SBOMs?
- A) JSON and YAML
- B) SPDX and CycloneDX
- C) CSV and XML
- D) OCI and Docker
Show Answer
Correct Answer: B) SPDX and CycloneDX
| Option | Explanation |
|---|---|
| A) JSON and YAML | ❌ JSON and YAML are data serialization formats — they can be used to encode SBOMs, but they are not SBOM standards themselves |
| B) SPDX and CycloneDX | ✅ SPDX (Linux Foundation, ISO standard) and CycloneDX (OWASP) are the two industry-standard SBOM formats. Both can be output in JSON or XML |
| C) CSV and XML | ❌ These are generic data formats, not SBOM standards |
| D) OCI and Docker | ❌ OCI is the container image specification; Docker is the container runtime/platform — neither is an SBOM format |
Tools like Syft and Trivy can generate SBOMs in both SPDX and CycloneDX formats.
Question 5 — SLSA Levels
The SLSA framework defines supply chain security levels. At which SLSA level does the build require a hosted, authenticated build platform with signed provenance?
- A) Level 1
- B) Level 2
- C) Level 3
- D) Level 4
Show Answer
Correct Answer: B) Level 2
| Option | Explanation |
|---|---|
| A) Level 1 | ❌ Level 1 only requires that provenance metadata exists — the build can happen anywhere, and provenance doesn’t need to be signed by a trusted platform |
| B) Level 2 | ✅ Level 2 requires a hosted, authenticated build service (like GitHub Actions) and signed provenance. This prevents tampering with provenance after the build |
| C) Level 3 | ❌ Level 3 adds hardened builds with strong isolation between build jobs — beyond what Level 2 requires |
| D) Level 4 | ❌ Level 4 requires that all dependencies themselves meet SLSA requirements — the most stringent level |
SLSA levels progress from “no guarantees” (Level 0) to “fully verified” (Level 4). Each level adds more trust and verification to the build process.
Question 6 — Supply Chain Attack Examples
The SolarWinds (Sunburst) attack is an example of which type of security compromise?
- A) A brute-force attack on Kubernetes API server credentials
- B) A software supply chain attack that compromised the build system
- C) A DDoS attack against the cloud provider’s infrastructure
- D) A container escape exploit in the Kubernetes runtime
Show Answer
Correct Answer: B) A software supply chain attack that compromised the build system
| Option | Explanation |
|---|---|
| A) Brute-force attack | ❌ SolarWinds was not a credential-guessing attack — it was sophisticated and stealthy |
| B) Supply chain attack | ✅ Attackers compromised SolarWinds’ build system and injected malicious code into the Orion software update. Customers who installed the legitimate-looking update unknowingly deployed the backdoor. This is a textbook supply chain attack |
| C) DDoS attack | ❌ There was no denial-of-service component — the attack was about stealth and data exfiltration |
| D) Container escape | ❌ The attack didn’t involve containers or container runtimes — it targeted the software build and distribution pipeline |
SolarWinds (2020) affected 18,000+ organizations and is one of the most significant supply chain attacks in history. It demonstrates why build system security and attestation (SLSA) matter.
Question 7 — Registry Security
Which Kubernetes imagePullPolicy ensures that the container runtime always downloads the image from the registry, even if a cached version exists on the node?
- A) IfNotPresent
- B) Never
- C) Always
- D) OnUpdate
Show Answer
Correct Answer: C) Always
| Option | Explanation |
|---|---|
| A) IfNotPresent | ❌ IfNotPresent uses the cached image if it’s already on the node — it only pulls if the image is missing |
| B) Never | ❌ Never will never pull the image — it must already be present on the node. Pod creation fails if the image isn’t cached |
| C) Always | ✅ Always forces a pull from the registry every time a Pod starts, regardless of whether the image is cached. This ensures you get the latest version, but adds network latency |
| D) OnUpdate | ❌ OnUpdate is not a valid Kubernetes imagePullPolicy. The valid options are Always, IfNotPresent, and Never |
For production, the recommended practice is to use image digests with IfNotPresent — the digest guarantees content immutability, and caching avoids unnecessary pulls.
Question 8 — Base Image Selection
A security engineer wants to minimize the attack surface of a container running a statically compiled Go binary. Which base image should they choose?
- A) ubuntu:22.04
- B) alpine:3.19
- C) node:20-slim
- D) scratch
Show Answer
Correct Answer: D) scratch
| Option | Explanation |
|---|---|
| A) ubuntu:22.04 | ❌ Ubuntu is a full OS image (~70 MB) with many packages — large attack surface. Appropriate for debugging, not production |
| B) alpine:3.19 | ❌ Alpine is a good choice (~5 MB) and much better than Ubuntu, but it still includes a shell, package manager, and musl libc |
| C) node:20-slim | ❌ This is a Node.js runtime image — unnecessary for a Go binary and includes many components the application doesn’t need |
| D) scratch | ✅ scratch is a completely empty image — 0 bytes. For a statically compiled Go binary (compiled with CGO_ENABLED=0), no runtime libraries are needed. This provides the absolute minimum attack surface — no shell, no package manager, no libraries, nothing for an attacker to use |
The key detail is “statically compiled” — the binary has no external dependencies, so scratch works perfectly. If the binary required shared libraries, you’d need at least distroless or alpine.
Question 9 — Content Trust and Image Signing
Which tool from the Sigstore project is used to sign and verify container images, and supports keyless signing using OIDC identities?
- A) Notary
- B) cosign
- C) GPG
- D) Vault
Show Answer
Correct Answer: B) cosign
| Option | Explanation |
|---|---|
| A) Notary | ❌ Notary is the signing mechanism behind Docker Content Trust (DCT). It’s a CNCF project but requires managing your own signing keys — it does not support keyless signing |
| B) cosign | ✅ cosign is part of the Sigstore project and is the modern standard for container image signing. It supports keyless signing using OIDC identity providers (e.g., Google, GitHub, Microsoft), with signatures recorded in the Rekor transparency log |
| C) GPG | ❌ GPG (GNU Privacy Guard) is a general-purpose encryption and signing tool. While it can sign files, it’s not designed for container image signing workflows |
| D) Vault | ❌ HashiCorp Vault is a secrets management tool. It can manage encryption keys but doesn’t sign container images |
Sigstore includes three key components: cosign (signing), Rekor (transparency log), and Fulcio (certificate authority for keyless signing).
Question 10 — Policy Enforcement
An organization wants to block any Pod that uses an image from an untrusted registry. Which Kubernetes component should they use?
- A) A CronJob that scans running Pods periodically
- B) A Kubernetes NetworkPolicy
- C) An admission controller like OPA Gatekeeper or Kyverno
- D) A kubelet configuration flag
Show Answer
Correct Answer: C) An admission controller like OPA Gatekeeper or Kyverno
| Option | Explanation |
|---|---|
| A) CronJob | ❌ A CronJob that scans running Pods is reactive — the untrusted image has already been deployed. You need to prevent it, not detect it after the fact |
| B) NetworkPolicy | ❌ NetworkPolicies control Pod-to-Pod and Pod-to-external network traffic. They don’t validate which images a Pod uses |
| C) Admission controller | ✅ OPA Gatekeeper and Kyverno are admission controllers that intercept API requests (like Pod creation) and validate them against policies. You can create a policy that rejects any Pod using an image that doesn’t match your trusted registry pattern (e.g., myregistry.io/*) |
| D) kubelet flag | ❌ The kubelet doesn’t have a built-in flag to restrict image registries. Image policy enforcement is handled at the API server level through admission controllers |
Admission controllers are the correct mechanism for preventive policy enforcement in Kubernetes. They evaluate requests before resources are persisted, allowing you to block non-compliant configurations.
Self-Assessment Scoring Guide
Count how many questions you answered correctly before looking at the solutions.
| Score | Rating | Recommendation |
|---|---|---|
| 9–10 | 🟢 Excellent | You have a strong grasp of cloud native security concepts. Move on to Chapter 3 with confidence. |
| 7–8 | 🟡 Good | Solid understanding, but review the topics where you made mistakes before proceeding. |
| 5–6 | 🟠 Fair | Re-read the sub-topics you struggled with. Focus on the tables and key takeaways in each section. |
| 3–4 | 🔴 Needs Work | Go back through the entire chapter. Pay special attention to the 4Cs model, shared responsibility, and supply chain concepts. |
| 0–2 | 🔴 Start Over | Take your time with each topic. Use the analogies and tables to build a mental framework before attempting the quiz again. |
Topic Coverage Map
If you got a question wrong, here’s where to review:
| Question | Topic | Review Link |
|---|---|---|
| Q1 — 4Cs Layers | The 4Cs of Cloud Native Security | Review Topic 1 |
| Q2 — Shared Responsibility | Cloud Provider & Infrastructure Security | Review Topic 2 |
| Q3 — Image Scanning | Container Image Security | Review Topic 3 |
| Q4 — SBOM Formats | Software Supply Chain Security | Review Topic 4 |
| Q5 — SLSA Levels | Software Supply Chain Security | Review Topic 4 |
| Q6 — Supply Chain Attacks | Software Supply Chain Security | Review Topic 4 |
| Q7 — Image Pull Policies | Artifact Repository & Registry Security | Review Topic 5 |
| Q8 — Base Images | Container Image Security | Review Topic 3 |
| Q9 — Content Trust | Container Image Security / Registry Security | Review Topic 3 |
| Q10 — Policy Enforcement | Artifact Repository & Registry Security | Review Topic 5 |
Chapter 2 complete! If you scored 7 or above, you’re ready for the next chapter. If not, revisit the topics above — these concepts form the foundation for everything else in the KCSA exam.
