KCSA Multiple Select — 50 Questions

Question 1

Which THREE mechanisms are used in a zero-trust platform security model for cloud-native applications? (Choose three)

Accepted Answer

Implementing microsegmentation via Kubernetes NetworkPolicies and service mesh auth policies. Option B is correct because zero-trust requires microsegmentation, and Kubernetes NetworkPolicies restrict pod-to-pod traffic at L3/L4 while service mesh authorization policies (e.g., Istio AuthorizationPolicy) enforce identity-based L7 access controls between workloads. Option C is correct because enforcing mutual TLS for all internal service-to-service communications cryptographically verifies both client and server identities, eliminating implicit trust based on network location. Option D is correct because admission webhooks (ValidatingAdmissionWebhook) intercept API server requests before object persistence, allowing policies to reject non-compliant workloads and enforce security baselines at creation time. Option A is incorrect because granting cluster-admin to all service accounts violates least privilege and massively expands the blast radius, the opposite of zero-trust. Option E is incorrect because assuming the internal network is secure and trusting all pods by default is the classic perimeter-trust model that zero-trust explicitly rejects.

Answer

Granting cluster-admin permissions to all application service accounts

Answer

Assuming internal cluster networks are fully secure and trusting all pods by default

Question 2

Which TWO of the following principles are core tenets of cloud native security?

Accepted Answer

Shift-left security, integrating security checks early into the development and CI/CD pipeline.. Option A is correct because shift-left security is a foundational cloud native principle: security checks (SAST, SCA, container image scanning, IaC validation) are integrated early into development and the CI/CD pipeline so vulnerabilities are caught before deployment rather than after. Option D is correct because defense-in-depth is a core tenet of cloud native security, layering overlapping controls across the 4Cs (Cloud, Cluster, Container, Code) so that no single control failure compromises the workload. Option B is wrong because hardcoding administrative credentials in source code violates secrets management and least-privilege practices, creating a critical vulnerability rather than a security principle. Option C is wrong because implicit trust between microservices is an anti-pattern; cloud native security requires zero-trust, mutual authentication (e.g., mTLS) and explicit authorization between services. Option E is wrong because perimeter-only defense assumes a hard outer shell with a soft interior, which fails against lateral movement, insider threats, and compromised workloads in dynamic cloud environments.

Answer

Hardcoding administrative credentials directly into source code for operational simplicity.

Answer

Implicit trust of internal microservices communicating within the same cluster network.

Answer

Perimeter-only defense, relying exclusively on an external corporate firewall.

Question 3

Which TWO of the following files or directories on a control plane node contain critical static pod manifests for core components? (Choose TWO)

Accepted Answer

/etc/kubernetes/manifests/etcd.yaml. Option A is correct because /etc/kubernetes/manifests/etcd.yaml is the static pod manifest that the kubelet on a control plane node watches and instantiates to run the etcd datastore as a static pod. Option E is correct because /etc/kubernetes/manifests/kube-apiserver.yaml is likewise a static pod manifest in the kubelet's configured staticPodPath, used to launch the kube-apiserver as a static pod. Option B is incorrect because /var/lib/kubelet/config.yaml is the kubelet's own configuration file (KubeletConfiguration), not a pod manifest. Option C is incorrect because /etc/default/kube-proxy is a service environment/defaults file for kube-proxy, not a static pod manifest. Option D is incorrect because ~/.kube/config is the client kubeconfig file used by kubectl to authenticate to the cluster, not a static pod manifest.

Answer

/var/lib/kubelet/config.yaml

Answer

/etc/default/kube-proxy

Answer

~/.kube/config

Question 4

Which TWO statements are true regarding Kubernetes NetworkPolicy default behaviors?

Accepted Answer

By default, all pods in a cluster are non-isolated and accept traffic from any source.. Option B is correct because Kubernetes starts with a flat, non-isolated network model: unless a NetworkPolicy selects a pod, that pod is non-isolated and accepts ingress from any source and sends egress to any destination. Option C is correct because once a NetworkPolicy selects a pod and defines ingress rules, the pod becomes isolated for ingress, so only traffic explicitly allowed by those rules (plus established return traffic) is permitted and all other ingress is denied. Option A is wrong because NetworkPolicies are namespaced, additive, and opt-in; installing a cluster does not create any policies or block cross-namespace traffic by default. Option D is wrong because egress is also non-isolated by default—egress is only restricted when a policy selects the pod and includes egress rules (egress isolation). Option E is wrong because NetworkPolicies select pods (via podSelector) within a namespace, not cluster nodes; node-level filtering is handled by other mechanisms such as iptables, nftables, or cloud security groups.

Answer

NetworkPolicies automatically block all traffic across all namespaces upon cluster installation.

Answer

Egress traffic is blocked by default even if no NetworkPolicy is created.

Answer

NetworkPolicies apply to cluster nodes rather than individual pods.

Question 5

An auditor is inspecting a Kubernetes cluster for compliance with the CIS Benchmark for etcd security. Which THREE configurations must be verified for the etcd cluster? (Choose THREE)

Accepted Answer

Peer communication is encrypted using TLS certificates. Option A is correct because the CIS Benchmark for etcd requires that peer (server-to-server) communication be encrypted with TLS certificates to protect cluster traffic between etcd members from eavesdropping or tampering. Option B is correct because enabling client certificate authentication via the --client-cert-auth=true flag ensures that only clients presenting a valid certificate signed by the trusted CA can connect to etcd, which is a core CIS control. Option E is correct because the etcd data directory (typically /var/lib/etcd) must have restrictive permissions such as 700 so that only the etcd process owner can read or write the sensitive key-value store and its WAL files. Option C does not belong because auto-compaction is a maintenance feature and the benchmark does not require it to be permanently disabled. Option D is clearly wrong because exposing etcd directly to the public internet without authentication is a severe misconfiguration that the CIS Benchmark explicitly prohibits.

Answer

etcd auto-compaction is permanently disabled

Answer

etcd is exposed directly on the public internet without authentication

Question 6

Which THREE of the following mechanisms are used by the Kubernetes API server to authorize requests after authentication succeeds? (Choose THREE)

Accepted Answer

RBAC (Role-Based Access Control) authorizer.. The Kubernetes API server supports multiple authorization modes that are evaluated in order after authentication: RBAC (A) grants or denies access based on Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings, making it the standard mechanism for user and service account permissions. The Node authorizer (B) is a specialized authorizer that restricts what kubelets can do, allowing each node to access only the resources (such as its own Pods, Secrets, and ConfigMaps) needed to run its workloads. The Webhook authorizer (E) sends SubjectAccessReview requests to an external HTTP service for authorization decisions, enabling integration with third-party policy engines like OPA/Gatekeeper. Etcd consensus authorizer (C) does not exist; etcd is the backing datastore and has no role in authorizing API requests. Kube-proxy IPVS routing authorizer (D) is fictitious; kube-proxy implements Service load balancing via iptables or IPVS but is not an authorization mechanism.

Answer

Etcd consensus authorizer.

Answer

Kube-proxy IPVS routing authorizer.

Question 7

Which TWO of the following mechanisms help secure the kubelet API from unauthorized access and container inspection? (Choose TWO)

Accepted Answer

Enabling Webhook authorization mode so kubelet requests are validated against API server RBAC.. Option A is correct because setting the kubelet's authorization mode to Webhook makes the kubelet send SubjectAccessReview requests to the API server, so access decisions are evaluated against API server RBAC policies rather than being granted blindly. Option D is correct because disabling anonymous authentication (--anonymous-auth=false) forces unauthenticated requests to the kubelet's HTTPS endpoint to be rejected with 401, preventing anonymous users from querying endpoints like /pods that could expose container details. Option B is wrong because removing TLS certificates would break kubelet authentication and encryption, making the API less secure, not more. Option C is wrong because AlwaysAllow authorizes every request without any check, which is the opposite of securing the kubelet. Option E is wrong because the read-only port 10255 serves unauthenticated, unencrypted data and should be disabled, not enabled.

Answer

Removing all TLS certificates from the kubelet configuration.

Answer

Setting kubelet authorization mode to AlwaysAllow.

Answer

Enabling the kubelet read-only port 10255.

Question 8

A security team is implementing Pod Security Standards (restricted, baseline, privileged) across namespaces. Which THREE controls are enforced under the Restricted Pod Security profile? (Choose THREE)

Accepted Answer

Requiring all capabilities to be dropped except NET_BIND_SERVICE or dropping all (capabilities.drop: [ALL]). The Restricted Pod Security profile is the most stringent of the three Pod Security Standards and enforces hardening controls on every container. Option A is correct because Restricted requires that Linux capabilities be dropped, either by dropping ALL (capabilities.drop: [ALL]) or by dropping all except NET_BIND_SERVICE, preventing containers from retaining dangerous privileges. Option B is correct because Restricted mandates runAsNonRoot: true, ensuring containers do not run as UID 0 (root), which limits the impact of a container compromise. Option C is correct because Restricted requires allowPrivilegeEscalation: false, blocking processes from gaining more privileges than their parent (for example via setuid binaries or file capabilities). Options D and E are incorrect because allowing host network/host PID namespaces and enabling privileged mode are explicitly forbidden by the Restricted profile (and privileged mode is only permitted under the Privileged profile), so they do not represent enforced Restricted controls.

Answer

Allowing unrestricted use of the host network and host PID namespaces

Answer

Enabling privileged mode for all standard workloads

Question 9

Which THREE of the following are official Pod Security Standard enforcement levels recognized by Kubernetes?

Accepted Answer

baseline. The three official Pod Security Standard enforcement levels defined by Kubernetes are privileged, baseline, and restricted. Option A (baseline) is correct because it is the minimally restrictive policy that prevents known privilege escalations while allowing default pod configurations. Option C (privileged) is correct because it is the unrestricted policy allowing the widest possible permissions, intended for trusted workloads such as system-level components. Option D (restricted) is correct because it is the most restrictive policy, enforcing current hardening best practices like requiring non-root users and dropping capabilities. Options B (isolated) and E (secure) are not recognized enforcement levels; they are not part of the Kubernetes Pod Security Standards, which only define privileged, baseline, and restricted.

Answer

isolated

Answer

secure

Question 10

In the context of Kubernetes API server security, which TWO mechanisms are used to authenticate incoming API requests?

Accepted Answer

X509 Client Certificates presented during TLS handshakes. Option C is correct because the Kubernetes API server supports X509 client certificate authentication, where the client presents a certificate during the mutual TLS handshake and the certificate's Common Name (CN) is used as the username and Organization (O) as group membership. Option E is correct because bearer tokens, including ServiceAccount JWT tokens mounted into pods, are passed in the Authorization: Bearer <token> header and validated by the API server via the TokenReview API or configured token authenticators. The other options do not belong: NetworkPolicy egress CIDR blocks (A) control pod-level network traffic, not API request authentication; PersistentVolume claim capacity metadata (B) is storage resource information; and container image pull secrets (D) are registry credentials used by kubelet to pull images, not API server authentication mechanisms.

Answer

Kubernetes NetworkPolicy egress CIDR blocks

Answer

PersistentVolume claim capacity metadata

Answer

Container image pull secrets stored in private registries

Question 11

A compliance team is adopting the NIST SP 800-190 standard to secure their container image pipeline. Which THREE practices are recommended in this framework for managing container images? (Choose THREE)

Accepted Answer

Employ trusted base images from verified publishers. NIST SP 800-190 Section 3.1 (Image Vulnerabilities) recommends using trusted base images from verified publishers (A) to reduce the risk of inheriting vulnerabilities or malicious code from untrusted sources, since every layer of a container image becomes part of the running container. The framework also calls for vulnerability scanning throughout the image lifecycle, including in the CI/CD pipeline and the registry (B), so that known CVEs are detected before deployment and continuously re-evaluated as new vulnerabilities are disclosed. Additionally, NIST SP 800-190 recommends digitally signing images and verifying those signatures (E) to establish provenance and integrity, ensuring that only images from authorized sources are deployed and that images have not been tampered with. Option C is incorrect because storing plaintext passwords in Dockerfile ENV directives exposes secrets in image layers and metadata, directly violating NIST guidance on protecting secrets. Option D is incorrect because relying exclusively on public unverified base images increases supply-chain risk and contradicts the recommendation to use trusted, verified image sources.

Answer

Store plaintext passwords directly inside Dockerfile ENV directives

Answer

Rely exclusively on public unverified base images to speed up development

Question 12

Which TWO types of selectors can be used within a Kubernetes NetworkPolicy ingress rule to specify allowed traffic sources?

Accepted Answer

namespaceSelector. In a Kubernetes NetworkPolicy ingress rule, the from field accepts three selector-based peer types: ipBlock, namespaceSelector, and podSelector. Option B (namespaceSelector) is correct because it selects entire namespaces by their labels, allowing traffic from all pods in matching namespaces (or, when combined with a podSelector in the same from element, only matching pods in matching namespaces). Option E (podSelector) is correct because it selects pods by their labels within the policy's own namespace, defining which pods may send traffic to the selected pods. Option A (serviceSelector) is incorrect because NetworkPolicy peers are never defined by Service; Services are not valid peer selectors in the API. Option C (ingressSelector) is incorrect because no such selector type exists in the NetworkPolicy spec. Option D (nodeSelector) is incorrect because NetworkPolicy operates at the pod/namespace/IP level and cannot select peers by node labels.

Answer

serviceSelector

Answer

ingressSelector

Answer

nodeSelector

Question 13

An attacker manages to compromise a low-privilege pod inside a Kubernetes cluster and attempts to escalate privileges or pivot to other cluster components. Which THREE of the following misconfigurations or weaknesses would significantly aid the attacker's lateral movement or privilege escalation? (Choose THREE)

Accepted Answer

The pod's ServiceAccount has a ClusterRoleBinding granting cluster-admin permissions.. Option C is correct because a ClusterRoleBinding that binds the pod's ServiceAccount to the cluster-admin ClusterRole grants that pod full, unrestricted permissions across every namespace and resource in the cluster, so a compromised pod can immediately read secrets, create privileged workloads, and take over the control plane. Option D is correct because hostNetwork: true places the pod in the node's network namespace, letting the attacker sniff node-level traffic (including kubelet, API server, and other pods' unencrypted communications) and reach services bound to the node's interfaces, which materially aids lateral movement. Option E is correct because if the instance metadata service (169.254.169.254) is reachable without IMDSv2 session-token enforcement, a compromised pod can retrieve the node's IAM credentials and use them against the cloud API, pivoting from the cluster into the underlying cloud infrastructure. Option A does not belong because KMS-backed etcd encryption at rest protects data on disk and does nothing to help an attacker already executing inside a pod. Option B does not belong because the Restricted Pod Security Standard blocks privileged settings such as hostNetwork and hostPath, so it actually hinders rather than aids escalation.

Answer

Etcd is encrypted at rest using a customer-managed KMS encryption provider.

Answer

The cluster uses a properly configured PodSecurityStandard of Restricted across all namespaces.

Question 14

Which TWO actions are core tenets of the "Shift-Left" security philosophy in cloud-native compliance? (Choose TWO)

Accepted Answer

Scanning infrastructure-as-code (IaC) templates for misconfigurations before deployment. Option B is correct because Shift-Left security means identifying misconfigurations in infrastructure-as-code (IaC) templates such as Terraform, CloudFormation, or Kubernetes manifests during development, before any resources are provisioned, so issues are caught early when they are cheapest and safest to fix. Option D is correct because embedding vulnerability scanning (for example SAST, SCA, or container image scanning) directly into the CI/CD pipeline enforces automated security gates on every commit or build, which is the operational core of shifting security left into the development lifecycle. Option A is wrong because disabling automated security tooling removes the very guardrails Shift-Left depends on and increases risk rather than reducing it. Option C is wrong because auditing only after a production breach is a reactive, right-side-of-development approach, the opposite of Shift-Left. Option E is wrong because relying solely on manual post-release code reviews is late, non-automated, and does not prevent defects from reaching production.

Answer

Disabling all automated security tooling to speed up commits

Answer

Waiting until a production breach occurs to audit logs

Answer

Relying entirely on manual code reviews post-release

Question 15

Which THREE of the following actions can compromise the security of the Kubernetes control plane if left unmitigated? (Choose THREE)

Accepted Answer

Granting wildcard cluster-admin permissions to untrusted service accounts.. Option A is correct because binding a service account to a ClusterRole with wildcard verbs/resources (e.g., via ClusterRoleBinding to cluster-admin) lets any pod using that account read secrets, create privileged workloads, and effectively take over the control plane. Option B is correct because enabling anonymous authentication (--anonymous-auth=true) on the API server or kubelet allows unauthenticated requests to reach endpoints, and combined with permissive authorization it exposes cluster data and node operations to anyone who can reach the port. Option E is correct because the API server's insecure port (--insecure-port) serves requests over plain HTTP with no authentication or authorization, so any network-reachable client can issue privileged API calls. Option C is not a compromise: Webhook authorization mode delegates decisions to the API server's SubjectAccessReview, which is the recommended secure mode for kubelet. Option D is not a compromise: encrypting etcd at rest with a valid key protects secret data and is a security best practice, not a risk.

Answer

Configuring kubelet authorization mode to Webhook.

Answer

Enabling etcd encryption at rest with a valid key.

Question 16

When designing a defense-in-depth strategy across the 4Cs, which THREE independent security controls can be applied at different layers? (Choose THREE)

Accepted Answer

Container image signing with Cosign and admission verification for Container. Option B is correct because container image signing with Cosign plus an admission controller that verifies signatures enforces supply-chain integrity at the Container layer, ensuring only trusted, unmodified images are admitted to the cluster. Option C is correct because Kubernetes NetworkPolicies provide Cluster-layer microsegmentation, restricting pod-to-pod traffic to explicitly allowed flows and limiting lateral movement if a workload is compromised. Option E is correct because SAST scanning in the CI/CD pipeline addresses the Code layer, detecting insecure code patterns and vulnerabilities before artifacts are built or deployed. Option A is not a valid independent control since relying solely on a cloud provider's default network security group creates a single point of failure and violates defense-in-depth. Option D is not a security control at all; granting all developers cluster-admin permissions violates least privilege and dramatically expands the attack surface.

Answer

Relying solely on the cloud provider's default network security group for all protection

Answer

Granting all developers cluster-admin permissions for operational speed

Question 17

Which THREE advanced container runtime or image security features help prevent container breakout exploits? (Choose three)

Accepted Answer

Using sandboxed container runtimes (such as Kata Containers or gVisor) for strong isolation. Option A is correct because sandboxed runtimes such as Kata Containers and gVisor insert a lightweight VM or user-space kernel boundary between the container and the host kernel, so a kernel exploit inside the container does not directly compromise the host. Option D is correct because restrictive Seccomp profiles filter the syscall table and block sensitive calls (for example, ptrace, mount, or unshare) that container breakout exploits rely on to escape isolation. Option E is correct because dropping dangerous Linux capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE removes the privileges needed to mount filesystems, craft raw packets, or inject into host processes, which are common breakout primitives. Option B is wrong because privileged mode disables isolation and grants all capabilities plus host device access, dramatically increasing breakout risk. Option C is wrong because mounting host /proc and /sys read-write exposes host kernel and process information and allows tampering, which weakens rather than strengthens isolation.

Answer

Running all containers in privileged mode

Answer

Mounting host /proc and /sys directories in read-write mode

Question 18

Which THREE security controls can be enforced by admission webhook policy engines (like Kyverno or OPA Gatekeeper) regarding container images? (Choose three)

Accepted Answer

Verifying cryptographic image signatures using tools like Cosign. Admission webhook policy engines such as Kyverno and OPA Gatekeeper intercept Kubernetes API admission requests and can validate container image attributes before a workload is persisted. Option A is correct because policies can invoke signature verification (e.g., Cosign keyless or key-based attestations) and reject pods whose images lack a valid cryptographic signature. Option B is correct because these engines can enforce registry allow-lists, rejecting any image reference whose registry does not match the approved enterprise registries. Option E is correct because policies can query vulnerability scan results (e.g., from Trivy or Grype reports) and block deployment of images containing unmitigated high-severity CVEs. Option C is not applicable because admission webhooks only validate Kubernetes API objects; they cannot modify kernel modules on worker nodes. Option D is likewise outside their scope, since restarting unhealthy pods is a runtime remediation handled by controllers like the kubelet or ReplicaSet, not by an admission policy.

Answer

Automatically updating kernel modules on the underlying worker node

Answer

Manually restarting unhealthy pods across worker nodes

Question 19

An enterprise security auditor is reviewing Kubernetes API server admission control configurations for compliance. Which THREE admission plugins or mechanisms are critical for enforcing security policies at admission time? (Choose THREE)

Accepted Answer

ValidatingAdmissionWebhook. ValidatingAdmissionWebhook (A) is correct because it lets the API server call external webhook endpoints to validate requests against custom security policies before persistence, enabling enforcement of organization-specific compliance rules. PodSecurity (B) is correct because it enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level via admission, blocking pods that violate the configured security profile. NodeRestriction (D) is correct because it is an admission plugin that limits kubelet credentials so a node can only modify its own Node object and Pods bound to it, preventing a compromised node from escalating cluster-wide. InsecureServing (C) is not an admission plugin but a deprecated API server serving option for unauthenticated/insecure port access, and AlwaysAllow (E) is an authorization mode that permits all requests, so neither enforces security policy at admission time.

Answer

InsecureServing

Answer

AlwaysAllow

Question 20

Which TWO mechanisms are used by Kubernetes admission controllers to enforce security policies during the API request lifecycle?

Accepted Answer

Validating admission webhooks can reject object definitions that violate security standards.. Validating admission webhooks (A) are invoked during the admission phase of the API request lifecycle and can evaluate an object against security policies, returning a denial that causes the API server to reject the request, which is exactly how policies such as Pod Security Standards or custom constraints are enforced. Mutating admission webhooks (D) run before validating webhooks and can modify the incoming request payload, for example injecting a securityContext, defaulting runAsNonRoot, or applying seccomp/AppArmor profiles so that objects comply with security defaults before persistence. The remaining options are incorrect: kubelet (B) pulls and runs containers on nodes but does not perform image security audits as an admission mechanism, etcd (C) is only a key-value store and does not execute validation scripts or strip RBAC rules, and kube-proxy (E) implements Service load balancing at Layers 3/4 and never inspects Layer 7 API payloads.

Answer

kubelet automatically runs security audits on all container images prior to pull.

Answer

etcd executes consensus validation scripts to strip unauthorized RBAC rules.

Answer

kube-proxy inspects network payloads at Layer 7 to block unauthorized API requests.