Question 1

What information is stored in etcd?

Accepted Answer

etcdis Kubernetes??key-value storeforcluster state.
 Stores: ConfigMaps, Secrets, Pod definitions, Deployments, RBAC policies, and metadata.
 Exact extract (Kubernetes Docs – etcd):
 ??etcd is a consistent and highly-available key-value store used as Kubernetes?? backing store for all cluster data.??
 Clarifications:
 B: Logs/metrics are handled by logging/monitoring solutions, not etcd.
 C: Secrets may be stored here but encoded in base64, not specifically "usernames/passwords" as primary use.
 D: Persistent Volumes are external storage, not stored in etcd.
References:
Kubernetes Docs — etcd: https://kubernetes.io/docs/concepts/overview/components/#etcd

Question 2

Which standard approach to security is augmented by the 4C??s of Cloud Native security?

Accepted Answer

The 4C??s model (Cloud, Cluster, Container, Code) is presented in the official Kubernetes documentation as alayeredmodel that explicitly maps todefense-indepth.
 Exact extracts from Kubernetes docs(security overview):
 ??The 4C??s of Cloud Native Security are Cloud, Clusters, Containers, and Code.??
 ??You can think of the 4C??s asa layered approach to security; applying security measures at each layer reduces risk.??
 ??This layered approach is commonly known asdefense in depth.??
References:
Kubernetes Docs — Security overview #The 4C??s of Cloud Native Security: https://kubernetes.io/docs
/concepts/security/overview/#the-4cs-of-cloud-native-security

Question 3

Which information does a user need to verify a signed container image?

Accepted Answer

Container image signing (e.g., withcosign, Notary v2) uses asymmetric cryptography.
 Verification process:
 Retrieve theimage??s digital signature.
 Validate the signature with thepublic keyof the signer.
 Exact extract (Sigstore Cosign Docs):

/KCSA-exam/ (60 Q&As)
 ??Verification of an image requires the signature and the signer??s public key. The signature proves authenticity and integrity.??
 Why others are wrong:
 A & B: The private key is only used by the signer, never shared.
 C: The hash alone cannot prove authenticity without the digital signature.
References:
Sigstore Cosign Docs: https://docs.sigstore.dev/cosign/overview

Question 4

In Kubernetes, what isPublic Key Infrastructure (PKI)used for?

Accepted Answer

Kubernetes usesPKI certificatesextensively to secure communication between control plane components (API server, etcd, kube-scheduler, kube-controllermanager) and with kubelets.
Certificates enablemutual TLS authentication and encryptionacross components.
PKI does not handle scaling, networking, or monitoring.
References:
Kubernetes Documentation – Certificates
CNCF Security Whitepaper – Cluster communication security and the role of PKI.

Question 5

In a Kubernetes environment, what kind of Admission Controller can modify resource manifests when applied to the Kubernetes API to fix misconfigurations
automatically?

Accepted Answer

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/

Question 6

Why does the defaultbase64 encodingthat Kubernetes applies to the contents of Secret resources provide inadequate protection?

Accepted Answer

Kubernetes stores Secret data asbase64-encoded stringsin etcd by default.

/KCSA-exam/ (60 Q&As)
 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., ]

Question 7

You want to minimize security issues in running Kubernetes Pods. Which of the following actions can help achieve this goal?

Accepted Answer

Pod Security Standards (PSS):
Kubernetes providesPod Security Admission (PSA)to enforce security controls based on policies.
Official extract: ??Pod Security Standards define different isolation levels for Pods. The standards focus on restricting what Pods can do and what they can
access.??
The three standard profiles are:
Privileged: unrestricted (not recommended).
Baseline: minimal restrictions.
Restricted: highly restricted, enforcing least privilege.
Why option C is correct:
Applying Pod Security Standards in YAML ensures Pods adhere tobest practiceslike:
No root user.
Restricted host access.
No privilege escalation.
Seccomp/AppArmor profiles.
This directly minimizes security risks.
Why others are wrong:
A:Sharing sensitive data increases risk of exposure.
B:Running with elevated privileges contradicts least privilege principle.
D:Random Pod names donotcontribute to security.
[References:, Kubernetes Docs — Pod Security Standards: https://kubernetes.io/docs/concepts/security/pod-security-standards/, Kubernetes Docs — Pod Security
Admission: https://kubernetes.io/docs/concepts/security/pod-security-admission/, ]

Question 8

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?

Accepted Answer

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/, ]

Question 9

When using a cloud provider's managed Kubernetes service, who is responsible for maintaining the etcd cluster?

Accepted Answer

Inmanaged Kubernetes services(EKS, GKE, AKS), the control plane is operated by thecloud provider.
This includesetcd, API server, controller manager, scheduler.
Users manageworker nodes(in some models) and workloads, but not the control plane.
Exact extract (GKE Docs):
"The control plane, including the API server and etcd database, is managed and maintained by Google."
Similarly forEKSandAKS, etcd is fully managed by the provider.
[References:, GKE Architecture: https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-architecture, EKS Architecture:

/KCSA-exam/ (60 Q&As)
https://docs.aws.amazon.com/eks/latest/userguide/eks-architecture.html, AKS Docs: https://learn.microsoft.com/en-us/azure/aks/concepts-clusters-workloads, ]

Question 10

An attacker has access to the network segment that the cluster is on.
What happens when a compromised Pod attempts to connect to the API server?

Accepted Answer

By default,Pods can connect to the API server(since ServiceAccount tokens are mounted).
However, whether they succeed in acting depends on:
Network Policies(may block egress).
RBAC(controls permissions).
Exact extract (Kubernetes Docs – API Access):
??Pods authenticate to the API server using the service account token mounted into the Pod.
Authorization is then enforced by RBAC. NetworkPolicies may further restrict access.??
Clarifications:
A: No default automatic isolation.
B: Not always unrestricted; policies may apply.
D: Pods get minimal default privileges, not automatic elevation.
References:
Kubernetes Docs — API Access to Pods: https://kubernetes.io/docs/concepts/security/service-accounts/ Kubernetes Docs — Network Policies:
https://kubernetes.io/docs/concepts/services-networking/networkpolicies/