Linux Foundation KCSA Sample Questions with Explanations

These original sample questions are designed to help you check how the exam topics appear in decision-style prompts. They are not taken from the live exam.

Use these sample questions as a guided self-assessment for Kubernetes and Cloud Native Security Associate (KCSA) topics such as Kubernetes identity, RBAC, pod security, image trust, secrets, network policy, audit evidence, and cloud native security controls. The goal is to practice control selection and elimination, not memorize vocabulary in isolation.

Where these questions fit in the KCSA guide

The sample set below is part of the Linux Foundation / CNCF KCSA guide path:

• Linux Foundation certification hub
• KCSA exam guide
• KCSA cheat sheet
• KCSA study plan
• KCSA FAQ
• KCSA resources
• KCSA glossary

KCSA security decision sample questions

Work through each prompt before opening the explanation. KCSA questions reward a practical security model: least privilege, workload hardening, network isolation, image trust, and evidence-preserving response.

---

Question 1

Topic: Service account permissions

A workload in the payments namespace needs to read one ConfigMap and list pods in the same namespace for service discovery. The platform team wants to avoid expanding access outside that namespace. Which access-control design is strongest?

• A. Bind the workload’s service account to cluster-admin so future discovery features do not need another change.
• B. Use the default service account and rely on application code to avoid unauthorized API calls.
• C. Create a dedicated service account, a namespace-scoped Role with only the required verbs and resources, and a RoleBinding in payments.
• D. Store an administrator kubeconfig as a Secret and mount it into the pod as read-only.

Best answer: C

Explanation: The scenario asks for least privilege inside one namespace. A dedicated service account plus a namespace Role and RoleBinding gives the workload only the API permissions it needs, keeps the permission boundary close to the workload, and avoids granting cluster-wide authority.

Why the other choices are weaker:

• A grants far more privilege than the workload needs and turns a local discovery requirement into a cluster-wide risk.
• B delegates enforcement to application behavior instead of Kubernetes authorization.
• D exposes a high-impact credential to the workload and bypasses normal RBAC scoping.

What this tests: Kubernetes RBAC scope, service accounts, least privilege, and namespace isolation.

Related topics: RBAC; Service accounts; Roles; RoleBindings; Least privilege

---

Question 2

Topic: Image trust before deployment

A team wants to reduce the chance that unreviewed container images reach production. Images must be scanned, signed by the release pipeline, and blocked if the signature or policy check fails. Which control best matches the requirement?

• A. Use an admission control policy that verifies image signatures and required scan metadata before allowing the pod.
• B. Ask developers to include the scanner name in the image tag so reviewers can identify approved images.
• C. Allow all images to run, then rely on runtime monitoring to find suspicious behavior later.
• D. Pull images only from Docker Hub because public repositories are easier to inspect.

Best answer: A

Explanation: The control needs to prevent noncompliant images before they become running workloads. Admission enforcement can check image identity, signature, source, and policy metadata at deploy time, which is stronger than relying on naming conventions or after-the-fact detection.

Why the other choices are weaker:

• B is a convention, not an enforceable control.
• C may detect some issues after deployment, but it does not block untrusted images from starting.
• D confuses public availability with trust and does not prove that an image was reviewed or signed.

What this tests: Image supply-chain controls, admission policy, signatures, scanning, and preventive enforcement.

Related topics: Image security; Admission control; Supply chain; Signatures; Scanning

---

Question 3

Topic: NetworkPolicy isolation

A namespace contains frontend, API, and database pods. The database should accept traffic only from the API pods on the database port, and all other ingress to the database pods should be blocked. Which approach is strongest?

• A. Put the database pods behind a Service and assume the Service name hides them from other pods.
• B. Use a liveness probe on the database pods so unauthorized clients are restarted automatically.
• C. Add a label to the database pods named restricted=true and document that other teams must not connect.
• D. Apply a NetworkPolicy selecting the database pods that allows ingress only from API pods on the required port.

Best answer: D

Explanation: A NetworkPolicy is the Kubernetes-native way to express pod-level traffic rules when the cluster network plugin enforces them. Selecting the database pods and allowing only the API source and port turns the intended trust boundary into an enforceable rule.

Why the other choices are weaker:

• A provides service discovery, not traffic isolation by itself.
• B checks container health; it does not authorize network clients.
• C is metadata and documentation unless a policy engine enforces it.

What this tests: Network segmentation, pod selectors, ingress policy, and the difference between discovery and isolation.

Related topics: NetworkPolicy; Pod selectors; Ingress rules; Zero trust; Workload isolation

---

Question 4

Topic: Secret exposure response

An engineer discovers that an application Secret was accidentally mounted into a pod that did not need it. The pod has been running for several days. What should the team do first?

• A. Delete the namespace immediately and close the incident because the Secret object is gone.
• B. Treat the Secret as exposed, preserve relevant audit and workload evidence, rotate the credential, and remove the unnecessary mount and permission path.
• C. Base64-decode the Secret to confirm whether it was human-readable before taking action.
• D. Move the Secret to a ConfigMap because ConfigMaps are easier to inspect during reviews.

Best answer: B

Explanation: A mounted Secret should be treated as accessible to the workload. The strongest response preserves evidence, rotates the affected credential, removes the exposure path, and then reviews why the pod had access in the first place.

Why the other choices are weaker:

• A can destroy useful evidence and does not guarantee credential rotation.
• C misunderstands the issue; encoding does not determine whether the credential is sensitive.
• D weakens handling because ConfigMaps are not designed for secret material.

What this tests: Secret handling, incident response order, evidence preservation, rotation, and least-privilege cleanup.

Related topics: Secrets; Credential rotation; Audit evidence; Incident response; Workload permissions

Independent study note

Tech Exam Lexicon and IT Mastery are independent study tools. They are not affiliated with, endorsed by, or sponsored by the Linux Foundation, CNCF, or any certification body.