Linux Foundation KCSA Exam Prep Guide: Prep guide for the KCSA Exam
2025 New Preparation Guide of Linux Foundation KCSA Exam
NEW QUESTION # 26
In the event that kube-proxy is in a CrashLoopBackOff state, what impact does it have on the Pods running on the same worker node?
- A. The Pods cannot communicate with other Pods in the cluster.
- B. The Pod cannot mount persistent volumes through CSI drivers.
- C. The Pod's resource utilization increases significantly.
- D. The Pod's security context restrictions cannot be enforced.
Answer: A
Explanation:
* kube-proxy:manages cluster network routing rules (via iptables or IPVS). It enables Pods to communicate with Services and Pods across nodes.
* If kube-proxy fails (CrashLoopBackOff), service IP routing and cluster-wide pod-to-pod networking breaks. Local Pod-to-Pod communication within the same node may still work, butcross-node communication fails.
* Exact extract (Kubernetes Docs - kube-proxy):
* "kube-proxy maintains network rules on nodes. These rules allow network communication to Pods from network sessions inside or outside of the cluster." References:
Kubernetes Docs - kube-proxy: https://kubernetes.io/docs/reference/command-line-tools-reference/kube- proxy/
NEW QUESTION # 27
A container running in a Kubernetes cluster has permission to modify host processes on the underlying node.
What combination of privileges and capabilities is most likely to have led to this privilege escalation?
- A. hostPID and SYS_PTRACE
- B. There is no combination of privileges and capabilities that permits this.
- C. hostNetwork and NET_RAW
- D. hostPath and AUDIT_WRITE
Answer: A
Explanation:
* hostPID:When enabled, the container shares the host's process namespace # container can see and potentially interact with host processes.
* SYS_PTRACE capability:Grants the container the ability to trace, inspect, and modify other processes (e.g., via ptrace).
* Combination of hostPID + SYS_PTRACE allows a container toattach to and modify host processes, which is a direct privilege escalation.
* Other options explained:
* hostPath + AUDIT_WRITE:hostPath exposes filesystem paths but does not inherently allow process modification.
* hostNetwork + NET_RAW:grants raw socket access but only for networking, not host process modification.
* A:Incorrect - such combinationsdo exist(like B).
References:
Kubernetes Docs - Configure a Pod to use hostPID: https://kubernetes.io/docs/tasks/configure-pod-container
/share-process-namespace/
Linux Capabilities man page: https://man7.org/linux/man-pages/man7/capabilities.7.html
NEW QUESTION # 28
A Kubernetes cluster tenant can launch privileged Pods in contravention of therestricted Pod Security Standardmandated for cluster tenants and enforced by the built-inPodSecurity admission controller.
The tenant has full CRUD permissions on the namespace object and the namespaced resources. How did the tenant achieve this?
- A. By using higher-level access credentials obtained reading secrets from another namespace.
- B. By deleting the PodSecurity admission controller deployment running in their namespace.
- C. By tampering with the namespace labels.
- D. The scope of the tenant role means privilege escalation is impossible.
Answer: C
Explanation:
* ThePodSecurity admission controllerenforces Pod Security Standards (Baseline, Restricted, Privileged)based on namespace labels.
* If a tenant has full CRUD on the namespace object, they canmodify the namespace labelsto remove or weaken the restriction (e.g., setting pod-security.kubernetes.io/enforce=privileged).
* This allows privileged Pods to be admitted despite the security policy.
* Incorrect options:
* (A) is false - namespace-level access allows tampering.
* (C) is invalid - PodSecurity admission is not namespace-deployed, it's a cluster-wide admission controller.
* (D) is unrelated - Secrets from other namespaces wouldn't directly bypass PodSecurity enforcement.
References:
Kubernetes Documentation - Pod Security Admission
CNCF Security Whitepaper - Admission control and namespace-level policy enforcement weaknesses.
NEW QUESTION # 29
A container image istrojanizedby an attacker by compromising the build server. Based on the STRIDE threat modeling framework, which threat category best defines this threat?
- A. Repudiation
- B. Denial of Service
- C. Tampering
- D. Spoofing
Answer: C
Explanation:
* In STRIDE,Tamperingis the threat category forunauthorized modification of data or code/artifacts. A trojanized container image is, by definition, an attacker'smodificationof the build output (the image) after compromising the CI/build system-i.e., tampering with the artifact in the software supply chain.
* Why not the others?
* Spoofingis about identity/authentication (e.g., pretending to be someone/something).
* Repudiationis about denying having performed an action without sufficient audit evidence.
* Denial of Servicetargets availability (exhausting resources or making a service unavailable).The scenario explicitly focuses on analtered imageresulting from a compromised build server-this squarely maps toTampering.
Authoritative references (for verification and deeper reading):
* Kubernetes (official docs)- Supply Chain Security (discusses risks such as compromised CI/CD pipelines leading to modified/poisoned images and emphasizes verifying image integrity/signatures).
* Kubernetes Docs#Security#Supply chain securityandSecuring a cluster(sections on image provenance, signing, and verifying artifacts).
* CNCF TAG Security - Cloud Native Security Whitepaper (v2)- Threat modeling in cloud-native and software supply chain risks; describes attackers modifying build outputs (images/artifacts) via CI
/CD compromise as a form oftamperingand prescribes controls (signing, provenance, policy).
* CNCF TAG Security - Software Supply Chain Security Best Practices- Explicitly covers CI/CD compromise leading tomaliciously modified imagesand recommends SLSA, provenance attestation, and signature verification (policy enforcement via admission controls).
* Microsoft STRIDE (canonical reference)- DefinesTamperingasmodifying data or code, which directly fits a trojanized image produced by a compromised build system.
NEW QUESTION # 30
As a Kubernetes and Cloud Native Security Associate, a user can set upaudit loggingin a cluster. What is the risk of logging every event at the fullRequestResponselevel?
- A. Increased storage requirements and potential impact on performance.
- B. Reduced storage requirements and faster performance.
- C. No risk, as it provides the most comprehensive audit trail.
- D. Improved security and easier incident investigation.
Answer: A
Explanation:
* Audit loggingrecords API server requests and responses for security monitoring.
* TheRequestResponse levellogs the full request and response bodies, which can:
* Significantly increasestorage and performance overhead.
* Potentially log sensitive data (including Secrets).
* Therefore, while comprehensive, it introduces risks of performance degradation and excessive log volume.
References:
Kubernetes Documentation - Auditing
CNCF Security Whitepaper - Logging and monitoring: trade-offs between verbosity, storage, and security.
NEW QUESTION # 31
In which order are thevalidating and mutating admission controllersrun while the Kubernetes API server processes a request?
- A. Validating and mutating admission controllers run simultaneously.
- B. Validating admission controllers run before mutating admission controllers.
- C. The order of execution varies and is determined by the cluster configuration.
- D. Mutating admission controllers run before validating admission controllers.
Answer: D
Explanation:
* Theadmission control flowin Kubernetes:
* Mutating admission controllersrun first and can modify incoming requests.
* Validating admission controllersrun after mutations to ensure the final object complies with policies.
* This ensures policies validate thefinal, mutated object.
References:
Kubernetes Documentation - Admission Controllers
CNCF Security Whitepaper - Admission control workflow.
NEW QUESTION # 32
In a Kubernetes environment, what kind of Admission Controller can modify resource manifests when applied to the Kubernetes API to fix misconfigurations automatically?
- A. PodSecurityPolicy
- B. ResourceQuota
- C. ValidatingAdmissionController
- D. MutatingAdmissionController
Answer: D
Explanation:
* Kubernetes Admission Controllers can eithervalidateormutateincoming requests.
* MutatingAdmissionWebhook (Mutating Admission Controller):
* Canmodify or mutate resource manifestsbefore they are persisted in etcd.
* Used for automatic injection of sidecars (e.g., Istio Envoy proxy), setting default values, or fixing misconfigurations.
* ValidatingAdmissionWebhook (Validating Admission Controller):only allows/denies but doesnot change requests.
* PodSecurityPolicy:deprecated; cannot mutate requests.
* ResourceQuota:enforces resource usage, but does not mutate manifests.
Exact Extract:
* "Mutating admission webhooks are invoked first, and can modify objects to enforce defaults.
Validating admission webhooks are invoked second, and can reject requests to enforce invariants.
"
References:
Kubernetes Docs - Admission Controllers: https://kubernetes.io/docs/reference/access-authn-authz
/admission-controllers/
Kubernetes Docs - Admission Webhooks: https://kubernetes.io/docs/reference/access-authn-authz
/extensible-admission-controllers/
NEW QUESTION # 33
What mechanism can I use to block unsigned images from running in my cluster?
- A. Using Pod Security Standards (PSS) to enforce validation of signatures.
- B. Configuring Container Runtime Interface (CRI) to enforce image signing and validation.
- C. Using PodSecurityPolicy (PSP) to enforce image signing and validation.
- D. Enabling Admission Controllers to validate image signatures.
Answer: D
Explanation:
* KubernetesAdmission Controllers(particularlyValidatingAdmissionWebhooks) can be used to enforce policies that validate image signatures.
* This is commonly implemented withtools like Sigstore/cosign, Kyverno, or OPA Gatekeeper.
* PodSecurityPolicy (PSP):deprecated and never supported image signature validation.
* Pod Security Standards (PSS):only apply to pod security fields (privilege, users, host access), not image signatures.
* CRI:while runtimes (containerd, CRI-O) may integrate with signature verification tools, enforcement in Kubernetes is generally done viaAdmission Controllersat the API layer.
Exact extract (Admission Controllers docs):
* "Admission webhooks can be used to enforce custom policies on the objects being admitted." (e.g., validating signatures).
References:
Kubernetes Docs - Admission Controllers: https://kubernetes.io/docs/reference/access-authn-authz
/admission-controllers/
Sigstore Project (cosign): https://sigstore.dev/
Kyverno ImageVerify Policy: https://kyverno.io/policies/pod-security/require-image-verification/
NEW QUESTION # 34
How can a user enforce thePod Security Standardwithout third-party tools?
- A. Use the PodSecurity admission controller.
- B. It is only possible to enforce the Pod Security Standard with additional tools within the cloud native ecosystem.
- C. No additional measures have to be taken to enforce the Pod Security Standard.
- D. Through implementing Kyverno or OPA Policies.
Answer: A
Explanation:
* ThePodSecurity admission controller(built-in as of Kubernetes v1.23+) enforces the Pod Security Standards (Privileged, Baseline, Restricted).
* Enforcement is namespace-scoped and configured throughnamespace labels.
* Incorrect options:
* (A) Kyverno/OPA are external policy tools (useful but not required).
* (C) Not true, PodSecurity admission provides native enforcement.
* (D) Enforcement requires explicit configuration, not automatic.
References:
Kubernetes Documentation - Pod Security Admission
CNCF Security Whitepaper - Policy enforcement and admission control.
NEW QUESTION # 35
What is the difference between gVisor and Firecracker?
- A. gVisor is a user-space kernel that provides isolation and security for containers. At the same time, Firecracker is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads.
- B. gVisor and Firecracker are two names for the same technology, which provides isolation and security for containers.
- C. gVisor and Firecracker are both container runtimes that can be used interchangeably.
- D. gVisor is a lightweight virtualization technology for creating and managing secure, multi-tenant container and function-as-a-service (FaaS) workloads. At the same time, Firecracker is a user-space kernel that provides isolation and security for containers.
Answer: A
Explanation:
* gVisor:
* Google-developed, implemented as auser-space kernelthat intercepts and emulates syscalls made by containers.
* Providesstrong isolationwithout requiring a full VM.
* Official docs: "gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system call interface."
* Source: https://gvisor.dev/docs/
* Firecracker:
* AWS-developed,lightweight virtualization technologybuilt on KVM, used in AWS Lambda and Fargate.
* Optimized for running secure, multi-tenant microVMs (MicroVMs) for containers and FaaS.
* Official docs: "Firecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services."
* Source: https://firecracker-microvm.github.io/
* Key difference:gVisor # syscall interception in userspace kernel (container isolation). Firecracker # lightweight virtualization with microVMs (multi-tenant security).
* Therefore, optionAis correct.
References:
gVisor Docs: https://gvisor.dev/docs/
Firecracker Docs: https://firecracker-microvm.github.io/
NEW QUESTION # 36
On a client machine, what directory (by default) contains sensitive credential information?
- A. $HOME/.config/kubernetes/
- B. /opt/kubernetes/secrets/
- C. $HOME/.kube
- D. /etc/kubernetes/
Answer: C
Explanation:
* Thekubectlclient uses configuration from$HOME/.kube/configby default.
* This file contains: cluster API server endpoint, user certificates, tokens, or kubeconfigs #sensitive credentials.
* Exact extract (Kubernetes Docs - Configure Access to Clusters):
* "By default, kubectl looks for a file named config in the $HOME/.kube directory. This file contains configuration information including user credentials."
* Other options clarified:
* A: /etc/kubernetes/ exists on nodes (control plane) not client machines.
* C: /opt/kubernetes/secrets/ is not a standard path.
* D: $HOME/.config/kubernetes/ is not where kubeconfig is stored by default.
References:
Kubernetes Docs - Configure Access to Clusters: https://kubernetes.io/docs/concepts/configuration/organize- cluster-access-kubeconfig/
NEW QUESTION # 37
What is the purpose of the Supplier Assessments and Reviews control in the NIST 800-53 Rev. 5 set of controls for Supply Chain Risk Management?
- A. To identify potential suppliers for the organization.
- B. To establish contractual agreements with suppliers.
- C. To conduct regular audits of suppliers' financial performance.
- D. To evaluate and monitor existing suppliers for adherence to security requirements.
Answer: D
Explanation:
* In NIST SP 800-53 Rev. 5,SR-6: Supplier Assessments and Reviewsrequires evaluating and monitoring suppliers' security and risk practices.
* Exact extract (NIST SP 800-53 Rev. 5, SR-6):
* "The organization assesses and monitors suppliers to ensure they are meeting the security requirements specified in contracts and agreements."
* This is aboutongoing monitoringof supplier adherence, not financial audits, not contract creation, and not supplier discovery.
References:
NIST SP 800-53 Rev. 5, Control SR-6 (Supplier Assessments and Reviews): https://csrc.nist.gov/publications
/detail/sp/800-53/rev-5/final
NEW QUESTION # 38
Which of the following statements on static Pods is true?
- A. The kubelet schedules static Pods local to its node without going through the kube-scheduler, making tracking and managing them difficult.
- B. The kubelet can run static Pods that span multiple nodes, provided that it has the necessary privileges from the API server.
- C. The kubelet can run a maximum of 5 static Pods on each node.
- D. The kubelet only deploys static Pods when the kube-scheduler is unresponsive.
Answer: A
Explanation:
* Static Podsare managed directly by thekubeleton each node.
* They arenot scheduled by the kube-schedulerand always remain bound to the node where they are defined.
* Exact extract (Kubernetes Docs - Static Pods):
* "Static Pods are managed directly by the kubelet daemon on a specific node, without the API server. They do not go through the Kubernetes scheduler."
* Clarifications:
* A: Static Pods do not span multiple nodes.
* B: No hard limit of 5 Pods per node.
* D: They are not a fallback mechanism; kubelet always manages them regardless of scheduler state.
References:
Kubernetes Docs - Static Pods: https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/
NEW QUESTION # 39
You are responsible for securing thekubeletcomponent in a Kubernetes cluster.
Which of the following statements about kubelet security is correct?
- A. Kubelet runs as a privileged container by default.
- B. Kubelet requires root access to interact with the host system.
- C. Kubelet supports TLS authentication and encryption for secure communication with the API server.
- D. Kubelet does not have any built-in security features.
Answer: C
Explanation:
* Thekubeletis the primary agent that runs on each node in a Kubernetes cluster and communicates with the control plane.
* Kubeletsupports TLS (Transport Layer Security)for both authentication and encryption when interacting with the API server. This is a core security feature that ensures secure node-to-control-plane communication.
* Incorrect options:
* (A) Kubelet does not run as a privileged container by default; it runs as a system process (typically systemd-managed) on the host.
* (B) Kubelet does include built-in security features such asTLS authentication, authorization modes, and read-only vs secured ports.
* (D) While kubelet interacts with the host system (e.g., cgroups, container runtimes), it does not inherently require root access for communication security; RBAC and TLS handle authentication.
References:
Kubernetes Documentation - Kubelet authentication/authorization
CNCF Security Whitepaper - Cluster Component Security (discusses TLS and mutual authentication between kubelet and API server).
NEW QUESTION # 40
What is the reasoning behind considering the Cloud as the trusted computing base of a Kubernetes cluster?
- A. A Kubernetes cluster can only be trusted if the underlying Cloud provider is certified against international standards.
- B. A vulnerability in the Cloud layer has a negligible impact on containers due to Linux isolation mechanisms.
- C. The Cloud enforces security controls at the Kubernetes cluster level, so application developers can focus on applications only.
- D. A Kubernetes cluster can only be as secure as the security posture of its Cloud hosting.
Answer: D
Explanation:
* The4C's of Cloud Native Security(Cloud, Cluster, Container, Code) model starts withCloudas the base layer.
* If the Cloud (infrastructure layer) is compromised, every higher layer (Cluster, Container, Code) inherits that compromise.
* Exact extract (Kubernetes Security Overview):
* "The 4C's of Cloud Native security are Cloud, Clusters, Containers, and Code. You can think of the 4C's as a layered approach. A Kubernetes cluster can only be as secure as the cloud infrastructure it is deployed on."
* This means the cloud is part of thetrusted computing baseof a Kubernetes cluster.
References:
Kubernetes Docs - Security Overview (4C's): https://kubernetes.io/docs/concepts/security/overview/#the-
4cs-of-cloud-native-security
NEW QUESTION # 41
Which security knowledge-base focuses specifically onoffensive tools, techniques, and procedures?
- A. CIS Controls
- B. OWASP Top 10
- C. NIST Cybersecurity Framework
- D. MITRE ATT&CK
Answer: D
Explanation:
* MITRE ATT&CKis a globally recognizedknowledge base of adversary tactics, techniques, and procedures (TTPs). It is focused on describingoffensive behaviorsattackers use.
* Incorrect options:
* (B)OWASP Top 10highlights common application vulnerabilities, not attacker techniques.
* (C)CIS Controlsare defensive best practices, not offensive tools.
* (D)NIST Cybersecurity Frameworkprovides a risk-based defensive framework, not adversary TTPs.
References:
MITRE ATT&CK Framework
CNCF Security Whitepaper - Threat intelligence section: references MITRE ATT&CK for describing attacker behavior.
NEW QUESTION # 42
Why does the defaultbase64 encodingthat Kubernetes applies to the contents of Secret resources provide inadequate protection?
- A. Base64 encoding is vulnerable to brute-force attacks.
- B. Base64 encoding does not encrypt the contents of the Secret, only obfuscates it.
- C. Base64 encoding is not supported by all Secret Stores.
- D. Base64 encoding relies on a shared key which can be easily compromised.
Answer: B
Explanation:
* Kubernetes stores Secret data asbase64-encoded stringsin etcd by default.
* Base64 is not encryption- it is a simple encoding scheme that merelyobfuscatesdata for transport and storage. Anyone with read access to etcd or the Secret manifest can easily decode the value back to plaintext.
* For actual protection, Kubernetes supportsencryption at rest(via encryption providers) and external Secret management (Vault, KMS, etc.).
References:
Kubernetes Documentation - Secrets
CNCF Security Whitepaper - Data protection section: highlights that base64 encoding does not protect data and encryption at rest is recommended.
NEW QUESTION # 43
Which of the following snippets from a RoleBinding correctly associates user bob with Role pod-reader ?
- A. subjects:
- kind: User
name: bob
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io - B. subjects:
- kind: User
name: pod-reader
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: bob
apiGroup: rbac.authorization.k8s.io - C. subjects:
- kind: User
name: bob
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io - D. subjects:
- kind: Group
name: bob
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Answer: A
Explanation:
Kubernetes RBAC usesRoleBindingto grant permissions defined in aRoleto asubject(user, group, or service account) within a namespace. The official example shows binding user jane to Role pod-reader:
"A RoleBinding grants the permissions defined in a Role to a user or set of users...." Example:
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
- Kubernetes docs, RBAC: RoleBinding and ClusterRoleBinding
OptionBmatches this pattern exactly, with name: bob as theUsersubject and roleRef pointing to theRole named pod-reader.
* Aswaps the names (subject is pod-reader, role is bob) # incorrect.
* Creferences aClusterRole, not aRole(the question asks for Role).
* Duses kind: Group even though we need theUserbob.
References:
Kubernetes Docs - Using RBAC Authorization #RoleBinding and ClusterRoleBinding: https://kubernetes.io
/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
NEW QUESTION # 44
......
Latest Questions KCSA Guide to Prepare Free Practice Tests: https://www.bootcamppdf.com/KCSA_exam-dumps.html
KCSA Practice Exam - 62 Unique Questions: https://drive.google.com/open?id=115PiiWZbUghNC21B9RjQ6v6vyPmiC0-b